IETF Logo Mail Archive

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

"Valery Smyslov" <valery@smyslov.net> Sat, 20 July 2019 11:30 UTC

Return-Path: <valery@smyslov.net>
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 990521203CF; Sat, 20 Jul 2019 04:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net
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 7lelEczyRGa8; Sat, 20 Jul 2019 04:30:23 -0700 (PDT)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=smyslov.net ; 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 modemcable142.183-83-70.mc.videotron.ca ([70.83.183.142]:51791 helo=svannotebook) by direct.host-care.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <valery@smyslov.net>) id 1honZD-0005k6-KN; Sat, 20 Jul 2019 07:30:19 -0400
From: Valery Smyslov <valery@smyslov.net>
To: 'Tarek Saad' <tsaad.net@gmail.com>, secdir@ietf.org
Cc: draft-ietf-teas-yang-te-types@ietf.org, ietf@ietf.org, teas@ietf.org, "'BRUNGARD, DEBORAH A'" <db3546@att.com>
References: <04bd01d50577$d66c5a50$83450ef0$@smyslov.net> <BYAPR19MB3415379DDF81CE15A2259394FCCB0@BYAPR19MB3415.namprd19.prod.outlook.com>
In-Reply-To: <BYAPR19MB3415379DDF81CE15A2259394FCCB0@BYAPR19MB3415.namprd19.prod.outlook.com>
Date: Sat, 20 Jul 2019 14:30:16 +0300
Message-ID: <013b01d53eee$81f4f2b0$85ded810$@smyslov.net>
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 - direct.host-care.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XJ4FnOYnjZvI5YQqfByi4trwlIE>
Subject: Re: [Teas] Secdir Last Call review of draft-ietf-teas-yang-te-types
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: 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.

Regards,
Valery.

> Hi Valery,
> 
> Thanks for the review. Regarding the nit below, we have followed the
> guidelines to as per https://tools.ietf.org/html/rfc8407#section-3.7.1 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-
> bounces@ietf.org on behalf of valery@smyslov.net> 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
> RESTCONF)
>     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
>     Teas@ietf.org
>     https://www.ietf.org/mailman/listinfo/teas
>

v2.23.0 | Report a Bug | By Email