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

Michael Tuexen <tuexen@fh-muenster.de> Mon, 16 November 2020 18:18 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81003A1371; Mon, 16 Nov 2020 10:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFPiqfzc9Gnr; Mon, 16 Nov 2020 10:18:21 -0800 (PST)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8954F3A11BD; Mon, 16 Nov 2020 10:18:19 -0800 (PST)
Received: from [IPv6:2a02:8109:1140:c3d:cb2:f97b:5916:11f5] (unknown [IPv6:2a02:8109:1140:c3d:cb2:f97b:5916:11f5]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7382A722C80C2; Mon, 16 Nov 2020 19:18:16 +0100 (CET)
From: Michael Tuexen <tuexen@fh-muenster.de>
Message-Id: <3FA411F5-5F36-4DAE-9F87-2935BF4A429F@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_FC3CBA10-CE8F-490F-AE4E-14BB9BBA6E43"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
Date: Mon, 16 Nov 2020 19:18:13 +0100
In-Reply-To: <62858250-8a5e-dc57-6ab0-9caacf74e63f@erg.abdn.ac.uk>
Cc: draft-ietf-tsvwg-natsupp@ietf.org, "tsvwg@ietf.org" <tsvwg@ietf.org>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
References: <62858250-8a5e-dc57-6ab0-9caacf74e63f@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/7L72OUA6J9yIYuR9HJvMnjxRbqw>
Subject: Re: [tsvwg] draft-ietf-tsvwg-natsupp - Shepherd review prior to publication request
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 18:18:24 -0000

> On 16. Nov 2020, at 17:55, Gorry Fairhurst <gorry@erg.abdn.ac.uk> 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.
> 
> (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?
> 
> Discussed only in sec considerations:
> [RFC8341]
> [RFC8446]
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
> 
> 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.
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.
>