Re: [yang-doctors] reference in import statement

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 23 February 2018 06:58 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6561243FE for <yang-doctors@ietfa.amsl.com>; Thu, 22 Feb 2018 22:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T7KNTLEu5A3f for <yang-doctors@ietfa.amsl.com>; Thu, 22 Feb 2018 22:58:42 -0800 (PST)
Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD96C124234 for <yang-doctors@ietf.org>; Thu, 22 Feb 2018 22:58:42 -0800 (PST)
Received: by mail-pl0-x22d.google.com with SMTP id 31so4416431ple.9 for <yang-doctors@ietf.org>; Thu, 22 Feb 2018 22:58:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UrCk4W03JpFnbhxFB59hGzXZZDGJtGQD3qioCtFjHmM=; b=i4cjG3sMudJFG8ZHEZS2YnJtIJWcygBMf7AkuPRQK+nut3VHxxNG/TgTTUF8TyvUvK n5wsABP7/bR8PzR8U0u0AqLKn9AwIo9EyRK8zWe9kf0AotZmRo/SvIBkc5M+0MIxhbb1 u9vykxbW9tgL7xq/hVJZdycJNfeUTnkwlg4RwrVAReBWnEaaWEzgsKX0BMp5wLDSzmgu D4Rm/1b0z4c0PUuILNtSPkRpXy0VR1VROWcgK0bEWm3fn4uD2hylXlAR8OyXarw9hFz9 A08695db4criPLUSKiUhUNby4kzJ4sQgW9CchlNuK0Moyw8Krhnh2qehh6CVCQe2opku ZwBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UrCk4W03JpFnbhxFB59hGzXZZDGJtGQD3qioCtFjHmM=; b=Mh4XJxFz0itTQl35sHVvt6WkpHRSiETYf2KGyMwN0WZLJ3MP7lqhDKQ5lOJa2zwpkh rTtVvJkG5CwX5zTaF0CU1dF6KUUAfvhjn/JbyP6Q72oXBgP2KMevDOYTVRjD+xsDC/6p LBeoBSwYCrzb7oJEL97jLTc0iVdx243t1xyW2yu+s0M/vAk3DxUitjRDZa2ll5LQF9S+ 3xzLu0Vdwzif+Kfc5TANDf8uUcs2KOb78rKxchoLyIDsQyOVjUwnQpjcyF0Z+irU28NA fP5NshNicPUsJVovd1fyMfrhAk8xX+sL8m0Lnx2JUWUXe8J62rpqT9+vy3zd3qnKuXjx J2ew==
X-Gm-Message-State: APf1xPA44JLSG7cT6/VX/S1GRKGeUz03IuX6kIzx5VLFDLfjTnkzqXid usnw0+boSX3tpleNJ4NigmE=
X-Google-Smtp-Source: AH8x224DZ3Gd9QzImDU6BPu484AFdf9UMXhjfclHoqh5lLdiFPIXuTy06kWDyZ9CC2ody1ZPH43/pA==
X-Received: by 2002:a17:902:9a98:: with SMTP id w24-v6mr758410plp.188.1519369121981; Thu, 22 Feb 2018 22:58:41 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:9d2d:1cd4:b8b7:50ab? ([2601:647:4700:1280:9d2d:1cd4:b8b7:50ab]) by smtp.gmail.com with ESMTPSA id 66sm3135008pfh.96.2018.02.22.22.58.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2018 22:58:41 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <5C700541-149D-453D-B3E7-B34CF3BE333B@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_45F25211-3DA9-4BF6-A1FA-0A8AEBA1C594"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 22 Feb 2018 23:04:15 -0800
In-Reply-To: <20180222205914.2fmyp4733wqckrvb@smtp.juniper.net>
Cc: Benoit Claise <bclaise@cisco.com>, yang-doctors@ietf.org
To: Ebben Aries <exa@juniper.net>
References: <20180215083130.uagwwr5huxgs5qst@elstar.local> <9783C687-6D5B-4FF4-BFB6-3D9FA62DB249@gmail.com> <20180222.085323.144940543114040096.mbj@tail-f.com> <A37B4457-245F-4ACA-957E-94206F08C491@gmail.com> <14396a94-e79f-1c94-564f-d1a9ebf87aec@cisco.com> <80C8A9F0-1067-4937-9FC1-7D18070CDF7A@gmail.com> <20180222205914.2fmyp4733wqckrvb@smtp.juniper.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/b8n8ogXbeoIVYX56LSvLK-wt2EM>
Subject: Re: [yang-doctors] reference in import statement
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Feb 2018 06:58:46 -0000

