Re: What to reference when importing an IANA module?

Hi -

Serves me right for responding before reading all the messages in
my inbox.  I concur with Benoit's comments.

Randy

On 2023-01-16 2:49 AM, Benoit Claise wrote:
> Dear all,
> 
> On 1/13/2023 9:22 PM, Randy Presuhn wrote:
>> Hi -
>>
>> On 2023-01-13 10:20 AM, Kent Watsen wrote:
>>>
>>>
>>>> On Jan 13, 2023, at 11:25 AM, Benoit Claise 
>>>> <[email protected]> wrote:
>>>>
>>>> Hi Tom,
>>>>> Yes I do think that people outside the IETF may be ignorant of the 
>>>>> nuances of the way the IETF works and  may not realise that a URL 
>>>>> to the IANA website must be used in preference to an RFC.  There is 
>>>>> more to YANG modules than extracting the code from somewhere in 
>>>>> order to incorporate it into something.  I have even seen RFC 
>>>>> reference the obsolete list of possibilities  in the RFC that set 
>>>>> up an IANA registry
>>>> If this is the case (And Randy supports this), then we should update 
>>>> RFC 8047.
>>
>> Benoit's reference to RFC 8047 had me puzzled until I saw Kent's
>> response regarding RFC 8407.  :-)
>>
>>> Agreed - as a hold for document update?
>>>
>>> Currently RFC 8407, Section 3.9 says:
>>>
>>>     For every import or include statement that appears in a module
>>>     contained in the specification that identifies a module in a 
>>> separate
>>>     document, a corresponding normative reference to that document MUST
>>>     appear in the Normative References section.  The reference MUST
>>>     correspond to the specific module version actually used within the
>>>     specification.
>>
>> I agree with Kent's "hold for document update" assessment.  The
>> difficultly with the existing text is that it correctly reflects
>> the concerns that were at the forefront when it was written -
>> e.g. making it as easy as possible for developers to get the
>> necessary context for implementing a module, but, as far as
>> I can recall, the group hadn't thought as deeply about
>> registries spun off from an initial document.
>>
>>> Want to take a swing at it?
>>
>> Not me.  :-)  There are competing requirements, and the "best" answer
>> will very much depend on each situation.  I think the *spirit* of
>> the RFC 8407 Section 3.9 is  "point to whatever resource will be most
>> enlightening to the developer / user."  But the letter of the law is
>> "point to whatever is needed to generate a tree of normative
>> reference dependencies" - that is, use what will be most helpful
>> to the people writing the standards.  There's a point to both kinds of
>> pointers.
>>
>> When in doubt, my preference is to go whichever way will make it
>> harder for implementations to get it wrong.
> Agree on the principles, but there is no quick fix.
> Look at Med's proposal:
> 
>         If an IANA-maintained module is imported by another module, a
>         normative reference with the IANA URL from where to retrieve the
>         IANA-maintained module SHOULD be included.  Although not encouraged,
>         referencing the RFC that defines the initial version of the IANA
>         module is acceptable in specific cases (e.g., the imported version is
>         specifically the initial version, the RFC includes useful description
>         about the usage of the module).
> 
> If we want to add an IANA link to update RFC 8407, Section 3.9, a couple 
> of remarks:
> - It's not clear what "a normative reference with the IANA URL" is.
>      Is it 
> https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml?
>      Or is it 
> https://www.iana.org/assignments/yang-parameters/[email protected]?
>      The more precise the later, right?
>      However, the latter, which is a typical example of IANA maintained 
> YANG module does NOT work, as the revision in the URL changes with any 
> IAN update
> - So this leads to have both RFC and IANA, so 
> https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml + 
> RFC7224 (in the above example)
> - Also, we should make more generic for some other SDOs, as IANA is for 
> IETF only.
>    And the guidelines are followed by others: BBF, IEEE, etc.
> 
> Regards, Benoit
>>
>> Randy
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
> 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod