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

Benoit Claise <> Wed, 18 April 2018 14:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CC6512D80F; Wed, 18 Apr 2018 07:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l8NQhIPIAxs3; Wed, 18 Apr 2018 07:14:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 933C312D80E; Wed, 18 Apr 2018 07:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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 (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2018 14:14:06 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w3IEE5f5010530; Wed, 18 Apr 2018 14:14:06 GMT
To: Benjamin Kaduk <>, The IESG <>
References: <>
From: Benoit Claise <>
Message-ID: <>
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: <>
Content-Type: multipart/alternative; boundary="------------6DF0478804D36CF349691FAC"
Content-Language: en-US
Archived-At: <>
Subject: Re: [L2sm] Benjamin Kaduk's No Objection on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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 <>.


    This version of the interfaces data model supports the Network
    Management Datastore Architecture (NMDA) [RFC8342 <>].

    The data model in this document is designed to be compliant with the
    Network Management Datastore Architecture (NMDA) [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
> .