Ebben,


> On Feb 22, 2018, at 12:59 PM, Ebben Aries <exa@juniper.net> wrote:
> 
> On Feb 22 11:02 AM, Mahesh Jethanandani wrote:
>> Benoit,
>> 
>>> On Feb 22, 2018, at 10:36 AM, Benoit Claise <bclaise@cisco.com> wrote:
>>> 
>>> Dear all,
>>> 
>>> I think that keeping the reference is good thing. Btw, this is not specifically a reference to where the YANG module is, but mainly where the supporting document is.
>>> I think that having the reference pointing to where the extracted YANG module is (read the IANA registry, as Mahesh suggested) misses the pointer to the supporting document.
>> 
>> I was thinking the registry would be of this format:
>> 
>> ID                                                  URI                                                             Filename                                          Reference
>> 
>> ietf-interfaces@2014-05-08               urn:ietf:params:xml:ns:yang:ietf-interfaces      ietf-interfaces@2014-05-08.yang         RFC7223
>> ietf-interfaces@2018-02-22               urn:ietf:params:xml:ns:yang:ietf-interfaces      ietf-interfaces@2018-02-22.yang <mailto:ietf-interfaces@2018-02-22.yang><mailto:ietf-interfaces@2018-02-22.yang <mailto:ietf-interfaces@2018-02-22.yang>>         RFCXXXX
>> 
>> where the last column would be a hyperlink to the supporting document. No?
>> 
> 
> I agree w/ Martin's comments below regarding modules being detached and
> living their own life outside of the originating document.  With that
> said each module will have its revision-date w/ a reference to its
> supporting document.  Isn't this all you are describing in the above
> registry example?
> 
> What we're talking about here is a reference on import w/o an import by
> revision (Otherwise this reference should match up cleanly).  To a
> module consumer, this can prove handy if they are just dealing w/ the
> modules offline but this reference is detached from the possible
> iterations that have come over separate supporting documents over time
> thus creating this confusion of a potential soft relationship to a
> specific revision.
> 
> If you aren't importing by revision then this really means the
> dependency can be fulfilled by any revision you have accessible or
> assume the latest.  These dependency modules will have their respective
> references encoded within each so I'm not sure there is that much of a
> need to have this encoded in each import statement tbh
> 
> If we leave out the reference, a consumer has to find another way to
> resolve the dependency and find a module other than going to the
> supporting document referenced (Which really shouldn't be the preferred
> way in which folks resolve dependencies).  If we leave in the reference
> and that dependency iterates over time, this can become out of date and
> in need of update to all modules referencing said dependency even though
> we are not importing by revision.

I should have added one more line to the example above to demonstrate the point I was trying to make:

ID                                                  URI                                                             Filename                                          Reference

ietf-interfaces@2014-05-08               urn:ietf:params:xml:ns:yang:ietf-interfaces      ietf-interfaces@2014-05-08.yang         RFC7223
ietf-interfaces@2018-02-22               urn:ietf:params:xml:ns:yang:ietf-interfaces      ietf-interfaces@2018-02-22.yang         RFCXXXX (where XXXX is the RFC number that is assigned to rfc7223bis)
ietf-interface                                       urn:ietf:params:xml:ns:yang:ietf-interfaces      ietf-interfaces@2018-02-22.yang         RFCXXXX

The last entry, without a revision number, is entry for the latest version of the model and in this case will point to the latest ietf-interfaces model that is released as part of rfc7223bis.

The idea being that models importing ietf-interfaces without revision, have a reference to the last line in the IANA registry. And that line gets updated every time the ietf-interfaces model is updated. That way none of the models that import without revision need to be updated, because their reference would always be to the latest version of the model.

It solves the problem of consumers looking for references, and it also solves the problem of updating all module references when a dependent module is changed.

