[Ndn-interest] any comments on naming convention?

Ignacio.Solis at parc.com Ignacio.Solis at parc.com
Mon Sep 15 19:45:59 PDT 2014


Just as a clarification to the document, the current CCNx (1.0) uses typed
components, we abandoned command markers.

I read the document more throughly. According to page 8, the disadvantages
to (#1) typed name components are:
- “type explosion” (still unsure where that is coming from),
- defining a few components,
- defining a way to add more,
- define a URI representation,
- defining what to do with unknown types.

Aren’t all of these a problem with all options?

The disadvantages to (#2) extra components:
- aliasing (components can be ambiguous)

The disadvantages to (#3) command markers:
- aliasing  (components can be ambiguous)


Isn’t this a good case for typed components?

To get rid of aliasing you’re basically going to require extra components
or markers before every other component, effectively using types.


Nacho


--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
+1(650)812-4458
Ignacio.Solis at parc.com





On 9/15/14, 6:11 PM, "Burke, Jeff" <jburke at remap.ucla.edu> wrote:

>Nacho, 
>I guess I'm not following most of these questions - there are some musings
>(at least) in the document that try to sketch an alternate perspective to
>typed components, and most of these questions are covered in some way. I
>should qualify that they just represent my attempt to provide another side
>to the argument. 
>Jeff
>
>On 9/15/14, 1:22 PM, "Ignacio.Solis at parc.com" <Ignacio.Solis at parc.com>
>wrote:
>
>>What is this ³type explosion² the document is talking about?
>>
>>Whether it is a type for a component, a command marker, or a marker
>>component, there needs to be some agreement on what the meaning of
>>type/marker is.  If not, then it would just be a regular name component
>>for a  single application.  So, like Dave says, there needs to be some
>>registry or overall agreement in some form.
>>
>>Wouldn¹t there be the same number of types as command markers?  So you
>>would basically have ³command marker explosion²? Or is there something
>>special about command markers?
>>
>>
>>What we are discussing here (I hope) is, what is the best way for
>>applications to talk about specific meaning of components. (Versions,
>>Segments, etc).  There are multiple ways to do this.
>>
>>- Typed named components are explicit and unambiguous. They always exist.
>>They can be the Generic type or some special type (like Version).  The
>>allow arbitrary binary data in a component.
>>- Command markers may or may not exist. This leads to aliasing if you
>>allow arbitrary binary data in a component.  If you don¹t allow arbitrary
>>binary data in a component, then to solve aliasing you need to escape
>>potentially ambiguous data.
>>- Command components suffer from the same fate.
>>
>>If your data structures do not use component types, then you¹ll have to
>>escape binary data to have a consistent type/marker system.
>>
>>Can somebody describe the disadvantage they see of using typed named
>>components?  Is it the potential requirement to register? Is it the
>>limited type space? Is it the extra bytes?
>>
>>What is the benefit of command markers over typed named components?
>>
>>
>>
>>
>>Is it possible for applications to follow a convention that doesn¹t
>>create
>>aliasing? Yes, you could start creating rules that don¹t allow binary
>>data
>>of some value in some components if followed by some components, etc.  So
>>now, any application that wants to put binary data has to check it¹s own
>>data to make sure it doesn¹t break other apps.
>>
>>Sometimes it seems to me that people assume that these names will be
>>human
>>readable most of the time. Where is this assumption coming from?  For all
>>we know everything will be binary.
>>
>>Taking my convert-to-CCN hat off for a second I think that it¹s in your
>>best interest to use component markers, that way if you keep using prefix
>>matching at least you can request  /foo/bar/v_/* and at least force the
>>network to get you something that is a version. Having said that, I still
>>think you¹ll end up doing exact matching soon, but in the meantime might
>>as well take advantage of it.
>>
>>Nacho
>>
>>
>>
>>
>>On 9/15/14, 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
>>>
>>
>>--
>>Nacho (Ignacio) Solis
>>Protocol Architect
>>Principal Scientist
>>Palo Alto Research Center (PARC)
>>+1(650)812-4458
>>Ignacio.Solis at parc.com
>>
>
>
>_______________________________________________
>Ndn-interest mailing list
>Ndn-interest at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest





More information about the Ndn-interest mailing list