Re: [Lsr] Last Call: <draft-ietf-lsr-ospfv3-extended-lsa-yang-25.txt> (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard

Hi Tom, 

Since this YANG model describes the RFC 8362 encodings, those encodings should be the primary reference all the leaves and identifies. 

> On Jan 13, 2024, at 07:42, tom petch <ietfc@btconnect.com> wrote:
> 
> From: Lsr <lsr-bounces@ietf.org> on behalf of The IESG <iesg-secretary@ietf.org>
> Sent: 11 January 2024 14:35
> 
> The IESG has received a request from the Link State Routing WG (lsr) to
> consider the following document: - 'YANG Model for OSPFv3 Extended LSAs'
>  <draft-ietf-lsr-ospfv3-extended-lsa-yang-25.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> <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 daigram, 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. 

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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr