Re: [Softwires] Genart last call review of draft-ietf-softwire-iftunnel-04

<mohamed.boucadair@orange.com> Mon, 06 May 2019 07:49 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781CC1200FA; Mon, 6 May 2019 00:49:50 -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 G5Go5UZ2cwLb; Mon, 6 May 2019 00:49:48 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7FA120049; Mon, 6 May 2019 00:49:45 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 44yFJ74NRtz1017; Mon, 6 May 2019 09:49:43 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 44yFJ73ZNYzDq86; Mon, 6 May 2019 09:49:43 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 6 May 2019 09:49:43 +0200
From: <mohamed.boucadair@orange.com>
To: Dale Worley <worley@ariadne.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "softwires@ietf.org" <softwires@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-softwire-iftunnel.all@ietf.org" <draft-ietf-softwire-iftunnel.all@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-softwire-iftunnel-04
Thread-Index: AQHVA7KBXyQhQ2zUWkigqcblo2dUGqZdouMA
Date: Mon, 6 May 2019 07:49:43 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA6C53A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155710932616.5380.16080578287406575461@ietfa.amsl.com>
In-Reply-To: <155710932616.5380.16080578287406575461@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.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/nARqClfR4e0Rq-bxgkhIL2ltkbM>
Subject: Re: [Softwires] Genart last call review of draft-ietf-softwire-iftunnel-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2019 07:49:50 -0000

Dear Dale, 

Thank for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dale Worley via Datatracker [mailto:noreply@ietf.org]
> Envoyé : lundi 6 mai 2019 04:22
> À : gen-art@ietf.org
> Cc : softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire-
> iftunnel.all@ietf.org
> Objet : Genart last call review of draft-ietf-softwire-iftunnel-04
> 
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
> 
> Document:  draft-ietf-softwire-iftunnel-04
> Reviewer:  Dale R. Worley
> Review Date:  2019-05-05
> IETF LC End Date:  2019-05-07
> IESG Telechat date:  [not known]
> 
> Summary:
> 
>        This draft is ready for publication as a Standards Track RFC.
> 
> Nits/editorial comments:
> 
>    Editorial Note (To be removed by RFC Editor)
> 
> This section is a great idea.  I haven't seen this usage before.
> 
>    Please update the "revision" date of the YANG modules.
> 
> This sentence doesn't say what to update the revision date to.
> 

[Med] The revision date will be updated with the publication date of the (future) RFC. The RFC editor is used with that. 

>    1.  Introduction
> 
>    This document specifies the initial version of the iana-tunnel-type
>    YANG module identifying tunnel interface types.
> 
> This could be made more specific, e.g.,
> 
>    This document specifies the initial version of the iana-tunnel-type
>    YANG module containing a collection of IANA maintained YANG
>    identities identifying tunnel interface types.
> 

[Med] OK.

> --
> 
>    2.  IANA Tunnel Type YANG Module
> 
>    The initial version of the module includes tunnels types defined in
>    [RFC4087], [RFC7856], [RFC7870], and [RFC6346].
> 
> s/tunnels types/tunnel types/
> 

[Med] Fixed.

> Should this mention the provenance of IP-HTTPS, which is in none of
> these RFCs?

[Med] This is already covered by the "reference" clause. 

> 
>      identity iphttps {
>        base ift:tunnel;
>        description
>          "IP over HTTPS (IP-HTTPS) Tunneling Protocol.";
>        reference
>          "Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling
>           Protocol Specification,
>           https://msdn.microsoft.com/en-us/library/dd358571.aspx";;
>      }
> 
> This type's reference doesn't appear in the list of references.

[Med] That is on purpose because otherwise that reference will need to be called out in the core text. 

> 
>    3.  Security Considerations
> 
>    These identies are intended to be
>    referenced by other YANG modules, and by themselves do not expose any
>    nodes which are writable, contain read-only state, or RPCs.
> 
> Logically, this is correct, but I think it would read better if
> s/contain read-only state/contain readable state/.

[Med] I will leave the initial wording. 

> 
>    4.1.  YANG Module
> 
>    The name of the "identity" is the same as the corresponding
>    enumeration in the IANAifType-MIB (i.e., IANAtunnelType).
> 
> This should be "... is the lower-case of the corresponding enumeration
> ...".
> 
>    "base":        Contains the name assigned to the tunnel type, in
>                   lowercase.
> 
> The description of this item should be "Contains 'ift:tunnel'.".

[Med] Good catch. Thanks. 

> 
>    6.2.  Informative References
> 
>    [TUNNELTYPE-IANA-REGISTRY]
>               Internet Assigned Numbers Authority, "tunnelType
>               Definitions", <https://www.iana.org/assignments/smi-
>               numbers/smi-numbers.xhtml#smi-numbers-6>.
> 
> Given that this document specifies substantial interaction with this
> registry, this reference should be normative.

[Med] We used to have this one as normative but we received comments asking to move it informative. I will leave this one to the AD. 

> 
> The title of this reference cannot be "tunnelType Definitions",
> because that text does not appear in either the referenced URL or the
> IANA assigned numbers index (https://www.iana.org/protocols).  The
> title of the entire web page is "Structure of Management Information
> (SMI) Numbers (MIB Module Registrations)"; the title of the section
> that is referenced is "Internet-standard MIB -
> mib-2.interface.ifTable.ifEntry.ifType.tunnelType", which is a
> subsection of the section titled "ifType definitions".  There is no
> reference to the section from the IANA assigned numbers index.
> 
> Comparing with this passage from section 4.1
> 
>       They must instead be respectively added to the
>       "tunnelType" sub-registry (under the "ifType definitions"
>       registry).
> 
> suggests the title "ifType definitions:  tunnelType" may be in
> informal use.

[Med] I went for: s/tunnelType Definitions/ifType definitions: tunnelType 

> 
> [END]
>