Re: [Netmod-ver-dt] Latest doc version

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 07 March 2019 11:53 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod-ver-dt@ietfa.amsl.com
Delivered-To: netmod-ver-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CD0131312 for <netmod-ver-dt@ietfa.amsl.com>; Thu, 7 Mar 2019 03:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 sB4jMpd6tQ6Y for <netmod-ver-dt@ietfa.amsl.com>; Thu, 7 Mar 2019 03:53:49 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596C412785F for <netmod-ver-dt@ietf.org>; Thu, 7 Mar 2019 03:53:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47498; q=dns/txt; s=iport; t=1551959629; x=1553169229; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=T4aTllS0lprasJkx1cdBcY2AabmPcZmKMYiok9kW9fo=; b=EVO5cds4qwveiPyN/P+7WpeHNPhEijtVW4Nm4ooSS1jg3JYBSPMrMlGg uvmPyJKhgqRAeePe8YMH1DVWKZ9RF7XucIHyykNe1h21nICU3YcusU3CG 631/1DZZBspK/F84SOqAR5lo258cZgrmfcVgAmBYHx5ohKthn9KV2hqT4 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAA0BYFc/5hdJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ2BAmiBAycKg3+IGospgg2YI4F7CwEBI4RJAheEHiI0CQ0BAQMBAQcBAwJtHAyFSgEBAQEDLVwCAQYCDgMEAQEhAQYFAgIwFAkIAQEEARIIgxuBEWQPjl+bYAiBLYosgS8BiysXgUA/gRGDEoMeAQEDgUgtH4JQgjkiAooGPoYJHocKjCAJAodLg3uHNSGBeFiQZYpxgRKET4xXAhEUgSgfOIFWcBU7gmwJgg0Xg0uFFIU/QTGMcoEfAQE
X-IronPort-AV: E=Sophos;i="5.58,451,1544486400"; d="scan'208,217";a="446223161"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Mar 2019 11:53:47 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x27BrluP019076 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Mar 2019 11:53:47 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Mar 2019 05:53:47 -0600
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 7 Mar 2019 05:53:46 -0600
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Qin Wu <bill.wu@huawei.com>, "netmod-ver-dt@ietf.org" <netmod-ver-dt@ietf.org>
Thread-Topic: Latest doc version
Thread-Index: AdTP++d2Dvwd8fG9R467D1DpT6PfAgE3ptiA
Date: Thu, 07 Mar 2019 11:53:46 +0000
Message-ID: <5f1379f31e234bc8b1b13cec1b12f114@XCH-RCD-007.cisco.com>
References: <B8F9A780D330094D99AF023C5877DABA9B28F195@nkgeml513-mbx.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9B28F195@nkgeml513-mbx.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.61]
Content-Type: multipart/alternative; boundary="_000_5f1379f31e234bc8b1b13cec1b12f114XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod-ver-dt/8PfDjjXqdqPasLYBm9H2L7aL1OE>
Subject: Re: [Netmod-ver-dt] Latest doc version
X-BeenThere: netmod-ver-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NetMod WG YANG Model Versioning Design Team <netmod-ver-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod-ver-dt>, <mailto:netmod-ver-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod-ver-dt/>
List-Post: <mailto:netmod-ver-dt@ietf.org>
List-Help: <mailto:netmod-ver-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod-ver-dt>, <mailto:netmod-ver-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 11:53:53 -0000

Hi Qin,

Thanks for the comments.



From: Netmod-ver-dt <netmod-ver-dt-bounces@ietf.org> On Behalf Of Qin Wu
Sent: 01 March 2019 07:10
To: Rob Wilton (rwilton) <rwilton@cisco.com>; netmod-ver-dt@ietf.org
Subject: Re: [Netmod-ver-dt] Latest doc version

Hi, Rob:
A few comments on the latest version

1.      Section 1, paragraph 2, 2nd bullet

      An extension to allow YANG module imports to be restricted to

      modules with particular semantic versions, allowing inter-module

      version dependencies to be captured within YANG module

      definitions.

  [Qin]s/An extension/A YANG extension

