Re: [Teas] [Gen-art] Genart last call review of draft-ietf-teas-yang-te-types-09

Alissa Cooper <alissa@cooperw.in> Thu, 22 August 2019 00:45 UTC

Return-Path: <alissa@cooperw.in>
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 D436512004C; Wed, 21 Aug 2019 17:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=cooperw.in header.b=HX+aG5OT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lBPL3BD5
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 BZdUGT9MQXY0; Wed, 21 Aug 2019 17:45:34 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BE7E120125; Wed, 21 Aug 2019 17:45:34 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4861521FE0; Wed, 21 Aug 2019 20:45:33 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 21 Aug 2019 20:45:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=7 k2gsHggS63G4kPwf6BDlO3Utu9vQj7bTu2h60MYXyY=; b=HX+aG5OTE5rLzumLl ZFp/1gk7jgFSUCUPvXmkUD7Snf97pbQvOlhSd311hioaGJFcq53Fgf6YWJlrdUuo fWZOkKbsxIKtcPy/JtN9NWhxWIyjPb5aNj/w8DtUn3geO2hubI3NBM16D6+7ZVYo trNTzReVjwtE98e4+mRBRnWCeQFhJfohL43cD/I1cj3SkWZXJG9ES+tGA6gVrPT3 aIt4eqZoOe4SsUgonMhr6r15mmDJF0Qg33+aZxK72j+b99hKL7Bzc4Fsnpygg7qC B89e9ZIUoMkT2QdKerBS6FDosLwaMbB5kqjfmvKvb3sZV/RJ7wUnn+7dMxJbyRQQ gshMw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=7k2gsHggS63G4kPwf6BDlO3Utu9vQj7bTu2h60MYX yY=; b=lBPL3BD5bVOJESTUoAXNn5KMsKDePO/02U3mZgJLNpM/y2jdeYP4TsgdY CC339XOBuzCwxpTLidxJX8aLAIhJg5gl3kzWallRPirDtcc5suC9KnS7Pa7m8Xtx 4jJcStju3ViNJ3m5QvDFD+XrZB2Vv0nrWF6zCaXYjIsLE8h4U4FdYkn1+5nlRl4d /GHB2X+vKlPWXJcLcwXO2h/0oD+d/iWMfUKYur/d3uhtLTXzqexXGLJAInNoJrtf LdmoiglSKwLokPqioAP8vwvloprl5pd6YYbGpQgFCyyFUrPyc4vmTV7Z43QrjvAA BsCLtELkO2kFHttAqcmFcIfvNSV+A==
X-ME-Sender: <xms:rOVdXee_5j4_wIJx_z3mCYuaDekOWaaYst60DD6vjVFAC5AEwFWb4A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeggedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucfkphepud ejfedrfeekrdduudejrdelvdenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgr segtohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:rOVdXcc0wvSwTH25aGHgBlwek7NS7w9r92Gje2CeOWcitYlR9EZ1QA> <xmx:rOVdXagvOq0XVa055cKwm6Isxr2ar46sqKK8RdEgq7pDAba8PCO_fA> <xmx:rOVdXQREdrY0pUXDarZLdHTI0uoAZtvhOvS6-kPEDr5jjCRBFhhHEQ> <xmx:reVdXWsfr5M9VUuNPHO04Xx4S0rFCsd-hlcEuO419DxtFp-2AX2_dA>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 3E57C80061; Wed, 21 Aug 2019 20:45:32 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B3D67EC@sjceml521-mbs.china.huawei.com>
Date: Wed, 21 Aug 2019 20:45:31 -0400
Cc: "gen-art@ietf.org" <gen-art@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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F9FF9146-2D43-4891-B68A-0A6693B94B7A@cooperw.in>
References: <155787365282.30182.991962621463628123@ietfa.amsl.com> <0C72C38E7EBC34499E8A9E7DD00786391C7031EB@sjceml521-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F66B3D67EC@sjceml521-mbs.china.huawei.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, Igor Bryskin <Igor.Bryskin@huawei.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/r3nD_yBb8fpxeAMLqTkVB6p1CY8>
Subject: Re: [Teas] [Gen-art] Genart last call review of draft-ietf-teas-yang-te-types-09
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, 22 Aug 2019 00:45:37 -0000

