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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 11 August 2020 09:47 UTC

Return-Path: <acee@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715713A0F2B; Tue, 11 Aug 2020 02:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PMPAm3c4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kMLFBYwS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8ZXB8_wufXD; Tue, 11 Aug 2020 02:47:42 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BFF3A0F25; Tue, 11 Aug 2020 02:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12620; q=dns/txt; s=iport; t=1597139261; x=1598348861; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GfVOD/mvxa26Ds99cqeDCG6AfjR89rgOxEr5LrWJXWs=; b=PMPAm3c4hH+V+/bfgeu+Q9j7kcbQ943mpnHgJR9KispgP3Lj2MecE7K8 CdegDYbiQJHD31mQafEIlbU2kDDEcZldTxQ6sOWrV9LuabhiNPzJLaGz7 p7L1FvaxL5NrPBVBAAN7W+q0HWPGe2owefxmCCct4aZIWNsn49UtGqRyb 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3AMeDMHhEVK3vJUjqf7kzZfJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gWbV5nQ7PRChuHK9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Yvna16zgfEQ?= =?us-ascii?q?m5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARDgBFaDJf/4gNJK1gHgEBCxIMQIM?= =?us-ascii?q?cKSgHb1gvLAqELINGA40tJZhmgUKBEQNVCwEBAQwBARgGDwIEAQGECEQCF4I?= =?us-ascii?q?fAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQQBARAREQwBASwLAQsEAgE?= =?us-ascii?q?IEQQBAQMCJgICAiULFQgIAgQBDQUbB4MEAYJLAy4BDqc5AoE5iGF2gTKDAQE?= =?us-ascii?q?BBYUNGIIOAwaBDiqCcYNfgjuEBRqCAIERJwwQgk0+gQSBWAEBgSoBDAYBB4M?= =?us-ascii?q?xM4Itj2QngnSHB4J5iAqRIQqCYohjkTYDHoJ9iViIJ4sWki6BbIhRkE2EKgI?= =?us-ascii?q?EAgQFAg4BAQWBaiNncHAVGiEqAYI+UBcCDY4fDAwLgQIBCoJBhRSFCQE3AXQ?= =?us-ascii?q?CNQIGAQcBAQMJfI1tgTQBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.75,460,1589241600"; d="scan'208";a="543133402"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Aug 2020 09:47:39 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 07B9ldRH030417 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Aug 2020 09:47:39 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 04:47:39 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 Aug 2020 05:47:38 -0400
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 11 Aug 2020 05:47:38 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fpXE85rtYkm/NNjBtfvdZNVB7GOLgn6jBHquQcO3vjk4+/DK2pG/xOJ6xaSCB071dBNzyv/THjiTV460hdmHdfPqyC8G8fq5fSHnbzxDaei00jX6uVOfyJ97MQUszilM4floywWn5l+phatkTV1cDpxUZm6tFeI+KvCIAde1zL71Msvafd4tA+Suf1KpC6SmpCJOir8TDOfOm5hR9eDMhmyroeeV6CsKg154QJAdYLF/ZLaUAn5+xwFWlR7fmiNhnCwsUTkyJQi4L8OQwvf8KTQMfZ9r68WJ9dozLsBDVeNgzZmzHv0fZLJFWKuk9bURv22NrFAQ5QXiUEzeUogxEg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GfVOD/mvxa26Ds99cqeDCG6AfjR89rgOxEr5LrWJXWs=; b=klex/CO+zt3CHtYjEWlt8hrqftxCJAylVrptgGtyGJMK+cYarS+sKmBxKcgPt1E1Kc7OCMbDzXPN+IFc4S+ntURJfkORhh7xKcP0nj7Owl4B0QD/bpmR5a+t4cvmA9fYzfX2hC4QBy8iX98GBjgyFGrEXIiqaNBqap2n7ZjaABXy81cbn7OLQ84UaHULYINmii3Ptd+SlceDbYHcHJQdNoM9kkCogAznNBqdQJaJQK9aHE9ExWlaieTH7Dbx70tERn5LSX0S4kXZStfjJORP9u7MVi3OFge8+32LKfpZZHwrgXcEwU9hZ2tscwLSpRwiTat5oiJH7NWFTl0LoLSxYw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GfVOD/mvxa26Ds99cqeDCG6AfjR89rgOxEr5LrWJXWs=; b=kMLFBYwS1MqBzlFyfTmZY/3yhx7yT0YWfpKLhsD7kytOPp6M5+0/C+P9ZPSoSvLNAkJMcwkKMt4ayyxsUveHIl7ML0s3ioL9l+ixd7pybLgtZpwLNzNi9zPVksm0JSIYKclQ2LxFIJHiYSY1AVl/SLw0gNLUpuBQqfOM6Ck0oaY=
Received: from BL0PR11MB2884.namprd11.prod.outlook.com (2603:10b6:208:72::25) by BL0PR11MB3042.namprd11.prod.outlook.com (2603:10b6:208:78::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Tue, 11 Aug 2020 09:47:37 +0000
Received: from BL0PR11MB2884.namprd11.prod.outlook.com ([fe80::99d7:9fb2:28a4:14e4]) by BL0PR11MB2884.namprd11.prod.outlook.com ([fe80::99d7:9fb2:28a4:14e4%2]) with mapi id 15.20.3261.025; Tue, 11 Aug 2020 09:47:37 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: tom petch <ietfc@btconnect.com>, Tarek Saad <tsaad@juniper.net>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "lhotka@nic.cz" <lhotka@nic.cz>, "yingzhen.qu@huawei.com" <yingzhen.qu@huawei.com>, "warren@kumari.net" <warren@kumari.net>
CC: "netmod@ietf.org" <netmod@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Thread-Topic: [netmod] [Technical Errata Reported] RFC8349 (6251)
Thread-Index: AQHWbNHhjFoS+TZQTU6nPSaQ4ny3G6kxjfoAgAAg14D//8zeAIAAUvsAgADS7oD//8qXgA==
Date: Tue, 11 Aug 2020 09:47:36 +0000
Message-ID: <24CD45FE-939A-4B51-9149-BE8487D5E026@cisco.com>
References: <20200807154534.98486F4074B@rfc-editor.org> <AM7PR07MB62480F112A28FA0B0F068D91A0440@AM7PR07MB6248.eurprd07.prod.outlook.com> <MN2PR11MB43664780B4844ABA07C84D0AB5440@MN2PR11MB4366.namprd11.prod.outlook.com> <3073B02B-7413-4C00-ACF1-CA2679C0C949@cisco.com> <57AAC8FB-65D7-40D9-BFE7-B16A7F680C0E@juniper.net> <AM7PR07MB6248984045BBA46199BE751CA0450@AM7PR07MB6248.eurprd07.prod.outlook.com>
In-Reply-To: <AM7PR07MB6248984045BBA46199BE751CA0450@AM7PR07MB6248.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=42648655-a83a-47dd-85df-00007a4a57df; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-08-10T20:01:11Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 22e5175b-2679-435a-77bc-08d83ddb948d
x-ms-traffictypediagnostic: BL0PR11MB3042:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BL0PR11MB30424F3A5E324FBDF1A96D42C2450@BL0PR11MB3042.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UrC3E92SQykNFBUL+uTCD9QwjgKqV/RFFKL1YqNTfJIISSpytU5pmHkKgy7Lzo7RjdkkAc2+aWmOUSOKwrI9MLsOAkAGZG/LmvQ3qSQEZtSug0IVH7qt5EWRQGqqcaf5pwnWomd9RxW+D2/Y45FMF5aJA1hzNUNWzfVGFnPyxZWfLYGEfZ5lo38rsoi0upNhN1/ULzz/DEoR8/0+KA7EY9hbDRtKFmNLdhSfd37N8VbZo2LX+McRnN6mgwRe6G28cFvAAhslwk7Ydt+bULQFs1MpKCCv2X2AMskWO9d5rliGBC7ofvorVSQUkVvx0WqusGJPG7hKu2tt7YJr8YA24zJXcYd241+nOsejGiBA1NthTdoQvdouGKhWIw9A9dPl9B0r8j+7Qq7loG4lTMnXnw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB2884.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(396003)(39860400002)(376002)(346002)(110136005)(33656002)(6486002)(54906003)(2906002)(296002)(76116006)(91956017)(316002)(53546011)(6506007)(26005)(4326008)(83380400001)(71200400001)(966005)(478600001)(8936002)(8676002)(86362001)(5660300002)(2616005)(36756003)(66476007)(64756008)(66556008)(186003)(6512007)(66446008)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Q3lvVAfLCJHVm+LBdU92XIfslhuuMbknOPO1EvbX3q0X4IcU7M2NHQr8Xei7WPls3v2ovSzWWifROCRQiclk0cHfYa1Jbr07Vv0bmxMwEShA7rQ1Xgp4KphwZ1l9MAWIeBOZCq5MOnxrneRt/py+5Ot86X+cjLXrsJ11nwWl67roMCBxawyeucpZPTf2JpYZlsGUf6iGVAqAHkNlBsl1vwhPPn0kEWb6WZZTPNHbekB16ux7E9/4K+KuyHDJqY1gOH2YtzxLsjjVGM4HEx5DDYFcfdD8iPiCks/lWUJBiguZXq9fVFN6ZaLiEmlXW6O5QlZrMG2chwzIG9YnKLe5y1QWjHNv2PHfKJO8esrcRcEah9M7ToqiUOH9wxCkv3V3oEd0Khwm+Z4heK1Y2akcTOOILkK0E+b/U+EsCHyCLreat5vEGAttk57dG2BO1+LXYNRhfLQywy4LqiVB+Appnn+LTygYuxkkQF8WJf25xkvNKwRuVj+wmPOL76YbBoBh/hHmpAeoP0+xUKHVsyhkJDjCY11Gw0JoD9Vqmelgn7QQ6tOqJuZj1Bo4h6gG+WBaZ1UWVlYKFKRbp3jtgaVB2hukSO4YKOh4Eclb2R65YVSrRYqG7Lyqin45WyAeaJIxAb7zzWzg19jsf4OugkHIgw==
Content-Type: text/plain; charset="utf-8"
Content-ID: <79029DCE14E1234988E769CCEF57D98E@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB2884.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 22e5175b-2679-435a-77bc-08d83ddb948d
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 09:47:37.1087 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2NEXZCMdN2w2ZGUd9DD/yHZ2H5HXWKhtpisZzn1P6y3wTf+rGXfE19p6OPqPxorP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3042
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/iZK-vEUgu342p3vRDoO27vIbbWY>
Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 09:47:45 -0000

Hi Tom, 
I fully understood your original comment. There are other problems with this model. See inline.

On 8/11/20, 4:59 AM, "tom petch" <ietfc@btconnect.com> wrote:

    Tarek

    Picking up on an earlier point,

    ________________________________________
    From: Tarek Saad <tsaad@juniper.net>
    Sent: 10 August 2020 21:23

    Hi Acee,

    The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to return the matching active route identified by a "destination address".
    The MPLS module is trying to reuse this RPC so to query the MPLS RIB to return the matching active route identified by a "local label".
    The RPC defined in RFC 8349 readily accepts MPLS AFI in it (/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress it with a "when check".
    IMO, it is reusable as-is but the text below is limiting the leaf name that identifies an entry in RIB to "destination-address" only - in MPLS RIB the entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation must have a when statement restricting it to AF MPLS. Also, local-label is a leaf which is applicable to all address families. It cannot be the AF MPLS destination-prefix. This augmentation is missing. 

Thanks,
Acee


    <tp>
    There should be a 'when' check to enforce the 'MUST' but the rules of YANG do not allow it in this structure.  I raised this on the NETMOD list at the time of WGLC and Martin pointed me to a rule in the ABNF which prohibits such a check.  He also said that the rule was not needed and would be a candidate to remove when YANG is revised.

    Hence I have always thought of this MUST in the documentation as a constraint that must be enforced in the YANG

    Tom Petch
            >            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'.";

    Regards,
    Tarek

    On 8/10/20, 3:27 PM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

        [External Email. Be cautious of content]


        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)" <rwilton@cisco.com> 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 <ietfc@btconnect.com>
            > Sent: 10 August 2020 17:32
            > To: RFC Errata System <rfc-editor@rfc-editor.org>rg>; lhotka@nic.cz; Acee
            > Lindem (acee) <acee@cisco.com>om>; yingzhen.qu@huawei.com; warren@kumari.net;
            > Rob Wilton (rwilton) <rwilton@cisco.com>om>; joelja@bogus.com;
            > kent+ietf@watsen.net; lberger@labn.net
            > Cc: tsaad@juniper.net; netmod@ietf.org
            > Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
            >
            > From: netmod <netmod-bounces@ietf.org> on behalf of RFC Errata System
            > <rfc-editor@rfc-editor.org>
            > 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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6251__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxw8DnSr2A$
            >
            > --------------------------------------
            > Type: Technical
            > Reported by: Tarek Saad <tsaad@juniper.net>
            >
            > 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
            > netmod@ietf.org
            > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxxyc2_LZA$



    Juniper Business Use Only