Hi Job,

I do understand your logic here, and I don't disagree with it taken by itself; 
however, I'm not sure YANG development in the IETF or at least the rtg-area can 
survive this requirement either -- we're barely relevant as it is b/c we take 
so long to publish these modules.

The main value I have seen in the field is to have well considered and 
constructed models developed by experts that vendors look to for guidance in 
creating their own vendor specific versions -- that's mostly how I've used them 
in FRR at least, although I did implement the keychain module verbatim :)

To your point why not just publish experimental then; maybe we should. Will 
that dissuade the few people willing to work on YANG modules from doing so? I 
don't know, it may. In LSR we've made an effort and some good progress towards 
publishing YANG inline with the feature development, which I think has some 
value in itself. It would be a shame if we lost that.

Perhaps this should really be a discussion that happens more generally in 
netmod/ops area, and guidance or requirements then provided based on the that. 
I do think that discussion should consider that certain requirements may also 
adversely affect what little YANG development and relevance we do have in the 
IETF.

Thanks,
Chris.


> On Apr 1, 2026, at 07:03, Acee Lindem <[email protected]> wrote:
> 
> 
> 
>> On Apr 1, 2026, at 5:13 AM, Job Snijders <[email protected]> wrote:
>> 
>> Dear Acee,
>> 
>> On Fri, Mar 27, 2026 at 07:08:34PM -0400, Acee Lindem wrote:
>>>> The document shepherd write-up is deficient. In answer to question 4 (For
>>>> protocol documents, are there existing implementations of the contents of 
>>>> the
>>>> document? ) it says "N/A". But this is a Standards Track protocol document.
>>>> YANG models are implementable and it would give significant credence to the
>>>> completeness of this specification if this question had been answered with
>>>> implementation details. (Of course, it would have been even better to see 
>>>> an
>>>> Implementation Status section in the document.)
>>>> 
>>>> It remains up to the WG and AD whether to pursue publication of an
>>>> unimplemented YANG model.
>>> 
>>> I'm not sure where you've been over the last ten years, but the IETF
>>> YANG models have not been widely implemented. In LSR, we have chosen to
>>> publish them without requiring implementation.
>> 
>> It is concerning to read this practise has been going on for many years
>> already, however it being a tradition does not equate it being a good
>> practise.
>> 
>> How does the WG know that the models are implementable, or even
>> operationally relevant?
>> 
>> The problem I see is that the LSR WG might take up review/editorial/IESG
>> resources with their requests for RFC publication for documents that
>> later on are discovered to be unimplementable works of fiction. What
>> exactly is the purpose of rough consensus without running code?
>> 
>> If the goal is to positively inspire vendors to copy parts of these
>> unimplemented models, wouldn't "Experimental" fullfill the same purpose
>> just as well?
>> 
>> Why is Standards track considered appropriate for such documents?
> 
> Independent of whether the IGP YANG models are implemented, they provide a 
> very useful
> reference for routing protocols. Standardization of the configuration and 
> operational state
> is essential to advance the IGPs and serves as a reference model for protocol 
> implementation. 
> 
> I've got much more important things to worry about than this. If you would 
> like to contribute
> To the IETF YANG model implementation, Renato Westphal has implemented the 
> base IGP
> models in his open-source implementation. 
> 
> https://github.com/holo-routing/holo/tree/master/holo-ospf/src/northbound
> https://github.com/holo-routing/holo/tree/master/holo-isis/src/northbound
> 
> Thanks,
> Acee
> 
> 
> 
> 
> 
> 
> 
>> 
>> Kind regards,
>> 
>> Job


_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to