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

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 18 Feb 2012 14:25:10 -0500

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.

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"?
     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.

Nits/editorial comments: