Re: [yang-doctors] RFC 9127-bis question - impact of reference clauses in an import statement

[t petch <[e-mail]>]

On 14/12/2021 16:24, Jeffrey Haas wrote:
> Martin,
>
> On Tue, Dec 14, 2021 at 05:20:42PM +0100, Martin Björklund wrote:
>>> On Thu, Dec 09, 2021 at 05:12:07PM -0500, Jeffrey Haas wrote:
>> Would it be possible to avoid the problem by not doing a full
>> 9127bis, but just publish an RFC with a new version of ietf-bfd-types?
>
> Tom seemed to think that was not acceptable.

Tom here,

The point of the update is to provide a feature so that the published 
modules (e.g. five such in RFC9127) can stop having deviations, a 
laudable aim.

But if the five published modules reference RFC9127 while importing 
bfd-types, then the import (no revision) will pick up the latest 
bfd-types from 9127-bis and so the feature will be available to them, no 
deviation needed.

What will be wrong, for the next five years or so, will be that anyone 
looking at those five modules in RFC9127, the latest version for those 
five, will see the import of bfd-types with reference to RFC9127 and 
will know that that is what they were tested with, developped with, and 
so will know that the feature should not be used because it is not in 
the referenced RFC9127 for the import; it might work they will think but 
should we risk it?  (The issue of import and its reference was much 
discussed during the development of YANG - it is there for guidance, 
like a SHOULD not a MUST).

My alternative is to publish 9127-bis without the IANA module because 
that is done and dusted, with the new bfd-types with its feature and 
updating the other five to reference 9127-bis in the import reference to 
show that it is ok to use the feature in the context of those five modules.

That will call for 10 or so more lines of change in 9127-bis to update 
the five import reference and to ask IANA to update the reference in 
IANA Considerations for 9127-bis for those five modules to point to 9127-bis

Tom Petch



>
> If this is the acceptable way to handle this, it's likely preferable.
>
>
> -- Jeff
> .
>