Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
tom petch <ietfc@btconnect.com> Wed, 02 January 2019 11:16 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD6D12D4E9; Wed, 2 Jan 2019 03:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 BhSdHTdx0Ru1; Wed, 2 Jan 2019 03:16:34 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130112.outbound.protection.outlook.com [40.107.13.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C4212872C; Wed, 2 Jan 2019 03:16:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cdSOjYH+HtReoz4PC6CTbHN1K/yyGzqpyE2Bb0sjUyk=; b=eFjpFsNfWgU6wsvvsN7MbkRSFjqO2JU0R9jUiqeQv8kjpuYsjAD1BVULvcmTky+2mSbG5TH4GDvGSD2NI6z804tMJ5tym6IzhbdFcfesaeprb+qpRPhnVPnf9H3OgrqB0gO7IpRUxTybNDUSNMj5dVw3vAU+3biuII8kQYGy3AE=
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com (20.178.23.17) by AM0PR07MB4754.eurprd07.prod.outlook.com (52.135.152.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.5; Wed, 2 Jan 2019 11:16:30 +0000
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::30d7:2d62:cf50:fb2a]) by AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::30d7:2d62:cf50:fb2a%2]) with mapi id 15.20.1495.005; Wed, 2 Jan 2019 11:16:30 +0000
From: tom petch <ietfc@btconnect.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, Ebben Aries <exa@juniper.net>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
CC: "draft-ietf-isis-yang-isis-cfg.all@ietf.org" <draft-ietf-isis-yang-isis-cfg.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Thread-Index: AQHUooycHlP19WSsQ0KaVvaziE5yug==
Date: Wed, 02 Jan 2019 11:16:30 +0000
Message-ID: <009101d4a28c$905b2300$4001a8c0@gateway.2wire.net>
References: <154025553381.13801.5009678921928527816@ietfa.amsl.com> <03ff01d48641$8f8d8600$4001a8c0@gateway.2wire.net> <19850_1543334259_5BFD6973_19850_302_6_9E32478DFA9976438E7A22F69B08FF924B7768B5@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <009101d4a135$a59c2780$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0304.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a5::28) To AM0PR07MB5506.eurprd07.prod.outlook.com (2603:10a6:208:103::17)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.139.215.184]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4754; 6:oZrGEsshadKoiVlSwP10TGtwIt7UmGqMbGMxSwX5aPDWNGxyveovKNvIC4BpClzrOXLRjWTdjsW74W/jLX5T0vMmlSSX6q1HxyCq+RnVgAgbYS/ILGfq66zw+dJQkTfGTl8MAjB5Ggfpulc1RVhIQ15ffX6xbzco8s5ma8KjcVgNslk1JKvH5HmvnCKglbMmN4Hd8brJ7x8YRD6UPqK2BjExNsTpCuHncJdJ6hkCUNNrIGNK5PImGnFd44W/Z+H3T7KBMjcc09c50EiiJ0MPG34NCxgjU3rlpqTurp6Cdxam5h8rLxntcV+/LLBXg+EObUWbNaDyLsXF9Hn7SIIp6asCQ/gapwou6bTUB3Q/5MgkJQ2yFDX1wFFq59tQZy1bFQwWGaQ7o0whmb9H6w0MI3c4B4lKa9HbOOxpp7akn03r3HwLkOoRcdF837H6tABvEpe1gyZEwKvtAd63Fw+ABw==; 5:atr6eVvRqckvvw/CuY/mGMBnUjgJylNwa+N351T4ZKC5UJXGaSli47agKtBtCNgSMfuLRSZva/DjHQ7QRBl53+XOzMA5NWdCRn9jgL5NvpIYgImN6etmfQN7aKC+ZMGAjiaVXfmRiHioac6HctUq+ebJeJjOeZDl/5AMTzF7h/kbSkCP2rG2J3Scub0BC0I/hBA+xXnbNTmexoV4DuKPIg==; 7:ltKJ70OSCeM9W9c8Zp+Y77/B9Mq8oWYrWgmvmN72/VV5ty3xhnelc7090KVDRNlKhNiC2xFCU6Fkx7jxDmt5El6x5746eeBYWpsoWR2tj3khZgSaBsrVnwByiHM9nsWWlqp0pgbwTvBS1gpEw8evVg==
x-ms-office365-filtering-correlation-id: 0ebb3912-30d0-45fe-a745-08d670a3bee3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7193020); SRVR:AM0PR07MB4754;
x-ms-traffictypediagnostic: AM0PR07MB4754:
x-microsoft-antispam-prvs: <AM0PR07MB4754524600FC8719462F1B03A08C0@AM0PR07MB4754.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(93006095)(93001095)(10201501046)(3231475)(944501520)(52105112)(3002001)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4754; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4754;
x-forefront-prvs: 0905A6B2C7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(396003)(376002)(136003)(13464003)(51444003)(189003)(199004)(71190400001)(4744004)(551544002)(14496001)(106356001)(86152003)(71200400001)(54906003)(93886005)(256004)(14444005)(5024004)(9686003)(6512007)(6306002)(53936002)(6246003)(110136005)(84392002)(2906002)(86362001)(66574012)(4326008)(316002)(1941001)(99286004)(105586002)(7736002)(1556002)(305945005)(44736005)(6436002)(486006)(186003)(8936002)(81156014)(8676002)(81166006)(478600001)(966005)(476003)(6506007)(5660300001)(25786009)(66066001)(53546011)(97736004)(26005)(76176011)(68736007)(2501003)(52116002)(102836004)(3846002)(14454004)(446003)(6486002)(6116002)(33896004)(386003)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4754; H:AM0PR07MB5506.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sNYvY4KoULfZvHRxTQqjAjO7dOafCo5TH/AieWsyM9fTZMcMbarmynHyITCDKm2INakVRYJ8RmS7caXBhgOwdspdzvujvYPo3DCOj2RMb0xvQf7w0W4H0t5dXzKckhGUOJzuDQIy1atUjySqc+m8UeIgPZx+C9E4yY7XDQpwtEzz+Npp9k4dtd9fo3e8OoILcDlmEcUYwGi7AYKHncVqnkutfRV59din3Vf/5X8eGEsvzzL4XyozWWEu6lleLeFhrRibpZCgveYLZIOWAK/Hf92+GP/AjiaD2kQ7QXGYsIPsxUYTWom8cCpX9FzZGTKH
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <69C925E1FBEDCF4FB851AB4CABE71BBE@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ebb3912-30d0-45fe-a745-08d670a3bee3
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2019 11:16:30.8449 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4754
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/lYL7aIn1yY-iGNRq3485KUAN5Vc>
Subject: Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jan 2019 11:16:37 -0000
Here are the rest of my comments on -29 with a slight tweak to the subject line. I would regard most of these (but not the first two) as non-discussable, ie I won't complain if you disagree:-) RFC1195 is in the YANG module but not the references of the I-D RFC5029 is in the YANG module but not the references of the I-D PSNPs, CSNPs expand on first use - LSP I think ok leaf best { type boolean; what is true and what false? I can guess from the English semantics of the name but would rather not guess. leaf non-best-reason { type string; suggest a maximum length, perhaps 127 or 255 ( unless you expect screenshots or packet traces to be attached). As it stands, you could validly receive a length of 18446744073709551615. You have a mixture of System-id system-id System id System ID System Id system id system ID suggest consistency; system-id wfm You have a mixture of lsp-id LSPID LSP ID here, perhaps lsp-id for the names and LSP ID in the text case password { leaf key { type string; perhaps better with a minimum length leaf i-e { type boolean; what is true and what false? here I am reluctant even to guess /"Authentication keyto/ "Authentication key to/ " the authentication key MUST NOT be presented in" RFC2119 language means that RFC2119 boilerplate should be in the YANG module (but without the [..] ie the reference must be plain text not an anchor). It is recommended to use an MD5 hash to present the authentication-key."; Mmm I think that this may be a red flag to security AD or directorate as being too vague as well as MD5 too weak; and I think this should be explicitly called out in Security Considerations. list level-db { key level; leaf level { A common convention is for a list of leaf thing to be named things i.e. list levels { key level; leaf level { rpc clear-adjacency { "Name of the IS-IS protocol instance whose IS-IS information is being queried. queried or cleared? Tom Petch ----- Original Message ----- From: "tom petch" <ietfc@btconnect.com> Sent: Monday, December 31, 2018 6:21 PM Subject: Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-yang-isis-cfg-24 > Stephane > > A new and different comment. > > grouping neighbor-gmpls-extensions { > > has a text reference to RFC5307 which does not appear in the references > for the I-D. However, before adding it, I would like to know why it is > a good reference for switching capabilities (which is part of this > grouping). I think that the reference for switching capabilities should > be RFC7074 (which this I-D does not currently reference and should IMO). > > And that begs the question, why is switching-capability an unrestricted > uint8 when only 12 values are valid and three are deprecated? > > So why not use > > draft-ietf-teas-yang-te-types? > > I have a number of additional comments on cfg-29 but this is the one > that may take some discussion. > > Tom Petch > > > ----- Original Message ----- > From: <stephane.litkowski@orange.com> > > Hi Tom, > > Thanks for your comments. I will fix them asap. > Regarding: > " Line length is within the RFC limit but the effect is to spread many > of the description clauses over multiple lines with indentation of 56 > characters, not user friendly e.g. > description > "List of max LSP > bandwidths for different > priorities."; > " > What's your suggestion on this one ? > > Brgds, > > -----Original Message----- > From: tom petch [mailto:ietfc@btconnect.com] > Sent: Tuesday, November 27, 2018 12:11 > To: Ebben Aries; yang-doctors@ietf.org > Cc: draft-ietf-isis-yang-isis-cfg.all@ietf.org; lsr@ietf.org; Tarek Saad > (tsaad) > Subject: Re: [Lsr] Yangdoctors last call review of > draft-ietf-isis-yang-isis-cfg-24 > > Some quirks in-25 > > I see lots of YANG reference statements - good - but no mention of them > in the I-D references - not so good. My list is > > 5130 > 5305 > 5306 > 5880 > 5881 > 6119 > 6232 > 7794 > 7810 > 7917 > 8405 > > Also perhaps > OLD > reference "RFC XXXX - YANG Data Model for Bidirectional > Forwarding Detection (BFD).Please replace YYYY with > published RFC > number for draft-ietf-bfd-yang."; > > NEW > reference "RFC YYYY - YANG Data Model for Bidirectional > Forwarding Detection (BFD). > > -- Note to RFC Editor Please replace YYYY with published RFC > number for draft-ietf-bfd-yang."; > > OLD > reference "draft-ietf-bfd-yang-xx.txt: > YANG Data Model for Bidirectional Forwarding > Detection (BFD)"; > NEW > reference "RFC YYYY - YANG Data Model for Bidirectional > Forwarding Detection (BFD). > > -- Note to RFC Editor Please replace YYYY with published RFC > number for draft-ietf-bfd-yang."; > > > Line length is within the RFC limit but the effect is to spread many of > the description clauses over multiple lines with indentation of 56 > characters, not user friendly > e.g. > description > "List of max LSP > bandwidths for different > priorities."; > > > Acknowledgements is TBD. I note that the editor list of the YANG module > is somewhat longer than the editor list of the I-D. > > I note that the augmentation of interfaces seems to have no conditional > and so will augment all interfaces. I think that this is a generic issue > but do not see it being addressed anywhere. > > In a similar vein, you are defining MPLS objects and I am unclear > whether or not those should be conditional, or part of the MPLS YANG > modules or both (copying Tarek for this) > > Tom Petch > > ----- Original Message ----- > From: "Ebben Aries" <exa@juniper.net> > Sent: Tuesday, October 23, 2018 12:45 AM > > > Reviewer: Ebben Aries > > Review result: On the Right Track > > > > 1 module in this draft: > > - ietf-isis@2018-08-09.yang > > > > No YANG compiler errors or warnings (from pyang 1.7.5 and yanglint > 0.16.54) > > > > "ietf-isis@2018-08-09" module is compatible with the NMDA > architecture. > > > > Module ietf-isis@2018-08-09.yang: > > - Both the description and the draft name reference that this module > is > > specific to configuration but contains operational state nodes in > addition > > to RPCs and notifications. Any wording suggesting this is only > > configuration should be changed > > - Module description must contain most recent copyright notice per > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.1 > > - Module description reads "common across all of the vendor > implementations". > > I don't think this needs to be called out as such as that is the > overall > > intention of *all* IETF models > > - This module contains '22' features (and the respective OSPF module > currently > > contains '26'). While it is understood the purpose of these > features in the > > module, take precaution as to complexity for clients if they need to > > understand >= quantity of features per module in use on a > > network-element. We are going to end up w/ feature explosion to > convey > > *all* possible features of each network-element leading to > divergence back > > towards native models at the end of the day. A large amount of > these > > feature names could be defined within a more global namespace (e.g. > nsr) but > > this gives us a granular yet cumbersome approach (e.g. feature > isis:nsr, > > ospf:nsr, etc..) > > - RPC 'clear-adjacency' does not have any input leaf that covers > clearing a > > specific neighbor/adjacency (See comments below as well regarding > RPC > > alignment w/ the OSPF model) > > - RPC 'clear-adjacency' has an input node of 'interface' however this > is just > > a string type. Is there any reason this is not a > leafref/if:interface-ref > > (much like in the OSPF model) > > - Child nodes within a container or list SHOULD NOT replicate the > parent > > identifier per > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.3. > 1. > > > > A case in point is the list /afs/af that has a leaf of 'af' > > <afs> > > <af> > > <af>ipv4</af> > > <enable>true</enable> > > </af> > > </afs> > > > > Not only is this replication, but we should likely not abbreviate > 'afs' if > > we are using the expanded 'address-family' in other IETF models such > as > > ietf-i2rs-rib > > > > > > General comments on the draft + nits: > > - Since YANG tree diagrams are used, please include an informative > reference > > per > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.4 > > - Section 1.1 does not need to exist since this would be covered by > the > > reference mentioned above > > - Reference to NMDA compliance should be contained within Section 1 > (vs. > > Section 2) per > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.5 > > - Section 2: It seems reference should be given to the location of > where the > > ietf-routing module is defined (As well as reference to NMDA RFC in > the > > above reference) > > - Section 2.1: "Additional modules may be created this to support..." > needs > > slight rewording adjustment > > - Section 3: The RPC operations are named 'clear-adjacency' and > > 'clear-database' rather w/ reliance off namespacing for uniqueness. > This > > section refers to 'clear-isis-database' and 'clear-isis-adjacency' > > - Section 4: Notification name mismatch in this section from actual > naming > > within the module (e.g. 'adjacency-change' should rather be > > 'adjacency-state-change') > > - Section 7: Security Considerations will need updating to be > patterned after > > the latest version of the template at > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines per > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.7 > > - Section 12: All modules imported within this module MUST be > referenced > > within this section per > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.9. > > There are quite a few missing from this section right now > > - Appendix A: Some of the XML elements are off in alignment > > - Appendix A: Examples must be validated. The example given has the > following > > issues: > > - /routing[name='SLI'] and /routing/description are invalid data > nodes and > > do not exist. I'm not sure why they are in the XML example here > > - The example is meant to reference configuration however > > /routing/interfaces is a r/o container > > - The control-plane-protocol 'type' needs to be qualified - e.g. > > <type > xmlns:isis="urn:ietf:params:xml:ns:yang:ietf-isis">isis:isis</type> > > - The area-address does not validate against the pattern regex and > must end > > with a '.' e.g. > > <area-address>49.0001.0000.</area-address> > > - metric-type/value is set to 'wide' which is invalid. This should > rather > > be 'wide-only' > > - isis/afs/af/af is set to 'ipv4-unicast' which is invalid. This > should > > rather be 'ipv4' per iana-routing-types > > - /interfaces/interface/type must be populated and is invalid. This > should > > rather be qualified as such: > > <type > xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:softwar > eLoopback</type> > > <type > xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:etherne > tCsmacd</type> > > - /interfaces/interface/link-up-down-trap-enable must have a value > > associated as such: > > <link-up-down-trap-enable>enabled</link-up-down-trap-enable> > > - NP container 'priority' has a must statement checking if an > interface-type > > is set to 'broadcast' however if you take the XML example from > this > > section, it will fail to validate even if <priority> is not > defined > > underneath an interface-type of 'point-to-point'. It seems to me > that > > this logic may need to be readjusted or not exist at all (priority > can > > still be set on implementations on loopback interfaces - which > would > > default to 'broadcast' in the example here). Could you not solve > this > > with use of 'when' vs. 'must' as such: > > > > when '../interface-type = "broadcast"' { > > description "Priority can only be set for broadcast > interfaces."; > > } > > > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.18 > ..2. > > > > - /interfaces/interface/ipv4/mtu must contain a valid value (and > likely not > > need to be defined for Loopback0) > > - 'isis/mpls-te/ipv4-router-id' is invalid and should rather be > > 'isis/mpls/te-rid/ipv4-router-id' > > - 'isis/afs/af/enabled' is invalid and should rather be > 'isis/afs/af/enable' > > - Examples should use IPv6 addresses where appropriate per > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.12 > > ________________________________________________________________________ > _________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
- [Lsr] Yangdoctors last call review of draft-ietf-… Ebben Aries
- Re: [Lsr] Yangdoctors last call review of draft-i… stephane.litkowski
- Re: [Lsr] Yangdoctors last call review of draft-i… tom petch
- Re: [Lsr] Yangdoctors last call review of draft-i… stephane.litkowski
- Re: [Lsr] Yangdoctors last call review of draft-i… tom petch
- Re: [Lsr] Yangdoctors last call review of draft-i… Acee Lindem (acee)
- Re: [Lsr] Yangdoctors last call review of draft-i… tom petch
- Re: [Lsr] Yangdoctors last call review of draft-i… tom petch
- Re: [Lsr] Yangdoctors last call review of draft-i… stephane.litkowski
- Re: [Lsr] Yangdoctors last call review of draft-i… stephane.litkowski
- Re: [Lsr] Yangdoctors last call review of draft-i… stephane.litkowski
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Juergen Schoenwaelder
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Ladislav Lhotka
- Re: [Lsr] Yangdoctors last call review of draft-i… tom petch
- Re: [Lsr] Yangdoctors last call review of draft-i… stephane.litkowski
- Re: [Lsr] Yangdoctors last call review of draft-i… tom petch
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Juergen Schoenwaelder
- Re: [Lsr] Yangdoctors last call review of draft-i… stephane.litkowski
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Juergen Schoenwaelder
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… stephane.litkowski
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… stephane.litkowski
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Juergen Schoenwaelder
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… stephane.litkowski
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Juergen Schoenwaelder
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Andy Bierman
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Juergen Schoenwaelder
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Acee Lindem (acee)
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Juergen Schoenwaelder
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… stephane.litkowski
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Andy Bierman
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Acee Lindem (acee)
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… Andy Bierman
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… tom petch
- Re: [Lsr] [yang-doctors] Yangdoctors last call re… stephane.litkowski