[Gen-art] R: R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it> Thu, 01 March 2018 10:59 UTC

Return-Path: <giuseppe.fioccola@telecomitalia.it>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6882C126DEE; Thu, 1 Mar 2018 02:59:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ43ASeYTnjx; Thu, 1 Mar 2018 02:59:20 -0800 (PST)
Received: from mx04.telecomitalia.it (mx04.telecomitalia.it [217.169.121.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0533B12E035; Thu, 1 Mar 2018 02:59:18 -0800 (PST)
X-AuditID: d9a97918-547ff70000006b07-de-5a97dd054826
Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id 37.4A.27399.50DD79A5; Thu, 1 Mar 2018 11:59:17 +0100 (CET)
From: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "l2sm@ietf.org" <l2sm@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-l2sm-l2vpn-service-model.all@ietf.org" <draft-ietf-l2sm-l2vpn-service-model.all@ietf.org>
Thread-Topic: R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08
Thread-Index: AQHTrdQE5atJ829Vik2Zfwxn3fWyhKO5pwJAgABqkQCAAP+AoA==
Date: Thu, 01 Mar 2018 10:59:16 +0000
Message-ID: <e89941446d8a4e53be61aa2069f5bd7f@TELMBXB02RM001.telecomitalia.local>
References: <151952041929.12995.5895779377191010604@ietfa.amsl.com> <295aa6644a884df5843f065508bbdf2e@TELMBXB02RM001.telecomitalia.local> <b547a8ad-3332-f4fa-0868-0a9b147b93bd@joelhalpern.com>
In-Reply-To: <b547a8ad-3332-f4fa-0868-0a9b147b93bd@joelhalpern.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.14.252.247]
x-ti-disclaimer: Disclaimer1
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsXCxfdHSpf17vQogz2LWSy2TWthtLj66jOL xbON81ksPp56w2Rx5+VLRgdWjyVLfjJ5nJvynTGAKaqB0SYxLy+/JLEkVSEltTjZVsklszg5 JzEzN7VIISQ1JzU5P1dJITPFVslYSaEgJzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl 56dk5qXbKnkG++taWJha6hoq2QWWphaX5CvkphYXJ6anZ+YrpCasF8zY+2Eee8GFf4wVh/Y3 MDUw9vxg7GLk5JAQMJF4+OgLexcjF4eQwBQmicsPb4Il2ARsJA6+OsEGYosIhEgceLiKDaSI WWA9o8SMbcvBioQFAiWub1zAClEULDHl+VKgIg4g20li0wp/kDCLgIrE7Y0TmEBsXqDyP+dv skIsO8Io8XHDYmaQek4BZ4nPa9NBahgFZCUm7F4ENp5ZQFzixfQT7BCHCkgs2XOeGcIWlXj5 +B8rhG0gsXXpPhYIW1FidfN8JghbRmLhkcmsIOOZBTQl1u/ShxipKDGl+yE7xDmCEidnPmGZ wCg2C8m2WQgds5B0zELSsYCRZRWjaG6FgYleCST+MksSczIT9TJLNjECk8nNlZUSOxi71zof YhTgYFTi4eW8PD1KiDWxrLgy9xCjBAezkgjv6e3TooR4UxIrq1KL8uOLSnNSiw8x+gDDayKz lGhyPjDR5ZXEG5pYWBoaW1gYGVqYmeIQVhLnXV4JNEsgHZjAslNTC1KLYMYxcXBKNTCqSGmJ Guy+MslN+dTdy8fnCG8Jm3Yo+pqg3v6Jtz+rfdzREFpyt6Ki6VJRkkaU+dYzUrel1SNmK6ac nL93hqiayL5NBR2pF5YFrjJrFMmq7bc2dg28+K/vy44dKa38eYl7s2uO7Go+8bJV7YKm89/Z G/dE3Ahq+3Vm+e5fnX4Bp9wi80Uyn79TYinOSDTUYi4qTgQAOrArelMDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/FPKmH7uApIYKyi1N4DqXYwhSNG0>
Subject: [Gen-art] R: R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2018 10:59:23 -0000

Hi Joel,
Thanks for your suggestions!
Answers inline tagged as [GF].
For now we are working on a new local revision and will see when to submit changes according to chairs and AD.

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: Joel M. Halpern [mailto:jmh@joelhalpern.com] 
Inviato: mercoledì 28 febbraio 2018 19:08
A: Fioccola Giuseppe; gen-art@ietf.org
Cc: l2sm@ietf.org; ietf@ietf.org; draft-ietf-l2sm-l2vpn-service-model.all@ietf.org
Oggetto: Re: R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

Further comments in line, marked <jmh> ... </jmh> as some mail readers mangle the inclusion marking.
As a reminder, please work with your chair and sponsoring AD to determine when to submit changes.

Yours,
Joel

On 2/28/18 6:22 AM, Fioccola Giuseppe wrote:
> Hi Joel,
> Thanks for your detailed review! It is very useful.
> My answers inline tagged as [GF]
> 
> Best Regards,
> 
> Giuseppe
> 
> -----Messaggio originale-----
> Da: Joel Halpern [mailto:jmh@joelhalpern.com]
> Inviato: domenica 25 febbraio 2018 02:00
> A: gen-art@ietf.org
> Cc: l2sm@ietf.org; ietf@ietf.org; 
> draft-ietf-l2sm-l2vpn-service-model.all@ietf.org
> Oggetto: Genart telechat review of 
> draft-ietf-l2sm-l2vpn-service-model-08
> 
> Reviewer: Joel Halpern
> Review result: On the Right Track
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-l2sm-l2vpn-service-model-08
> Reviewer: Joel Halpern
> Review Date: 2018-02-24
> IETF LC End Date: 2018-03-26
> IESG Telechat date: 2018-04-05
> 
> Summary: Given the number of Major and minor issues, this document is not yet ready for publication as a Proposed Standard RFC.
> 
> Major:
>      Introduction: The phrasing of "an abstract model", "this model is not a
>      configuration model..." creates some confusion in the reader as to whether
>      this model represent the current state of service deliveyr, the desired
>      state of service delivery (which would drive configuration) or both.
>      Please clarify.
> 
> [GF]: Ok I understand and we can clarify this point in a new revision. This model is used to describe service intent or service requirements and characteristic associated with connectivity service. Consider that also in RFC 8299 (L3SM) there is the same phrasing.

<jmh>Thank you.  I think clarifying this will help the reader. </jmh>

[GF]: Ok

> 
>      The "valid-provider-identifiers' distinguish between cloud-identifier and
>      remote-carrier-identifier.  It i unclear why the VPN service provider
>      should know or care whether the remote provider he is connecting with is a
>      cloud provider, and another L2 service provider, or both.  And if it is
>      both, which identifier should be used.
> 
> [GF]: Remote-carrrier-identifier is used in the NNI case, see the code within YANG module:
> “
>              leaf remote-carrier-name {
>                when "derived-from-or-self(../../../site-vpn-flavor,"+
>                  "'l2vpn-svc:site-vpn-flavor-nni')" {
>                  description
>                    "Relevant when Site vpn flavor is
>                    site-vpn-flavor-nni.";
>                }
> 
> ”
> [GF]: In the NNI case, the current VPN Service provider can connect to another L2VPN or Data Center network or Cloud Provider’s network. Please also see section 5.16 for NNI support details.
> You are right, the VPN service provider doesn’t  care whether the remote provider is a cloud provider or L2VPN service provider. So remote carrier-name doesn’t need to distinguish cloud provider or L2VPN service provider, if you believe we should distinguish we can remove remote carrier name, we think it add complexity and note that remote carrier name is an optional parameter. Regarding cloud-identifier defined within “valid-provider-identifiers”, cloud-identifier is only applied to public cloud or internet access, while remote-carrier-name can be referred to private cloud/data center or another L2VPN. That’s why we use cloud-identifier within cloud-access.

<jmh> I did see the indirect references, that basically make these name lists a constraint on what values can be used in the other parts of the model.  That is effective.  What is unclear is why you have the different kinds of identifiers, as the distinctions are not very clear. 
</jmh>

[GF]: Will clarify better this point.

> 
>      Also, it is very unclear how these identifiers will be used.  They
>      presumably are names of something.  But of what?  As known to whom?
>      Derived from where?  I do not see how a provider / customer pair using this
>      model will know what values to use for this.
> 
> [GF]: We think one is name of the public cloud or internet access, the other is carrier name, they are different. We assume in this model to use “cloud access” to get access to public cloud or internet, we use “NNI” to get access to private cloud, data center or another L2VPN, therefore Cloud identifier should be known by both the current L2VPN Service provider and the customer. Remote Carrier name in NNI case should be known by the current L2VPN service provider it is connecting.

<jmh>The point I was trying to get at, and probably muddled, is that the 
name a customer uses for some third party may not be the same as the 
name the service providers uses (although they will be similar.  Is 
Ericsson A.B. the same or different from Ericsson Inc. or just Ericsson. 
  So these need to be coordinated.

Writing this, it also seems that there needs to be an additional 
clarification.  Suppose that as a customer I want an L2VPN that reachs 
third party.  But that third party is not directly reachable by the 
service provider.  I as the customer probably do not specify what 
transit provider the service provider should use to get connectivity to 
the far end.  But the far end may not even be directly known to the 
service provider.  This leads to a lack of clarity as to what names or 
types should be used.  (And what if I need a third party to reach some 
of my own sites?)  </jmh>

[GF]: Will clarify better this point. I think your example can be addressed by optionally using remote-carrier-name:
  leaf remote-carrier-name {
                ...
              description
                "Remote carrier name. The remote-carrier-name
                 must be configured only when site-vpn-flavor
                 is set to site vpn-flavor-nni. If it is not
                 set,it indicates customer does not know remote
                 carrier name beforehand.";
            }

> 
> Even if the intention is that
>      these be names made available by the provider by external means, the YANG
>      model needs to say that if it is to be usable. I did eventually find some
>      explanation in section 5.15.  At the very least a forward reference is
>      needed.  I think more explanation of what these things names would also
>      help.
> 
> [GF]: Ok
<jmh> ack </jmh>

> 
>      The use of different sets of what read like service types (is cloud access
>      a service type?  Is remote-access a service type?) and the use of similar
>      but not the same terminology between provider descriptions, service types,
>      and service topologies, leaves the reader VERY confused.  Please, do not
>      use the same term for kinds of providers, kinds of services, and kinds of
>      topologies unless the names are fully congruent (which they currently are
>      not.)
> 
> [GF]: No, the service-type is only referred to L2VPN service types.
<jmh>The same names are used for different things.  Pleaes give them 
different names. </jmh>

[GF]: Ok

> 
>       It is unclear why "Cloud-Access" is listed in the VPN Service Overview
>       (section 5.2),  or even why Cloud Access is any different from any other
>       access.  Presumably, the customer can configure authorization for the
>       sites to meet his needs.   Any topological effect would be capture in
>       5.2.2 on VPN Service Topology, not as a different kind of VPN Service.
> 
> [GF]: It is intended to list “Cloud-Access” in VPN service Overview, since “Cloud-Access” is applicable to all the sites rather than site-level parameter. Note that this model is a VPN model, so public Cloud and private cloud, datacenter are not part of VPN therefore we separate Cloud Access from Network Access within VPN. VPN service topology describe how site within VPN are connected to each other rather than describe how VPN is connecting to public Cloud.
<jmh>The document describes the purpose of cloud access as a means to 
define a constraint on authorization.  Given that there are means to 
define the authorization model, this "short-cut" seems 
counter-productive. </jmh>

[GF]: Ok understand, it is a good point but it could be also open to future extensions.

> 
>       Regarding VPN Service Type (svc-type) the text in section 5.2 says that
>       this is explicitly for the local administrator to use to flexibly define
>       the CPN service type.  Section 5.2.1 then says that it has one of six
>       values, implying that if other values are needed they will need to be
>       defined in an extension to the model.  If they are for model use, and for
>       model extension, then they should be using a two-level identity (where the
>       second level provides the possible values.)
> 
> [GF]: Two level identity has already been achieved by using identity data type in this  model, Since we have defined base identity in the model, other identity can be extension of the base identity. See the code in the module:
<jmh>The text in 5.2 says that svc-type is a string.  Apparently I had 
missed that the YANG defined it as an identity.  Which is what I ould 
prefer.  Please tune the text in 5.2 to reflect the fact that there are 
some defined values, that it uses the identity mechanism, and that thus 
service providers can extend the available values. </jmh>

[GF]: Ok. Will fix it.

> “
> 
>    identity service-type {
>      description
>        "Base Identity of service type.";
>    }
> 
>     leaf svc-type {
>        type identityref {
>          base service-type;
>         }
>       default "vpws";
> ”
> 
>      Given taht this is a model for providers and customers to use to
>      collaborate on the configuration of VPNs, I would expect to see some
>      discussion of how this is used on the provider end so as to collaborate
>      with multiple customers, working with each only about their VPNs.  I missed
>      any such description.
> 
> [GF]: Similar to L3SM (RFC 8299), under VPN-services, the customer-name is defined and associated with each VPN-service. Under Sites, VPN-attachment is defined to describe which site is attached to which VPN. Then we can have Site A, Site B, Site C, Site D, Site A, Site B, Site C are attached to VPN-A, Site B, Site C and Site D are attached to VPN B (i.e., vpn-id is set to VPN-B), VPN A and VPN B belong to the same provider, then one provider end can talks to two customers.
<jmh>I wasn't asking where the customer name lived.  I was asking what 
security assumption was being made about how the model behavior is 
restricted so taht a given customer can only modify his own services.  I 
am not sure whether that is a new section or a subsection in security 
considerations. </jmh>

[GF]: Ok, probably we could add some text on this.

> 
> Minor:
>      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.  This may be a deliberate
>      working group choice, as I see in teh change log that there were references
>      to EVC and OVC.  It still seems that it would help readers to have
>      something.
> 
> [GF]: We tried to cooperate and we participate also to some MEF conference calls but we noticed that there are some differences in particular between the MEF LSO (Lifecycle Service Orchestration) architecture and the IETF SDN architecture.
<jmh>As far as I know, the IETF does not have an SDN architecture.  Even 
if this model needs to be different from the MEF work, it would be good 
to relate this even if by highlighting the differences.  Also, I was not 
asking for alignment with LSO, even if I would like that.  I understood 
that was a step too far.  I am concerned about the service definitions 
and descriptions themselves.  The MEF service descriptions are what most 
Ethernet service providers use.  </jmh>

[GF]: Will clarify this. Anyway I mean the examples of architecture described in RFC 8309 and RFC 8199, a little bit different from LSO scheme.
[GF]: Both RFC 8309 and RFC 8199 are references for L2SM.

> 
>      The structure of the vpn-profile-cfg grouping seems very strange.  It is a
>      series of 4 lists, each of which only contains an id leaf.  First, and less
>      important, that makes them leaf-lists, doesn't it?  Or is it structured
>      this way with no explanation to allow for unexplained type specific
>      augmentation?
> 
> [GF]: Yes, it allows augmentation, you may add some new parameters under each list.
<jmh>The way it is currently used does not seem to make it likely that 
additional parameters are going to be useful.  Is there some practical 
expectation of that?  The structure would be simpler if you did not use 
separate lists.</jmh>

[GF]: Ok

> 
>   If no Augmentation is needed, it would seem more general to
>      use a two level identity (identity based enumeration) for the type of VPNs,
>      use a single list containing an id and a type field, where both are keys
>      and the type field uses the enumeration.  This would still easily allow for
>      adding new types, and would avoid using the same leaf name in different
>      lists (which while legal often leads to errors.) If we really need four
>      distinct lists, then I would recommend changing the names of the id field
>      so each one has a unique leaf name (cloud-id, qos-id, bfd-id, ...)
> 
> [GF]: We could, but these leaf are located in different paths, therefore unique leaf name under different parent node doesn’t matter.
<jmh>Yes, the leafs are under different paths.  This is a minor comment 
because it is driven by personal observation of effectiveness, rather 
than an agreed IETF rule.  </jmh>

[GF]: Ok

> 
>   It
>      appears that the purpose of this list is to be used as targets for
>      leafrefs.  As such, it does not seem that distinct lists are needed.
> 
> [GF]: To get consistent with RFC8299, we prefer to keep as it does.
<jmh>Okay.  I will get off this point.  I can live with what you have.</jmh>

> 
>      The placement of section 5.2.2.1 (and the resulting YANG objects) seems
>      odd.  "Route Target Allocation" is a mechanism, not a topology.  It is not
>      even listed in the options mentioned in 5.2.2.
> 
> [GF]: Route Target Allocation section is VPN service topology relevant since Route Target is allocated based on the requested VPN service topology. See Section 5.2.2.1 for more details.
<jmh>Yes, it is "relevant", but it is not itself a property of the 
topology.  So the placement seemed very odd. </jmh>

[GF]: Will check.

> 
>      Section 5.2.3 on Cloud Access uses a variant on the unfortunate "MUST ...
>      except ... MAY" construction.  As far as I can tell, that is a very nice
>      SHOULD, with an explanation of when the SHOULD does not apply.  Even if
>      this is not fixed, the inconsistency between having an exception here, and
>      the strict requirement (upper case MUST with no exception) in section 5.2
>      needs to be fixed.
> 
> [GF]: Ok
<jmh> ack </jmh>

> 
>      Section 5.3 on a Site Overview has an item for "Management" which "Defines
>      the model of management for the site".  It is completely unclear from this
>      text what it is intended to mean, and the example does not help. (5.11 is
>      better, but still vague.)
> 
> [GF]: Define the model of management for the site means: who has ownership of CE device, who manage CE device; this will decide the boundary between service provider and customer.
<jmh>Then please put words to that effect in that place in the document. 
</jmh>

[GF]: Ok

> 
>      When I reached the note in section 5.3.1 that a site may have multiple
>      locations, I realized that I did not see anything explicit as to whether a
>      site is assumed to have full internal connectivity (so that from the point
>      of view of the VPN any of the access links to the site are interchangeable,
>      or if it is fully meshed but there may be preferences for entrance for
>      different distinations, or whether sites may actually be partitioned, where
>      one part of a site is only reachable from another part of a site fia the
>      VPN (the usual assumption when told that there are multiple locations in a
>      site).  I think this should be clarified.
> 
> [GF]: The site may support single-homed or multi-homed. In case of multi-homed, the site can support multiple site-network-accesses, under each site-network-access, vpn-attachment is defined and it will describe which site-network-access associated with which site will connect to which vpn.
<jmh>I think the text needs to be explicit about what is assumed about 
internal connectivity of a mult-homed site. </jmh>

[GF]: Ok, will clarify.

> 
>      In section 5.5.1.2 on MultiVPN attachment, the text says "Reaching VPN A or
>      VPN from the New York office will be done via destination-based routing."
>      Routing usually refers to the handling of IP packets.  Is the intention
>      that this distinction is based on IP destination even though we are
>      providing an L2 service?  Is the intention that MAC addresses are unique
>      across the two VPNs, and the bridging tables will know which VPN contains
>      which destinations?  If the later is the intention, how does that interact
>      with B/U/M frames?
> 
> [GF]: The user can use a target-sites to identify the destination of a flow rather than using destination addresses. In some other case, the user can use VPN-id combining with MAC address to identify the destination of a flow. This has been specified in section 5.10.2.1.
<jmh>Please add explanatory text and a forward reference to 5.10.2.1.</jmh>

[GF]: Ok, a reference can be added.

> 
>       In section 5.5.2.2 on site policy, the text appears to be attempting to
>       answer the question of which destinations in a site should be reachable
>       over (possibly should have reachability to) which VPNs.  It does this via
>       a "lan" tag.  The meaning of this tag is unclear.  Reading between the
>       lines, this appears to be intended to say that the segregation is on the
>       basis vlan tag (although the string is "lan" not "vlan" much less "vlan
>       tag".)  if the intention is that policy is on the basis of vlan, it is
>       unclear how this relates to the assert in 5.5.1.2 that selection is on the
>       basis of destination address.
> 
> [GF]: Section 5.10.2.1 instead of section 5.5.1.2 answer your question. Site policy just describe which site is attached to which vpn, in more granularity case, it describe which lan from which site is attached to which VPN.
<jmh>If 5.10.2.1 answers the question, then what is 5.5.1.2 doing> </jmh>

> 
>      Section 5.6 seems to indicate that parameters and constraints are different
>      things.  Several of the subsections of 5.6 such as access-type seem to
>      indicate that information may be either a parameter or a constraint.  Given
>      that the difference seems to be between a customer hint and a customer
>      requirement, how can something be both?
> 
> [GF]: No
<jmh>Not sure what "no" means.  On the one hand, the early text seems to 
say they are different.  On the other hand, later things are listed as 
constraint / parameter.  If they are the same, then is it a hint or a 
requirement?  If they are a different, how can something be both.  "No" 
does not answer the question. </jmh>

[GF]: No in the sense that hint and requirement cannot be both. 
[GF]: So we could specify better which are parameters and constraints.

> 
>      Section 5.17 has a short paragraph in the middle that uses the term OVC
>      that is not otherwise used in this document.
> 
> [GF]: Good catch, Thanks! we will fix this.
<jmh>ack</jmh>

> 
>      Why do the examples in section 7 include qos-profile-identifiers when the
>      description does not include any reference to multiple QoS behaviors, and
>      nothing in the example makes use of the defined identifiers?
> 
> [GF]: Note that QoS parameter defined under site is an optional parameter. For simplicity, QoS behaviors are not included in the Example.
<jmh>Then please remove the qoa-profile-identifiers.</jmh>

[GF]: Ok

> 
> Editorial:
>      The wording at the front of section 5.2.5 could use tuning.  It currently
>      says "If Frame Delivery Service support is required..."  It seems to me
>      that by definition all L2VPNs require support for delivery of L2 frames.
>      This seems instead to be about parameters for handling BUM (Broadcast /
>      Unkown / Multicast) delivery.  If so, this should be named suitably.  It
>      would also be helpful if this were explicitly related to the support
>      parameter in 5.10.3.
> 
>      Section 5.3.2 refers to the "bearer" parameters as "below layer 2".
>      Section 5.3.2.1 on Bearer refers to it as "below layer 3".  I presume that
>      should be "below layer 2"?
> 
>      In Section 5.5.1 the text states that "There are three possible types of ..
>      Therefore the model supports three flavors:"  Which is then followed by a
>      list of four bullets.
> 
>      The indenting of the XML in section 5.5.2.1 should be repaired.  All of the
>      XML examples should have their indenting checked.
> 
>      The text in section 5.6 says "The management system MUST honor all customer
>      constraints...".  Then it says "Parameters such as site location ... are
>      just hints."  I think that the intention is that "parameters" and
>      "constraints" are different things.  If so, the paragraph above where those
>      terms are introduced should at least indicate something about the diffence.
>       Maybe "parameters (hints) and constraints (customer requirements)"?
> 
>      It seems surprising in 5.6.4 on Access Diversity for a customer to be able
>      to talk about whether things are premitted to be on the same line card.
>      That seems a level that an operator is unlikely to expose.
> 
>      It is surprising that committed vs excess bandwidth is treated as a QoS
>      parameter, with no mention of it in 5.10.1 "Bandwidth".  Particularly since
>      these are actually parameters of "<bandwidth>"
> 
> [GF]: Will fix them, thanks.
<jmh>ack.</jmh>


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.