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

[Gorry Fairhurst <[e-mail]>]

> On 16 Nov 2020, at 18:18, Michael Tuexen <[e-mail]> wrote:
> 
> 
>> 
>> On 16. Nov 2020, at 17:55, Gorry Fairhurst <[e-mail]> wrote:
>> 
>> 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?
> No. If you want, I can cite that in Section 6.5.

I do not mind, I wanted to ask. Do what is best,
>> 
>> (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]
> 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.
>> 
>> Discussed only in sec considerations:
>> [RFC8341]
>> [RFC8446]
> 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.
>> 
>> (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?
Yes.
>> 
>> 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.
> 
Seems like we have a plan,

GOrry

> Best regards
> Michael
>> 
>> 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:
>> 
Thanks - all look ok

>> 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.
>> 
>> OLD:
>> For example only
>> NEW:
>> 
>> 
>> For example, only
> Fixed.
>> 
>> OLD:
>> during the processing which
>> NEW:
>> 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.
>> 
>> 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.
> 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.
>> 
>