[RW]

OK



2.      Section 1.2, paragraph 2

   [Qin]: which requirements have not been addressed, should this be clear in this section?

[RW]

OK.



3.      Section 1.2 paragraph 3

   [Qin]:draft-wang-netmod-module-revision-management-01 section 4.1 is also

   targeted to address requirements 2.1 defined in draft-verdt-netmod-yang-versioning-reqs-02

   and will review details in section 6.

[RW]

We’ve not discussed this draft in the design team at all, so I think that we should find time to discuss this perhaps at IETF 104.



4.      Section 2.1

   Q.  Does statement ordering need to be considered as part of the

   comparison?  RW: I think the answer should be no.  RR: ordering

   matters for RPC/action input as per https://tools.ietf.org/html/

   rfc7950#section-7.5.7

   [Qin]: I believe when you compare two modules, statement order in one module

   should be adjusted to follow the same statement order of the other module. But

   not sure automation tool can be built to do this. Manual provision on the statement

   order is needed.

[RW]

For the moment, I am just tracking this issue at https://github.com/netmod-wg/yang-ver-dt/issues/6, and I intend to list this as an open issue in the draft.





5.      Section 2.2

      Module definitions that follow the semver.org 2.0.0 versioning

      scheme are fully compatible with implementations that understand

      the YANG semantic versioning scheme.

  [Qin]:What about module definitions that follows YANG semantics versioning schema defined in this document?

  are they compatible with implementation that understand YANG semantics version schema defined in this document,

  probably the answer is yes, but it is not clear in the text.

[RW]

Sorry, I don’t understand the question.





6.      Section 3, paragraph 3 said

“   changing the name of a leaf could break an

   import but frequently would not, ”

[Qin]:frequently changing the name of a leaf would not break an import? Would you clarify this?

[RW]

This just means that in many cases changing the name of a leaf is unlikely to break a module import, but it might (e.g. if another module had a leafref to that leaf).



7.      Section 3, paragraph 4

   [Qin]: Do we support some import statement contains version statement or

   some import statement contains revision-date? Are these important statement interchangeable?

[RW]

There are 3 choices:

-        Regular import

-        Import by version (which we adding)

-        Import by revision (which is basically broken)



8.      Section 5.1 said:

“

The following rules remove the ambiguity:”

I feel these rules are more related to RFC8407 instead of [I-D.ietf-netconf-rfc7895bis].

So the last rule should be default rule defined in RFC8407

[RW]

RFC8407 only provides guidelines.  We need something stronger than that.  Basically, if want it to be the case that if the server implements semver then it will follow these rules.  So I think that updating 7895bis (RFC 8525) is the right thing to do here.



Thanks for your comments.  I’ve incorporated them and updated the draft.



Thanks,
Rob





“

   If a module import statement could resolve to more than one module

   revision defined in the datastore schema, none of those revisions are

   implemented, and none of the modules revisions have a YANG semantic

   version number, then the import MUST resolve to the module that has

   the most recent revision-date.

”

The other two rules are additional rules that can be used to enhance RFC8407, but I didn’t check details.
Will review remaining sections when in convenience.

-Qin
发件人: Netmod-ver-dt [mailto:netmod-ver-dt-bounces@ietf.org] 代表 Rob Wilton (rwilton)
发送时间: 2019年2月28日 2:07
收件人: netmod-ver-dt@ietf.org<mailto:netmod-ver-dt@ietf.org>
主题: [Netmod-ver-dt] Latest doc version

Just pushed to the github develop branch.

Latest draft version attached.

Still to do:

-        Update abstract

-        Probably should add some definitions.

-        Resolve comments from Balazs (across the doc)

-        Resolve comments from Reshad on chapter 2.

-        Incorporate text from Balazs on instance data versioning.

-        Chapter 4 needs some serious focus.

-        Add tree output and updates the text around the YANG modules.

Thanks,
Rob