Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 29 Sep 2020 21:44:55 +0000

Hi Tom, 

We can add the references. See ACEE>. 

On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch" <[email-masked] on behalf of [email-masked]> wrote:

    From: Lsr <[email-masked]> on behalf of [email-masked] <[email-masked]>
    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-masked]
    https://www.ietf.org/mailman/listinfo/lsr

    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsr

---

From: tom petch <[email-masked]>
Date: Wed, 30 Sep 2020 10:13:41 +0000

From: Acee Lindem (acee) <[email-masked]>
Sent: 29 September 2020 22:44

Hi Tom,

We can add the references. See ACEE>.
<tp>
Yes please - it will make it easier for me to review

<tp>
The very last sentence of RFC8362 about the interaction of ExtendedLSASupport and AreaExtendedLSASupport; YANG has 'must' not 'should' and I would be inclined to make this a YANG 'must' but it you think that that is too much, then a comment in the description is needed IMHO

<tp>
Yes, my question is more about the base ospf model about the valid values that can appear in rt:type; is ospf per se a valid value of type or must it be either ospfv2 or ospfv3?

<tp>
Yes,  In base ospf.yang  link type is YANG type enum but in this it is type unit8 so modelling the same object with two different data types I think might be confusing.

Tom Petch

Thanks,
Acee

    Tom Petch

    Abstract:

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 30 Sep 2020 15:16:05 +0000

Hi Tom, 

See inline <ACEE2> . I've addressed your comments in 05. 

On 9/30/20, 6:14 AM, "tom petch" <[email-masked]> wrote:

    Hi Tom,

    <tp>

<ACEE2> Ok - I've changed this quite a bit by removing the default for the area level and adding the SHOULD as a YANG must. 

    <tp>

    <tp>

<ACEE2>I see now. I've used the type ospf:link-type consistent with ietf-ospf.yang. 

Thanks,
Acee

    Tom Petch

    Thanks,
    Acee

        Tom Petch

        Abstract: