[Ndn-interest] any comments on naming convention?

[Tai-Lin Chu]

>So - just to poke at this a bit - who's the "we" here, and whose pain and
complexity?  Application developers, network architects, equipment mfrs,
or ?  (And do they agree?)

I think "we" are the people who question whether there exists a better
naming convention. The current naming convention does not receive
enough comments from those who you described.

I don't agree with "type explosion". But before I say my reason, I
hope someone can bring up Van's reason why this type explosion
happens(maybe he got his point too).



On Mon, Sep 15, 2014 at 12:12 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>
> Hi all,
>
>
> On 9/15/14, 11:33 AM, "Mark Stapp" <mjs at cisco.com> wrote:
>
>>interesting:
>>
>>On 9/15/14 1:41 PM, Tai-Lin Chu wrote:
>>> I think for naming convention, the community should come up with a
>>> solution that people "want" to use.
>>
>>I think that we should work toward specifying something that does what
>>we've learned (over several years of work) we need to do, and that does
>>not add any additional pain or unnecessary complexity.
>
> So - just to poke at this a bit - who's the "we" here, and whose pain and
> complexity?  Application developers, network architects, equipment mfrs,
> or ?  (And do they agree?) As you know, NDN takes an application-motivated
> approach to the development and evaluation of the architecture, and NSF
> has asked for this explicitly in their most recent RFP.  If we could
> discuss some pros/cons from that perspective - perhaps via quick examples
> or case studies that have led you to this conclusion, it would be helpful
> (in my mind) to this current discussion.
>
> Attached are some previously shared thoughts on segmenting and versioning
> conventions related to this discussion, and some arguments against types,
> after page 2. Though Junxiao's marker type is an interesting new twist, I
> am so far unconvinced that it addresses all of the concerns in this doc.
>
> Note - these were not originally intended for a public discussion, at
> least not in this form, so be kind. :) I can also imagine that some of the
> discussion could be dismissed via "drop selectors and add manifests" but
> would suggest addressing the spirit of argument in light of the current
> NDN architecture instead.
>
> (Unfortunately I am on the road so not sure I can keep up with the
> discussion, but wanted to inject some other perspectives. :)
>
> Thanks,
> Jeff
>
>>
>>>
>>> Could you describe the ambiguous case? I think I know what you mean by
>>> ambiguous, but I just want to make sure. (I remembered someone from
>>> cisco mentioned this in ndncomm 2014.)
>>>
>>> To avoid ambiguity, I will start from name component tlvs and allocate
>>> more types for different meanings.
>>>
>>> 8 = regular name component
>>> <type> = segmented name component
>>>
>>
>>yes, this is the approach I favor. typed name components allow us to
>>identify the 'infrastucture' data in name components, while allowing us
>>to set aside some number space for application-defined components. code
>>that just wants to compare names or identify component boundaries needs
>>to be able to treat the components as 'opaque', of course.
>>
>>Thanks,
>>Mark
>>_______________________________________________
>>Ndn-interest mailing list
>>Ndn-interest at lists.cs.ucla.edu
>>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>