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

Tarek Saad <tsaad@juniper.net> Mon, 10 August 2020 23:27 UTC

Return-Path: <tsaad@juniper.net>
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 AE1553A0DED; Mon, 10 Aug 2020 16:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=kKaSYAhg; dkim=pass (1024-bit key) header.d=juniper.net header.b=IJptokaB
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 x1sYFiIZMqzw; Mon, 10 Aug 2020 16:27:43 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E3E3A0DEA; Mon, 10 Aug 2020 16:27:43 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07ANRaWk023453; Mon, 10 Aug 2020 16:27:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=n+vF/CYE9i+c9BEL0lsB5imckZUuBnhXL9NGog/Jgbc=; b=kKaSYAhgNVsHK6eMnmnyiGxsaRByjPsXFDiRziAbDY2omf3WI69m4Q3HTzaipC6sWy5A B/q+LpAext3WeVmeNfAUF6dd742E3NULMqBldHiN37N/FTxLeeWRXGsUCfCod4+p14JV wRSBMjJjWxAZgFl5CgZeoogzlHRc45oNhAma7q317rQ54UGlhzUYDaNm2FaYcBXVk+j2 jbTvg1cPaNZ7k2z5970BuhWdtbjOZ1Z/vcQq1q0xTvsc0ANjyT+7+EIgWgErTpIGjFoK Xqh3Ea4MsXfOORBPPzZfWuwoqoQyFm3DpSEC2ChyR4JgKL2g6xrLIKKOB4xytDWJoo9B Dw==
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2169.outbound.protection.outlook.com [104.47.55.169]) by mx0a-00273201.pphosted.com with ESMTP id 32suamu9e3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Aug 2020 16:27:36 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JCAFVQRnh26OYpQVMSmIFvKGgWJr32zd5eooNzey5umMcT7HLp2yVzmp9PKkvvzrUvfSYxisFVYLeCGy55CKH1EHlO7WOhQkm1fGbdYs/TCHhZpDX1X75IOY+TeWlKxWy2ooG3i9KB2FOQHEeK25xchFYKgoJReiEQBtAF2n0sY7jRogcsrLm+m70wwfeQg3GPmQlFuzySD+QWCGRsjaTocjbDzRqpDbU2VwmSQK0izmyopmQKTSq5BPzsqYuiaJ/4AfJ9XfHAH4ie8zP8AN34h0BF3S/36/WpDByIHaUfTuDWOxK7TyqINbfZ56Un5PwnO5wUFCiLEKaw6taTVaIA==
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=n+vF/CYE9i+c9BEL0lsB5imckZUuBnhXL9NGog/Jgbc=; b=aelP9kLgWP0tzNxTKIXFgu98SrHCWPYS5n+zXfbFhy/NTls4nXv+R9lTpMF964dpvg1e3AvImgG1yfHn4tc6lhCLMLOIERjXiCxOAUKFdBayUdSALe4G3Xj2qTfCxewFgLIEsGLnoDiN/zQXD6JmuN/SRzj47/1qgg7DAQrQ5NyPV5ngzGUXKe8GCuKfMHRq/2YyT039Qsj5ySFBwVbkhh0m2mfOKw8SHjZRT4n86cF+ag3+gsGhAd+H3RirncEjbqsJFw2ZRFsUTzT5MM5o4KpafLuEPFIKU5gDLgm+oGMonj8WvHH2EwyFbUVbflta0X/jVjeiwDWgvqvCkjEQ7w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n+vF/CYE9i+c9BEL0lsB5imckZUuBnhXL9NGog/Jgbc=; b=IJptokaBfe3BKQMlrjOq1RStqE681oXo0l6/8z11Elokh63JSPjx4ANabhSwusVWD2Si2hqfcZvuyXBbLpIL2m4IFT5WoXsh/J4oAb2EbbzOBTuawbvqq2X4LFGtKJtOYJyy08920slJZMlLToEVOkAGr1+R34OXCEtSAt2eWak=
Received: from BYAPR05MB4136.namprd05.prod.outlook.com (2603:10b6:a02:85::18) by BYAPR05MB4888.namprd05.prod.outlook.com (2603:10b6:a03:4e::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.10; Mon, 10 Aug 2020 23:27:30 +0000
Received: from BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::380d:349c:196f:a61d]) by BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::380d:349c:196f:a61d%4]) with mapi id 15.20.3283.014; Mon, 10 Aug 2020 23:27:30 +0000
From: Tarek Saad <tsaad@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, tom petch <ietfc@btconnect.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: AQHWbNHUXD7iYiyo6Ey57883AGo+lqkxjfoAgAAg2ICAAA/wAP//zNmAgABHbQD//+vUAA==
Date: Mon, 10 Aug 2020 23:27:30 +0000
Message-ID: <24B5482E-16AC-44B4-8028-079BFBE331C0@juniper.net>
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> <E384A4B4-2823-445D-A89A-94409A1D3F5E@cisco.com>
In-Reply-To: <E384A4B4-2823-445D-A89A-94409A1D3F5E@cisco.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: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ef8c0010-9c0b-4d07-08d7-08d83d84f3c9
x-ms-traffictypediagnostic: BYAPR05MB4888:
x-microsoft-antispam-prvs: <BYAPR05MB4888B3CF0AC0D8789EBB058BB7440@BYAPR05MB4888.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HxIwS1lobaNvp0TK16O7c1zOfJSe8Z2ZCuUjANLfPaXubyR2dYdz84bvMa6gnD5g+7kpsxs6mZDLsdGIqG7hq5a/corwepTjut20jBhVqEzchbNkzn/otDxw3QJkj5N5vfPrqRz4HY1XYRTKzUyOqgZrImovlECbaScBCU6tjMjC4EI4Xm+SFJd1qrp+7ns8wEAWSvaVI/uHL2zrBS6p1IzI8tPgx9sk6XcetRPO2D68S12NCbASSfaSR3lbsDZVArL0Eqy3Zb+oMh0D6zBgPWYmZvWZ74WQrxTrcH9v1EWsZNCIUFBDnTKfUjWK+SHphjvgMfb17ZEWph59yJFQh0hTLkR1ipyC8YVq/jg6qwY8VAu07BTB9Wt9h744BzRaVPLNPrIJoQnMTVmElyy7NA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB4136.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(39860400002)(346002)(366004)(136003)(54906003)(316002)(71200400001)(26005)(8676002)(5660300002)(186003)(2906002)(6486002)(76116006)(66946007)(33656002)(64756008)(8936002)(66556008)(66476007)(66446008)(83380400001)(4326008)(478600001)(2616005)(966005)(110136005)(86362001)(53546011)(6512007)(6506007)(36756003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: GDmx7YYozO+iP+lUbcnT4tXj0WSijPwYnReqbZzkdQWXNYoIj1r8q7jYm89gHsVaNg6kDw5Ym+5r5mHKcRIGoGVLnkHbB+gIsJjMJ8HhoeO9Z90J7qwyfYqrxsbfGSokaSw7pjqnFpOmQ89tDgTfefvhV3FPqVtNl/vh7XQR6gTu+jTnkh7uZRhlYxhLO0jPk7KA6r1BnR3N4Hb1Sh8qrkQwIwpiM6sT7lAJOo3X9GeL8sG+Bbb42hb4QC71RdJqRqaZWRwqJkPoTnoRvIAtSdF1u6bmjyLJY7iElK0KOCrqMNQzgEq/ugdRbIlIVOfcYamTY1hVwKiPO2EsErykrNBOEAHrG3GhAg0DFlmplubA3UntIVIea7Q2WjsHM+FbQfSf0VKVb2CY8cPZ4+xaz+1KRyNclUKuNWgTFvHITtXSl7wqpaMUMrdTw6YxtYWZVCA1u+F1OilSfI6QfW3P76GtF8hijy9eNR/iOuxlYU1ISETurYfoxmP8vdK+JgWBoUbheA/id1t9hCMS2yKrSp/1GXO9cLWH6Pc77i/DB+uukj5ZujDaY/XcZjNWpn0Ff8AZYCi/r4f7N6hCnxCjTX1D5Kx+Mp5e9PqZbFLfupYnl5283MCUcxnWkGzxDLLBLZlwYuAnmSd2F7g0JtKL6Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <228F7EE84E4F6748A6645121AF601BBF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB4136.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef8c0010-9c0b-4d07-08d7-08d83d84f3c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2020 23:27:30.6981 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DbxN6asamqlWJF0WrgL+V7rGTA7PdyT/ndvm74MOfkNqJFhWESETsO8bPjUZ4eBWVEplL/cSjBhKYxS2ShkPQw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4888
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-10_22:2020-08-06, 2020-08-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 adultscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008100159
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/reJDQ4N9phkSOZv4pxAjnv91Bqs>
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: Mon, 10 Aug 2020 23:27:48 -0000

Hi Acee,

Are you checking https://tools.ietf.org/html/draft-ietf-mpls-base-yang-14?
If so, Figure 2 shows the module is augmenting IPv4/IPv6 AFI with MPLS for paths - check the paths
augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop:

You'll notice the MPLS augmentation above is applicable for all RIB types (including IPv4/IPv6 and the new AFI introduced by this module). The MPLS augmentation for IPv4/IPv6 RIBs are specific to IP prefixes that are MPLS enabled.
You'll also notice draft-ietf-mpls-base-yang is defining a new RIB address-family for MPLS as per section 3 in RFC8349 (search for "identity mpls" in YANG module).
The new MPLS RIB address-family is meant for "non IP" MPLS routes (e.g. MPLS routes installed by RSVP on transit nodes, cross-connects, etc.).

Given the above, can you take another look and let us know?

Regards,
Tarek


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

    [External Email. Be cautious of content]


    Hi Tarek,

    In that case, there is more wrong than just the RPC since you haven't augmented ietf-routing.yang properly to define an MPLS-specific RIB. Furthermore, I don't think you should. We need the optional MPLS augmentations for the IPv4 and IPv6 address families as these are what one would need in for a IPv4 or IPv6 RIB for a device that supports MPLS.

    Your augmentation to the active-route RPC needs to just be removed.

    Acee

    On 8/10/20, 4:24 PM, "Tarek Saad" <tsaad@juniper.net> wrote:

        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".


                >            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


    Juniper Business Use Only


Juniper Business Use Only