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

Tarek Saad <tsaad.net@gmail.com> Fri, 19 July 2019 14:13 UTC

Return-Path: <tsaad.net@gmail.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 9EC76120279; Fri, 19 Jul 2019 07:13:05 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 P32oUcKUJ1SQ; Fri, 19 Jul 2019 07:13:02 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E725120270; Fri, 19 Jul 2019 07:12:58 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id k10so31149575qtq.1; Fri, 19 Jul 2019 07:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=4Bn/UwZe1214ndB+8koUWBT7Sde3SeAb1J42cgw2z/Q=; b=uWG8vKBEVtom8SR2va+3rM+1qpIGpdPP0CMxkKmFskyQSSJxmuNYVaCyLgV/cFkcpC +BgHqysF9+5ZmKy2WSOXGEKyBvlJF68bcZsx2BzhES4xJEdE5jPiz+xroUYaCsBs9Lnt 2hiaDWKHQj0MnL2TeKrDSxOiiSWZ2Ht1PtwtAj1eqoJoGBkvDSYrEPCSHvNLsBduB+TY 845uNAiT4CQdd7Nzt2wrtFBrfOFIH9lCqzGkfOUHUD2tcqigHBXnpcqiAnoh+eWcGOM/ 7eHysJDxZIMiC3YlZHpBDGJT31RVir/Jh3uNudh73eMIjFbXhZPVHcDa2TcDWH04M7E5 tfZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=4Bn/UwZe1214ndB+8koUWBT7Sde3SeAb1J42cgw2z/Q=; b=RTlS37XMR7aLEyA6yeuhr4pEm5z75F6w3ei3iZO+zlPhli0gzVO2PdYRC2UF4lD0In yqCqefEZqKzTJNcoyAm9UaHsb3f1G6XVg+V9hjXz2rGo44kNtyjRoHSt0MztrlGFGKlk QVuQxrYHuASYqh6kmn1+PgWC1F7e6EejohCZFby0GUZadGPYyRD764ITZQrUvULY6iSD qM5MoJ0G321Q3YQ7l0Wn3BtkELjZAYlOYGEzbHl/kMW7SJVZLer5+Q6Ja7XxwGFshlTU jTiC+SN+bwSfa8TRN4X0duwwempMGZkXzO4uedZhfretLEXNxjzXql5eiuHLQ/XrgDVU gsKg==
X-Gm-Message-State: APjAAAWRZe0N2Ut3bSbUooewucQqFbvXA8ezET4bzp8p281ERKARhECL loSodfr2jZbzw7HuMsTu9RWCE+msf3E=
X-Google-Smtp-Source: APXvYqzbLjFM/x6JVIzRCGhIZxnYBqZ/GTpTcdZpL2l9Zuj72tpeO13ZBGlpquJZCh3WWB95wHg8HA==
X-Received: by 2002:ac8:37b8:: with SMTP id d53mr36781083qtc.227.1563545577202; Fri, 19 Jul 2019 07:12:57 -0700 (PDT)
Received: from BYAPR19MB3415.namprd19.prod.outlook.com ([2603:1036:307:293b::5]) by smtp.gmail.com with ESMTPSA id p13sm11810489qkj.4.2019.07.19.07.12.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 07:12:56 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: Valery Smyslov <valery@smyslov.net>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-teas-yang-te-types@ietf.org" <draft-ietf-teas-yang-te-types@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "teas@ietf.org" <teas@ietf.org>, "BRUNGARD, DEBORAH A" <db3546@att.com>
Thread-Topic: [Teas] Secdir Last Call review of draft-ietf-teas-yang-te-types
Thread-Index: ASQ0YSRkhZYlxpY4H2/pUKK5ga9BLOITtdRO
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 19 Jul 2019 14:12:54 +0000
Message-ID: <BYAPR19MB3415379DDF81CE15A2259394FCCB0@BYAPR19MB3415.namprd19.prod.outlook.com>
References: <04bd01d50577$d66c5a50$83450ef0$@smyslov.net>
In-Reply-To: <04bd01d50577$d66c5a50$83450ef0$@smyslov.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/G6Z_DfnIkrLMY-dh4uBhi9fNWq8>
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: Fri, 19 Jul 2019 14:13:06 -0000

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