[tsvwg] draft-ietf-tsvwg-natsupp-12 -- comments on the draft

[G Fairhurst <[e-mail]>]

Thanks for this revision, but I still do have a number of concerns that 
I think need to be acted upon before a WGLC. The editors may like to 
address some/all of these before the IETF TSVWG meeting... If people 
have opinions please.

Gorry

---
  I think the use of "NAPT" seems odd to me. I think in most cases the 
document is talking about adding NAPT functions (that I know of as an 
ALG) to support SCTP NAT traversal.
---

I think this text is not quite correct:
  "This document describes an SCTP specific variant NAT and specific
    packets and procedures to help NATs provide similar features of NAPT
    in the single-point and multi-point traversal scenario.  An SCTP
    implementation supporting this extension will follow these procedures
    to assure that in both single-homed and multi-homed cases a NAT will
    maintain the proper state without needing to change port numbers."

I think this text may be a better start:
  "  This document  specifies procedures allow a NAT to support SCTP
   by providing similar features
   to those provided by a NAPT for TCP and other supported protocols "

   The document also specifies a set of data formats for SCTP packets
    and a set of SCTP endpoint procedures to support NAT traversal. An SCTP
    implementation supporting these procedures
    can assure that in both single-homed and multi-homed cases a NAT will
    maintain the proper state without needing to change port numbers."
---
There are several text note that say something like:
' [NOTE:

       ASSIGNMENT OF M-BIT TO BE CONFIRMED BY IANA.

    ]"

(I do not understand from that *what* you wish the RFC-ED to insert 
here. I think we want the RFC-ED to remove this commnent, and if we keep 
thois, we should say so.)

Actually, I really do we need to actually retain the comment now, as we 
move to WGLC - could we just remove?
---
Nits:

"NAT box" to "NAT device"
"NAT which has" to ""NAT that has"
"can't" to "is unable to" (or similar)
"i.  e." to "i.e."
- is "end point" one word?

---
To me, NAPT includes port translation of the IP payload, and NAT only 
changes IP addresses. Is this your interpretation, and has this been 
used consistently?
---
I am unclear what is intended by the para with this statement:
"When considering this feature it is possible to have multiple levels
    of support. "
- This para needs to be rewritten, does the table refer to support of 
the new mechanisms in this document? or do I misunderstand?
are the features just what is described in one of the sections, or 
something else. I was pretty confused.
What does this mean:
"This is because for the most part of the current situation".
- what situation?
---
"This document uses the following terms"
- I think this should also use the terms defined by the IETF BEHAVE 
work. Please be consistent with these and say so in the terminology.
---

I am not a huge fan of a construct that uses MUST followed by a bullet 
list, as in:
"The endpoint MUST do the following:"
- I would strongly advise you to use "MUST" instead in each individual 
bullet, so that the requirement is clear.

---
The meaning of this requirement appears ambiguous:
"if it does not discard the incoming ERROR chunk."
If I understamd this, you could write:
"if the NAT device does not discard the incoming ERROR chunk, then the 
server MUST validate that the peer of the SCTP association supports the
       dynamic address extension".
---
Section 4.1 and 4.2
- I think (maybe I am wrong) this is all background? and therefore could 
be subsections of section 1?
---
The english in section 4 reads like a paper, there are many loose terms 
here, that need to be tightened.
e.g. (but please check the entire text):
"Furthermore we are
    focusing in this section on the single point traversal scenario."
- who is we, and what does this mean?
"The modification of SCTP packets sent to the public Internet is easy."
- what does that mean?
"It may also be necessary to establish some state in the NAT
    box to handle incoming packets, which is discussed later."?
---
Section 4.3 needs to be renamed to align with BEHAVE terms.
---
There are several examples of requirements that do not say how to 
realise them, this is a problem. I suspect we could simply be missing 
cross-references to the SCTP base spec to tell the NAT implementer where 
the appropriate method is defined.
"A NAT box MUST support IP reassembly of received fragmented SCTP packets."

---

Section 6.6 is inherently IPv4, and I think thoought is needed to help 
avoid silly review comments:
"Handling of Fragmented SCTP Packets" to "Handling ofFragmented SCTP 
Packets"
 >> Is there an RFC that decsribes in-network reassembly of IPv4 fragments?
 >> If you allow this, then you place requirements on all IP fragments 
passing through this NAT, that you should state.
 >> You also need to discuss timer actions, MSL, etc.
 >> How do you deal with fragments that set "DF"?
 >> Do you propose or not to re-assemble IPv6 fragments?
 >> There are also security issues in performing reassembly!

After all this, I really wonder if this is a GOOD thing to include in 
the NAT function.  Can you justify why this is an important function?
------------

Please rephrase this:
"The suggested value for the T bit is 0x01 and for the M bit is 0x02."
as something like:
"IANA is requested to assign the value of 0x01 for theT bit and the 
value of 0x02 for theM bit."
---
Please rephrase this (multiple):
"It is suggested to use the values given below."
as
"IANA is requested to assign the following values:"
---
"More than one host behind a NAT may pick".
- could this be.
"Multiple endpoints behind a NAT device could use"
---
Why is there a section 6.1 subsection, this text seems to belong in 
section 6 as an overview of everything in section 6?
---
Section 6.2
- I retain my comment that I think this section should differentiate NAT 
and endpoint actions.
In this case it should somehow be labeled as an endpoint mechanism. e.g.,
"Considerations when an endpoint sets up an SCTP association"
---
In section 6.2, there are a set of requirements:
e.g, "Every association MUST initially be set up single-homed." , etc, etc.
I am unclear. Are these changes to the base spec, or clarifications of 
what the base spec says, either way I would not feel comfortable without 
some sort of reference back to the base spec.
---
I think the first part of section 6.3 refers to what NATs provide, I 
think you need to make a subsection title including "NAT" and place the 
first part in this.
e.g.
"6.3.1 NAT Handling of Internal Port Number and VTAG Collisions"
I think the last 3 para  of section 6.3 refers to what NATs provide, I 
think you need to make a subsection title including "NAT" and place the 
first part in this.
"6.3.2 SCTP Endpoint Handling of Internal Port Number and VTAG Collisions"
---
I really think that section 6.4 can and should also be sub-divided in 
the same way.
---
I really think that section 6.5 can and should also be sub-divided in 
the same way.
---
In section 6.5, this also states:
"Upon reception of this ERROR chunk by an SCTP endpoint the receiver 
SHOULD take the following actions"
- what happens if it does not? (please say).
---
Section 6.6 is clearly just "NAT" ? - if I understand, can this be added 
to the title?
---
Section 6.7 is clearly just "SCTP Endpoint" ? - if I understand, can 
this be added to the title?
---