Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)
draft-ietf-ecrit-dhc-lost-discovery-03

[Ballot 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/

[Ballot 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...

[Ballot 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.

[Ballot 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.

[Ballot discuss]
First, a process problem: We have had a model for DHCP option
development that involves an effort in the WG that is interested
in the functionality (in this case ECRIT) but also review by DHC
WG. This is accomplished through simultaneous WGLCs in both WGs.
In my search of DHC WG archives, there's nothing on this document.
We need that review, and I would suggest starting a WGLC in the
DHC WG now, followed possibly by discussion in Philadelphia meeting
(if needed) so that we can get the review done but do not lose much
time.

I apologize for not catching this earlier. The DHC chairs and me
try to remind WG chairs and the iesg of this policy on a regular
basis, maybe we should send another reminder. The DHC WG also has
an early warning system review team, not sure if this caught their
attention. Or have I missed some discussion? If review has happened,
I have no problem.

Technical content:

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

[Ballot discuss]
First, a process problem: We have had a model for DHCP option
development that involves an effort in the WG that is interested
in the functionality (in this case ECRIT) but also review by DHC
WG. This is accomplished through simultaneous WGLCs in both WGs.
In my search of DHC WG archives, there's nothing on this document.
We need that review, and I would suggest starting a WGLC in the
DHC WG now, followed possibly by discussion in Philadelphia meeting
(if needed) so that we can get the review done but do not lose much
time.

I apologize for not catching this earlier. The DHC chairs and me
try to remind WG chairs and the iesg of this policy on a regular
basis, maybe we should send another reminder. The DHC WG also has
an early warning system review team, not sure if this caught their
attention. Or have I missed some discussion? If review has happened,
I have no problem.

[Ballot discuss]
This mechanism does not seem to support internationalized domain names.  First, there is
no discussion about converting IDNs to and from ACE format.  Secondly, the size limitations
(consistent with RFC 1035) seem inadequate for IDNs.  63 octets doesn't seem like enough for
a typical label ACE-encoded label.  I also worry about the 255 octet limit for the domain name.

[Ballot discuss]
There are values that need to be assigned by IANA, but it appears that
  the document is not consistent about about the manner in which the
  assigned values should be inserted in the document.  For example, as
  pointd out in the Gen-ART Review by Vijay Gurbani, the code in
  Figure 1 is "TBD", but the text right underneath the figure refers
  to the code as "(TBD1)".  Consistent symbolic substitution is needed
  to avoid errors.

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
assignment in the "DHCP and BOOTP PARAMETERS" registry located at
http://www.iana.org/assignments/bootp-dhcp-parameters
sub-registry "BOOTP Vendor Extensions and DHCP Options"

Data
Tag Name Length Meaning Reference
--- ---- ------ ------- ---------
[TBD] OPTION_V4_LOST N LoST server Domain Name
[RFC-ecrit-dhc-lost-discovery-02]


Action 2:

Upon approval of this document, the IANA will make the following
assignment in the "DHCPv6 and DHCPv6 options" registry located at
http://www.iana.org/assignments/dhcpv6-parameters
sub-registry "DHCP Option Codes"

Value Description Reference
----- ---------------------- ---------
[TBD2] OPTION_V6_LOST [RFC-ecrit-dhc-lost-discovery-02]


We understand the above to be the only IANA Actions for this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?


Document Shepherd is Marc Linsner (marc.linsner@cisco.com).
The document is ready for publications and I have reviewed the document
personally.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The DHCP-based LoST discovery is part of the LoST specification. It provides
a possibility for the end host to learn LoST servers that are closer to the
client. Such a LoST server placement provides benefits in disaster
situations with intermittent network connectivity regarding the resiliency
of emergency service communication.

The document has been reviewed by ECRIT and DHC working group members. The
document experienced two WGLCs (scheduled
together with the LoST specification) on the ECRIT and the DHC WG.

The two WGLCs were posted on 14 February 2007 and on 15 August 2007.



(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

There are no concerns with the document.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no concerns.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is consensus behind this document.



(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The document does not contain nits.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].


The document has references split into normative and informative references.




(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

An IANA consideration section exists and is consistent with the rest of the
document.



(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such sections in the document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents.



Document Announcement Write-Up for draft-ietf-ecrit-dhc-lost-discovery-02

Technical Summary

The Location-to-Service Translation Protocol (LoST) describes an XML-
based protocol for mapping service identifiers and geospatial or
civic location information to service contact Uniform Resource
Locators (URLs). LoST servers can be located anywhere but a
placement closer to the end host, e.g., in the access network, is
desirable. Such a LoST server placement provides benefits in
disaster situations with intermittent network connectivity regarding
the resiliency of emergency service communication.

This document describes how a LoST client can discover a LoST server
using the Dynamic Host Configuration Protocol (DHCP).


Working Group Summary

There is consensus in the WG to publish this document.

Document Quality

Although the LoST specification has been implemented there are
no implementations known for the DHCP-based discovery
procedure. From a deployment point of view it is likely
that the DNS-based discovery procedure will be available
before this document will see a deployment.

Personnel

Marc Linsner is the document shepherd for this document.