Subject: [tsvwg] draft-ietf-tsvwg-natsupp - Shepherd review prior to publication request

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Nov 2020 16:55:05 +0000

Document editors (and WG):

I am currently compelting a detailed review of draft-ietf-tsvwg-natsupp 
as I prepare to submit this to our AD for publication. During this 
review I have the following questions:

(1) The ID mentions issues with IP Fragments, but do cite: rfc8900 which 
is a BCP that talks about the issues with fragments and also mentions 
NAT. Is there merit in citing this BCP also?

(2) I don’t understand why the following are normative? Can you explain 
why these are normative or make informative?

[These seem to be cited as examples:
RFC6241]
[RFC6242]
[RFC8040]

Discussed only in sec considerations:
[RFC8341]
[RFC8446]

(3) I think it’s slightly awkward to have two informational sections 
with one normative section (yang model) between the two. Have you 
considered reordering the sections to place all info sections at the end 
(or possibly in an annexe?)

Please let me know how you would like to handle these comments, and text 
NiTs below. I'll pause preparing the wrietup until I hear from you.

Best wishes

Gorry

- as document shepherd for this document.

---

I also observed the following textual NiTs, some of which I think impact 
the reading of normative text. I phrased these as OLD/NEW - in case you 
would like to take the suggestions of new text:

OLD:
 From the table it can be seen that when a NAT function does not support 
SCTP-aware NAT no communication can occur.
NEW:
 From the table it can be seen that no communication can occur when a 
NAT function does not support SCTP-aware NAT.

OLD:
In some cases, where the NAT function supports SCTP-aware NAT but one of 
the two hosts does not support the feature, communication possibly 
occurs but in a limited way.
- Too many buts?
NEW:
In some cases, where the NAT function supports SCTP-aware NAT, but one 
of the two hosts does not support the feature, communication can 
possibly occur in a limited way.

OLD:
For example only
NEW:

 For example, only

OLD:
during the processing which
NEW:
during the processing, which

OLD:
The processing of outgoing SCTP packets containing an INIT chunk is 
described in the following figure. The scenario shown is valid for all 
message flows in this sectiondoes a figure describe?

NEW: 

The processing of outgoing SCTP packets containing an INIT chunk is 
illustrated in the following figure. This scenario is valid for all 
message flows in this section

OLD:
The processing of incoming SCTP packets containing an INIT ACK chunk is 
described in the following figure.
NEW:
The processing of incoming SCTP packets containing an INIT ACK chunk is 
illustrated in the following figure.

OLD:
The Lookup() function getting as input the Internal-VTag, Internal-Port, 
Remote-VTag, and Remote-Port, returns the corresponding entry of the NAT 
binding table and updates the Remote-VTag by substituting it with the 
value of the Initiate-Tag of the INIT ACK chunk.
NEW:
The Lookup() function has as input the Internal-VTag, Internal-Port, 
Remote-VTag, and Remote-Port. It returns the corresponding entry of the 
NAT binding table and updates the Remote-VTag by substituting it with 
the value of the Initiate-Tag of the INIT ACK chunk.

OLD:
Note that the receiver MUST NOT change this 32-bit value.
- Please remove “Note that” from a normative statement:
NEW:
The receiver MUST NOT change the value of the ASCONF-Request Correlation ID.

OLD:
This parameter MAY appear in ASCONF chunks and MUST NOT appear in any 
other chunk.
- for the avoidance of doubt please replace /parameter/ with the one you 
mean.
NEW:
The Remote Verification parameter MAY appear in ASCONF chunks and MUST 
NOT appear in any other chunk.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 16 Nov 2020 19:18:13 +0100

> On 16. Nov 2020, at 17:55, Gorry Fairhurst <[email-masked]> wrote:
> 
> I am currently compelting a detailed review of draft-ietf-tsvwg-natsupp as I prepare to submit this to our AD for publication. During this review I have the following questions:
> 
> (1) The ID mentions issues with IP Fragments, but do cite: rfc8900 which is a BCP that talks about the issues with fragments and also mentions NAT. Is there merit in citing this BCP also?
No. If you want, I can cite that in Section 6.5.
> 
> (2) I don’t understand why the following are normative? Can you explain why these are normative or make informative?
> 
I guess this is because Mohamed provided it that way. I'm more than happy to move them to the informative references. Would that resolve your issue?
> Discussed only in sec considerations:
Same as above. Would you be happy If I move them to the informative section?
> 
> (3) I think it’s slightly awkward to have two informational sections with one normative section (yang model) between the two. Have you considered reordering the sections to place all info sections at the end (or possibly in an annexe?)
I can move the YANG section before the examples. Would that resolve your issue?
> 
> Please let me know how you would like to handle these comments, and text NiTs below. I'll pause preparing the wrietup until I hear from you.
I have already fixed all nits. I would prefer to fix the above issues before you progress the document.
So please let me know if you are fine with the above suggestions.

