[Ndn-interest] any comments on naming convention?

[Burke, Jeff]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: A Few Arguments for Explicit Segment and Version Naming 4.pdf
Type: application/pdf
Size: 224524 bytes
Desc: A Few Arguments for Explicit Segment and Version Naming 4.pdf
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140915/9f1c6191/attachment.pdf>