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

Suresh Krishnan <suresh@kaloom.com> Wed, 07 March 2018 04:44 UTC

Return-Path: <suresh@kaloom.com>
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AE7126D73; Tue, 6 Mar 2018 20:44:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan <suresh@kaloom.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-netmod-rfc6087bis@ietf.org, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.74.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152039784116.17621.12389822772400710157.idtracker@ietfa.amsl.com>
Date: Tue, 06 Mar 2018 20:44:01 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OqrCWCobkB3eMbNAHPvYm0w-UcM>
Subject: [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
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 04:44:01 -0000

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:


* 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?


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'

and the actual code component defined right after

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

* 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

   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.

* Section 4.14.1.  Non-Presence Container

So what is the guideline here? That there is no guideline?

* Section 4.20

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

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