Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)

Suresh Krishnan <Suresh@kaloom.com> Wed, 07 March 2018 14:09 UTC

Return-Path: <Suresh@kaloom.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF31127698; Wed, 7 Mar 2018 06:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.onmicrosoft.com
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 dERMEBI5mbgA; Wed, 7 Mar 2018 06:09:23 -0800 (PST)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670092.outbound.protection.outlook.com [40.107.67.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E4C127522; Wed, 7 Mar 2018 06:09:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.onmicrosoft.com; s=selector1-kaloom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S2kbNe8aqxHwSHW6vXJcTTIzwbMDEF0vAJay380qCdQ=; b=AeuQ6yMJiL7LX7xgfUF2rxRqD0hD32zUdiLM3iEbAsLpvtmuTdlgjEL36ZUWdbMa+fKnghEXLrUlfkunY0i9SugtuTEsV4fUqin3btDKROe6LNqzi4qkF2WvdfR0l1Ye8SZlFOIhQJfpl2xvz7DmZBPjpS8u9KQ+NEoVdLywMfY=
Received: from YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM (52.132.77.143) by YQXPR0101MB2294.CANPRD01.PROD.OUTLOOK.COM (52.132.80.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Wed, 7 Mar 2018 14:09:20 +0000
Received: from YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM ([fe80::a0a9:b971:1b66:bfc2]) by YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM ([fe80::a0a9:b971:1b66:bfc2%13]) with mapi id 15.20.0548.016; Wed, 7 Mar 2018 14:09:20 +0000
From: Suresh Krishnan <Suresh@kaloom.com>
To: Benoit Claise <bclaise@cisco.com>, Andy Bierman <andy@yumaworks.com>
CC: NetMod WG Chairs <netmod-chairs@ietf.org>, "draft-ietf-netmod-rfc6087bis@ietf.org" <draft-ietf-netmod-rfc6087bis@ietf.org>, Kent Watsen <kwatsen@juniper.net>, The IESG <iesg@ietf.org>, NetMod WG <netmod@ietf.org>
Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)
Thread-Index: AQHTtdNfEmqaf0tAfkqq9nbOpV+DcaPEkUKAgAA+3AA=
Date: Wed, 7 Mar 2018 14:09:20 +0000
Message-ID: <96340504-5C2C-4FF0-8B0F-0D8AA5375E96@kaloom.com>
References: <152039784116.17621.12389822772400710157.idtracker@ietfa.amsl.com> <CABCOCHT+GDL_KBcpfX5kxXT+P9tQTVQiR5LcBCkXPzQHEoJGYw@mail.gmail.com> <70b5aeb1-ec66-fd8d-06d0-a6ac97ed98b9@cisco.com>
In-Reply-To: <70b5aeb1-ec66-fd8d-06d0-a6ac97ed98b9@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com;
x-originating-ip: [67.22.228.35]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; YQXPR0101MB2294; 7:3DlYVTTLTi5JUbpIeHMN/E0l2gnuvyd5f2yTxnKpVwIvj32Xz13X9dAIaYH2EhezJGGA5AZnUq9mJ1+fRLkl2KCXDavYMxlTZQqPRHwJBH2K1NRicr8OLh+sRP8U23K6tzWaWkS8a9H6osBGnTkI44ge7aduSgvo6qLqvTsoo8vUHH4qUKexPRU4faK3/SUUaWFuXBV+yw2rMOXHw4/+kaaFr7Yv+n2EPQTWdLVs0KgOyBYxq3uany01aUGxKIcn
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 9058b3a3-a87d-4cdd-68a6-08d5843505b9
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:YQXPR0101MB2294;
x-ms-traffictypediagnostic: YQXPR0101MB2294:
x-microsoft-antispam-prvs: <YQXPR0101MB22942E0759794514B1B2479DB4D80@YQXPR0101MB2294.CANPRD01.PROD.OUTLOOK.COM>
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(85827821059158)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231220)(944501244)(52105095)(3002001)(10201501046)(6041288)(2016111802025)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:YQXPR0101MB2294; BCL:0; PCL:0; RULEID:; SRVR:YQXPR0101MB2294;
x-forefront-prvs: 0604AFA86B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(376002)(346002)(39830400003)(366004)(377424004)(54534003)(199004)(189003)(478600001)(102836004)(26005)(36756003)(53936002)(8666007)(6486002)(6436002)(2950100002)(72206003)(6512007)(6306002)(59450400001)(76176011)(236005)(53546011)(8936002)(6116002)(3846002)(966005)(6506007)(54896002)(82746002)(6246003)(97736004)(5250100002)(33656002)(83716003)(105586002)(186003)(25786009)(68736007)(4326008)(3280700002)(66066001)(8676002)(81156014)(81166006)(5660300001)(3660700001)(2906002)(80792005)(54906003)(86362001)(229853002)(99286004)(110136005)(2900100001)(606006)(14454004)(106356001)(316002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:YQXPR0101MB2294; H:YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 5e47GXqdxSX00ld7MWCGyVvNhrm92Y0Q0tDlSG6Z6nW0B+oorvGnaxjZuI6qLtf7EgaM0qkTO7bRTpD//TgMpy3O6HRS9YqoiJAn6ihHcHHYVexYvao7BGS6KwQ3km2O9PG8GBl+5CrtVpr372nvTXI9ed6lEZRlyMdQ3AYpy1BFaDJy5bKU5QEHaOxVUOIpYnOQUK24QXWV6qbiLQD3pm9CXbGPZTxL1ir56e9rVqVj8wyx0YXjX7DtmxPVtZVzH6myyuvKPSk1bc0hyZpsBhPDGkg55Tqjbpd+gzK2fan0eDq6SUed4H5/kQ0yMDYpjtYLllZuwZ375t2QFqbMLg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_963405045C2C4FF08B0F0D8AA5375E96kaloomcom_"
MIME-Version: 1.0
X-OriginatorOrg: kaloom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9058b3a3-a87d-4cdd-68a6-08d5843505b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2018 14:09:20.5869 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB2294
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YDXwWBSb0t69ge94Ej3YncPXakc>
Subject: Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2018 14:09:27 -0000

Hi Andy/Benoit,
  Your suggested changes look good to me. I will clear as soon as the new version hits.

Regards
Suresh

On Mar 7, 2018, at 5:24 AM, Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>> wrote:

Suresh,


On Tue, Mar 6, 2018 at 8:44 PM, Suresh Krishnan <suresh@kaloom.com<mailto:suresh@kaloom.com>> wrote:
Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 4.25

I think this might be a simple misunderstanding but I have no idea what
compliance with this statement implies.

"A YANG module MUST NOT be designed such that the set of modules found on a
server implementation can be predetermined in advance."

Can you please clarify?



OK to remove this sentence.
Not sure where it came from



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.2:
  The date looks to be contradictory between the explanatory text

"The following example is for the '2010-01-18' revision of the  'ietf-foo'
module:"

and the actual code component defined right after

                   <CODE BEGINS> file "ietf-foo@2016-03-20.yang"<mailto:ietf-foo@2016-03-20.yang>
...
                                 revision 2016-03-20 {
...


OK will update revision date



* Section 4.8

I went over this text several times to figure out what it means. Can you
simplify this, or provide examples as to when revision dates are/are not to be
updated.

   It is not required to keep the full revision history of draft
   versions (e.g., modules contained within Internet-Drafts).  That is,
   within a sequence of draft versions, only the most recent revision
   need be recorded in the module.  However, whenever a new (i.e.
   changed) version is made available (e.g., via a new version of an
   Internet-Draft), the revision date of that new version MUST be
   updated to a date later than that of the previous version.


OK -- will clarify that the same revision-stmt can be reused in an Internet Draft.
The revision date is updated if the module is changed.
What we mean here is that the published RFC should contain something such as:

     revision 2018-01-09 {
       description
         "Updated to support NMDA.";
       reference
         "RFC XXXX: A YANG Data Model for Interface Management";
     }

As opposed to the full draft history and change log

     revision 2018-01-09 {
       description
         "Updated to support NMDA.";
       reference
         "RFC XXXX: A YANG Data Model for Interface Management";
     }

     revision 2017-11-01 {
       description
         "Updated to address AD review.";
       reference
         "draft-ietf-netmod-rfc7223bis-03";
     }

     revision 2017-09-01 {
       description
         "Updated to address issue X, Y, Z";
       reference
         "draft-ietf-netmod-rfc7223bis-02";
     }




* Section 4.20

What does "cannot" imply here? MUST NOT? SHOULD NOT?


MUST NOT -- per RFC 7950, 7.20.3



"The YANG "deviation" statement cannot appear in IETF YANG modules"



Will change "cannot" to is not allowed to"
There is not point to repeat the RFC7950 specifications, but we want to add to it.
Therefore, let me propose:

OLD:

   The YANG "deviation" statement cannot appear in IETF YANG modules,
   but it can be useful for documenting server capabilities.  Deviation
   statements are not reusable and typically not shared across all
   platforms.


NEW:


   Per RFC 7950, 7.20.3, the YANG "deviation" statement is not allowed to appear in IETF YANG modules,
   but it can be useful for documenting server capabilities.  Deviation
   statements are not reusable and typically not shared across all
   platforms.

Regards, Benoit