TFTP Server Address Option for DHCPv4
RFC 5859

[Ballot discuss]
There was a long email thread where we tracked down existing behaviors and based on that I have updated my discuss to.



As the existing devices only doing TFTP, this need to be clearly restricted to TFTP only. Future designs for HTTP would cause interoperability problems if they used this same option.

The majority of existing code base go in sequential order (not random) so need to make clear that is the correct behavior. The draft basically says this now but probably want that the client MUST try the servers in sequential order but it is not required to try all of them and can use a few as it wants. Need specification of timers for failure and retry. Need to clarity what happens after all the servers have been tried and failed. When does it start trying again. If we don't specify lower bounds on this, we run into congestion control issues.

Discuss how this is secured by signing the configuration files. Remove security approaches that not used by any existing stuff.

Option 150 needs to take priority over option 66. Not doing this will cause unpredictable behavior for people trying to deploy a system.

[Ballot comment]
Point out this won't work for IPv6. Suggest what IPv6 phones should do instead.

Explain the array type in DHCP results in same on the wire messages as the list formatting.

There a lot of SHOULDs in this document that make no sense and need to be cleaned up. In every case where you have a SHOULD, explain in what cases the device might not want to do this. Take for example the client SHOULD include the 150 in the parameter list of the request. How can this be a SHOULD, if the client does not do it, there's will it get the data back? If the client receives an option where the length is not divisible by n, there are basically two choices, ignore it or use the part it can. Just pick on and say MUST or ignore or not. Similarly with priority ordering.

[Ballot discuss]
There are a few issues where I don't think this document represents what many devices implement and we need to refine it with a few topics.

1) If the 150 option takes priority over others

2) If the devices should try the first address or a random address in the list.

3) If singed config files are used in practices and can recommended as a way to address security concerns

4) if the address represents protocols other than tftp

I'm glad to help coordinate with Cisco folks to resolve what exists today in devices I am aware of.

[Ballot discuss]
1. The Abstract and maybe also the title must make clear that the option documented by this document refers to IPv4-only configuration servers.

2. I support the issues raised by Cullen in his DISCUSS and COMMENT.

[Ballot discuss]
The security considerations text should mention that TFTP itself
provides no authentication or access control mechanisms, so even if
DHCP messages would be authenticated (not very likely), downloading
the configuration would still be insecure (unless some object-level
security mechanisms would be used).

[Ballot comment]
Can someone point me at a hardware devices that implement this but does not implement DNS? Without being aware of any, I find the the justification a bit strange. 

Would help to have a normative reference to 3942

[Ballot discuss]
I unfortunatley left this fairly late to review as it was informational and looked like it would be vary quick to review. Take these points as a start of a conversation - I have not got a chance to go and read all the background email on this so apologize in advance if these topics have already been discussed.

I think this spec needs to say, for devices that support 150, which takes presences 66 or 150. If different phones do different things, it becomes very hard to run a site that uses both. You end up in a catch 22 where some thing want it one way and other things want it another and you try and guess the range of mac addresses used by devices to get it to work. Unless there is a good reason not to pick one, just say what takes precedence on the client.

Saying that the first address is preferred does not work for some deployments that want to use the multiple tftp server for scaling. Imagine a deployment where you are providing services to many IP phones in a large city. When the city looses power and restarts, it puts a huge load on the tftp servers and you need to distribute the load across all of them not force it onto the first one. It seems that the client should randomly select a server out of the list. I realize that the server could randomize the ordering of the lists but I don't think that is what is done in todays deployments. I realize we are trying to document what's out there and there are clients that likely pick the first, but I think there are also ones that load balance like this and it seems picking that path results in less interoperability problems that the other selection.

I think the security section would be improved by saying something along lines of - due to the ability to hijack these, and the RECOMMENDED approach is for the download configuration files need to have some object level security where the client can validate that the config file was signed by an appropriate entity. The use of a shared secret for DHCP is very unlikely because nearly any situation where a pre established shared secrete could be used, there would be no need to auto discover the configuration server and one could just directly configure the address of the configuration server and skip all this DHCP stuff.

