Hi Chris, all,
I agree with Chris that this is a generic discussion that should not be
blocking the progress of this document and which needs to be done at a wider
level.
FWIW, the discussion has taken place as part of the IAB NEMOPS workshop and is
being further explored within NMOP WG with a hope to have a consolidated set of
recommendations in this area. The specific point about implems is anchored to
the following:
OPS-REQ-READILY-IMPLEM: The availability of implementations is
concerning. Consider catalyst approaches to trigger more (open)
implementations, especially during the development of protocols/
extensions.
However, the big picture is more nuanced and should be balanced as there is
also the following need; LSR is doing a great job in this front:
OPS-REQ-STRENGTHEN-DM: Network softwarization can only happen with a
strong, committed standardization effort, complemented by active
involvement in open-source projects that facilitate access to
code.
Particularly, without data models, a Network API is essentially
useless.
OPS-REQ-TIMELY-DM: Consider having YANG as part of the protocol
specification/change where possible, or have the YANG document
progress in parallel. That may slow down the protocol
specification, though.
For those interested in continuing discussion on this specific point, please
reach out NMOP and share your views there. This OPS-DIR thread should not be
used for that.
Thank you.
Cheers,
Med
> -----Message d'origine-----
> De : Christian Hopps <[email protected]>
> Envoyé : jeudi 2 avril 2026 08:14
> À : Acee Lindem <[email protected]>
> Cc : Christian Hopps <[email protected]>; Job Snijders
> <[email protected]>; [email protected]; [email protected]; draft-ietf-
> [email protected]; last-call <last-
> [email protected]>; lsr <[email protected]>
> Objet : [OPS-DIR]Re: [Last-Call] Broken tooling : draft-ietf-lsr-
> ospf-flex-algo-yang-05 ietf last call Opsdir review
>
>
> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> gith
> > ub.com%2Fholo-routing%2Fholo%2Ftree%2Fmaster%2Fholo-
> ospf%2Fsrc%2Fnorth
> >
> bound&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9120db3ddde1
> 4b63
> >
> 846408de907f6884%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6391
> 0707
> >
> 4065725402%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI
> wLjA
> >
> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7
> C%7C
> >
> &sdata=X5ZREng5fDC2DHdtSGl53ofXVP%2BeOCa%2FYq%2F22QT1RAo%3D&reserv
> ed=0
> >
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> gith
> > ub.com%2Fholo-routing%2Fholo%2Ftree%2Fmaster%2Fholo-
> isis%2Fsrc%2Fnorth
> >
> bound&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9120db3ddde1
> 4b63
> >
> 846408de907f6884%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6391
> 0707
> >
> 4065742007%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI
> wLjA
> >
> uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7
> C%7C
> >
> &sdata=%2B8o8WPPLD80A08W%2FKT%2B7%2BgFHKlf9ye3mG8HCNr%2FpUVw%3D&re
> serv
> > ed=0
> >
> > Thanks,
> > Acee
> >
> >
> >
> >
> >
> >
> >
> >>
> >> Kind regards,
> >>
> >> Job
>
>
> _______________________________________________
> OPS-DIR mailing list -- [email protected] To unsubscribe send an
> email to [email protected]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
