Re: [yang-doctors] reference in import statement

[Benoit Claise <[e-mail]>]

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 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