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

[Benjamin Kaduk <[e-mail]>]

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:[e-mail]] 
> Inviato: mercoledì 4 aprile 2018 21:48
> A: The IESG
> Cc: [e-mail]; Adrian Farrel; [e-mail]; [e-mail]; [e-mail]
> 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.