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

[Fioccola Giuseppe <[e-mail]>]

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.