Editorial comments draft-ietf-tsvwg-natsupp-07.txt
Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>
2015-03-22 21:03:27 GMT
I separately sent some questions on the new draft. The list below contains mainly minor comments on the new test.
“To date, specialized code for SCTP has not yet been added to most NATs so that only pure NAT is available.
The end result of this is that only one SCTP capable host can be behind a NAT.”
- While I think this text may be very important fro the introduction, it is not really necessary in the
abstract. We can just specify the mechanisms.
- The abstract also need stop say that the document defines the NAT behaviour required to support SCTP.
- I think (am I correct) that the view of a NAT maps to one public IP address. Is this the case? Can we say this?
“The authors feel”
- Authors appears more than once. While it may be true, this phrase should’t appear in a WG draft, unless
the authors may differ in opinion to the WG. I don’t think this us the case. I suggest we simply make the
statement and see if there is working group consensus. If there is any doubt, please raise this at a WG
meeting in the presentation and confirm the outcome on the list.
“much as TCP does today”
- I suggest “in the same way that a TCP session can use a NAT”
- Do you also need to add a clause saying: “The reader is also assumed to be familiar with the terminology in
RFC4960, and XXXX.
- It could be worth prefixed “Verification Tag” with “SCTP” in case a NAT implementor does not
immediately understand these terms.
- Better perhaps as: “considerably adds”
“considered by the authors”
- should be removed.
”it should be noted that”
- should be removed.
Says that an error chunk SHOULD be sent.
- Why SHOULD in this case. I can see that potentially the chunk may not be delivered, but why not say MUST send.
This seems in line with other recommendations later to require sending in 6.3
- Could we add a sentence saying what is in the section, such as:
“This section defines the formats used to support NAT traversal. Section 5.1 and 5.2 describe chunks
generated by NATs and interpreted by SCTP end hosts. 5.3 describes parameters set by end hosts and used by
NATs and end hosts.” (checking of course these statements are correct).
- In several places this speaks of extending, rather than updating. This may or may not be the correct term.
What is the compliance statement with respect to the SCTP base sec. Are implementations expected to
implement the NAT travseral endpoint support, or is this optional? How does the WG wish to handle this and
what are reasonable expectations of a “full” SCTP stack?
- In several places this makes assumptions of the IANA registry update. Can you please add a note, such as
this below before each of these to ensure these are not overlooked when we go for publication:
“XXX TO BE CONFIRMED BY IANA”
- Would it be possible to rename this section “End host and NAT Procedures”. This could be helpful to
ensure readers get to the correct sections.
- Excess letters after [RFC4960] ???
- I wonder if a NAT implementor a little unfamiliar with SCTP would benefit from a few short words that
explained how SCTP-INIT normally works without a NAT. I found this a sudden change in the expected
background of the reader.
- Insert “-“ between “TCP” and “like”
“These procedures SHOULD be followed only if the appropriate error cause code for colliding NAT table
state is included AND the association is in the COOKIE-WAIT state (i. e. it is awaiting an INIT-ACK). If the
endpoint is in any other state an SCTP endpoint SHOULD NOT respond.”
- I couldn’t work this out. Following a SHOULD with a condition is always a recipe for making a difficult
sentence. Does this mean (or not):
If the appropriate error cause code for colliding NAT table state is included and the association is also in
the COOKIE-WAIT state (i. e. it is awaiting an INIT-ACK), then these procedures SHOULD be followed.”?
Or is it “MUST” under this specific case?
- and the next phrase has a “If” and a SHOULD NOT, that’s not entirely clear to me when and why you would not.
- Could you please think about making the RFC2119 language simpler?
“For the NAT”
-insert comma after “NAT” and before “tracking”
- can we start a new line with the NAT behaviour, I’m keen to see separation between paras that tell NATs
what to do and paras that tell host stacks what to so. (more later).
“i. e.” should be “i.e.,”
- If this is the same as RFC4960, then please cite, if not explain the difference between this and an SCTP end
host fragment reassembly rule.
- I think this section is informative, if it is, it would be nice to have a sentence saying so at the start.
- I think this section should not the possibility of off-path attacks and provide a more or less standard
sentence saying how SCTP provides protection from off-path data insertion, stating that this
protection remains when NATs are used. This “background” may also help readers understand a little
more of SCTP.