Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
RFC 6155

Note: This ballot was opened for revision 06 and is now closed.

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2010-10-27 for -)
No email
send info
I agree with the discusses already posted, but no additional issues.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-10-26)
No email
send info
Section 3.6., paragraph 4:
>    A domain name does not always correspond to a single IP address or
>    host.  If this is the case, a domain name is not a suitable
>    identifier.

  Right. Domain names are also clearly context specific (split-horizon
  DNS, etc.)

(Adrian Farrel) No Objection

Comment (2010-12-02)
No email
send info
I support Dan's Discuss.
draft-ietf-georiv-arch is (somewhat) careful in its definition of "device" and I do not think it means "network interface".
Although it is true that network interfaces do not currently wander independent of devices (and if they did, they might need to be independently trackable) some care is needed in the wording to make the association clear.

(Russ Housley) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2010-11-15)
No email
send info
2.2.  Identifier Format and Protocol Details

   If the LIS requires an identifier that is not provided in the
   request, the desired identifiers MAY be identified in the HELD error
   response, using the "requiredIdentifiers" element.  This element
   contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
   that identify the identifier elements required by the LIS.  Namespace
   prefix bindings for the qualified names are taken from document
   context.  Figure 2 shows an example error indicating that the
   requester needs to include a MAC address (Section 3.2) if the request
   is to succeed.

Is there an IANA registry for these?


5.  Security Considerations

   All HELD requests containing identity MUST be authenticated by the
   LIS.  How authentication is accomplished and what assurances are
   desired is a matter for policy.

Is this description sufficient for providing interoperability?

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2010-10-26)
No email
send info
I support the issues raised by Alexey in his DISCUSS.

(Peter Saint-Andre) No Objection

(Sean Turner) No Objection

Comment (2010-12-02)
No email
send info
I support Tim's discuss.

The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then it's not suitable. Should this be repeated in the other sections? e.g., if the URI doesn't specifically refer to a particular device, then a URI is not a suitable identifier.  I see the general guidance in Section 2- just curious why only FQDN got this special treatment.

In Section 3.7, I says:

Each identifier contains a string of decimal digits with a length as specified.

But, the imsi and min identifier descriptions don't include length constraints.  Seems like they all should (they're in the schema I guess just copy the values forward to the descriptions).

Please remove "Note that" from the last paragraph of the Security considerations.  Normative language should not be in a note.