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

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 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".
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 <https://tools.ietf.org/html/rfc8342>.

Or:

    This version of the interfaces data model supports the Network
    Management Datastore Architecture (NMDA) [RFC8342 <https://tools.ietf.org/html/rfc8342>].

or:
    The data model in this document is designed to be compliant with the
    Network Management Datastore Architecture (NMDA) [RFC8342 <https://tools.ietf.org/html/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
> L2sm@ietf.org
> https://www.ietf.org/mailman/listinfo/l2sm
> .
>