Best regards
Michael
> I also observed the following textual NiTs, some of which I think impact the reading of normative text. I phrased these as OLD/NEW - in case you would like to take the suggestions of new text:
> 
> OLD:
> From the table it can be seen that when a NAT function does not support SCTP-aware NAT no communication can occur.
> NEW:
> From the table it can be seen that no communication can occur when a NAT function does not support SCTP-aware NAT.
Fixed.
> 
> OLD:
> In some cases, where the NAT function supports SCTP-aware NAT but one of the two hosts does not support the feature, communication possibly occurs but in a limited way.
> - Too many buts?
> NEW:
> In some cases, where the NAT function supports SCTP-aware NAT, but one of the two hosts does not support the feature, communication can possibly occur in a limited way.
Fixed.
> For example, only
Fixed.
> during the processing, which
Fixed.
> 
> OLD:
> The processing of outgoing SCTP packets containing an INIT chunk is described in the following figure. The scenario shown is valid for all message flows in this sectiondoes a figure describe?
> 
> NEW:
> 
> 
> The processing of outgoing SCTP packets containing an INIT chunk is illustrated in the following figure. This scenario is valid for all message flows in this section
Fixed.
> 
> OLD:
> The processing of incoming SCTP packets containing an INIT ACK chunk is described in the following figure.
> NEW:
> The processing of incoming SCTP packets containing an INIT ACK chunk is illustrated in the following figure.
Fixed.
> 
> OLD:
> The Lookup() function getting as input the Internal-VTag, Internal-Port, Remote-VTag, and Remote-Port, returns the corresponding entry of the NAT binding table and updates the Remote-VTag by substituting it with the value of the Initiate-Tag of the INIT ACK chunk.
> NEW:
> The Lookup() function has as input the Internal-VTag, Internal-Port, Remote-VTag, and Remote-Port. It returns the corresponding entry of the NAT binding table and updates the Remote-VTag by substituting it with the value of the Initiate-Tag of the INIT ACK chunk.
Fixed.
> The receiver MUST NOT change the value of the ASCONF-Request Correlation ID.
Fixed.
> 
> OLD:
> This parameter MAY appear in ASCONF chunks and MUST NOT appear in any other chunk.
> - for the avoidance of doubt please replace /parameter/ with the one you mean.
> NEW:
> The Remote Verification parameter MAY appear in ASCONF chunks and MUST NOT appear in any other chunk.
Changed for the Disable Restart Parameter and the VTags Parameter.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Nov 2020 20:52:55 +0000

> On 16 Nov 2020, at 18:18, Michael Tuexen <[email-masked]> wrote:
> 
> 
>> 

I do not mind, I wanted to ask. Do what is best,
> I guess this is because Mohamed provided it that way. I'm more than happy to move them to the informative references. Would that resolve your issue?
Yes - unless someone tells me otherwise, I think I wold be happy as Info.
> Same as above. Would you be happy If I move them to the informative section?

Yes - unless someone tells me otherwise, I think I wold be happy as Info.
> I can move the YANG section before the examples. Would that resolve your issue?
Yes.
> So please let me know if you are fine with the above suggestions.
Seems like we have a plan,

GOrry

>> I also observed the following textual NiTs, some of which I think impact the reading of normative text. I phrased these as OLD/NEW - in case you would like to take the suggestions of new text:
Thanks - all look ok

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 16 Nov 2020 22:48:36 +0100

> On 16. Nov 2020, at 21:52, Gorry Fairhurst <[email-masked]> wrote:
> 
> 
> 
I added to section 6.5:
See <xref target="RFC8900"/> for more information about IP fragmentation.
> Yes - unless someone tells me otherwise, I think I wold be happy as Info.
Done.
> Yes - unless someone tells me otherwise, I think I wold be happy as Info.
Done.
>> I can move the YANG section before the examples. Would that resolve your issue?
Done.
> Seems like we have a plan,
New revision (-22) has been submitted. That should resolve all your issues.

Best regards
Michael