[netmod] kw review of draft-verdt-netmod-yang-semver-00

Kent Watsen <kent+ietf@watsen.net> Fri, 22 March 2019 21:43 UTC

Return-Path: <01000169a75bd9aa-8ae4d091-6f9f-4e4a-90ec-453b026510d1-000000@amazonses.watsen.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E6672131585 for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2019 14:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.409
X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v4uoPoRDtIIQ for <netmod@ietfa.amsl.com>; Fri, 22 Mar 2019 14:43:30 -0700 (PDT)
Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCBE130E85 for <netmod@ietf.org>; Fri, 22 Mar 2019 14:43:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1553291008; h=From:Subject:To:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=8YCe92SRyMNOdfZ2IimyU/7QwksDCTKz09/gR+jUcQw=; b=FEE8pEDAaR/5rvhSVob+HUZBJanmO2OQIHqavF3bBfG1yYdmiLfhvqm4xnsOT8v7 jWUc27bXoSnimnE4im/pOG4HIbneycVYk/srhsxJsEmukFqoWT6KAb2irhuI/wHPY6u E8xkVDwbPf4Y8NP71+4EiCoLAbgkQVUrY6umswKI=
From: Kent Watsen <kent+ietf@watsen.net>
To: netmod@ietf.org
Message-ID: <01000169a75bd9aa-8ae4d091-6f9f-4e4a-90ec-453b026510d1-000000@email.amazonses.com>
Date: Fri, 22 Mar 2019 21:43:28 +0000
User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-SES-Outgoing: 2019.03.22-
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BI5UIelwCMbqb4ySD16aOU-gDJ8>
Subject: [netmod] kw review of draft-verdt-netmod-yang-semver-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 22 Mar 2019 21:43:31 -0000

I understand that this draft is shaking fundamentals that is making
some folks nervous.  The concern is appreciated, but I also understand
well issues vendors are facing and don't believe that maintaining
status quo is realistic.

The requirements are, for the most part, correct (IMO), especially
regarding support for NBCs.  At least, the way I see it, that is the
reality of native models for products that have multiple simultaneous
release trains.

Maybe deviations could be used but 1) it's kind of strange for a vendor
to deviate from its own native model and 2) it seems complicated to swap
the compiled native model with a standard native model + some dynamically
generated deviations, using some TBD tooling.  To be clear, my assumption
is that the underlying NC/RC interface is unchanged, only the modules the
server reports would vary.  But why haven't vendors done this already?

I don't yet see a downside to embracing the sem-ver proposal, while
OpenConfig alignment seems like goodness.  We should analyse the tradeoffs

For the following review, I assume that Sem-Ver is good, and the added 'M'
and 'm' suffixes are useful.  Whether these things pan out in time is TBD.


Beginning of Section 1.2:
     OLD: This section is to aid the WG understand how the full set
     NEW: This section is to aid the WG understanding in how the full set

End of Section 2.1
     OLD: and those changes do not follow the rules
     NEW: and at least one change does not follow the rules

Just before Section 2.2.1:
     OLD: There MUST NOT be multiple versions of a YANG module
     NEW: There MUST NOT be multiple published versions of a YANG module

     Actually, it might be more helpful to have a clarification note 
near the top
     that the draft only regards published modules and specifically does not
     apply to the various revisions of a draft.

In Section 2.2.1:
      The line “0.2.0 - second beta module version (with NBC changes)” 
    point to rule 4 in Section 2.3

In Section 2.3:
     For rule 4, why not peg the semver to “0.0.0” for beta modules? 
  Already the
     Interpretation is off, so no semantic meaning comes through.  Going 
back to
     my earlier comment about having general statement regarding 
     modules, it seems that “beta” modules fall into this category and 
hence okay
     to reuse the same semver value.

In Section 3:
    There are two numbered lists in this section, each containing three 
entries: 1,
    2, and 3.   First, please change one of the lists to a different 
format (e.g., i, I, iii).
    Next, it would be helpful to explain which parts belong to which. 
  E.g., 1–>i, 2–>ii,
    3 —> ii and iii.

Section 3.1:
     OLD: that is hypothetically available in the following versions:
     NEW: that is published in the following versions:

Section 4.2:
     OLD: The document update these rules
     NEW: This document updates these rules

     Also: s/chanage/change/

Section 5.2:
     OLD: but one of more modules
NEW: but one or more modules

Section 5.3:

     The augmentation in the YANG module indicates the intention is to 
enable a
     server to express its conformance at the “server” level, but it 
seems that it
     should be at the module-level.  As support across modules may vary.

     Also, this section has a nice wrap up paragraph where it states
     “implementations <snip> MUST set the 'deprecated-nodes-implemented' 
     But it fails to say anything about the obsolete-nodes-absent leaf? 
  It seems that
     It should be required as well but, if not, then the text should 
state why not.

Section 6:

     Says “this extension can contain freeform text”, but it seems that 
a node that
     tools could act on would be better.  Is it we think that the 
deprecation warning
     message should be sufficient to guide the developer to look at the 

Section 7:

     Not specific to this draft, but is it an omission in 
doesn’t specify schema compatibility for instance data?

Kent // contributor