Re: [Teas] not a Yangdoctor review of draft-ietf-teas-yang-te-types-03

"Tarek Saad (tsaad)" <tsaad@cisco.com> Thu, 07 February 2019 15:03 UTC

Return-Path: <tsaad@cisco.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B863124C04; Thu, 7 Feb 2019 07:03:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.601
X-Spam-Level:
X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=g2R6QR/G; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Wm89+Ln4
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 zyRFcHB0EFYL; Thu, 7 Feb 2019 07:03:53 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0731200D7; Thu, 7 Feb 2019 07:03:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78297; q=dns/txt; s=iport; t=1549551832; x=1550761432; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jZ+axA+RpcyhqhjAW7TUQG//LzpQkEZBe/th/DJePnk=; b=g2R6QR/Gi+tYLepevIiuD/sqB+VsiPhWbMzaS3aml7sbm91x9U0bVho3 C7BY3aKhzKuTouzE61pnckKkQ+t8d+SuDTdfFrikDaOqVDW/oaIOMcGKh jaV8DXVJtw8B3fuuvTS7VRoQZ6PgbjOk26jgVOcgKxiQBlHYeWY+AUonN E=;
IronPort-PHdr: =?us-ascii?q?9a23=3AZ9m0JB8VpQhSJP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdKeAET3BPXrdCc9Ws9FUQwt8g=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAB2SFxc/5xdJa1aCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENIyUrA2d0BAsnhAODRwOEUIslSoI?= =?us-ascii?q?NmBEUgRADUAQLAQEYAQoJhEACF4MRIjQJDQEDAQECAQECbRwMhUoBAQEDAQE?= =?us-ascii?q?BIQoTAQEsCwEEBwQCAQgRAwEBASEBCQICAiULHQgCBAENBYMkAYEdTAMNCAE?= =?us-ascii?q?OoXsCihRxgS+CeAEBBYR/GIILAwWMQxeBQD+BEScfgh4ugx4BAQIBgTQSLwk?= =?us-ascii?q?NglwxggQiiwGFGR2GcosSVwkChzWDZocoGYFthUaIEYMRiSiBBYEOhCqMFwI?= =?us-ascii?q?EAgQFAg0BAQWBRjiBVnAVGiEqAYJBCYITg26FFIU/cgGBJ41SAQE?=
X-IronPort-AV: E=Sophos;i="5.58,344,1544486400"; d="scan'208,217";a="517123089"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2019 15:03:34 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x17F3Xb9001156 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Feb 2019 15:03:34 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 7 Feb 2019 09:03:33 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 7 Feb 2019 09:03:32 -0600
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 7 Feb 2019 09:03:32 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jZ+axA+RpcyhqhjAW7TUQG//LzpQkEZBe/th/DJePnk=; b=Wm89+Ln4xsk/143vho/u9Yxix1XyTFv24i1cSQMnQWSsXW+ByJpAjLycMNJuYq6S/HXDFM0nYiL7OQbdONyKmJDh+YhzU46dHFPG0d/p7fYsBqZHxcwcFHK46pXuEWzltduMn4lNeAHiTQvCf85vO5L9LypFD9c2+ap62ehJ7/A=
Received: from BN6PR11MB1794.namprd11.prod.outlook.com (10.175.100.8) by BN6PR11MB1810.namprd11.prod.outlook.com (10.175.96.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.17; Thu, 7 Feb 2019 15:03:30 +0000
Received: from BN6PR11MB1794.namprd11.prod.outlook.com ([fe80::f850:65c4:46eb:7e66]) by BN6PR11MB1794.namprd11.prod.outlook.com ([fe80::f850:65c4:46eb:7e66%9]) with mapi id 15.20.1601.016; Thu, 7 Feb 2019 15:03:30 +0000
From: "Tarek Saad (tsaad)" <tsaad@cisco.com>
To: tom petch <ietfa@btconnect.com>, Jan Lindblad <janl@tail-f.com>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "draft-ietf-teas-yang-te-types.all@ietf.org" <draft-ietf-teas-yang-te-types.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] not a Yangdoctor review of draft-ietf-teas-yang-te-types-03
Thread-Index: AQHUsz7qhRxUpP0qbkyLe9M1xeeg7qXUMkAA
Date: Thu, 7 Feb 2019 15:03:29 +0000
Message-ID: <62AD0720-EA72-4F6A-B476-13F9637243DD@cisco.com>
References: <154090780735.15255.3911131220920609603@ietfa.amsl.com> <973699DE-882E-4531-A7D5-32AFEF4359E7@cisco.com> <6CC3CA10-0768-4C99-9237-30A78E1EC3DA@tail-f.com> <BB36593B-0A4E-4F88-A088-3C35BBCAB902@cisco.com> <39E705F8-EE93-4F16-AD3A-39B2E6FCC37E@tail-f.com> <00bc01d4b33e$c42e4d20$4001a8c0@gateway.2wire.net> <B9068E7A-9D15-4F77-A9BF-3B25092DC1CC@cisco.com> <005f01d4bd61$8855f8c0$4001a8c0@gateway.2wire.net> <8009797C-AAFD-46A9-860F-04059D44F6D1@cisco.com> <00c901d4bed9$fdf8aae0$4001a8c0@gateway.2wire.net>
In-Reply-To: <00c901d4bed9$fdf8aae0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.15.0.190117
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tsaad@cisco.com;
x-originating-ip: [2001:420:c0c0:1005::2f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR11MB1810; 6:6UI2bfya+HyeeW/1MuL8SFEGEYxk7k/2PxUA61Diux+VdtXcqejy9ydBrpft9CKmhbhVd6AOEdRtlFpjcSu6EsprC4gP50jLWM9GaGC9eggwLq7SB3o0BffnNz8V7AZTKvXfl5+K8JJaZZX5692r6jk3avtm9POyhAysVmWpoBOVJ7ec8wwNWoIXU8WJerStn6OLK/8VNn0q58XXaqudNc1YuZQPCjQa79VhDYz3ZMzjmyffu8B+4I83rS7Huo4cMc0Nw5JmhfQbYf+5kXo6jLilI6EnTdyHOfGLKdEnncJeYGjHMgZiISDkOKm3vE+GRheiqptLQ0L24NUCZi/AiyO1CUDSYId1L5RCxlbYPXaxqVV5FV/TU2/MUe8XX7tuUIb3nUtT4sFIaPJQl1M+erNVigrF5VlrkMPiMQZVSpQAdkRjwNeOPl7/gEuHqPj6dBVFUz2BNLxcKckdhj9pTg==; 5:rLDtje40PPqBTEd/bwR9uLOzsBza9QTPsyJiCcUwch36r6xLXrcHHMuTPe0pwTWRJqs66zeSnl73ZbKMwozP/fcv/8iec+mBJJ1c6nYG0Myc6j3lmxt4KNrrOiY2XAyKRY7o4+v/nnBrgVc1cRo//keERiTSHcKDXOmptcJu52p/Qt1Yor919aLpEDKH8UVam7m/qS6t+lqRVpH1CX/daQ==; 7:kA3VK8UkvZDf1p9krH7DMXtoznpFGYjZEbWYD+mMdIGqR2WPMfYY+F1oVeGDeWOHMaKpc/r+mq7XSlXaJZsgIU7xR0wK4PmFXlqKpgvV7QF62TPEQVKZngi5RI7Plt3bOonYwFO5mlCBLDsSuJEqKQ==
x-ms-office365-filtering-correlation-id: 5776e441-f939-494b-6c46-08d68d0d6bcf
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BN6PR11MB1810;
x-ms-traffictypediagnostic: BN6PR11MB1810:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <BN6PR11MB18107424F7CEFCEC8632DC2CA3680@BN6PR11MB1810.namprd11.prod.outlook.com>
x-forefront-prvs: 0941B96580
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(396003)(136003)(39860400002)(199004)(43544003)(189003)(13464003)(71190400001)(6116002)(46003)(790700001)(6246003)(99286004)(33656002)(36756003)(97736004)(8676002)(53546011)(6486002)(6506007)(316002)(186003)(7736002)(9326002)(11346002)(82746002)(58126008)(54906003)(229853002)(110136005)(8936002)(296002)(476003)(486006)(2616005)(2906002)(6436002)(6512007)(68736007)(14444005)(53946003)(54896002)(81156014)(102836004)(53936002)(236005)(81166006)(256004)(25786009)(446003)(606006)(76176011)(71200400001)(106356001)(105586002)(4326008)(93886005)(966005)(6306002)(83716004)(14454004)(86362001)(478600001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1810; H:BN6PR11MB1794.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-message-info: NLXtMzX18Ffw6ZnVG7gQAvIT6OaP/cGY97iHjDvMUXDkvv3BfjgC0lwezlwluDagcVgFCYWG1T0u1+4yp6Tg/gP7mG7TfGqiy3PmVmVICRmXzT45ZZCqeCmczmJawhg8lqszH9TpiAUYmgVXXX34cdkxDlVVsTaABUxMLqMrZkNKeESxsD/8iLa++MUeLwsRnrNP/7F69hBOgS1uUyI2U+97vXZ8SCoTVqqrJO0w4Eh4Lix4e+y/27QRHqsgOB0Q+ZmTWVG7QUbMu4WaOsd+mi0m0qFRj/3PSP6AkDPrqpOlEayLQxD7+unmgtGeimF7zvJdBCK029Hng2jOMoKFg64OaA3txCm40lUZ/aWrLCx9OvqixN4XQwj1oJUBg0lLnLiEPs5PlP3eaTnXZ+utGwW3cCr4cKtBtXwhaLCu/Zs=
Content-Type: multipart/alternative; boundary="_000_62AD0720EA724F6AB47613F9637243DDciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5776e441-f939-494b-6c46-08d68d0d6bcf
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2019 15:03:29.9588 (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-Transport-CrossTenantHeadersStamped: BN6PR11MB1810
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/KHa03bPxZbVTmtk7zt4DOV6BJAI>
Subject: Re: [Teas] not a Yangdoctor review of draft-ietf-teas-yang-te-types-03
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 15:03:57 -0000

Hi Tom,



>>     - anything referenced in the YANG module must have a HTML/XML style

>>     reference somewhere in the RFC outside the YANG module.



[TS]: I don’t mind if it is a common practice to follow it.. However, I’d note as can be seen in the uploaded ver -05, I am able to have all references mentioned in YANG module show up in the references section of the I-D without explicitly needing cross-reference them in the I-D text outside of the YANG module. FWIW, kramdown-rfc2629 allows to list those at the top so they automatically get added to the references section.



Also, since I see (some) IETF tools are already parsing the I-D YANG module contents (e.g. for replacing RFC tags with HTML’zed URL links – see below), I would have thought it would be possible to determine such warnings were inaccurate..



“  == Unused Reference: 'RFCXXXX' is defined on line 3780, but no explicit

     reference was found in the text”





E.g.:


Liu, et al.                  Standards Track                    [Page 8]
________________________________
<https://tools.ietf.org/html/rfc8294#page-9>
RFC 8294<https://tools.ietf.org/html/rfc8294>                 Routing Area YANG Types           December 2017


      revision 2017-12-04 {
        description "Initial revision.";
        reference
          "RFC 8294<https://tools.ietf.org/html/rfc8294>;: Common YANG Data Types for the Routing Area.
           Section 3<https://tools.ietf.org/html/rfc8294#section-3>.";;
     }

     /*** Identities related to MPLS/GMPLS ***/

    identity mpls-label-special-purpose-value {
       description
         "Base identity for deriving identities describing
          special-purpose Multiprotocol Label Switching (MPLS) label
          values.";
       reference
         "RFC 7274<https://tools.ietf.org/html/rfc7274>;: Allocating and Retiring Special-Purpose MPLS
          Labels.";
     }

     identity ipv4-explicit-null-label {
       base mpls-label-special-purpose-value;
       description
         "This identity represents the IPv4 Explicit NULL Label.";
       reference
         "RFC 3032<https://tools.ietf.org/html/rfc3032>;: MPLS Label Stack Encoding.  Section 2.1<https://tools.ietf.org/html/rfc8294#section-2.1>.";;
     }



Regards,

Tarek



-----Original Message-----

From: Teas <teas-bounces@ietf.org>; on behalf of tom petch <ietfa@btconnect.com>;

Date: Thursday, February 7, 2019 at 6:42 AM

To: Tarek Saad <tsaad@cisco.com>;, Jan Lindblad <janl@tail-f.com>;

Cc: "yang-doctors@ietf.org"; <yang-doctors@ietf.org>;, "draft-ietf-teas-yang-te-types.all@ietf.org"; <draft-ietf-teas-yang-te-types.all@ietf.org>;, "ietf@ietf.org"; <ietf@ietf.org>;, "teas@ietf.org"; <teas@ietf.org>;

Subject: Re: [Teas] not a Yangdoctor review of draft-ietf-teas-yang-te-types-03





    ----- Original Message -----

    From: "Tarek Saad (tsaad)" <tsaad@cisco.com>;

    Sent: Tuesday, February 05, 2019 8:11 PM



    > Thanks, Tom. Please see inline below.

    >

    > -----Original Message-----

    > From: tom petch <ietfa@btconnect.com>;

    > Date: Tuesday, February 5, 2019 at 9:47 AM

    >     Tarek

    >

    >     Getting there .

    >

    >     You will need to have a reference to the new I-D references in the

    body

    >     of the I-D else you will get unused references.  One way to do

    this is

    >     to have a Section 4.1 This module references [RFC3272]. [....  I

    have

    >     not gone through and seen how many this applies to but imagine it

    is

    >     most of them.

    > [TS]: unfortunate that the tool will flag those as warning as the I-D

    YANG module clearly references them.. I am wondering if there is a

    chance or a plan to enhance the IETF idnit tool to parse the YANG module

    for references and silence such warnings?

    >



    Well no, that would be wrong.



    A YANG module needs references, for import statements and to tell the

    user where to go for more information on the objects, their use and so

    on.



    A YANG module must be plain text so cannot contain the usual HTML/XML

    style anchors that an I-D/RFC has.



    Documents referenced from within an RFC must appear in the References of

    that RFC.



    Hence

     - anything referenced in the YANG module must be in the References of

    the RFC

    - anything referenced in the YANG module must have a HTML/XML style

    reference somewhere in the RFC outside the YANG module.



    Where such references do not crop up in the existing text of the memo

    outside the YANG module, then the practice is to add a

    Section X.1

    before the YANG module saying words to the effect that this YANG module

    imports from [. and references [....



    So the tool wants enhancing to generate more warnings, not less, when

    the contents of a a YANG reference clause do not appear in the Reference

    section of the I-D.



    HTH



    I was unclear about my comment on G808; having the reference is find but

    I would prefer G.808; I note that Deborah's e-mail used G.808 even when

    referring to the 'G808' in the I-D so I think G.808 is to be preferred.



    Tom Petch





    >     Also you have G.8031 but G808.  Not wrong, but...

    > [TS]: G.8031 is already listed in references. G808 is still relevant.

    I've moved both to informative references as per other recommendations.

    >

    >           import ietf-routing-types { prefix "rt-types";

    >     now has the right RFC but the wrong title; should be

    >     Common YANG Data Types for the Routing Area

    >

    > [TS]: thank you. I'll take care of this one in the next update.

    >

    > Regards,

    > Tarek

    >

    >

    >     Tom Petch

    >

    >     ----- Original Message -----

    >     From: "Tarek Saad (tsaad)" <tsaad@cisco.com>;

    >     Sent: Thursday, January 31, 2019 2:10 PM

    >

    >     > Hi Tom,

    >     >

    >     > Thank again for your review comments below. We've uploaded

    version

    >     04/-05 which attempts to address these comments.

    >     > See inline [TS] for resolution.

    >     >

    >     > -----Original Message-----

    >     > From: tom petch <ietfa@btconnect.com>;

    >     > Date: Wednesday, January 23, 2019 at 12:13 PM

    >     > To: Jan Lindblad <janl@tail-f.com>;, Tarek Saad <tsaad@cisco.com>;

    >     > Cc: "yang-doctors@ietf.org"; <yang-doctors@ietf.org>;,

    >     "draft-ietf-teas-yang-te-types.all@ietf.org";

    >     <draft-ietf-teas-yang-te-types.all@ietf.org>;, "ietf@ietf.org";

    >     <ietf@ietf.org>;, "teas@ietf.org"; <teas@ietf.org>;

    >     > Subject: [Teas] not a Yangdoctor review of

    >     draft-ietf-teas-yang-te-types-03

    >     >

    >     >     Tarek

    >     >

    >     >     The YANG modules have lots of references - good - but they

    are not

    >     in

    >     >     the I-D references - not good.

    >     >

    >     >     My list is

    >     >

    >     >     3272

    >     >     4202

    >     >     4328

    >     >     4657

    >     >     5817

    >     >     6004

    >     >     6205

    >     >     6511

    >     >     7139

    >     >     7308

    >     >     7551

    >     >     7571

    >     >     7579

    >     >     7951

    >     >     G.808

    >     >     G.8031

   >     >     G.8131

    >     >     G.873.1

    >     >

    >     > [TS]: thanks. I've added the missing references and they should

    show

    >     in the I-D references now.

    >     >

    >     >     s.3.1 I would find more usable if the types were in an order

    I

    >     could

    >     >     recognise, such as alphabetical

    >     >

    >     > [TS]: OK, I tried an attempt to sort the typedefs

    alphabetically.

    >     >

    >     >       import ietf-routing-types { prefix "rt-types";

    >     >     reference "RFC6991: Common YANG Data Types";

    >     >     perhaps RFC8294 is intended

    >     >

    >     > [TS]: corrected to RFC8294

    >     >

    >     >     "   defined in ietf-network.yang, to help user to understand

    ""

    >     >     might benefit from a reference - is this

    >     >     draft-ietf-i2rs-yang-network-topo?

    >     >

    >     > [TS]: added reference RFC8345.

    >     >

    >     >     /"Then index of the label/ "The index of the label /

    >     >

    >     > [TS]: fixed typo.

    >     >

    >     >               container tiebreakers {

    >     >                 description

    >     >                   "The list of tiebreaker criterion to apply

    >     >                    on an equally favored set of paths to pick

    best";

    >     >                 list tiebreaker {

    >     >                   description

    >     >                   "The list of tiebreaker criterion to apply

    >     >                      on an equally favored set of paths to pick

    best";

    >     >     One description is perhaps enough

    >     >

    >     > [TS]: removed/updated redundant description.

    >     >

    >     >     uses path-objective-function_config;

    >     >     using _ is not wrong but is discouraged, mixing _ with - in

    a

    >     label more

    >     >     so

    >     >

    >     > [TS]: OK, we have moved away from using "_" in the naming.

    >     >

    >     >     /This document registers a YANG module/

    >     >     This document registers two YANG modules/

    >     >

    >     > [TS]: fixed typo.

    >     >

    >     >        name: ietf-te-types namespace:

    >     urn:ietf:params:xml:ns:yang:ietf-te-

    >     >        types prefix: ietf-te-types reference: RFC3209

    >     >        name: ietf-te-packet-types namespace:

    >     >        urn:ietf:params:xml:ns:yang:ietf-te-packet-types prefix:

    >     ietf-te-

    >     >        packet-types reference: RFC3209

    >     >

    >     >     Perhaps /3209/XXXX/

    >     >

    >     > [TS]: fixed.

    >     >

    >     > Regards,

    >     > Tarek

    >     >

    >     >     Tom Petch

    >     >

    >     >     ----- Original Message -----

    >     >     From: "Jan Lindblad" <janl@tail-f.com>;

    >     >     To: "Tarek Saad (tsaad)" <tsaad@cisco.com>;

    >     >     Cc: <yang-doctors@ietf.org>;;

    >     >     <draft-ietf-teas-yang-te-types.all@ietf.org>;;

    <ietf@ietf.org>;;

    >     >     <teas@ietf.org>;

    >     >     Sent: Monday, January 21, 2019 10:10 AM

    >     >     Subject: Re: [Teas] Yangdoctors early review of

    >     >     draft-ietf-teas-yang-te-types-03 (was -01)

    >     >

    >     >

    >     >     >

    >     >

    >     >

    >     >

    >     >

    >

    >

    >

    >



    _______________________________________________

    Teas mailing list

    Teas@ietf.org

    https://www.ietf.org/mailman/listinfo/teas