Re: [L2sm] Benjamin Kaduk's No Objection on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)

Benoit Claise <bclaise@cisco.com> Wed, 18 April 2018 14:14 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC6512D80F; Wed, 18 Apr 2018 07:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, 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
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 l8NQhIPIAxs3; Wed, 18 Apr 2018 07:14:10 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933C312D80E; Wed, 18 Apr 2018 07:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10832; q=dns/txt; s=iport; t=1524060849; x=1525270449; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=2PBWdZKWjJFqUKqmc434rSxx8WzlAlPgzTzfLICWKj0=; b=QFbKm65RlsbLdW0ROmpiGKwKJYoRCgAlSI+D2/kyZXwZVm7iPngdBH/5 Uy6JRi4HuUMYrxjlv/2e1DaIAxTmwgiiBpOhbB+SuCarA9epgTmW+ncYr o3RO882uqEK/V98W8nqE4K4AGISxDjPtydQ10+yksfv/qLSld39M8c4KB 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AQBdUdda/xbLJq0aAUIOCwEBAQE?= =?us-ascii?q?BAQEBAQEBAQcBAQEBAYQjF2Mog2iIAl6NdimBD44HhGsUgWQLGAEKhEYCgwE?= =?us-ascii?q?0GAECAQEBAQEBAmwcDIUjAQEBAwEBIUsLEAsSBhUVAgInIg4GAQwGAgEBhQk?= =?us-ascii?q?PiWqcPoIcH4Q4g2uCIAWJWj+BDyOCaIMRAQEBAgGBFxIBEgFegkGCVAKHL5A?= =?us-ascii?q?8CIVZiF0GgTSDXYI4hQSJM4FThSCBJRw4YVgRCDMaCBsVO4JDgiUSEYhIhQQ?= =?us-ascii?q?8PTABjRKCNwEB?=
X-IronPort-AV: E=Sophos;i="5.48,465,1517875200"; d="scan'208,217";a="3214315"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2018 14:14:06 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w3IEE5f5010530; Wed, 18 Apr 2018 14:14:06 GMT
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
Cc: adrian@olddog.co.uk, draft-ietf-l2sm-l2vpn-service-model@ietf.org, l2sm-chairs@ietf.org, l2sm@ietf.org
References: <152287130759.23972.4894092819553843074.idtracker@ietfa.amsl.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <603906a5-28a9-3b20-110e-313d428b25c8@cisco.com>
Date: Wed, 18 Apr 2018 16:14:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152287130759.23972.4894092819553843074.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------6DF0478804D36CF349691FAC"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/FiQ33Vvr_yTxTJOeEfS6D0sY4T4>
Subject: Re: [L2sm] Benjamin Kaduk's No Objection on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:l2sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-Help: <mailto:l2sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:l2sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2018 14:14:13 -0000

On 4/4/2018 9:48 PM, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-l2sm-l2vpn-service-model-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Alissa's DISCUSS.
>
> Please be consistent about BUM vs. B-U-M and what it expands to.  (This is
> probably a symptom of a more general issue for documents this long with
> multiple contributors, where it's easy to lose a common editorial style.)  NNI
> and potentially other acronyms should be expanded, as well.
>
> In Section 1
>
>     This version of L2VPN service model supports the Network Management
>     Datastore Architecture (NMDA) [I-D.ietf-netmod-revised-datastores].
>
> is ambiguous, being readable either as "NMDA is an optional features
> of this version of (the) L2VPM service model" or "(the) L2VPN
> service model works in support of the NMDA".
Note that we tried to insert this consistent text for YANG-related RFCs:

    The YANG data model in this document conforms to the Network
    Management Datastore Architecture (NMDA) defined inRFC 8342 <https://tools.ietf.org/html/rfc8342>;.

Or:

    This version of the interfaces data model supports the Network
    Management Datastore Architecture (NMDA) [RFC8342 <https://tools.ietf.org/html/rfc8342>].

or:
    The data model in this document is designed to be compliant with the
    Network Management Datastore Architecture (NMDA) [RFC8342 <https://tools.ietf.org/html/rfc8342>].

ex: RFC 8343 and related RFC834*

Regards, B.
>
> Section 5.3.2
>
>     This site-network-access type may have an impact on the parameters
>     offered to the customer, e.g., an SP might not offer encryption for
>     multipoint accesses
>
> I'm reluctant to document in 2018 something as a "VPN" that does not
> offer encryption, given the term's slight redefinition in the
> public's eye.  Maybe a different example could be used?
>
> Section 5.6.4
>
>     For an already-configured site-network-access, each constraint MUST
>     be expressed against a targeted set of site-network-accesses.  This
>     site-network-access MUST never be taken into account in the targeted
>     set -- for example, "My site-network-access S must not be connected
>     on the same POP as the site-network-accesses that are part of Group
>     10."
>
> I'm confused by this statement.  Possibly just by the pronoun "This
> site-network-access", but maybe more.
>
> Section 5.10.3
>
>     The whole Layer-2 multicast frame (whether for data or control)
>     SHOULD NOT be altered from CE to CEs except that the VLAN ID field
>     may be modified, ensuring that it is transparently transported.  If
>     VLAN IDs are assigned by the SP, they can also be altered.
>
> I assume that "from CE to CEs" means when spanning the SP network,
> right?
>
> But I'm still confused by the "SHOULD NOT ... except that the VLAN
> ID field" combined with "If VLAN IDs are...they can also be
> altered".  Is this redundant or in need of rephrasing, or am I
> misreading something?
>
> In Section 5.16, why would someone pick option A, B, or C over the others -- in
> which case(s) are they better or worse?
>
> In the security considerations (Section 9), I see the standard YANG boilerplate
> is in use. In some ways this document's use of YANG is non-standard, though,
> since it's instantiated at a management system and not used for configuration
> directly.  So I'd be open to modifying the boilerplate if that seems
> appropriate.
>
> The document also covers situations where shared tenancy is possible, both on
> hardware and on links. Do we want to list some of the potential risks of such
> shared tenancy in the security considerations, or is that too far afield?
>
> One last note on the security considerations -- are sections 5.12 and 5.13
> really the only points for extension via augmentation?  Perhaps I misunderstand
> the intended semantics of the statement.
>
>
> _______________________________________________
> L2sm mailing list
> L2sm@ietf.org
> https://www.ietf.org/mailman/listinfo/l2sm
> .
>