Skip to main content

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