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:
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
