[L2sm] Alissa Cooper's Discuss on draft-ietf-l2sm-l2vpn-service-model-09: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-l2sm-l2vpn-service-model-09: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sec 5.2 says:

"Cloud Access (cloud-access):  All sites in the L2VPN MUST be
      authorized to access to the cloud.  The cloud-access container
      provides parameters for authorization rules.  A cloud identifier
      is used to reference the target service.  Th"

But Sec 5.2.3 says:

"By default, all sites in the L2VPN SHOULD be authorized to access the
   cloud.  If restrictions are required, a user MAY configure the
   "permit-site" or "deny-site" leaf-list.  The permit-site leaf-list
   defines the list of sites authorized for cloud access.  The deny-site
   leaf-list defines the list of sites denied for cloud access.  The
   model supports both "deny-any-except" and "permit-any-except"
   authorization."

These seem to be conflicting normative requirements. At a minimum, they need to
be aligned (presumably to the formulation in 5.2.3, given the existence of
permit-site and deny-site). But more generally, why does the model need to
normatively require nodes to have a certain kind of access? As the Gen-ART
reviewer pointed out, this doesn't seem necessary. And given that the
cloud-access configuration requires the specification of a specific
cloud-access identifier, what does it even mean that nodes should be authorized
to access "the" cloud?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This comment from the Gen-ART reviewer has not been addressed and I think it
should be: "I would have expected some reference to the MEF Ethernet service
   definitions and MEF defined parameters of interest, as industry usage seems
   to reflect those as the common basis for L2 services.  I udnerstand that
   this model is not mandated to conform to the MEF Forum work.  I would
   expect some discussion of the relationship."

Sec 5.2.3:

"The usage of cloud-access is targeted for public
   cloud and for Internet access.
   ...

   <cloud-accesses>
       <cloud-access>
          <cloud-identifier>INTERNET</cloud-identifier>
       </cloud-access>
      </cloud-accesses>"

>From the perspective of the output of the IETF overall, the above phrasing
gives me pause. The notion that the Internet is just one cloud among many seems
out of sync with how we would typically talk about the Internet in the IETF,
and with RFC 4084 (and perhaps RFC 1958). I realize this is basically a
labeling issue, but if the cloud-access element stays in the model, would it be
possible to use a different label for configuration of Internet service other
than "cloud-access"? This potentially gets back to the point from the Gen-ART
reviewer about the necessity of having these different identifiers not being
obvious.

Sec 8:

Regarding the location element, if you want the address information to be
usable globally (which presumably you do), you will want to consider profiling
the address elements in RFC 4119 and/or RFC 5139. At a minimum,
jurisdiction-specific identifiers like ZIP code, which only exist in the US,
should be replaced by generic address field types.

Nits:

Sec 5.15:

s/remote-carrrier-name/remote-carrier-name/

Sec 5.10.3:

s/broadcast-unknowunicast-multicast/broadcast-unknown-unicast-multicast/