Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

["Acee Lindem (acee)" <[e-mail]>]

All (Speaking as an author of RFC 8349), 
I just looked at this in more detail and I don't think the ietf-mpls.yang model should be augmenting the /rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to return the address-family specific active-route corresponding to the destination-address. This model attempts to overload this RPC with a different action all together - returning a route that has the local-label as an optional attribute. I'd reject the Errata and believe the augmentation should be removed from ietf-mpl.yang. Whether it is replaced with a different one is up to the co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)" <[e-mail]> wrote:

    [Resend to hopefully pass recipient limit filter]

    Hi Tom,

    I would be interested to hear from the original authors.

    My impression is that this is a technically reasonable change, but I don't think that an erratum can create a new revision of a YANG module.

    If this erratum was processed as "Hold for document update" then would that be sufficient to do the right thing in the MPLS YANG module?

    Regards,
    Rob


    > -----Original Message-----
    > From: tom petch <[e-mail]>
    > Sent: 10 August 2020 17:32
    > To: RFC Errata System <[e-mail]>; [e-mail]; Acee
    > Lindem (acee) <[e-mail]>; [e-mail]; [e-mail];
    > Rob Wilton (rwilton) <[e-mail]>; [e-mail];
    > [e-mail]; [e-mail]
    > Cc: [e-mail]; [e-mail]
    > Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
    > 
    > From: netmod <[e-mail]> on behalf of RFC Errata System
    > <[e-mail]>
    > Sent: 07 August 2020 16:45
    > 
    > <tp>
    > This is the erratum of whose arrival I speculated on this list on June
    > 16th.
    > 
    > There is a degree of urgency about it.  The I-D in question is mpls-base-
    > yang, currently in IETF Last Call, which is a Normative dependency of bfd-
    > yang which is a Normative dependency for a small mountain of I-D which
    > have been waiting a year or so (e.g.  ospf-yang).
    > 
    > I suspect that the technically perfect solution would involve a YANG
    > union, choice or some such structure but as I said in my Last Call comment
    > I can live with a label that contains such as 'address' encompassing such
    > as 'label' in the context of forwarding.  I take labels to mean what
    > labels mean rather than what I might find in a work of reference.
    > 
    > Tom Petch
    > 
    > The following errata report has been submitted for RFC8349,
    > "A YANG Data Model for Routing Management (NMDA Version)".
    > 
    > --------------------------------------
    > You may review the report below and at:
    > https://www.rfc-editor.org/errata/eid6251
    > 
    > --------------------------------------
    > Type: Technical
    > Reported by: Tarek Saad <[e-mail]>
    > 
    > Section: 7
    > 
    > Original Text
    > -------------
    > The RPC "active-route" is used to retrieve the active route in a RIB.
    > RFC8349 defined two AFIs (v4/v6).
    > 
    > draft-ietf-mpls-base-yang is defining a new RIB AFI for MPLS as per
    > section 3 in RFC8349.
    > 
    > The RPC has a "MUST" statement that all RIBs must augment input
    > parameters with a leaf named 'destination-address'.
    > 
    > For MPLS RIB, it makes sense to augment with leaf named 'local-label'
    > since MPLS routes are identified by MPLS label.
    > 
    > We ask to make the following change:
    > 
    > OLD:
    >            action active-route {
    >              description
    >                "Return the active RIB route that is used for the
    >                 destination address.
    > 
    >                 Address-family-specific modules MUST augment input
    >                 parameters with a leaf named 'destination-address'.";
    > 
    > 
    > Corrected Text
    > --------------
    > NEW:
    >            action active-route {
    >              description
    >                "Return the active RIB route that is used for the
    >                 destination address.
    > 
    >                 Address-family-specific modules MUST augment input
    >                 parameters with a suitable leaf that identifies the
    > route.";
    > 
    > 
    > Notes
    > -----
    > 
    > 
    > Instructions:
    > -------------
    > This erratum is currently posted as "Reported". If necessary, please
    > use "Reply All" to discuss whether it should be verified or
    > rejected. When a decision is reached, the verifying party
    > can log in to change the status and edit the report, if necessary.
    > 
    > --------------------------------------
    > RFC8349 (draft-ietf-netmod-rfc8022bis-11)
    > --------------------------------------
    > Title               : A YANG Data Model for Routing Management (NMDA
    > Version)
    > Publication Date    : March 2018
    > Author(s)           : L. Lhotka, A. Lindem, Y. Qu
    > Category            : PROPOSED STANDARD
    > Source              : Network Modeling
    > Area                : Operations and Management
    > Stream              : IETF
    > Verifying Party     : IESG
    > 
    > _______________________________________________
    > netmod mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/netmod