Hi Tom, We can add the references. See ACEE>.
On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch" <[email protected] on behalf of [email protected]> wrote: From: Lsr <[email protected]> on behalf of [email protected] <[email protected]> Sent: 13 August 2020 05:37 I said before that it was tough to review because of a lack of references in the YANG module and that remains true. You have two Boolean to enable extended LSA on for ospf, one for area. Yes, the answer is in RFC8362 but it tells me the YANG module is wrong - and it took me some time to find it. RFC8362 defines two parameters ExtendedLSASupport and AreaExtendedLSASupport and the latter is not in the model; yes you have a Boolean under area but I think its meaning requires a reading of RFC8362 Appendix B and that is missing and the description is unclear and the name is wrong. Also the RFC has a SHOULD in it which the model does not implement. You reference s.6.2 but I think that wrong, that it is Appendices A and B that describe this. ACEE> What is the SHOULD that isn't implemented? On type, you say there are three possible values. Precisely. Can you have the type set to 'ospf' and support ospfv3? If so, your model fails. Or does ospf-yang only allow the type to be ospfv2 or ospfv3 and bar the use of ospf per se? ACEE>"ospf" is the base identity for "ospfv2" and "ospfv3". So, if a container is applicable to both, no when constraint is needed. However, if it is applicable to the one or the other, a "when" constraint. It is common to do this in YANG. This module is applicable only to OSPFv3. The reference statement after the description could do with a title as you have for the revision description My point about link type is that you are augmenting ospf-yang which uses an enum so in places users will be required to use an enum and in others a uint8 which could be confusing ACEE> I don't get this. We don’t augment link-type. Thanks, Acee Tom Petch A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename : draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt Pages : 27 Date : 2020-08-12 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
