Hardware and Network Address Options for TFTP
draft-evans-tftp-address-options-00
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
00 | (System) | Notify list changed from N7DR@arrisi.com, szeng@cisco.com,rdroms@cisco.com to rdroms@cisco.com |
2006-07-10
|
00 | (System) | Ballot writeup text was added |
2006-07-10
|
00 | (System) | Last call text was added |
2006-07-10
|
00 | (System) | Ballot approval text was added |
2006-07-10
|
00 | (System) | State Changes to Dead from AD is watching by system |
2006-07-10
|
00 | (System) | Document has expired |
2006-05-11
|
00 | Magnus Westerlund | State Changes to AD is watching from AD Evaluation by Magnus Westerlund |
2006-05-11
|
00 | Magnus Westerlund | I have now further considered and discussed this document with some of my AD colleges. My conclusion is that I can't sponsor the publication of … I have now further considered and discussed this document with some of my AD colleges. My conclusion is that I can't sponsor the publication of this document in its current state and intended status. The main issue is the considerations about further development of TFTP present in RFC 3617. Also as this options makes TFTP even more vulnerable from a security perspective I think there would be need for a proper security solution. Due to that TFTP's other flaws this is not in the IETF interest to do. I do recommend the transition to a better transport protocol. |
2006-04-24
|
00 | Magnus Westerlund | State Changes to AD Evaluation from Publication Requested::External Party by Magnus Westerlund |
2006-04-24
|
00 | Magnus Westerlund | This document is an individual submission. Thus the PROTO writeup was done by the authors. 1.a) Have the chairs personally reviewed this version … This document is an individual submission. Thus the PROTO writeup was done by the authors. 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Which chair is the WG Chair Shepherd for this document? The authors have reviewed the document and believe that it is ready to forward. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The document has been explicitly reviewed by representatives of the companies that would be expected to first implement it. It has been available for review by a much larger community. We believe that this is adequate. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, internationalization, XML, etc.)? We have no concerns about these matters. This is a simple document, and was written in the context of a work item for a security group. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. We have no concerns about these matters. 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? The members of the group that desired creation of this document unanimously support this document. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. (It should be separate email because this questionnaire will be entered into the tracker). There has been no indication of dissatisfaction with this document. 1.g) Have the chairs verified that the document checks out against all the ID nits? (see http://www.ietf.org/ID-Checklist.html). Boilerplate checks are not enough; this check needs to be thorough. # No text beyond the 72nd column of a line. This is especially important for diagrams and code, which the RFC Editor may not be able to trivially reformat to fall within the margins. OK # Must be ragged right OK # No hyphenation for line-breaks OK # No footnotes OK # ASCII-only, no control characters (other than CR, NL and FF). OK # Do not number the "Status of Memo" or "Abstract" sections OK # Do not add a numbered reference in the I-D boilerplate to RFC 3978 or RFC 3979 (or to RFC 2026, RFC 3667 or RFC 3668 for older documents). If you do, it makes it harder for the RFC editor to process the document when they strip off the I-D boilerplate. OK # Reasonably well formatted for readibility and clarity OK # Use network byte order in diagrams (see [I-D.rfc-editor-rfc2223bis] (Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors," July 2004.) section 3.4) OK 1.h) Has the document split its references into normative and informative? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? The RFC Editor will not publish an RFC with normative references to IDs (will delay the publication until all such IDs are also ready for RFC publication). If the normative references are behind, what is the strategy for their completion? On a related matter, are there normative references that are downward references, as described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? Listing these supports the Area Director in the Last Call downref procedure specified in RFC 3967. All references are normative. There are no normative references to IDs. No normative references are behind. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality 1.j) Please provide such a write-up. Recent examples can be found in the "Action" announcements for approved documents. Technical Summary: Under some circumstances, a TFTP server may need to have knowledge of addressing information for the client that may be lost due to a request traversing a proxy or a router. The options defined in this document allows the client and/or a proxy to insert this information into the request. Working Group Summary: There are no specific notes concerning the process in which this document was produced Protocol Quality: 1. Are there existing implementations of the protocol? None known as of this writing. The first implementations will probably occur this summer. However, the implementation is trivial. 2. Have a significant number of vendors indicated they plan to implement the specification? All vendors of Cable Modem Termination Devices will implement this specification. At the very least, this means: Cisco, Motorola, ARRIS, Juniper, BigBand Networks. 3. Are there any reviewers that merit special mention as having done a thorough review (i.e., that resulted in important changes or a conclusion that the document had no substantive issues)? This document has been available for review by a community of > 250 cable operators and equipment vendors, and none has raised substantive issues. 1.k) Note: * The relevant information for the technical summary 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. * For the Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points, decisions where consensus was particularly rough, etc. * For the protocol quality, useful information includes: + Are there existing implementations of the protocol? + Have a significant number of vendors indicated they plan to implement the specification? + Are there any reviewers that merit special mention as having done a thorough review (i.e., that resulted in important changes or a conclusion that the document had no substantive issues)? > > I would also like to know where you have solicited feedback on this > > document. > > In detail: the document has been explicitly reviewed by the CableLabs security focus team, which contains representatives of the following equipment vendors: Cisco, ARRIS, Motorola, BigBand Networks, Broadcom, Texas Instruments, as well as several large cable operators. This document has also been included as a portion of a specification that has been circulated under NDA to more than 250 cable equipment vendors. It has also been circulated to all major US cable operators and many foreign cable operators. No negative comments have been received. |
2006-04-21
|
00 | Magnus Westerlund | State Changes to Publication Requested::External Party from Publication Requested by Magnus Westerlund |
2006-04-21
|
00 | Magnus Westerlund | Awaiting PROTO writeup from authors. Also awaiting applicability statement update of draft. |
2006-04-21
|
00 | Magnus Westerlund | State Change Notice email list have been change to N7DR@arrisi.com, szeng@cisco.com,rdroms@cisco.com from N7DR@arrisi.com, szeng@cisco.com |
2006-04-20
|
00 | Magnus Westerlund | Intended Status has been changed to Proposed Standard from None |
2006-04-20
|
00 | Magnus Westerlund | Draft Added by Magnus Westerlund in state Publication Requested |
2005-12-08
|
00 | (System) | New version available: draft-evans-tftp-address-options-00.txt |