Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-held-identity-extensions-06
Yes
(Robert Sparks)
No Objection
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 06 and is now closed.
Robert Sparks Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-12-02)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2010-11-15)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2010-10-26)
Unknown
I support the issues raised by Alexey in his DISCUSS.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2010-10-26)
Unknown
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.)
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2010-12-02)
Unknown
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 IESG member
No Objection
No Objection
(2010-10-27)
Unknown
I agree with the discusses already posted, but no additional issues.
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown