Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)
RFC 5223
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Lars Eggert No Objection
(Jon Peterson; former steering group member) Yes
(Chris Newman; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
Like David Hankins, I wondered about the expression "Only onee domain name MUST be present ...". I would suggest a rewrite to "Exactly one domain MUST be present ...", possibly followed by the explanation that anything after the last zero by should be ignored. By the way, I was confused about the level of DHC WG review, because (a) the writeup did not say anything about it and (2) the mails about the WGLC on DHC WG did not have the draft or even WG name on the title. I found the mails eventually, but... Christian Vogt's review: This document defines a DHCP-based mechanism for LoST server discovery. LoST server discovery is unspecified by the LoST protocol, but is an important complement to it in scenarios where client pre-configuration is infeasible. LoST server discover in this document is realized through new DHCPv4/v6 options that carry a LoST server's domain name. Summary: The document is well-written and -- after a revision addressing the comments below -- will be ready for publication. (1) Specification clarity Authors should clarify how the domain name encoding specified in section 3 fits into the encoding of the DHCPv4 option specified in section 4. Specifically: - How does the length fields in the domain name encoding relate to the length field in the DHCPv4 option? Clarification is needed that the latter is the length of the entire domain name encoding, whereas the former is the length of a single domain name label. - It should be stated that the values s1, s2, s3, ... in the DHCPv4 option represent the domain name labels in the domain name encoding. (2) Relationship to LoST Protocol Security The security considerations of this document do not address how the specified LoST server discovery procedure supports the security mechanisms suggested for the LoST protocol. E.g., one way to protect LoST is via TLS. This requires knowledge of a LoST server's public key in addition to its domain name or IP address. The discovery mechanism described in this document cannot provide both: The public key would have to be either pre-configured into a host, or be verifiable via a trusted 3rd party. The security considerations should therefore state that, to bootstrap LoST in a secure manner, client pre-configuration or further infrastructure may be necessary besides DHCP. (3) Editorial comments: - 2nd paragraph in section 1: s/LoST server DHCP/LoST server, DHCP/ - Move 3rd-to-last paragraph in section 5 to section 4 because it is DHCPv4-specific. - 1st paragraph in section 5: s/This document defines/This section defines/ - 1st paragraph in section 5: s/DHCPv6 options/DHCPv6 option/
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection