Re: [Lsr] Robert Wilton's Yes on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with COMMENT)

2024-02-01 Thread Acee Lindem
Hi Rob,

> On Feb 1, 2024, at 9:11 AM, Robert Wilton via Datatracker  
> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for publishing another YANG model.
> 
> I do have a little sympathy to Roman's comment that having a bit more
> descriptive prose at the beginning of this document might be helpful to 
> readers
> (i.e., I'm thinking in the order of one or two paragraphs).  But at the same
> time, I can also see that repeating (or perhaps summarising) what is already
> written in another RFC isn't necessarily that helpful, and having the details
> in the YANG module itself is arguably the most important and useful place
> because then the tooling can build appropriate GUI help text or user
> documentation.

I honestly don’t know what I’d add. While sometimes the abstract/introduction 
of documents do
not adequately articulate the document purpose and scope, the succinct text 
below is clear (at least to me):


  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.

What is missing here?

One area of confusion that it would be good for you to get the message out, is 
that operational state  is
typically validated prior to being returned and the data is typically not 
validated by the YANG infra-structure
(al though types must still match). As you know, this is being addressed in RFC 
8407BIS. 


Thanks,
Acee


> 
> Regards,
> Rob
> 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[Lsr] Robert Wilton's Yes on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with COMMENT)

2024-02-01 Thread Robert Wilton via Datatracker
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/



--
COMMENT:
--

Thanks for publishing another YANG model.

I do have a little sympathy to Roman's comment that having a bit more
descriptive prose at the beginning of this document might be helpful to readers
(i.e., I'm thinking in the order of one or two paragraphs).  But at the same
time, I can also see that repeating (or perhaps summarising) what is already
written in another RFC isn't necessarily that helpful, and having the details
in the YANG module itself is arguably the most important and useful place
because then the tooling can build appropriate GUI help text or user
documentation.

Regards,
Rob



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr