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

[Benjamin Kaduk <[e-mail]>]

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".

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.