Linda, thanks for your review. Igor, thanks for your response. I’ve entered a No Objection ballot.

Alissa


> On May 15, 2019, at 4:51 PM, Linda Dunbar <linda.dunbar@huawei.com>; wrote:
> 
> Igor, 
> 
> Thank you very much for the reply. 
> Are you saying that all the "common TE types" in this document have been validated? If yes, then it is good. Thank you. 
> 
> Just as a Gen-Art Directorate reviewer, I did my due-diligence to check the common types defined in your draft are actually from the referred RFCs to make sure they are consistent. But I can't easily cross check them.  I understand it can be a lengthy job to validate all of them. 
> 
> If the WG has checked the consistency, then it is all good. 
> 
> Thank you very much for the explanation. 
> 
> Linda
> 
> 
> 
> -----Original Message-----
> From: Igor Bryskin 
> Sent: Wednesday, May 15, 2019 1:13 PM
> To: Linda Dunbar <linda.dunbar@huawei.com>;; gen-art@ietf.org
> Cc: draft-ietf-teas-yang-te-types.all@ietf.org; ietf@ietf.org; teas@ietf.org
> Subject: RE: Genart last call review of draft-ietf-teas-yang-te-types-09
> 
> Hi Linda,
> 
> Thank you for your comments.
> 
> Please, note that it was never a goal of this work to produce some sort of Oxford English Dictionary for Traffic Engineering with providing references illustrating basic and subtle usages of each ID of each defined TE related definition (as OED does).
> No, our ambitions are far more modest. The work was triggered by realization that many exact same types required by te-topology model are also required by te-tunnel model. We could have (and initially started to) define the types twice (separately for each model), but later decided to put the common te types into a single module/document. This way the te-topo and te-tunnel model families and models directly depending on them (e.g. path computation and VN models) could use the common set of types. This is our primary objective. We also encourage using the te-types model in any other TE related model (if/when it proves useful) with understanding that some types/identities may not be found and hence need to be defined in addition to what has been defined in the te-types model.
> 
> Furthermore, in defining TE types and identities we tried to re-use as much as possible the definitions provided by IETF RFCs describing signaling and routing protocols and their management. Although this, strictly speaking, is not necessary, such an approach is far less confusing and more convenient for the model implementers and readers (as compared to independent definitions). This said, on some occasions we have added IDs to cover additional use cases, which understandably were never covered by older RFCs.
> 
> I believe your understanding “This document defines all the "Identity" (or types) for TE data types)” is incorrect. Nor I think the cross-check on completeness you mentioned is a requirement.
> 
> Regards,
> Igor      
> 
> 
> 
> 
> -----Original Message-----
> From: Linda Dunbar via Datatracker [mailto:noreply@ietf.org] 
> Sent: Tuesday, May 14, 2019 6:41 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-teas-yang-te-types.all@ietf.org; ietf@ietf.org; teas@ietf.org
> Subject: Genart last call review of draft-ietf-teas-yang-te-types-09
> 
> Reviewer: Linda Dunbar
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
> 
> Document: draft-ietf-teas-yang-te-types-??
> Reviewer: Linda Dunbar
> Review Date: 2019-05-14
> IETF LC End Date: 2019-05-16
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> This document defines all the "Identity" (or types) for TE data types.
> Therefore, it is hard to tell if all the types are completely specified without cross reference to the TE specification drafts. For example, I tried to cross reference to RFC3209 on "identity local-protection-desired", the words are not completely matched in RFC3209.
> 
> (e.g. identity local-protection-desired { base session-attributes-flags; description "Fastreroute local protection is desired."; reference "RFC3209"; }
> 
> It would make it much easier to validate the YANG model if the page number of the referenced RFC is listed in the Reference, or the actual TLV being referenced are described.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> Add the page number of the referenced RFC  to make it easier to validate the correctness of the "types", or describe the actual TLV being referenced .
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art