Some additional thoughts regarding the “name”… I can understand why people are averse to an old ISO acronym like “PICS” – but there are some accurately chosen words in that acronym. Let’s examine this:
P = Protocol This is redundant – implicit given this is about IS-IS Not needed I = Implementation What is being described is the state of an implementation. Needed I don’t think any of the suggested alternatives (“support” “functionality” “feature”) are as appropriate. C = Conformance Yes – we are reporting conformance – but what else would we report? Non-conformance?? Not needed S = Statement A noun to define “what” is being produced. This is needed – but I think there are a number of synonyms which might be equally as apt: “Report” “Description” “Information” “Summary” “Record” “Declaration” My first choice: ietf-isis-implementation-description.yang, isis-id (YANG Module for IS-IS Implementation Description) My second choice: ietf-isis-implementation-declaration.yang, isis-id (YANG Module for IS-IS Implementation Declaration) Some additional notes: I have to admit I was tempted to choose “isis-implementation-statement” – which could lead to the abbreviation “is-is-is” – but I thought better of it. 😊 I also considered “isis-implementation-report” – but as “implementation-report” is already used in the IETF for a different purpose I thought it would be confusing. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of Yingzhen Qu Sent: Saturday, November 18, 2023 9:11 AM To: Acee Lindem <acee.i...@gmail.com> Cc: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; Loa Andersson <l...@pi.nu>; lsr@ietf.org Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang 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 <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> 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, > bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote: > > Orange Restricted > From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of > Acee Lindem > Sent: Thursday, November 16, 2023 11:33 PM > To: Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> > Cc: Loa Andersson <l...@pi.nu<mailto:l...@pi.nu>>; > lsr@ietf.org<mailto:lsr@ietf.org> > 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=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> > 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 <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of > Loa Andersson > Sent: Thursday, November 16, 2023 2:06 AM > To: lsr@ietf.org<mailto:lsr@ietf.org> > 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: l...@pi.nu<mailto:l...@pi.nu> > Senior MPLS Expert > loa.pi...@gmail.com<mailto:loa.pi...@gmail.com> > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org<mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org<mailto:Lsr@ietf.org> > 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 Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
