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

Benjamin Kaduk <kaduk@mit.edu> Tue, 10 April 2018 01:09 UTC

Return-Path: <kaduk@mit.edu>
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 8CD47120227; Mon, 9 Apr 2018 18:09:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nodcR9JyOCai; Mon, 9 Apr 2018 18:09:56 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 0D45E1201F8; Mon, 9 Apr 2018 18:09:55 -0700 (PDT)
X-AuditID: 1209190e-76bff70000000744-4f-5acc0ee22027
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.00.01860.2EE0CCA5; Mon, 9 Apr 2018 21:09:55 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w3A19nsw009083; Mon, 9 Apr 2018 21:09:51 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3A19jsH008940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Apr 2018 21:09:48 -0400
Date: Mon, 9 Apr 2018 20:09:45 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it>
Cc: "draft-ietf-l2sm-l2vpn-service-model@ietf.org" <draft-ietf-l2sm-l2vpn-service-model@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, "l2sm-chairs@ietf.org" <l2sm-chairs@ietf.org>, "l2sm@ietf.org" <l2sm@ietf.org>
Message-ID: <20180410010945.GF89183@kduck.kaduk.org>
References: <152287130759.23972.4894092819553843074.idtracker@ietfa.amsl.com> <12f3fba7302e43d1acc2edf6706426a4@TELMBXB02RM001.telecomitalia.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <12f3fba7302e43d1acc2edf6706426a4@TELMBXB02RM001.telecomitalia.local>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6nrvuY70yUwc42JosfPTeYLXoeNzJZ nL5xnMniwc6LbBZ3Xr5kdGD1WLLkJ5PHis0rGT1azvWyBzBHcdmkpOZklqUW6dslcGVsmtTC WrDUqGLnh0/sDYxPNLoYOTkkBEwkDs7+ygZiCwksZpJ4+y4Zwt7AKPFgVmYXIxeQfYVJonXT RbAiFgEViaf3LzKB2GxAdkP3ZWYQW0TASuLUitlsIA3MAh8ZJRafvMQIkhAWyJRo+bkJzOYF 2rbkzQ9WiKlTGSWOPr7NBpEQlDg58wkLiM0soCOxc+sdoDgHkC0tsfwfB0RYXqJ562ywZZwC QRItd96DlYsKKEvs7TvEPoFRcBaSSbOQTJqFMGkWkkkLGFlWMcqm5Fbp5iZm5hSnJusWJyfm 5aUW6Rrr5WaW6KWmlG5iBIU/pyTfDsZJDd6HGAU4GJV4eC32n44SYk0sK67MPcQoycGkJMq7 rQcoxJeUn1KZkVicEV9UmpNafIhRgoNZSYT34GKgHG9KYmVValE+TEqag0VJnHfR/r1RQgLp iSWp2ampBalFMFkZDg4lCd5/vGeihASLUtNTK9Iyc0oQ0kwcnCDDeYCGvwOp4S0uSMwtzkyH yJ9i1OXoeD+lh1mIJS8/L1VKnPcoSJEASFFGaR7cHFDaksjeX/OKURzoLWHecpAqHmDKg5v0 CmgJE9CSTwknQJaUJCKkpBoY9xfovL57VVmDQ+2YrZispLFg4U3HZVFSzbN/uHlNeZX+dR9T eU7/RL3eK63Om75+PvtknwlLglfZNr2wZbssZ/IV35qpWxFWYHikT/mKIkfu2dudoRp8G7QO i//sPlkbfuP/gaeiQY1MJ6fL+/xbrdb3alubJLNHcJ7h+VMPrmsYHtROZ5mpxFKckWioxVxU nAgAq87VlDYDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/oExJocPEDftq3aXZVHoIMShC7yg>
Subject: Re: [L2sm] R: 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: Tue, 10 Apr 2018 01:09:58 -0000

Hi Giuseppe,

Thanks for the clarifications -- I look forward to the updated
revision.

-Benjamin

On Thu, Apr 05, 2018 at 02:46:30PM +0000, Fioccola Giuseppe wrote:
> Hi Benjamin,
> Thanks for your comments.
> My answers inline tagged as [GF]
> 
> Best Regards,
> 
> Giuseppe
> 
> -----Messaggio originale-----
> Da: Benjamin Kaduk [mailto:kaduk@mit.edu] 
> Inviato: mercoledì 4 aprile 2018 21:48
> A: The IESG
> Cc: draft-ietf-l2sm-l2vpn-service-model@ietf.org; Adrian Farrel; l2sm-chairs@ietf.org; adrian@olddog.co.uk; l2sm@ietf.org
> Oggetto: Benjamin Kaduk's No Objection on draft-ietf-l2sm-l2vpn-service-model-09: (with COMMENT)
> 
> 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.
> 
> [GF]: Ok, we will fix it.
> 
> 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".
> 
> [GF]: Agree, we will change the sentence according to your suggestion.
> 
> 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?
> 
> [GF]: Yes, we have to change or remove the example.
> 
> 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.
> 
> [GF]: You are right, this sentence can confuse and will be rephrased or omitted. It means that the considered site-network-access cannot be part of the targeted set of site-network-accesses against which the constraint is applied.
> 
> 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?
> 
> [GF]: Yes we should explain better this sentence. Only If the VLAN ID field is transparently transported, it can be altered by the CE.
> 
> 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?
> 
> [GF]: It depends because VPNs need to span different ASes in different geographic areas or span different Service Provider networks. This can be considered out of scope here because the multiple flavors are detailed in RFC4761. 
> 
> 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.
> 
> [GF]: You are right and this is possible with extensions via augmentation.
> 
> 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?
> 
> [GF]: Agree, one more sentence will be added.
> 
> 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.
> 
> [GF]: The model defined in this document implements many features and augmentation but, regarding the security aspects, Section 5.12 and 5.13 are more relevant.  
> 
> 
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 
> 
> This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 
> 
> Rispetta l'ambiente. Non stampare questa mail se non è necessario.