Re: [mpls] mldp was Re: Yangdoctors last call review of draft-ietf-mpls-ldp-yang-06

"Kamran Raza (skraza)" <skraza@cisco.com> Mon, 23 December 2019 18:06 UTC

Return-Path: <skraza@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFE0120CA0; Mon, 23 Dec 2019 10:06:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=OcQKqVLK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=O/QC6fSx
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 uvS2qMHbfOhp; Mon, 23 Dec 2019 10:06:29 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256FE120C8E; Mon, 23 Dec 2019 10:06:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16762; q=dns/txt; s=iport; t=1577124389; x=1578333989; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PElbFBxNt6mtDZmlE9zXLj60gjQuewhg2MLGYhr72AM=; b=OcQKqVLKjYi9wnSu21guFOZS+wQlLnswXXtQofInLx529H7pjIL5F9wB lnJIXojvm2/pIWMDgzYGX0YGaVHR2RJI8ycDKHNOYRyiu9PiePjZYVbtP RN5hK2mWtiuDvkUWJjy3B4N0BoOoJYPZhI+TCzPW7bM39aM05Kyh3C7Kn E=;
IronPort-PHdr: =?us-ascii?q?9a23=3AitMJ9hMnmeFNi6b8Ef0l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjgL+TjfSUSF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAADcAAFe/5pdJa1cCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBfIFSKScFbFggBAsqhAiDRgOKeYI6JZgIgUK?= =?us-ascii?q?BEANUCQEBAQwBARgLCgIBAYRAAheCByQ4EwIDDQEBBAEBAQIBBQRthTcMhV4?= =?us-ascii?q?BAQEBAgEBARAREQwBASwEBwELBAIBCBEBAwEBAwImAgICJQsVAgYIAgQBDQU?= =?us-ascii?q?igwABgkYDDiABAgyhfAKBOIhhdYEygn4BAQWFGhiCDAMGgQ4oilaBQxqCAIE?= =?us-ascii?q?RJwwUgU5+PoJkAQGBOQQOAhYXgnkyggoijXuCP4V7l2sGbgqCNJF3hCIUB4J?= =?us-ascii?q?Gh3uQFo5SgUaZEAIEAgQFAg4BAQWBaSKBWHAVOyoBgkFQGA1XiXKCSQ0WFW8?= =?us-ascii?q?BCYJChRSFP3SBKIx/gkIBAQ?=
X-IronPort-AV: E=Sophos;i="5.69,348,1571702400"; d="scan'208";a="388786086"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Dec 2019 18:06:28 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xBNI6RJR007668 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Dec 2019 18:06:28 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 23 Dec 2019 12:06:27 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 23 Dec 2019 13:06:25 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 23 Dec 2019 12:06:25 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ji009NSzSoK0XBYIJyoGvUEPP7sB9VNmNkDiSVM0Izr2a4Lu9zwmyS2XEV5rDsr5JYVjpJxV+uIZIzMaJCIdXAM4OIl8ZGhT2EBotdYOh8FwAVqFmQb17pf+4nDfFnEUl/z+u+hcDaEJMqdbOBWce/YwxzX/RFjlIyf6nFNpaoztEoBtko7hA8hcrhRm3vtigNUG4Wr1QkSIads87y1xOoWLt5NAIz/JLtOtDiShNWq+o3gL2AyM0PdtHkhMjZfYoA6eKYLVRFgcWl1eynKHqkWgLEpxE0kzDjocveg6qJz5IFJNbSNlZP4z2fyxBJK6tyQc4BShKp+x12KuHp00GA==
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=PElbFBxNt6mtDZmlE9zXLj60gjQuewhg2MLGYhr72AM=; b=lwU2ktZpiQ2Vic+l53GzKsgZ50vIanxPQ65iLU4E/pBpXHCfAeiXBulc/3ukaEi/uW3Jo7G4N4htnhCrfIHCPjruHEVJuPuZRxuhLGuUv4oSjvR2sAn08aFdMUD2UIoHQbr+9+0NFCALNWjXTdGv/t2K9i8d5HFBYqB8JndsxH/N0cCO6KFaTo4Oz8LNP841B2JYWVN6RXCteqq2aXgXS/4MKaEYXmW1erwz2DZEvgG6WNY9SaJDD7JtRHzR9fcDFzVzTkE77WATnXn9EefsqMiTj3CUjZ8zpXTvvsMcYa2EUdmnuVFmPMP+DDbZ+UwFb16FS5Xy26fUnTDXhRfbkQ==
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=PElbFBxNt6mtDZmlE9zXLj60gjQuewhg2MLGYhr72AM=; b=O/QC6fSxlZk6MQ7kodFm4wKbgO60iO6oBufEov2DYQXECfV8PZA78t4BZu1iP9Lex1T3IXKeORWVnuT1tuppKYZRgJwmJCU7oeg1YvoGHUL5PLtmCsGWenJnbguatU0QzeV80BrSlWTOnExdl3YJ2JbDcTIh6ZD7U9RsoXoZa/w=
Received: from DM6PR11MB3865.namprd11.prod.outlook.com (20.176.127.159) by DM6PR11MB2972.namprd11.prod.outlook.com (20.177.216.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.19; Mon, 23 Dec 2019 18:06:24 +0000
Received: from DM6PR11MB3865.namprd11.prod.outlook.com ([fe80::8955:6ce6:45c6:77ed]) by DM6PR11MB3865.namprd11.prod.outlook.com ([fe80::8955:6ce6:45c6:77ed%6]) with mapi id 15.20.2559.017; Mon, 23 Dec 2019 18:06:24 +0000
From: "Kamran Raza (skraza)" <skraza@cisco.com>
To: tom petch <ietfc@btconnect.com>, Jan Lindblad <janl@tail-f.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-ldp-yang.all@ietf.org" <draft-ietf-mpls-ldp-yang.all@ietf.org>, "draft-ietf-mpls-ldp-yang@ietf.org" <draft-ietf-mpls-ldp-yang@ietf.org>
Thread-Topic: mldp was Re: [mpls] Yangdoctors last call review of draft-ietf-mpls-ldp-yang-06
Thread-Index: AQHVg1EltAi0uXkfJ0+36WG0fwUl4KfIHOkA
Date: Mon, 23 Dec 2019 18:06:24 +0000
Message-ID: <EAF7CF35-E2C0-4057-ABB5-065BCA0320B4@cisco.com>
References: <157114122559.18000.6531210525259761076@ietfa.amsl.com> <011501d58376$aa19e120$4001a8c0@gateway.2wire.net>
In-Reply-To: <011501d58376$aa19e120$4001a8c0@gateway.2wire.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is ) smtp.mailfrom=skraza@cisco.com;
x-originating-ip: [2001:420:2840:1250:4c27:6c90:817d:cf21]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4e9db7f3-7c43-4b00-7e36-08d787d2d2cf
x-ms-traffictypediagnostic: DM6PR11MB2972:
x-microsoft-antispam-prvs: <DM6PR11MB2972E97500988EA918D9C6C9D02E0@DM6PR11MB2972.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0260457E99
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(189003)(13464003)(66556008)(66476007)(66946007)(66446008)(4001150100001)(2616005)(4326008)(36756003)(110136005)(54906003)(316002)(296002)(86362001)(6486002)(76116006)(64756008)(8936002)(33656002)(81166006)(81156014)(8676002)(186003)(2906002)(30864003)(478600001)(6512007)(6506007)(966005)(5660300002)(71200400001)(91956017)(98474003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2972; H:DM6PR11MB3865.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pqrC+Zd2AHSDCWUK6Ms8ujQm/c5g8DfxCW4St1s6YTDckZii4tOfZOu+sGuJDnR+6gO9fKyjrpYDCN90/wUpybcz9Gbny5UcbqIbgX/xk4kiHHn7rqYts05Beo+IsK+IDXzL0LKPs3TXRJ+BT23cA6e6K2cRbRDqMtLfZ/0yIO1jJDqdsBeIRV7voePo9TRnACu9dAjmrfnBHonzAlwqRal05xl7yWdmu5XGTuokPJlgumVR2PjtNfSPBQqV9495ojnWf8i1RU5nvNTz4ji7bb4arPNjxVCAMVbN+WM8SjEB63h+RJVn2hB98BAJOl2hoCp8qkxtKiLJ4uAtoSNb1c9i24VqH8hd3zUDPS3Dl6mv4CD7yf/ELZ4kLmVvkcw3+KnAaDlDlcHYD21JCuV73a66otiz+UZ6xNl6FjtdzFy6ECDJQgrcAc58ndtAGUnbzHWfTyvgOwJyjU6EGQKdw3Z6nfcLmv5JsGuu9LgLjGmVjYc+7c/HuVnM6+iL4o5yW9acoeEia/NocyiQzz2avG6K6dYg7uwI/y+3E3Oea3n1s0IWHR1BPbzICZOeMFmP
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <861B1A801DF13645BC5DEAB3257B9D68@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e9db7f3-7c43-4b00-7e36-08d787d2d2cf
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2019 18:06:24.4161 (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: m47gltupLh72eFyMOvyUXO6loCNM+W8878JzwjhFWMILO3hFJ7FXElfYfZ/LVJawk3+NxyK3aXccT9jEPOTzfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2972
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/XetRPRHv1mBT_7jIluO-172DAjA>
Subject: Re: [mpls] mldp was Re: Yangdoctors last call review of draft-ietf-mpls-ldp-yang-06
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Dec 2019 18:06:32 -0000

Hi Tom,

Thanks for your review. We've just replied to Jan's review. 
Please see further below inline [skraza]:

On 2019-10-15, 12:38 PM, "tom petch" <ietfc@btconnect.com> wrote:

    Jan
    
    It would likely help if you could also look at
    draft-ietf-mpls-mldp-yang-06
    which augments
    draft-ietf-mpls-ldp-yang-06
    with such as
    [widescreen needed]
    module: ietf-mpls-mldp
      augment
    /rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:capab
    ility:
    and
         augment "/rt:routing/rt:control-plane-protocols/"
           + "ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:received-peer-state/"
           + "ldp:capability/mldp:mldp" {
    i.e. there are another 20 or so augment which are affected by the
    changes you propose.
    
    Note that the prefixes are ldp: and mldp: so the identities for the
    control plane protocols are probably better as those and not mpls-ldp or
    mpls-mldp.  But is mldp a separate protocol in RFC8349 terms or just
    part of ldp? I do not know.
    
[skraza]: We had discussed this day-1 of LDP/mLDP YANG design mtgs and had x-vendor consensus to make mLDP a child/dependent of LDP.
   So we do not need a separate identity for this. 

    The mldp draft has just completed WGLC. I looked at it but gave up on it
    because the line lengths were too long to display on my screen.

[skraza]: We will also fix the draft .txt format at next publication of mldp draft.

    Tom Petch
    
    
    ----- Original Message -----
    From: "Jan Lindblad via Datatracker" <noreply@ietf.org>
    To: <yang-doctors@ietf.org>
    Cc: <mpls@ietf.org>rg>; <draft-ietf-mpls-ldp-yang.all@ietf.org>rg>;
    <ietf@ietf.org>
    Sent: Tuesday, October 15, 2019 1:07 PM
    Subject: [mpls] Yangdoctors last call review of
    draft-ietf-mpls-ldp-yang-06
    
    
    > Reviewer: Jan Lindblad
    > Review result: Ready with Issues
    >
    > Modules: ietf-mpls-ldp.yang, ietf-mpls-ldp-extended.yang
    > Review result: Ready with Issues
    > Reviewer: Jan Lindblad
    >
    > This is my YANG doctor LC review of draft-ietf-mpls-ldp-yang-06. I
    find the
    > module ready with issues, even if there are a couple rather
    fundamental things
    > to work out. It is evident that the authors have spent considerable
    time to
    > make the module clean and tidy, which is why I can say it's more or
    less ready
    > even when there are fundamentals to work out. In my judgement it may
    be
    > possible to work out all remaining issues rather quickly.
    >
    > #1) Fitting mpls-ldp into the ietf-routing framework
    >
    > The modules at hand, ietf-mpls-ldp.yang and
    ietf-mpls-ldp-extended.yang, are
    > augmenting into the ietf-routing module (RFC 8022). I find this highly
    > appropriate. RFC 8022 has a section on how control plane protocols are
    meant to
    > fit into the ietf-routing framework:
    >
    > 5.3.2.  Defining New Control-Plane Protocols
    >
    >    It is expected that future YANG modules will create data models for
    >    additional control-plane protocol types.  Such a new module has to
    >    define the protocol-specific configuration and state data, and it
    has
    >    to integrate it into the core routing framework in the following
    way:
    >
    >    o  A new identity MUST be defined for the control-plane protocol,
    and
    >       its base identity MUST be set to "rt:control-plane-protocol" or
    to
    >       an identity derived from "rt:control-plane-protocol".
    > ....
    >    o  Configuration parameters and/or state data for the new protocol
    >       can be defined by augmenting the "control-plane-protocol" data
    >       node under both "/routing" and "/routing-state".
    >
    > The current draft is doing neither of the above two points. IMHO, it
    should do
    > both. Or if there is strong reason not to do that, incorporate a
    statement from
    > the ietf-routing authors and a clear explanation of why the mpls-ldp
    related
    > modules would be exempted. At present, this deviation from the RFC
    8022
    > architecture is never mentioned in the draft.
    >
    > Even if this issue falls under fundamental issues, the way I look at
    it, it
    > would be quite easy to fix. Adjusting the two draft modules to comply
    with the
    > points above requires changes to two dozen augment statement paths and
    a
    > handful of leafref paths. Adding the identity and corresponding when
    derived
    > from statement are a couple of lines.
    >
    > In principle, this change opens up for multiple instances of mpls-ldp.
    This
    > might be useful if a system is used with two entirely separate
    networks (such
    > as two separate customers), where each one might be running an
    mpls-ldp
    > instance. If this is not desired, a must statement could be introduced
    to limit
    > the number of instances to one.
    >
    > #2) Global level vs. local (e.g. interface or peer) level
    >
    > The module has several configurations that have a global and local
    level, such
    > as configurations per peer or per interface. Presumably, these local
    level
    > configurations are meant to override the global default when set and
    let the
    > global default prevail when nothing specific is specified at the local
    level.
    >
    > The way this is being currently implemented in the modules, however,
    makes it
    > impossible not to set a value at the local level, so the local setting
    will
    > always prevail. The global configuration would have no effect at all
    (except in
    > those cases where a local level configuration is marked with an
    if-feature and
    > the server would not announce that feature).
    >
    > For example:
    >
    > On the global level, there is a graceful-restart/enable leaf:
    >
    >       container global {
    > ....
    >         container graceful-restart {
    >           leaf enable {
    >             type boolean;
    >             default false;
    >           }
    >
    > Further down, we have another graceful-restart/enable leaf, used per
    peer:
    >
    >   grouping graceful-restart-attributes-per-peer {
    > ....
    >     container graceful-restart {
    >       leaf enable {
    >         type boolean;
    >         default false;
    >       }
    >
    > I would assume this latter enable leaf should take precedence over the
    global
    > graceful-restart when set on the peer. But if not set on the peer, the
    global
    > graceful-restart value should be used. Since the peer
    graceful-restart/enable
    > leaf has a default value, however, it will never happen that it is not
    set, and
    > will thus render the global value completely irrelevant for all peers.
    >
    > The fix is simple: Do not have a default statement on the local leafs.
    Explain
    > in the description statement what happens when the element has no
    value (the
    > globally configured value will be used). Make sure the global leaf has
    a
    > default (they all do already).
    >
    > The same applies to a rather long list of leafs in the module. I don't
    dare
    > listing them here, because I would surely miss a few. My point is that
    the
    > global/local relationships needs to be identified, local defaults
    removed. It
    > would also make sense to mention how this is supposed to work in the
    > descriptions.
    >
    > #3) Unlinked multikey leafrefs
    >
    > The grouping ldp-peer-ref has two leafrefs, one for each key in the
    list of ldp
    > peers. Two leafrefs are exactly what you need to reference an entry in
    a list
    > with two keys, so that's good. It is not enough to simply have two
    unlinked
    > leafrefs, however. That would still allow them to have values that are
    valid
    > separately, but not point to any entry in the list combined. If you
    have a copy
    > of "Network Programmability with YANG", this is explained in detail on
    pp.
    > 451-454.
    >
    > To link the leafrefs, you'd need to update the path expression in the
    > label-space-id leaf as follows:
    >
    >   grouping ldp-peer-ref {
    >     description
    >       "An absolute reference to an LDP peer, by the LDP ID, which
    >        consists of the LSR ID and the Label Space ID.";
    >
    >     leaf lsr-id {
    >       type leafref {
    >         path "/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/"
    >           + "ldp:peers/ldp:peer/ldp:lsr-id";
    >       }
    >       description
    >         "The LSR ID of the peer, as a portion of the peer LDP ID.";
    >     }
    >     leaf label-space-id {
    >       type leafref {
    >         path "/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/"
    >           + "ldp:peers/ldp:peer[lsr-id =
    >           current()/../lsr-id]/ldp:label-space-id";
    >       }
    >
    > The paths above would also have to be adjusted as part of fixing issue
    #1
    > above. If this fixing results in allowing multiple mpls-ldp instances,
    the
    > grouping above needs to be extended with one additional, linked
    leafref that
    > points out which mpls-ldp instance is being targeted. Or if that is
    always the
    > same instance as the reference is coming from, a reformulation of the
    paths
    > above could ensure no mpls-ldp instance name would be required. In
    that case,
    > the paths should be relative and never venture outside the mpls-ldp
    container.
    > I would be happy to explain this further.
    >
    > #4) Weakly defined types for neighbor-list-ref, prefix-list-ref,
    peer-list-ref
    >
    > These types are not leafrefs, but strings without any YANG
    substatements to
    > define the format. The only thing the description does is to claim
    that the
    > entities they refer to are outside the scope of this document. For an
    > operator/programmer encountering this type, that isn't very helpful,
    and is not
    > going to be interoperable.
    >
    >   typedef neighbor-list-ref {
    >     type string;
    >     description
    >       "A type for a reference to a neighbor address list.
    >        The string value is the name identifier for uniquely
    >        identifying the referenced address list, which contains a list
    >        of addresses that a routing policy can applied. The definition
    >        of such an address list is outside the scope of this
    >        document.";
    >   }
    >
    > I'm not sure if this is fixable by sharpening the YANG module, but
    maybe more
    > could be done to guide a confused reader. What would the user do to
    find out
    > the format of this type and valid values? Add to the description.
    >
    > #5) Interfaces or mpls, who's on top?
    >
    > In the mpls-ldp modules, there are two interface lists and two
    leafrefs
    > pointing to interfaces. This makes me wonder if some of the YANG
    structure
    > would belong more naturally as an augment to ietf-interfaces instead?
    I mean,
    > it doesn't sound fun to define the same interfaces in a lot of
    different
    > places, just because a protocol needs some additional information.
    This is just
    > a casual observation from an mpls-innocent guy, so you can disregard
    if you
    > feel it's irrelevant.
    >
    > #6) MD5 key
    >
    > There is a leaf md5-key of type string. Is this leaf sensitive from a
    security
    > point of view? A plaintext string would not be ideal if that is the
    case.
    > Choose a crypto type instead. Also, the format of this string is not
    defined.
    > Hex without spaces? Explain the format in the description.
    >
    > ><
    >
    > _______________________________________________
    > mpls mailing list
    > mpls@ietf.org
    > https://www.ietf.org/mailman/listinfo/mpls