Re: [Teas] Secdir Last Call review of draft-ietf-teas-yang-te-types

"Valery Smyslov" <> Sat, 20 July 2019 11:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 990521203CF; Sat, 20 Jul 2019 04:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7lelEczyRGa8; Sat, 20 Jul 2019 04:30:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B096312008C; Sat, 20 Jul 2019 04:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KjNBNalhDGIomqVSegxFq69FdWKXMOvie8u9PkIl5MI=; b=1rBgne+XUMTVzD6391c1qHT3Hq G/tu/qbsOZLBwf+3G3UIuYNQvmESb1/R5v3SmRbFR9mSxW0E3dkxvtpoT98NTRX9ahOAIgq8iZ8D+ A41QBJgPWI88rq1tId1MPhk7SxvUL6CKDWd5UtBXLoPBh9OAYifQF5PSNw23FZXr35Uo84wy2MxHx o8N5tQqB+ilxhvGY7YdJsfRmkXpM/Se6RAmQPT4WeniBolnPqVunCuBV5ML3yN9VXDEUjy8z4B3AR 3BMkycOVhe8bDvyLRH2H4hC8ga61izclNk1QBgm5iIhbF1IeysqqEANH2MBITFWO+D6/PFEwvAvxT rvIK3Hbg==;
Received: from ([]:51791 helo=svannotebook) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1honZD-0005k6-KN; Sat, 20 Jul 2019 07:30:19 -0400
From: "Valery Smyslov" <>
To: "'Tarek Saad'" <>, <>
Cc: <>, <>, <>, "'BRUNGARD, DEBORAH A'" <>
References: <04bd01d50577$d66c5a50$83450ef0$> <>
In-Reply-To: <>
Date: Sat, 20 Jul 2019 14:30:16 +0300
Message-ID: <013b01d53eee$81f4f2b0$85ded810$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIbKM+FxiWWhTiWbx/pUKK5ga9BLAHS7SJjpjjx0cA=
Content-Language: ru
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [Teas] Secdir Last Call review of draft-ietf-teas-yang-te-types
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Jul 2019 11:30:26 -0000

Hi Tarek,

thank you for providing the reasoning. I definitely have no problem
with listing RFC8446 as normative, if there is a template and this is
a common practice for YANG model documents. Anyway, it was just a nit.


> Hi Valery,
> Thanks for the review. Regarding the nit below, we have followed the
> guidelines to as per which
> has RFC8446 as normative.
> My understanding is this is being used as a template in several other YANG
> RFCs/drafts. Let us know if you still find it an issue and we'll try to address it.
>     Nit: I don't think that reference to TLS1.3 (RFC8446)
>     should be normative. In my understanding readers of this document
>     are not obliged to read and fully understand the details of TLS to be able
>     to import the definitions and create a TE-related YANG module.
> Regards,
> Tarek
> On 5/8/19, 4:28 AM, "Teas on behalf of Valery Smyslov" <teas-
> on behalf of> wrote:
>     Reviewer: Valery Smyslov
>     Review result: Ready with Nits
>     I have reviewed this document as part of the security directorate's
>     ongoing effort to review all IETF documents being processed by the
>     IESG.  These comments were written primarily for the benefit of the
>     security area directors.  Document editors and WG chairs should treat
>     these comments just like any other last call comments.
>     The draft defines a set of common YANG elements (typedefs, identities and
> groupings)
>     that are intended to be used in Traffic Engineering related YANG modules.
>     The draft as such doesn't have security implications. The Security
> Considerations
>     section contains general advices on using YANG with data management
>     protocols (like NETCONF or RESTCONF), which are applicable when
>     these definitions are imported and used in other YANG modules.
>     The advices include using secure protocols (SSH for NETCONF and TLS1.3 for
>     and implementing access control for sensitive YANG data nodes.
>     Nit: I don't think that reference to TLS1.3 (RFC8446)
>     should be normative. In my understanding readers of this document
>     are not obliged to read and fully understand the details of TLS to be able
>     to import the definitions and create a TE-related YANG module.
>     _______________________________________________
>     Teas mailing list