Hi Tom, > On Jan 16, 2024, at 06:50, tom petch <[email protected]> wrote: > > From: Acee Lindem <[email protected]> > Sent: 15 January 2024 20:30 > > Hi Tom, > > Since this YANG model describes the RFC 8362 encodings, those encodings > should be the primary reference all the leaves and identifies. > > <tp> > > Acee > > I think that you are wrong. The historian in me knows that given a choice or > primary or secondary sources, the secondary can only get it wrong; you always > go back to the primary (unless or until the primary is replaced which is not > the case for most of the definitions here).
We can disagree then - I have included both references. Note that in any case, someone really want to dig into the contents of an OSPFv3 LSDB would need to reference both RFCs if they were not very familiar with OSPFv3 and the extended encodings. > >> On Jan 13, 2024, at 07:42, tom petch <[email protected]> wrote: >> >> From: Lsr <[email protected]> on behalf of The IESG >> <[email protected]> >> Sent: 11 January 2024 14:35 >> > <snip> > >> <tp> >> Most of my comments on this I-D from August are addressed but I still have >> some doubts. >> >> p.11 identity nu-bit >> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a >> better reference > > Agreed. However, I think including both references would be good since RFC > 8362 includes the > flags in TLVs > >> >> identity la-bit >> here RFC8362 changes the meaning so I think the reference to RFC8362 is ok > > Actually, for the LA-bit, both references would be good. > >> p.11 identity p-bit >> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a >> better reference > > Same as nu-bit. > >> p.12 identity dn-bit >> this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a >> better reference > > Same as nu-bit. > >> p.12 identity e-bit >> this is not esplained in the referenced RFC8362; in fact, this one defeats >> me. It is present in a diagram, s.3.6, but with no explanation. Reading >> RFC5340 it could be A.4.3 but I am not sure > > If one is familiar with OSPF, it is clear. For AS External and NSSA metrics, > there are type 1 and type 2 metrics. Type 1 are simply added to intra-area > metric to the originator. Type 2 metrics are considered greater than type 1 > metrics. This hasn’t changed since RFC 1247 - just the OSFPv3 and OSPFv3 > extended-LSA encodings. Since the description is brief, I’ll include it in > its entirety. > > <tp> > Indeed I learnt about Type 1 and Type 2 25 years ago and know them well; but > in the modern context of SR, IPv6, OSPFv3, extended LSA etc I did not > recognise the terse allusion. Yes - since it was not that verbose. I included the complete description in the description. > > And why do you not include the AC bit defined in RFC9513? We have a separate model for these OSPFv3 segment routing extensions. However, since the AC-bit is not unique to segment routing, I could just as well include it here. We’ll see if I get any more IETF Last Call comments. Thanks, Acee > > Tom Petch > > Thanks, > Acee > > > > >> >> Tom Petch >> >> >> >> Abstract >> >> >> This document defines a YANG data model augmenting the IETF OSPF YANG >> model to provide support for OSPFv3 Link State Advertisement (LSA) >> Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide >> extensible TLV-based LSAs for the base LSA types defined in RFC 5340. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
