NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
draft-ietf-nsis-nslp-natfw-25

[Ballot discuss]
This document is defined as Experimental but there is nothing inside that describes the criteria of the experiment and the limitations in deployment which have been subject of extensive discussion. I believe that we need to include a reference to draft-ietf-nsis-ext-07.txt and text that points to that I-D for the status of the document and deployment limitations.

IANA comments:

Please note that there are some questions to the authors. Please see
"QUESTION" tags below.

======================
======================
Create a new registry "NATFW NSLP Message Types" located at:
http://www.iana.org/assignments/TBD

Registration procedures: IETF Review
Value = 8 bit unsigned

Value Name Reference
----- ---------- -----------------------
0 Unassigned [REF-nsis-nslp-natfw-23]
1 CREATE [REF-nsis-nslp-natfw-23]
2 EXTERNAL [REF-nsis-nslp-natfw-23]
3 RESPONSE [REF-nsis-nslp-natfw-23]
4 NOTIFY [REF-nsis-nslp-natfw-23]
5-255 Unassigned [REF-nsis-nslp-natfw-23]

QUESTION: The document is silent about value=0 while the assignments
start at 1. Should value=0 be unassigned or reserved?

======================
======================
Create a new registry "NATFW NSLP Header Flags" located at:
http://www.iana.org/assignments/TBD

Registration procedures: IETF Review
Bit field = 8 bits

Bit Name Reference
--- ---- ------------------------
0 P [REF-nsis-nslp-natfw-23]
1 E [REF-nsis-nslp-natfw-23]

======================
======================
make new assignments in the "General Internet Signalling Transport
(GIST) Parameters" registry located at
http://www.iana.org/assignments/gist-parameters/gist-parameters.xhtml,
sub-registry "GIST Object Types"

Value Description Reference
------- ---------------------- ------------------------
TBD NATFW_LT [REF-nsis-nslp-natfw-23]
TBD NATFW_EXTERNAL-IP [REF-nsis-nslp-natfw-23]
TBD NATFW_EXTERNAL_BINDING [REF-nsis-nslp-natfw-23]
TBD NATFW_EFI [REF-nsis-nslp-natfw-23]
TBD NATFW_INFO [REF-nsis-nslp-natfw-23]
TBD NATFW_NONCE [REF-nsis-nslp-natfw-23]
TBD NATFW_MSN [REF-nsis-nslp-natfw-23]
TBD NATFW_DTINFO [REF-nsis-nslp-natfw-23]
TBD NATFW_ICMP_TYPES [REF-nsis-nslp-natfw-23]

======================
======================
QUESTION: Section 7.4 refers to a NSLP Response Code registry, which to
our knowledge, does not yet exist. Could you provide a reference to that
registry, to a document requesting its creation, or maybe it is defined
differently, or are you asking to create one?

======================
======================
make a new assignment in the "General Internet Signalling Transport
(GIST) Parameters" registry located at
http://www.iana.org/assignments/gist-parameters/gist-parameters.xhtml,
sub-registry "NSIS Signaling Layer Protocol (NSLP) Identifiers"

NSLPID Description Reference
------ ----------- ------------------------
TBD NATFW [REF-nsis-nslp-natfw-23]

======================
======================
make a new assignment in the "IPv4 Router Alert Option Values" registry
located at
http://www.iana.org/assignments/gist-parameters/gist-parameters.xhtml

Value Description Reference
----- ----------- -----------------
TBD NATFW NSLP [REF-nsis-nslp-natfw-23]

======================
======================
make a new assignment in the "IPv6 Router Alert Option Values" registry
located at
http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml

Value Description Reference
----- ----------- -----------------
TBD NATFW NSLP [REF-nsis-nslp-natfw-23]

Write-up for NAT/Firewall NSIS Signaling Layer Protocol (NSLP)


    1. Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the IESG for
publication?

Yes, it is.

    2. 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 draft has been discussed in depth for a long time and has passed
the latest Working Last Call.

    3. Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No concerns. There are at least three full implementations of the
protocol and some partial and inter-op tests have been successful.

    4. 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 whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway.

No major issues. The only issue to consider is whether the error code values should be harmonized between NSLPs and IANA could have a single repository for shared error codes, and not one registry per NSLP.


    5. 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 consensus is clear and strong, there have been no objections to the
proposal.

    6. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

    7. Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-nits.html).

There is 1 nit: "There are 2 instances of lines with private range IPv4
addresses in the document.  If these are generic example addresses,
they should be changed to use the 192.0.2.x range defined in RFC 3330."

Yet, the example needs to point out two different subnets, thus, the
use of only one C-class "TEST NET" subnet is not enough for the example.

    8. Does the document a) split references into
normative/informative, and b) are there normative references to IDs,
where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note: the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.)

The key normative reference is the GIST-specification which is
practically ready to proceed to the RFC editor.

    9. For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following sections:

          * Technical Summary

The draft defines the NSIS Signaling Layer Protocol (NSLP) for
Network Address Translators (NATs) and firewalls.  This NSLP allows
hosts to signal on the data path for NATs and firewalls to be
configured according to the needs of the application data flows. For
instance, it enables hosts behind NATs to obtain a public reachable
address and hosts behind firewalls to receive data traffic.  The
overall architecture is given by the framework and requirements
defined by the Next Steps in Signaling (NSIS) working group.  The
network scenarios, the protocol itself, and examples for path-coupled
signaling are given in this memo.

          * Working Group Summary

There have been several WGLC on the document, plus several
pre-WGLCs on the document. The editors have gotten extensive
feedback from implementors and have clarified text based upon
the feedback.  There are 3 or more independent
implementations of the NSLP, and there were multiple
interop events in the past.

          * Protocol Quality

This document was reviewed by the working group chair as well
as the WG. We feel that this document is ready, and
implementors feel that the specification is implementable.