Hi, About the name, here are some suggestions about the module name and prefix:
- ietf-isis-feature-support.yang, isis-fs (YANG Module for IS-IS Feature Support) - ietf-isis-conformance-state.yang, isis-cs (YANG Module for IS-IS Protocol Conformance Statement) - ietf-isis-protocol-compliance.yang, isis-pc (YANG Module for IS-IS Protocol Compliance Report) - ietf-isis-functionality-conformance.yang, isis-fc (YANG Module for IS-IS Functionality Conformance) - ietf-isis-function-support.yang isis-fs (YANG Module for IS-IS Functional Support) The authors are open to suggestions. Thanks, Yingzhen On Fri, Nov 17, 2023 at 1:37 PM Acee Lindem <[email protected]> wrote: > Speaking as WG member: > > Ok - I can see that I’m in the minority here in thinking this should be at > a less granular level than specific TLVs. We can see where the more > granular definition takes us and I’ll help with the OSPFv2/OSPFv3 models. > > Hopefully, the enthusiasm for implementation will match our IGP protocol > support modeling efforts. > > Thanks, > Acee > > > On Nov 17, 2023, at 4:14 AM, [email protected] wrote: > > > > Orange Restricted > > From: Lsr <[email protected]> On Behalf Of Acee Lindem > > Sent: Thursday, November 16, 2023 11:33 PM > > To: Les Ginsberg (ginsberg) <[email protected]> > > Cc: Loa Andersson <[email protected]>; [email protected] > > Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang > > Speaking as a WG contributor: > > Hi Les, > > I think a simpler name is better - perhaps > ietf-isis-feature-support.yang with YANG prefix isis-fs would be better. > Which brings me to my next and more important point… > > Like carbon neutrality, everyone at the LSR WG meeting who had an > opinion thought such a YANG model would be operationally useful. However, I > think the level of granularity is key. > > [Bruno] +1 > > I agree that the level of granularity is key. > > I’d rather call for a significant granularity (but I’d welcome any > pushback). > > Personally, I don’t see why per TLV granularity would not be ok: it’s ok > to implement which is more work, so just listing the supported TLV and > sub-TLV should be doable. In any case, operators, pre-sales and support > engineers will likely need this information some day. So let’s just fill it > once for all and have it available for all persons. > > I’d would even call for more granularity. E.g. for RFC 5130, for “32-bit > Administrative Tag Sub-TLV 1”, “On receipt, an implementation MAY consider > only one encoded tag, in which case, the first encoded tag MUST be > considered and any additional tags ignored. » > > To me, if the WG bothered making such granularity at the > feature/TLV/implementation level, we need such granularity at the reporting > level. And that’s not theoretical, I had to check that for a project a > month ago. At best, it’s indicated in the vendors documentation, so the > data is there, so let’s make it friendly to digest. At worst, we need to > involve expensive people 😉. > > If we want less granularity, let’s do less granularity in spec > (everything is MUST) > > https://datatracker.ietf.org/doc/html/rfc5130#section-3.1 > > Thanks, > > --Bruno > > I believe that having a separate data node for each TLV/sub-TLV as was > done in the example ietf-isis-pics-sr-mpls.yang module is way too granular > to be useful. Rather, the YANG reporting should be done at the feature > level. Also, does a distinction need to be made as to whether the IS-IS > node supports the feature or both supports it and has it enabled (as would > be the case for non-backward compatible features)? > > Thanks, > > Acee > > On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) <ginsberg= > [email protected]> wrote: > > Loa - > > > > I agree with you that simply "IS-IS Support" may not be the best choice. > > Although, the meeting minutes have not yet been posted, as I recall my > response to Tony Li's suggestion of "IS-IS Support" was "Yes - something > like that." > > > > The draft authors have not yet discussed this - but we will and share > the proposed new name. > > Other suggestions welcomed. > > > > Les > > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of Loa Andersson > > Sent: Thursday, November 16, 2023 2:06 AM > > To: [email protected] > > Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang > > > > Working Group, > > > > During the presentation of draft-qgp-lsr-isis-pics-yang there was a > > rather strong opposition in the chat against using the ISO-term "PICS" > > in an IETF document. > > > > I think the term "Support" was suggested (excuse me if I missed > > something), but I'm not that impressed, and would rather like to see > > something like - "Supported Protocol Aspects". > > > > /Loa > > -- > > Loa Andersson email: [email protected] > > Senior MPLS Expert [email protected] > > Bronze Dragon Consulting phone: +46 739 81 21 64 > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > > ____________________________________________________________________________________________________________ > > 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] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
