Re: [Gen-art] [core] Review: draft-ietf-core-link-format-11

Joel,

Thanks for the review. See comments regarding your suggestions in-ine:

On Feb 18, 2012, at 9:25 PM, Joel M. Halpern wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments you may receive.
> 
> Document: draft-ietf-core-link-format-11
>    CoRE Link Format
> Reviewer: Joel M. Halpern
> Review Date: 18-Feb 2012
> IETF LC End Date: 28-Feb-2012
> IESG Telechat date: N/A
> 
> Summary: This document is almost ready for publication as a proposed standard.
> 
> Major issues:
>    What is the registration / collision avoidance strategy for resource type (rt) and interface description (if) values?  They are both defined as opaque strings which can happen to be URIs.  So there seems to be potential for collision.

There is definitely a possibility for collision for those two attributes, especially as there will be a mix of specifications that define specific values to be used, and developers using their own values. Currently while those are being defined in CoRE drafts we can avoid collisions, but when other WGs or SDOs start defining them...

We have deliberated on the idea of defining registries for rt= and if= values, but it has not been clear if that should be done in this document. Recently several CoRE drafts have been written that do specify well-known values for those fields, so it starts to become obvious that those registries would be useful. If I understand right, your recommendation would be that we define those registries in the IANA section of this document? I would be in favor of doing that.

> Minor issues:
>    Would it be sensible, in the introduction, when the well-known URI is first introduced, to refer to it as a "well-known relative URI"?

Sure, will fix.

>    Should this document register a resource type (rt) and interface description (if) for the server resource manager itself?  The text refers to using multicast to find resources, with filtering based on rt and if.  (This would, I think, be defined in section 4, and registered in the IANA considerations section?)  Presumably all devices would support the interface, which is why a resource type for the master server would seem useful.

I am not sure what you mean by "master server" here. Maybe you are referring to something like a resource directory defined in [http://tools.ietf.org/id/draft-shelby-core-resource-directory-02.txt]? Yes, that specification does specify a well-known rt= value "core-rd" with which any node can discovery the location of a resource directory.

Thanks,
Zach

> 
> Nits/editorial comments:
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297