Re: [OPSAWG] Tsvart telechat review of draft-ietf-opsawg-nat-yang-16

<mohamed.boucadair@orange.com> Thu, 27 September 2018 07:44 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A405130F6D; Thu, 27 Sep 2018 00:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 r53jgvIfTPuK; Thu, 27 Sep 2018 00:44:15 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A3F130E6A; Thu, 27 Sep 2018 00:44:14 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 42LRdn199CzFqgY; Thu, 27 Sep 2018 09:44:13 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 42LRdn0GWhz5vNB; Thu, 27 Sep 2018 09:44:13 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0415.000; Thu, 27 Sep 2018 09:44:12 +0200
From: mohamed.boucadair@orange.com
To: Joerg Ott <jo@acm.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "draft-ietf-opsawg-nat-yang.all@ietf.org" <draft-ietf-opsawg-nat-yang.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Tsvart telechat review of draft-ietf-opsawg-nat-yang-16
Thread-Index: AQHUVV4lOaWPiR88SUCJK7Na+Rcxa6UDu6ZQ
Date: Thu, 27 Sep 2018 07:44:12 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DFE7813@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <153794159155.5472.10376988707954786720@ietfa.amsl.com>
In-Reply-To: <153794159155.5472.10376988707954786720@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/dcTxqiEP5u4ickJ5R_y7SnJSWWg>
Subject: Re: [OPSAWG] Tsvart telechat review of draft-ietf-opsawg-nat-yang-16
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2018 07:44:18 -0000

Hi Joerg, 

Thank you for the review. 

Cheers,
Med

> -----Message d'origine-----
> De : Joerg Ott [mailto:jo@acm.org]
> Envoyé : mercredi 26 septembre 2018 08:00
> À : tsv-art@ietf.org
> Cc : draft-ietf-opsawg-nat-yang.all@ietf.org; ietf@ietf.org; opsawg@ietf.org
> Objet : Tsvart telechat review of draft-ietf-opsawg-nat-yang-16
> 
> Reviewer: Joerg Ott
> Review result: Ready with Nits
> 
> Hi,
> 
> I've reviewed this document as part of TSV-ART's ongoing effort to review
> key IETF documents. These comments were written primarily for the
> transport area directors, but are copied to the document's authors for
> their information and to allow them to address any issues raised.  When
> done at the time of IETF Last Call, the authors should consider this
> review together with any other last-call comments they receive. Please
> always CC tsv-art@ietf.org if you reply to or forward this review.
> 
> Generally, the document is ready to go, but I have one comment/question
> and one nit.  See the review below.
> 
> Joerg
> 
> draft-ietf-opsawg-nat-yang defines a YANG data model for all flavors
> of Network Address Translators.  As a data model, the document does
> not define transport layer operation but rather relies on NETCONF or
> RESTCONF for data carriage, which in turn use congestion controlled
> transports.  The YANG model defines configurable application layer
> rate limiting for events generated by the entities implementing the
> model.
> 
> The model captures the transport protocols defined in the IETF, subsuming,
> as NATs do, all UDP-based protocols under UDP; not much more would be
> known to the NAT by just inspecting the protocol type field of the IP header.
> One question that arises is why SCTP doesn't receive equal treatment as
> TCP and UDP do.  Specifically:
> 
> p.7, 2nd para reads:
>    Future extensions may be needed to cover NAT-related considerations
>    that are specific to other transport protocols such as SCTP
>    [I-D.ietf-tsvwg-natsupp].  Typically, the mapping entry can be
>    extended to record two optional SCTP-specific parameters: Internal
>    Verification Tag (Int-VTag) and External Verification Tag (Ext-VTag).
> 

[Med] This is because we don't have yet IETF endorsed NAT behavioral RFCs for these protocols; we do have for TCP/UDP/ICMP. 

When these documents will be available, it will be easy to extend the module (if needed) hence the note you quoted above. 

What is really important is that the document does not exclude by design other transport protocols. A fair discussion and features are included in the document. 

> This brings up two questions: 1) What is the sentence beginning with
> "Typically" supposed to convey?

[Med] This is to provide a concrete example about possible extensions.  

 2) Why wouldn't such expected parameters
> be defined as part of the model right away rather than being left to an
> extension? 

[Med] Because we don't have (yet) an IETF consensus whether this is the way to go for SCTP NATs.   

 Even if those aren't included it may be worthwhile motivating
> this.  Also, should there be some more guidance what to include and what
> not for future transports so that the model would get extended consistently?

[Med] This is IMHO not specific to this area, but to any extension to an existing model/module. Generic guidance would apply here. 

FWIW, we do already have a module which extends this one: https://tools.ietf.org/html/draft-ietf-softwire-dslite-yang-17 (in the RFC Editor Queue).   

> 
> Nits:
> 
> p.4, 1st bullet:
> OLD:
> A NAPT may use an extra identifier, in addition to the
> five transport tuple, to disambiguate bindings [RFC6619].
> NEW:
> A NAPT may use an extra identifier, in addition to the
> five tuple used for transport, to disambiguate bindings [RFC6619].
> 
[Med] OK.