[Ndn-interest] any comments on naming convention?
Marc.Mosko at parc.com
Marc.Mosko at parc.com
Mon Sep 15 13:58:16 PDT 2014
Thank you for sharing that document. I have a few comments.
In CCNx 1.0, a name component is the tuple (type, length, value), carried everywhere. The “type” is not just a namespace encoding, it is considered an integral part of the name component, as a command-marker would be. We do not ignore component types in forwarding. yes, the URI representation gets a bit messier as each name component is “type=value” (we prefer to call it a “label=value”, but that’s just wording).
I do not think you can separate the name component type from forwarding. If two name component types have different meanings, then they need to be forwarded individually. They need to be included in other things, like selectors processing too. Otherwise, how could one exclude a name component with one type but not another?
Using a separate name component to indicate the type again falls back to convention to indicate semantics. I could write a program that puts in a binary value that just happens to decode to “_v” without intending the next component to be a version. Yes, if you specifically type the “_v” component differently than a binary component, then it is not ambiguous, but now you are using name component type to indicate semantics, so why not just use it everywhere instead of the _v and _s, etc.? In the document you forwarded, I noticed someone make this observation, and the response was along the lines of “this is true for any convention” and “use unusual markers” does not seem like a good justification. Putting the type in a TLV “T” for all name components is not just a convention, it is a mandatory, standardized system. For any “unusual marker” one will always be able to find some binary name component that aliases it.
In some discussions we had at PARC about this, my position was that if you are using a naming convention, it should be explicit somewhere and standardized, like a URI scheme. If an application cannot place a “_v” binary component followed by a number in the 4th to last name component (e.g. /foo/_v/10/_s/20), then that really needs to be explicit so we know if an application is conforming to the convention. If the convention is mandatory, then its a standard and should be explicit somewhere in the packet. I do not subscribe to the notion that “the application” will know — the point of having data on a network is such that many applications could share the data, like a photo.
It seems to me that there is little difference between coordinating the TLV type space for name components and the marker names (“_v”, etc.) in a naming convention. Everyone still needs to agree with them. I guess I’m disagreeing with the sentiment quoted here.
> can come into being organically based on agreement within a particular application community, and if
> technical governance structures are needed to create standards that resolve ambiguity or promote
> interoperability, they can arise - but all of this dialogue happens around namespaces, not the weird
> intersection of typespaces and namespaces.
In regards to the name component “namespace” becoming bifurcated from the global type namespace, in CCNx 1.0 we promote a non-global TLV system. It just seems inevitable that we will end up there. Our main reason is this. Once a company “A” gets assigned a TLV type, say in an Interest Guider for proprietary QoS, they will not want to coordinate with the rest of the world for the TLVs they put inside that assigned TLV container. They will want to have control over the inside of their container. Then company “B” gets another assigned TLV number for an Interest Guider for a flow id, and they start putting their own TLVs in that container. If someone wants to support both of those proprietary types, then they will end up with context-dependent types. Either that, or each company must coordinate every TLV they put in a proprietary type.
In CCNx 1.0 we specifically set aside a block of “application dependent” types so applications or application communities could use non-standardized types. Typically, one would have a name component that identified the application or conventions being used prior to those types. If at some point they were considered generally useful to the community as a whole they could be promoted to standardized types. In a sense, one could think about this like context-dependent types in a name, their meaning coming from a “left” name component that identifies the application or protocol being used.
On 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:
>> 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. :)
>>> 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.
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
> <A Few Arguments for Explicit Segment and Version Naming 4.pdf>_______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
More information about the Ndn-interest