>>> I think that this problem is maybe not that confusing. Either people find the YANG module from the RFCs and they would see RFCbis links, or people find YANG module from a repo (IANA, yangcatalog.org <http://yangcatalog.org/>, github) and they would directly discover the latest revision. So adding "(at the time of this writing)" doesn't hurt but doesn't add a lot of value. Actually, this is typically the type of rules that hurts if not done consistently. Ex: 90% of YANG modules contains "(at the time of this writing)", while the complementary 10% doesn't. What should I conclude for the 10%? Something special or simply an oversight?
>>> 
>>> Regards, Benoit (as a contributor)
>>>> Hi Martin,
>>>> 
>>>> 
>>>>> On Feb 21, 2018, at 11:53 PM, Martin Bjorklund <mbj@tail-f.com <mailto:mbj@tail-f.com>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>>>>>> I agree that this is grounds for confusion.
>>>>>> 
>>>>>> My preference would be that we NOT have a reference statement for
>>>>>> import, or a comment for that matter, unless the module is doing
>>>>>> import by revision. The text of the document is already required to
>>>>>> have normative references to whatever the module imports.
>>>>> I think this would be quite unfortunate, even though I agree that it
>>>>> might be confusing to have the reference.  The problem with having
>>>>> the reference only in the main body is that modules are typically
>>>>> extracted from the RFCs and live their own life.  So all you have is a
>>>>> list of various imported modules, and it is not obvious where to find
>>>>> them.
>>>> Wasn’t the idea to not have the relationship between RFC number and a YANG model because of some of these very reasons, and move to IANA maintaining a copy of all version of the YANG models? If so, would it not make sense to refer to the IANA registry, rather than point to the RFC?
>>>> 
>>>>> We added the "reference" statement to "import" for this very reason in
>>>>> YANG 1.1.
>>>>> 
>>>>> So maybe the best solution is the one suggested by Juergen initially:
>>>>> 
>>>>>   reference "RFC 6991: Common YANG Data Types
>>>>>                (at the time of this writing)";
>>>>> 
>>>>> 
>>>>> Or maybe we declare that in fact this is not confusing (or at least it
>>>>> is not a major issue) - people are aware of the fact that documents
>>>>> evolve, and that there might be a more recent version available.
>>>>> 
>>>>> 
>>>>> /martin
>>>>> 
>>>>>> Cheers.
>>>>>> 
>>>>>>> On Feb 15, 2018, at 12:31 AM, Juergen Schoenwaelder
>>>>>>> <j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I have just seen this pattern
>>>>>>> 
>>>>>>> import ietf-inet-types {
>>>>>>>   prefix "inet";
>>>>>>>   reference "RFC 6991";
>>>>>>> }
>>>>>>> 
>>>>>>> and I wonder how people understand this. From the way this import
>>>>>>> works, any (newer) version of ietf-inet-types is OK to use to resolve
>>>>>>> the import but I could see that this statement makes people believe
>>>>>>> they have to use the version of ietf-inet-types contained in RFC 6991
>>>>>>> (but then this should have been import by revision). I know that we
>>>>>>> had a common practice to have comments before this was possible, like
>>>>>>> 
>>>>>>> import ietf-inet-types {             // RFC 6991
>>>>>>>   prefix "inet";
>>>>>>> }
>>>>>>> 
>>>>>>> but then this was a comment, now the RFC numbers becomes part of the
>>>>>>> definition. Should we be concerned about this? Or should we suggest
>>>>>>> to be more clear about this, e.g.:
>>>>>>> 
>>>>>>> import ietf-inet-types {
>>>>>>>   prefix "inet";
>>>>>>>   reference "RFC 6991 (at the time of this writing)";
>>>>>>> }
>>>>>>> 
>>>>>>> /js
>>>>>>> 
>>>>>>> -- 
>>>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>>>>> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=veqwbYHV1hLJdgQPus6LkKH-qWMRlJYVp3UMxeQ9_r0&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=veqwbYHV1hLJdgQPus6LkKH-qWMRlJYVp3UMxeQ9_r0&e=>>
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> yang-doctors mailing list
>>>>>>> yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e=>
>>>>>> Mahesh Jethanandani
>>>>>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>>>>>> 
>>>>>> _______________________________________________
>>>>>> yang-doctors mailing list
>>>>>> yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e=>
>>>>>> 
>>>> Mahesh Jethanandani
>>>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>>>> 
>>>> _______________________________________________
>>>> yang-doctors mailing list
>>>> yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e=>
>>> 
>> 
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>> 
> 
>> _______________________________________________
>> yang-doctors mailing list
>> yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e=>
Mahesh Jethanandani
mjethanandani@gmail.com