Subject: [Ietf-behave] -behave-nat-udp-05: PROTO questionnaire and write-up

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Apr 2006 16:16:06 -0700 (PDT)

draft-ietf-behave-nat-udp has been submitted to the IESG for their review.

Per the procedures described in draft-ietf-proto-wgchair-doc-shepherding-06,
a copy of the PROTO questionnaire and write-up are below.  

You can track the progress of draft-ietf-behave-nat-udp at:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1268
2&rfc_flag=0

-Dan Wing

-----

PROTO questionnaire for:  draft-ietf-behave-nat-udp-05.txt
prepared by:  Dan Wing, dwing@xxxxxxxxx, 14-Apr-2005

WG chair shepherd: dwing@xxxxxxxxx

   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?

Yes.

   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?

Yes.  No concern about depth or breadth of reviews.

   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.)?

No.

   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.

Careful consideration should be made regarding the timers and the port
ranges of the timers.  This has been a difficult issue within the working
group to resolve.

   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?

It represents strong consensus within the working group, with no known
dissenters.

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

No.

   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.

Yes.

(I did note that http://tools.ietf.org/tools/idnits says the document
is fine, except for missing RFC2119 boilerplate.  However, the document
does have RFC2119 boilerplate at the beginning of its section 3.)

   1.h) Has the document split its references into normative and
        informative?

Yes.

        Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?

There is only one normative reference, and it is to an RFC.

        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 publicatioin).  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.

-----

Protocol write-up for draft-ietf-behave-nat-udp-05.txt
by Dan Wing, dwing@xxxxxxxxx, 14-Apr-2005

Technical Summary

   This document defines basic terminology for describing different
   types of NAT behavior when handling Unicast UDP and also defines a
   set of requirements that would allow many applications, such as
   multimedia communications or on-line gaming, to work consistently.
   Developing NATs that meet this set of requirements will greatly
   increase the likelihood that these applications will function
   properly.

Working Group Summary

   There has been some disagreement with default NAT binding timers
   in general, and specific concern around handling of specific
   applications such as DNS which don't need 5 minute timeouts

Protocol Quality

   No new protocols are defined in this document, rather, this
   document describes how NATs should function when NATting UDP
   packets.

   The WG is confident that this document captures the behevior
   of NATs typically sold to consumers.

-----