[Ecrit] [Fwd: DISCUSS and COMMENT: draft-ietf-ecrit-dhc-lost-discovery]

FYI

-------- Original Message --------
Subject: 	DISCUSS and COMMENT: draft-ietf-ecrit-dhc-lost-discovery
Date: 	Thu, 21 Feb 2008 08:26:21 -0800 (PST)
From: 	Jari Arkko <jari.arkko@piuha.net>
To: 	iesg@ietf.org
CC: 	christian.vogt@ericsson.com,ecrit-chairs@tools.ietf.org, 
draft-ietf-ecrit-dhc-lost-discovery@tools.ietf.org

Discuss:
Section 5 (DHCPv6) talks about how DHCPv4 clients can request options.
Is this text in the right place? Section 4 seems the correct place.

David Hankins' comments on Section 3 limit "254" have not been addressed.
David sent his comments on the DHC WG list on April 27, 2007.

Comment:
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/

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
http://www.ietf.org/mailman/listinfo/ecrit