Re: [yang-doctors] reference in import statement

[Mahesh Jethanandani <[e-mail]>]

Benoit,

> On Feb 22, 2018, at 10:36 AM, Benoit Claise <[e-mail]> 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      [e-mail]         RFC7223
ietf-interfaces@2018-02-22               urn:ietf:params:xml:ns:yang:ietf-interfaces      [e-mail] <mailto:[e-mail]>         RFCXXXX

where the last column would be a hyperlink to the supporting document. No?

> 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, 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 <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> Mahesh Jethanandani <[e-mail]> 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
>>>>> <[e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>>>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>>>> 
>>>>> _______________________________________________
>>>>> yang-doctors mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/yang-doctors
>>>> Mahesh Jethanandani
>>>> [e-mail]
>>>> 
>>>> _______________________________________________
>>>> yang-doctors mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/yang-doctors
>>>> 
>> Mahesh Jethanandani
>> [e-mail]
>> 
>> _______________________________________________
>> yang-doctors mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/yang-doctors
> 

Mahesh Jethanandani
[e-mail]