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

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

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.)

(Robert Sparks; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (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.

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (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?

(Dan Romascanu; former steering group member) (was Discuss) No Objection

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

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ()
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection (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.

(Stewart Bryant; former steering group member) No Objection

No Objection (2010-10-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree with the discusses already posted, but no additional issues.

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info