Re: [netmod] RFC 7950 - Import without revision

Robert Wilton <rwilton@cisco.com> Tue, 07 March 2017 10:03 UTC

Return-Path: <rwilton@cisco.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 C738C129455 for <netmod@ietfa.amsl.com>; Tue, 7 Mar 2017 02:03:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 bVvAfYInKlB8 for <netmod@ietfa.amsl.com>; Tue, 7 Mar 2017 02:03:02 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B78129434 for <netmod@ietf.org>; Tue, 7 Mar 2017 02:03:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7314; q=dns/txt; s=iport; t=1488880981; x=1490090581; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bvjCITg+b2dLdTyKD07DpNRPn3UnGVf0byfaxJwAynE=; b=biSZUEOfxFnbv2hBB8ZaHWdmWhIOzEY0cohUJEgYsD30u/whn80tKHdq rnL62gAsFcyjPymBw0WFdJzpNpVi0DBzA0lpZCiNUT6U3TozydCP74v3l uHSZ/Mp3/tBx2AI30oBJvbuuBx0XlYeWEtAqLiVtAAZ8HyFFu7boerkqK I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CLAgC3hL5Y/xbLJq1UCRkBAQEBAQEBAQEBAQcBAQEBAYJuOYELAydgjWtzkFeQC4Usgg0fAQqFLkoCgmQYAQIBAQEBAQEBax0LhRYBAQQBAWwbCxguJzAGDQYCAQGJeA6xRCuKUgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6CBYJqgTyCcRGFewWcMIZ2i0CKToZRizKICR84gQMiFQgXFT+EYYFzQDWKEwEBAQ
X-IronPort-AV: E=Sophos;i="5.35,258,1484006400"; d="scan'208,217";a="651250744"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 10:02:59 +0000
Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v27A2xVX008718 for <netmod@ietf.org>; Tue, 7 Mar 2017 10:02:59 GMT
To: "netmod@ietf.org" <netmod@ietf.org>
References: <c13a86d6-0389-843d-d5eb-fe56ec5486ef@cisco.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <c19e9b2f-d392-558a-340c-23cae0456a19@cisco.com>
Date: Tue, 07 Mar 2017 10:02:59 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <c13a86d6-0389-843d-d5eb-fe56ec5486ef@cisco.com>
Content-Type: multipart/alternative; boundary="------------70982D8F6773CF924CA79B5D"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_Wuhd-r4SMTd-lrU16CsvRxg8Hc>
Subject: Re: [netmod] RFC 7950 - Import without revision
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 07 Mar 2017 10:03:04 -0000

Another place in the draft that appears to be inconsistent with the 
section 5.6.5 text below is in 7.1.5, last sentence of this paragraph:

    When the optional "revision-date" substatement is present, any
    typedef, grouping, extension, feature, and identity referenced by
    definitions in the local module are taken from the specified revision
    of the imported module.  It is an error if the specified revision of
    the imported module does not exist.*If no "revision-date" substatement is present, it is undefined from 
which revision of the module they are taken.*


I think that section 5.6.5 does define which revision is used (as the 
text below). I.e. it is the most recent revision out of all the module 
revisions that are imported or implemented.

Rob


On 27/02/2017 11:15, Robert Wilton wrote:
>
> in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by 
> Revision" states:
>
> "If a module is not imported with a specific revision, it is 
> undefined which revision is used."
>
> But I was wondering if the above text is misleading, since section 
> 5.6.5: "Implementing a Module" has the following two paragraphs:
>
>     If a server implements a module A that imports a module C without
>     specifying the revision date of module C and the server does not
>     implement C (e.g., if C only defines some typedefs), the server MUST
>     list module C in the "/modules-state/module" list from
>     "ietf-yang-library" [RFC7895 <https://tools.ietf.org/html/rfc7895>], and it MUST set the leaf
>     "conformance-type" to "import" for this module.
>
>     If a server lists a module C in the "/modules-state/module" list from
>     "ietf-yang-library" and there are other modules Ms listed that import
>     C without specifying the revision date of module C, the server MUST
>     use the definitions from the most recent revision of C listed for
>     modules Ms.
>
>     The reason for these rules is that clients need to be able to know
>     the specific data model structure and types of all leafs and
>     leaf-lists implemented in a server.
>
> This seems to imply that import without specifying the revision would 
> mean that the latest revision listed in ietf-yang-library must be the 
> one that is imported.  Is that correct, or am I misinterpreting the 
> text?  Hence, should the last paragraph of section 5.1.1 be deleted?
>
> Thanks,
> Rob
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod