State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
draft-ietf-behave-p2p-state-06

[Ballot comment]
NITS:

Might want to define SOHO

TODO - check meaning lie

I don't think it is correct to say Skype uses central public server for registration (at least the type of registration you mean here)

In section 5.2 , mention audio conferencing. I think this is a bad example in that it often was media relay. Did you mean to just say RTP audio sessions?

Other than I am author, any particular reason not to reference draft-jennings-behave-test-results? If there is a problem with that work, it would be nice to know about it. I note that instead you are using a link that says at the top of the page "This page, the NAT servers, and the results database are no longer being actively maintained. "

[Ballot discuss]
The first para claims it is the filtering behavior of NATs the interferes with P2P. I don't believe this is the opinion of the WG - the rest of the draft seems to state it is the mapping behavior, not the filtering, that is the issue. I think this paragraph needs revision with respect to v6 firewalls.

I have several comments about the terminology - I mostly think these are very local and could be fixed without changing anything that draft is trying to say.

The terminology section seems very confusing with regards to other documents from the WG. The term endpoint seems to be redefined to mean address and is used in a way that seems inconsistent with other uses of the word Endpoint at the IETF. Is there any reason this could not be consistent with other BEHAVE RFCs?

The Behave WG explicitly decided to stop using terms like Symmetric. The primary reason was because what most people outside the IETF mean by symmetric proved to be very different than how we had defined it. I think it is a serious mistake to continue usage of these terms and unless there is some reasons to include them, i think ti would be better not to use them.

When I have seen the term "promiscuous NAT" used, it has had a different definition that used here. I have seen it used around the latching technology used in some NATs. Unless there is some need to use this term in the draft, I would rather just remove it instead of trying to come to consensus on a meaning for it. Alternatively if you have a reference for a definition of it.

In section 3.3, it implies both NATs need to be EIM for it to work. Is this really right? It seems like there are some case where it will work if only one is EIM.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document?

Dan Wing, dwing@cisco.com

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?

Yes.


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

Yes, it has been reviewed by some members of the BEHAVE working group and some
members of SIP-P2P. The document shepherd believes the document accurately
describes today's state-of-the-art for NAT traversal.


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


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

This document was WGLC'd previously, and all substantive comments
were integrated into the document. During this second WGLC, there
were no additional comments.


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

Most of the working group appears satisified with the document as
being useful to explain how applications are traversing NATs today.



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

There have been no such concerns.


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

The only remaining nits are to older versions of the drafts (-03
instead of -04).


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?

Yes; none are required.


If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Informational.


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

Yes.


Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

It contains a reference to RFC2766, which has recently been declared
Historic; however, the document is Informational so this isn't a
significant concern.


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 is Informational, so this isn't a concern.


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


Document is Informational and has no IANA considerations.


(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 is no formal language 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. 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 the various methods known to be in use by
applications to establish direct UDP or TCP communication in the
presence of Network Address Translators (NATs).


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

Agreeing on RFC3489 terminology (which is well known) versus
RFC4787 terminology (which is more accurate but longer) involved some
controversy. Consensus was to use RFC4787 terminology.


Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification?

Yes, in a manner of speaking -- the document explains how existing
software traverses NATs.

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?

They have been acknowledged in the Acknowledgements section.

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?

The document is Informational and only describes the state-of-the-art
for traversal of NATs for UDP and TCP.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Document shepherd: Dan Wing, dwing@cisco.com
Responsible AD: Magnus Westerlund, magnus.westerlund@ericsson.com