[Ballot discuss]
I have not seen a response to the Gen-ART Review by Pete McCann.
  After providing a lot of context in the review, Pete says that he is
  a bit worried that a standard option won't be used with a standard
  downloading protocol.  It might be better for interoperability if
  the downloading protocol remains specified as part of the option.
  Also, Pete thinks it is a bit strange to specify that a particular
  option is named after one application that might be run on a host.
  Please repond to these points.

IANA Last Call comments:

IANA has questions about the actions requested by
draft-raj-dhc-tftp-addr-option-04.txt.

We understand that we should make the following change in the
"BOOTP Vendor Extensions and DHCP Options" registry at
http://www.iana.org/assignments/bootp-dhcp-parameters:

OLD:

150 TFTP server address (Tentatively Assigned - 2005-06-23)

NEW:

150 150 VoIP Configuration Server Address [RFC-raj-dhc-tftp-addr-option-04]

Should we also remove the following registrations?

150 Etherboot
150 GRUB configuration path name

Submission questions for "VoIP Configuration Server Address Option"


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

John Jason Brzozowski, dhc WG co-chair
I have reviewed the document and I believe it is ready for
publication.

(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 document was reviewed by key members of the dhc WG as well as non-dhc WG members.
At this time there are not concerns about the breadth and depth of the review conducted
for this document.  This document is ready for publication.

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

No.  This document describes a DHCP option used to configure to configure VoIP type devices.
This document leverages common, well-known constructs typical to DHCP and as such an extended
review is not required.

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

I have no specific concerns about this document.

Also consider that RFC3942 governs the use of the DHCP option defined
in this document.

The primary areas of discussion included discussion surrounding this option compared to
existing options or fields used in DHCP to address similar requirements, specifically
SiAddr.  After discussion the consensus amongst the reviewers was this document should move
forward as it does in fact address valid requirements.  Further, there was also a discussion
pertaining to the naming of this document, to avoid confusion it was intentionally left as it
stands today.

To the best of my knowledge, there are no IPR disclosures on file with
the IETF related to this document.

(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 was good level of WG involvement in the development leading up to
the final version of this document.  There was strong consensus from a few
individuals.  There were no objections in response to the WG last
call.  Although only a few individuals responded to the WG last call,
I believe the WG as a whole understands and agrees with the document.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise 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?

I have verified that the document meets the requirements of
ID-Checklist.html.  There are no formal reviews required.

(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 references are split into normative and informative.  There are no
problematic normative references.

(1.i)  Has the Document Shepherd verified that the document IANA
      consideration 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 Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists.  It specifies reservations
that are appropriate for the clearly identified existing registries.

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

Not applicable.

(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.  The approval
      announcement contains the following sections:

      Technical Summary
  Relevant content can frequently be found in the abstract
  and/or introduction of the document.  If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

  "This memo documents existing usage for the "VoIP Configuration Server
  Address Option" (previously known as the "TFTP Server IP Address
  Option").  The option number currently in use is 150.  This memo
  documents the current usage of the option in agreement with
  [RFC3942], which declares that any pre-existing usages of option
  numbers in the range 128 - 223 should be documented and the working
  group will try to officially assign those numbers to those options."

      Working Group Summary
  Was there anything in WG process that is worth noting?  For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There was nothing controversial about this document.

      Document Quality
  Are there existing implementations of the protocol?  Have a
  significant number of vendors indicated their plan to
  implement the specification?  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?  If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)?  In the case of a Media Type
  review, on what date was the request posted?


It is believed that at least one DHCP server and client implementation support the
option specified in this document.  Further, it is believed that to some extent this
option is in use in some deployments of VoIP devices.

Beyond was was performed with key members of the dhc WG no special reviews were
performed or required.


      Personnel
  Who is the Document Shepherd for this document?  Who is the
  Responsible Area Director? Is an IANA expert needed?

Shepherd: John Jason Brzozowski
AD:      Jari Arkko
IANA:    N/A