On Tuesday, December 21, 2021, 05:13:24 AM EST, t petch <ie...@btconnect.com> 
wrote:
 
 
 On 16/12/2021 22:43, Reshad Rahman wrote:
>  Hi,
>      On Wednesday, December 15, 2021, 09:40:05 AM EST, Martin Björklund 
><mbj+i...@4668.se> wrote:
>
>  Hi,
>
> Jeffrey Haas <jh...@pfrc.org> wrote:
>> Tom,
>>
>> On Wed, Dec 15, 2021 at 09:47:50AM +0000, t petch wrote:
>>>> Which begs the question that I think Jeff was asking - what is the 
>>>> recommendation for updating modules that import modules that undergo a 
>>>> revision?
>>>
>>> The point here is that we have RFC9127 with seven modules, five
>>> importing bfd-types from therein, so if we upgrade bfd-types to
>>> provided needed funtionality then it behoves us to make clear IMHO
>>> that this upgrade is ok for the other five, which can be done by
>>> changing the import reference to be 9127-bis and not RFC9127, a one
>>> line, documentation change in each of the five modules (which
>>> unfortunately then need a new revision, date, IANA Considerations
>>> but that is business as usual).
>>>
>>> What other WG do is up to other WG.  Let's make this I-D right.
>>
>> Your position is understood.
>>
>> Martin basically states this is a procedural question:
>> : What makes this case special is that you plan to (re)publish modules
>> : with references to the document that you are replacing.
>> :
>> : I'm not sure that this is a YANG doctors question... it seems more of
>> : a procedural issue.
>>
>> "Special" implies this is a variance from expectations.
>>
>> The advice being solicited from the YANG doctors is what expectations are.
>>
>> Martin (and others), is the republish solely to update references unusual?
>
> I have never seen such an update.
>
> Also note that the intention with the reference statement is to refer
> to the spec that was current at the time the reference statement was
> written.  Since there is no import-by-revision, we are explicitly
> prepared to handle newer versions of the imported module (provided the
> module follow the upgrade rules).
>
> I think this can be compared to references in RFCs.  If RFC A has a
> reference to RFC B, A doesn't have to be updated if B is updated.
>
> <RR> And in the case of 9127-bis, the modified grouping is not used by any of 
> the modules in that document (only in the "routing" YANG documents).So 
> spinning a new revision for these BFD modules just for the sake of updating 
> the reference seems "wasteful". But I have no idea if there are any 
> rules/guidelines for this kind of change.

End of WG LC and I await a consensus call from the chairs.

I see three options.  The worst one is the present I-D, neither flesh 
nor fowl.
Publishing something that is clearly not a bis but just includes a new 
bfd-types is not so bad but for me leaves a confusing trail behind it. 
The two versions of bfd-types will only be a few months apart so I am 
comfortable that the later one can be regarded as current when the 
others were written, which, as Martin says, is what the reference 
statement means.  It will mean that RFC9127 has references to RFC9127 
for bfd-types while other modules from other WG will have reference a 
version of a few months later which will cause some to scratch their 
heads in future and wonder what has gone wrong here.
<RR> Ack (we discussed this). But note that irrespective of what we do in BFD, 
some modules in other WGs may/will still refer to 9127, so some confusion will 
remain in that regard.
Publishing a genuine 9127-bis with the IANA module excised and the 
references updated so that everyone uses the same reference is to me the 
clearest statement of what is available and should be used from now on.
<RR2> Would 9127-bis obsolete or update 9127? I think it has to be update.I can 
live with this approach although it still irks me to spin a new module revision 
just for the sake of updating a reference is overkill and potentially confusing 
in a different way. Maybe that's only because it's not usually done.   
A 4th option would be like option 3 but to only change references where needed. 
That was my preferred option but since we do have to change the references in 
ietf-bfd-mpls, it would seem odd to change 1 module and not the others. 
Regards,Reshad (no hat).
Tom Petch


> Regards,Reshad (no hat).
> /martin
>
> _______________________________________________
> yang-doctors mailing list
> yang-doct...@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
>
  

Reply via email to