Acee – Thanx for the comments – inline.
From: Acee Lindem <acee.i...@gmail.com> Sent: Thursday, November 16, 2023 2:33 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Loa Andersson <l...@pi.nu>; 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… [LES:] My problem with “feature” in the name is that it suggests that the concept is not applicable to the base protocol – which isn’t the case. Note that I am not suggesting (or even expecting) that we will introduce YANG to cover base protocol functionality – but it would be legitimate to do so. But, I am not rejecting the suggestion – just sharing some thoughts. 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. 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. [LES:] I strongly disagree with that – and we chose SR-MPLS as the first example to illustrate why a simple Boolean is not sufficient. There are many real world examples of implementations that support portions of an RFC – but not its entirety. In the case of SR-MPLS there are implementations that support IPv4 but not IPv6. There are implementations which don’t support SRMS advertisements. Etc. This is important for operators to know when they are planning deployments. 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)? [LES:] The point was made that this has nothing to do with whether a feature has been enabled or not. The support information should be retrievable without even having instantiated an IS-IS instance on the router. I believe this was further highlighted in the chat by a suggestion that this information could be retrievable from a vendor wiki. We have config models to determine what is actually enabled. Les Thanks, Acee On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org<mailto:ginsberg=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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
