From nobody Fri Feb 2 02:53:31 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E40312EB38; Fri, 2 Feb 2018 02:53:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ck11lHZ4ITSN; Fri, 2 Feb 2018 02:53:23 -0800 (PST) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 3481712EAC0; Fri, 2 Feb 2018 02:53:21 -0800 (PST) X-AuditID: d9a97916-04fff7000000a80b-51-5a74431f28a3 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 mx02.telecomitalia.it () with SMTP id 17.B4.43019.F13447A5; Fri, 2 Feb 2018 11:53:19 +0100 (CET) From: Fioccola Giuseppe To: "adrian@olddog.co.uk" , 'Jan Lindblad' CC: "l2sm@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" Thread-Topic: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05 Thread-Index: AQGbYYMLnOH+20pqSyT8FxtWyiFAXQLBgAiWAcQeilMCRvT87aPIFyEQgALj9zA= Date: Fri, 2 Feb 2018 10:53:19 +0000 Message-ID: <01ef378c564b4c9697f2db73ba7caa0d@TELMBXB02RM001.telecomitalia.local> References: <058801d38f72$7526d800$5f748800$@olddog.co.uk> <16F8CDDD-6FB9-4C29-BE19-31C398540303@tail-f.com> <05c101d38f88$482eb0a0$d88c11e0$@olddog.co.uk> <0b4b01d39aa0$1f91f3a0$5eb5dae0$@olddog.co.uk> In-Reply-To: <0b4b01d39aa0$1f91f3a0$5eb5dae0$@olddog.co.uk> 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.240] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_01ef378c564b4c9697f2db73ba7caa0dTELMBXB02RM001telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNKsWRmVeSWpSXmKPExsXCxfdHSlfeuSTK4OIaU4sfPTeYLXoeNzJZ /J/Vx2hx5+VLRgcWjyVLfjJ5rNi8ktFj46/FLAHMUQ2MNol5efkliSWpCimpxcm2Si6Zxck5 iZm5qUUKIak5qcn5uUoKmSm2SsZKCgU5icmpual5JbZKiQUFqXkpSnZcChjABqgsM08hNS85 PyUzL91WyTPYX9fCwtRS11DJLrA0tbgkXyE3tbg4MT09M18hNWG9YMaBg3tZC15PZa2YdesJ cwPj4W0sXYycHBICJhKTtzSydzFycQgJTGGS6Nv0ghEkwSZgI3Hw1Qk2EFtEIFji46KvTCBF zAJtjBLPti8F6xYWcJfY2XKREaLIU+LHtFOsXYwcQLafxLtPDiBhFgEViXcLWsFKeAUCJY62 XWWBWNbCJHFxz02wOZwC1hKzp31kB7EZBWQlJuxeBNbALCAu8WL6CXaISwUkluw5zwxhi0q8 fPyPFcI2kNi6dB/UN4oSWz/B1MtILDwymRViTr7E/+NP2SCOEJQ4OfMJywRG0VlIVsxCUjYL SRlEXE/ixtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKJpbYWCkVwKJ2sySxJzMRL3Mkk2M wBR0c2Wl2A7G1rXOhxgFOBiVeHhjNEuihFgTy4orcw8xSnAwK4nwft1QHCXEm5JYWZValB9f VJqTWnyI0QcYlBOZpUST84HpMa8k3tDEwtLQ2MLCyNDCzBSHsJI4r5ge0HiBdGDay05NLUgt ghnHxMEp1cBYOc+ZhUnLfPthY93QA03K0z33Xotrk1H0n7BszQPWZ3cDasSYDLmPXni2oNxk uy1nmnL3xVwR7Zs2B/jyv+1+smHZsi1/jr5bcOKLwdMT6/cKzg1rO7HZRakykLPOq1j+i9yZ WK2bF+Lc9v1mybFNZoo3OF3xdLPfqg3H7sjNXVR1zPs+897lSizFGYmGWsxFxYkAwHprx24D AAA= Archived-At: Subject: [L2sm] R: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 10:53:29 -0000 --_000_01ef378c564b4c9697f2db73ba7caa0dTELMBXB02RM001telecomit_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jan, Adrian, First of all, Thank you Jan for your good opinion of the document (in partic= ular for the YANG :)). Your review is very detailed and I really appreciate it. I will check all your comments and address them in a new revision. If there are doubts, as usual, I will share them with you and the L2SM WG. Best Regards, Giuseppe Da: Adrian Farrel [mailto:adrian@olddog.co.uk] Inviato: mercoled=EC 31 gennaio 2018 15:31 A: draft-ietf-l2sm-l2vpn-service-model@ietf.org Cc: l2sm@ietf.org; 'Jan Lindblad' Oggetto: FW: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05 Hi authors, Jan Lindblad has done a great review for us. On the positive side he thinks you have done a really good job with the modu= le, but he has nevertheless found a pile of small issues. It looks to me (what do I know ;-) that the majority of these should be real= ly easy to fix, so I'd like to lean on you a bit to get a revision "soon." C= an you let us know what the plan is? At the same time, I will do an English language review. Thanks, Adrian From: Jan Lindblad [mailto:janl@tail-f.com] Sent: 31 January 2018 13:48 To: Adrian Farrel Cc: bclaise@cisco.com; Qin Wu Subject: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model-05 Adrian, shepherds, I've now made a YANG review of the l2vpn YANG model and examples. Since I'm= not listed as the formal reviewer, I'll just write it in a mail like this.= Let me know how you'd like me to post this if this mail to you is not what= you had in mind. That's fabulous! We are looking to do WG last call in early February. Of course, incorporatin= g your comments before then would be best, but that would mean completing yo= ur review by the end of January. The back-up plan would be to do your review before the end of last call so t= argeting 20th Feb. So I read the first 35 pages of the RFC before I realized I'm not going to u= nderstand this well enough to have any use of the plaintext when looking at= the YANG anyway. So then I jumped right at the YANG and examples instead. I= must say it's a clean and simple approach and one of the more well written= YANGs I have seen; I could not find any serious issues with it. Since it's= written in a very down to earth fashion without much in terms of fancy cons= tructs, it stays clear of some of the pitfalls we've seen in the past. When= it comes to the examples, they all omit things (which may or may not be acc= eptable, you decide) and almost all the examples are broken. In other words,= business as usual. On the detailed level I have a long list of comments. Mostly the usual stuff= . So here goes: General: -- indentation is broken General: feature dot1q{ -- missing space between name and open brace in lots of places General: identity opaque { base bw-type; description "Opaque"; -- descriptions like this have negative value, no information but take up sp= ace. I would have hoped to understand how/when to use "opaque", etc. 46: feature L2CP-control { 443: identity all2one-Bundling { -- should be all lowercase 80: feature signaling-options { description "Enable the support of signalling option."; 3001: leaf signalling-type { -- make spelling consistent; either "signaling" or "signalling". Our own XML= examples below stumble over this as well 365: identity site-vpn-flavor-single { 371: identity site-vpn-flavor-multi { 381: identity site-vpn-flavor-nni { 601: identity co-managed { 606: identity customer-managed { 611: identity provider-managed { 616: identity address-family { -- remove the word "Base" in the description, these are identities, but not= base identities 454: identity color-id--cvlan { 468: identity cos-id--dscp { -- use single dash 906: identity bidirection { -- should be "bidirectional" ? 1024: choice list-flavor { 1064: leaf site-vpn-flavor { 1252: leaf delivery-mode { 1452: leaf bundling-type { 1459: leaf default-ce-vlan-id { 1469: grouping cfm-802-grouping { (one leaf has a default) 1538: grouping y-1731 { 1650: grouping lacp-grouping { 1672: leaf system-priority { 1830: leaf enable { 1838: leaf uni-loop-prevention { 1888: leaf tag-type { 1895: leaf cvlan-id { 1909: leaf tag-type { 1925: leaf tag-type { 1932: leaf svlan-id { 1937: leaf cvlan-id { 1951: leaf tag-type { 1958: leaf svlan-id { 1972: leaf vni-id { 1977: leaf peer-mode { 2005: leaf encapsulation-type { 2012: leaf eth-inf-type { 2049: grouping svc-preservation-grouping { 2073: grouping site-mac-addr-limit { 2105: leaf access-priority { 2139: grouping l2cp-grouping { 2199: grouping site-bum { 2275: grouping site-mac-loop-prevention { 2301: grouping ethernet-svc-oam-grouping { 2327: grouping fate-sharing-group { 2452: choice request-type-choice { 2542: leaf attachment-device-id { 2577: leaf vpn-id { 2648: leaf vpn-id { 2653: leaf cir { 2661: leaf cbs { 2855: leaf direction { 2863: leaf policing { 2879: choice flavor { 2907: choice flavor { 3001: leaf signalling-type { 3135: leaf svc-type { 3147: leaf svc-topo { 3203: leaf remote-carrier-name { -- no default, no mandatory, no description what happens if not set. Groupin= gs included above when every leaf inside is lacking default/mandatory/descri= ption 1171: list filter { -- only one filter of each type (and only one standard type). Will there eve= r be a filter that you'd want to have several of? 1211: mandatory true; -- redundant, this is already a key, hence mandatory 1349: leaf group-id { 1718: leaf profile-name { 1779: leaf flow-control { 1818: leaf flow-control { 2334: leaf group-color { 2341: leaf group-id { 2362: leaf group-id { 2399: leaf group-id { 2455: leaf physical-if { 2472: leaf physical-if { 2477: leaf circuit-id { 2499: leaf requested-type { 2542: leaf attachment-device-id { 3203: leaf remote-carrier-name { -- These use type string, is that really the right type? How about leafref,= enumeration, ...? What are the valid values here? What happens if an "incor= rect" value is given? 1563: leaf message-period { 1569: leaf measurement-interval { 1662: leaf lacp-speed { 1667: leaf mini-link { 1695: leaf bfd-interval { 1700: leaf bfd-hold-timer { 1748: leaf port-speed { 1803: leaf port-speed { 2245: leaf bum-overall-rate { 2259: leaf rate { 2277: leaf frequency { 2935: leaf fr-loss-rate { -- add units. In some cases unit is specified in the description, but better= in units stmt. 1107: leaf management-transport { 1650: grouping lacp-grouping { 1652: leaf lacp-state { 1657: leaf lacp-mode { 1662: leaf lacp-speed { 1681: leaf micro-bfd-on-off { 1695: leaf bfd-interval { 1700: leaf bfd-hold-timer { 1710: leaf bfd-hold-timer { 1857: leaf lag-ifindex { 1875: leaf tagged-inf-type { 2075: leaf mac-num-limit { 2776: container qos-classification-policy { 2824: container qos-profile { 2935: leaf fr-loss-rate { 3060: leaf site-network-access-type { -- remove redundant part of the name. Inside container bfd, leaf:s should no= t be called bfd-foo, but just foo 1652: leaf lacp-state { -- wouldn't "enable" be a better name than "state" for an on/off switch? 1657: leaf lacp-mode { -- what does values true and false mean here? How is this different from lea= f lacp-state? 1740: container member-link-list { -- should probably be "member-links" 1798: leaf ifindex { -- how do I know what ifindex value to use? Is this the same ifIndex as in s= nmp? 1853: container lag-interface { -- should probably be lag-interfaces 2112: leaf single-active { 2121: leaf all-active { -- I think you mean type empty? 2308: leaf md-level { 2792: leaf match-phy-port { -- how do I know what is a good value for this leaf? 2460: leaf vlan-id { -- add a range? 2499: leaf requested-type { -- same name as parent container, confusing Finally, there are seven leafrefs with absolute paths. In the past reviews t= here have been issues when an absolute path was used but only a relative pat= h had the right semantics. In this case, I don't understand well enough what= the author's intent is, so let me verify for each one that the YANG matches= the author's intent: 1015: leaf cloud-identifier { -- points to ANY cloud, regardless of profile 1033: leaf-list permit-site { 1042: leaf-list deny-site { -- points to ANY site, regardless of which customer 1206: leaf vpn-id { 1273: leaf svc-id { 2577: leaf vpn-id { -- points to ANY vpn, regardless of which customer 2832: leaf profile { -- points to ANY qos-profile Then we have the XML examples. I refer to them by page number in the spec, w= ith "a" and "b" suffix when there is more than one on a single page. p24a, p24b, p25: The /l2vpn-svc/vpn-services/vpn-service["123456487"]/frame-delivery/multicas= t-gp-port-mapping is mandatory and not set by the example. After working a b= it with the model, I'd suggest removing mandatory here and add a default ins= tead. It's really a bit annoying to have to care about multicast properties= as soon as I define a vpn-service. p26: Example broken in a couple of places: 1. hub-spoke =3D=3D> hub-spoke 2. any-to-any =3D=3D> any-to-any 3. spoke-role =3D=3D> spoke-role p39: Example broken in a couple of places: 1. LA1 =3D=3D> LA1 2. LA2 =3D=3D> LA2 And a few things are omitted: /l2vpn-svc/sites/site["SITE1"]/service/svc-mtu is mandatory and not included= in the example. I'd suggest adding a default instead, the MTU is perhaps no= t the first thing you think about when defining a new service. Now it has to= be given immediately. /l2vpn-svc/sites/site["SITE1"]/management/type is mandatory and not included= in the example. As soon as a type is set, a number of other things become m= andatory too. Which ones depends on what type you select. /l2vpn-svc/sites/site["SITE1"]/site-network-accesses/site-network-access["LA= 1"]/vpn-attachment/vpn-id refers to a VPN that is not defined, but I guess t= hat's acceptable. p41: Example broken: LA1 =3D=3D> LA1 Same things omitted as on p39. p42: Example broken in a couple of places: 1. LAN1 =3D=3D> lan 17 2. LAN2 =3D=3D> lan 18 3. LA1 =3D=3D> LA1 Omits service/svc-mtu and management/type like on p39. p60: Example broken in a number of places: 1. NY US =3D=3D> NY1 NY US 2. CSP_A_VN1 =3D=3D> CSP_A_VN1 3. tagged =3D=3D> tagged 4. dot1q-vlan =3D=3D> dot1q 5. 17 =3D=3D> 17 6. Need to move out of 7. Missing end tag 8. Not making up our mind on how to spell signaling/signalling bites us: bgp =3D=3D> bgp Same omissions as on p39. p68a: Example broken: Some unwanted whitespace crept in: vpws =3D=3D> vpws /l2vpn-svc/vpn-services/vpn-service["12456487" and "12456488"]/frame-deliver= y/multicast-gp-port-mapping is mandatory and not configured p68b: Example broken in a number of places: 1. NY US =3D=3D> NY1 NY US 2. Double start tags =3D=3D> 3. I'm guessing the author means "vlan" when saying "dot1q" ? dot1q =3D=3D> vlan 4. Wrong end tag =3D=3D> 5. Needs to be lowercase TUNNEL =3D=3D> tunnel 6. TRUE =3D=3D> true 7. Need to move out of 8. bgp =3D=3D> bgp Same omissions as on p39. Obviously, these XML fixes assume an unchanged YANG model. As they YANG is f= ixed/changed, the examples should follow suit. That's all I found. Thanks! /jan From: Jan Lindblad [mailto:janl@tail-f.com] Sent: 17 January 2018 11:29 To: Adrian Farrel Cc: bclaise@cisco.com; Qin Wu Subject: Re: Cheeky request Adrian, You did such a good job with the L3SMbis draft that it should come as no surprise that we are all queueing up to have you as a reviewer. https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ is now very close to WG last call and we just made a request for "early" YANG Docto= r review. But if you were able to look at it as well, that would be rather good. Of course, you are allowed to be tired/bored/busy :-) Flattery is often effective ;-) Thank you for asking. I would certainly be i= nterested to have a good look at all IETF service models, and perhaps better= to get into the habit of doing that before the publication rather than afte= r :-/ I guess it's primarily going to be a question of when you need the ans= wer. By when would you need it? Best Regards, /jan -- Jan Lindblad, janl@tail-f.com, +46 702855728 Solutions Architect, Business Development, Tail-f Tail-f is now a part of Cisco Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, 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 =E8 necessario. --_000_01ef378c564b4c9697f2db73ba7caa0dTELMBXB02RM001telecomit_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jan, Adri= an,

First of all= , Thank you Jan for your good opinion of the document (in particular for the= YANG J).

Your review= is very detailed and I really appreciate it.

I will check= all your comments and address them in a new revision.

If there are= doubts, as usual, I will share them with you and the L2SM WG.

 <= /o:p>

Best Regards= ,

 <= /o:p>

Giuseppe

 <= /o:p>

Da: Adrian Fa= rrel [mailto:adrian@olddog.co.uk]
Inviato: mercoled=EC 31 gennaio 2018 15:31
A: draft-ietf-l2sm-l2vpn-service-model@ietf.org
Cc: l2sm@ietf.org; 'Jan Lindblad'
Oggetto: FW: YANG + XML review of draft-ietf-l2sm-l2vpn-service-m= odel-05

 

Hi authors,<= o:p>

 <= /o:p>

Jan Lindblad= has done a great review for us.

 <= /o:p>

On the posit= ive side he thinks you have done a really good job with the module, but he h= as nevertheless found a pile of small issues.

 <= /o:p>

It looks to= me (what do I know ;-) that the majority of these should be really easy to= fix, so I'd like to lean on you a bit to get a revision "soon." Can you let us know what the plan is?

 <= /o:p>

At the same= time, I will do an English language review.

 <= /o:p>

Thanks,=

Adrian<= /o:p>

 <= /o:p>

From: Jan Lindblad [mailto:j= anl@tail-f.com]
Sent: 31 January 2018 13:48
To: Adrian Farrel
Cc: bclaise@cisco.com; Qin W= u
Subject: YANG + XML review of draft-ietf-l2sm-l2vpn-service-model= -05

 

Adrian, shepherds,

 

I've now made a YANG review of t= he l2vpn YANG model and examples. Since I'm not listed as the formal reviewe= r, I'll just write it in a mail like this. Let me know how you'd like me to= post this if this mail to you is not what you had in mind.

 

That's fabul= ous!

 

We are looki= ng to do WG last call in early February. Of course, incorporating your comme= nts before then would be best, but that would mean completing your review by the end of January.

 

The back-up= plan would be to do your review before the end of last call so targeting 20= th Feb.

 

So I read the first 35 pages of= the RFC before I realized I'm not going to understand this well enough to h= ave any use of the plaintext when looking at the YANG anyway. So then I jump= ed right at the YANG and examples instead. I must say it's a clean and simple approach and one of the more we= ll written YANGs I have seen; I could not find any serious issues with it. S= ince it's written in a very down to earth fashion without much in terms of f= ancy constructs, it stays clear of some of the pitfalls we've seen in the past. When it comes to the exampl= es, they all omit things (which may or may not be acceptable, you decide) an= d almost all the examples are broken. In other words, business as usual.

 

On the detailed level I have a l= ong list of comments. Mostly the usual stuff. So here goes:

 

General:

-- indentation is broken

 

General:

  feature dot1q{<= /o:p>

-- missing space between name an= d open brace in lots of places

 

General:

  identity opaque {

    base bw-type;=

    description

      "Opaqu= e";

-- descriptions like this have n= egative value, no information but take up space. I would have hoped to under= stand how/when to use "opaque", etc.

 

46:  feature L2CP-control {=  

443:  identity all2one-Bund= ling {

-- should be all lowercase<= /o:p>

 

80:  feature signaling-opti= ons {
    description
      "Enable the support of signalling option.";

3001:      leaf s= ignalling-type {

-- make spelling consistent; eit= her "signaling" or "signalling". Our own XML examples be= low stumble over this as well

 

365:  identity site-vpn-fla= vor-single {

371:  identity site-vpn-fla= vor-multi {

381:  identity site-vpn-fla= vor-nni {

601:  identity co-managed {=

606:  identity customer-man= aged {

611:  identity provider-man= aged {

616:  identity address-fami= ly {

-- remove the word "Base&qu= ot; in the description, these are identities, but not base identities

 

454:  identity color-id--cv= lan { 

468:  identity cos-id--dscp= {

-- use single dash

 

906:  identity bidirection= {

-- should be "bidirectional= " ?

 

1024:        = ;choice list-flavor {

1064:    leaf site-vpn= -flavor {

1252:        = ;leaf delivery-mode {

1452:    leaf bundling= -type {
1459:    leaf default-ce-vlan-id {

1469:   grouping cfm-802-gr= ouping { (one leaf has a default)

1538:  grouping y-1731 {

1650:   grouping lacp-group= ing {

1672:       leaf= system-priority {

1830:        = ;leaf enable {

1838:      leaf u= ni-loop-prevention {

1888:        = ;leaf tag-type {

1895:        = ;leaf cvlan-id {

1909:        = ; leaf tag-type {

1925:        = ;leaf tag-type {

1932:        = ;leaf svlan-id {

1937:        = ;leaf cvlan-id {

1951:        = ;leaf tag-type {

1958:        = ;leaf svlan-id {

1972:        = ;leaf vni-id {

1977:        = ;leaf peer-mode {

2005:      leaf e= ncapsulation-type {

2012:      leaf e= th-inf-type {

2049:  grouping svc-preserv= ation-grouping {

2073: grouping site-mac-add= r-limit {

2105:      leaf a= ccess-priority {

2139:  grouping l2cp-groupi= ng {

2199:  grouping site-bum {<= o:p>

2275:  grouping site-mac-lo= op-prevention {

2301:  grouping ethernet-sv= c-oam-grouping {

2327:  grouping fate-sharin= g-group {

2452:      choice= request-type-choice {

2542:      leaf a= ttachment-device-id {

2577:        = ;  leaf vpn-id {

2648:        = ;leaf vpn-id {

2653:        = ;leaf cir {

2661:        = ;leaf cbs {

2855:        = ;        leaf direction {

2863:        = ;        leaf policing {

2879:        = ;          choice flavor {

2907:        = ;          choice flavor {

3001:      leaf s= ignalling-type {

3135:        = ;leaf svc-type {

3147:        = ;leaf svc-topo {

3203:        = ;    leaf remote-carrier-name {

-- no default, no mandatory, no= description what happens if not set. Groupings included above when every le= af inside is lacking default/mandatory/description

 

1171:        = ;     list filter {

-- only one filter of each type= (and only one standard type). Will there ever be a filter that you'd want t= o have several of?

 

1211:        = ;       mandatory true;

-- redundant, this is already a= key, hence mandatory

 

1349:        = ;  leaf group-id {

1718:        = ;    leaf profile-name {

1779:      leaf f= low-control {

1818:      leaf f= low-control {

2334:      leaf g= roup-color {

2341:        = ;leaf group-id {

2362:        = ;leaf group-id {

2399:        = ;          leaf group-id {

2455:        = ;    leaf physical-if {

2472:        = ;  leaf physical-if {

2477:        = ;  leaf circuit-id {

2499:        = ;leaf requested-type {

2542:      leaf a= ttachment-device-id {

3203:        = ;    leaf remote-carrier-name {

-- These use type string, is tha= t really the right type? How about leafref, enumeration, ...? What are the v= alid values here? What happens if an "incorrect" value is given?

 

1563:       leaf= message-period {

1569:      leaf m= easurement-interval {

1662:      leaf l= acp-speed {

1667:      leaf m= ini-link {
1695:        leaf bfd-interval {

1700:        = ;leaf bfd-hold-timer {

1748:        = ;  leaf port-speed {
1803:      leaf port-speed {

2245:      leaf b= um-overall-rate {

2259:        = ;leaf rate {

2277:      leaf f= requency {

2935:        = ;          leaf fr-loss-rate {

-- add units. In some cases unit= is specified in the description, but better in units stmt.

 

1107:        = ;  leaf management-transport {

1650:   grouping lacp-group= ing {

1652:      leaf l= acp-state {

1657:      leaf l= acp-mode {

1662:      leaf l= acp-speed {

1681:        = ;leaf micro-bfd-on-off {

1695:        = ;leaf bfd-interval {

1700:        = ;leaf bfd-hold-timer {

1710:        = ;leaf bfd-hold-timer {

1857:        = ;leaf lag-ifindex {

1875:      leaf t= agged-inf-type {

2075:      leaf m= ac-num-limit {

2776:      contai= ner qos-classification-policy {

2824:      contai= ner qos-profile {

2935:        = ;          leaf fr-loss-rate {

3060:    leaf site-net= work-access-type {

-- remove redundant part of the= name. Inside container bfd, leaf:s should not be called bfd-foo, but just f= oo

 

1652:      leaf l= acp-state {

-- wouldn't "enable" b= e a better name than "state" for an on/off switch?

 

1657:      leaf l= acp-mode {

-- what does values true and fal= se mean here? How is this different from leaf lacp-state?<= /p>

 

1740:      contai= ner member-link-list {

-- should probably be "memb= er-links"

 

1798:      leaf i= findex {

-- how do I know what ifindex va= lue to use? Is this the same ifIndex as in snmp?

 

1853:    container lag= -interface {

-- should probably be lag-interf= aces

 

2112:        = ;  leaf single-active {

2121:        = ;  leaf all-active {

-- I think you mean type empty?<= o:p>

 

2308:      leaf m= d-level {

2792:        = ;       leaf match-phy-port {

-- how do I know what is a good= value for this leaf?

 

2460:        = ;    leaf vlan-id {

-- add a range?

 

2499:        = ;leaf requested-type {

-- same name as parent container= , confusing

 

Finally, there are seven leafref= s with absolute paths. In the past reviews there have been issues when an ab= solute path was used but only a relative path had the right semantics. In th= is case, I don't understand well enough what the author's intent is, so let me verify for each one that the= YANG matches the author's intent:

 

1015:        = ; leaf cloud-identifier {

-- points to ANY cloud, regardle= ss of profile

 

1033:        = ;    leaf-list permit-site {

1042:        = ;    leaf-list deny-site {

-- points to ANY site, regardles= s of which customer

 

1206:        = ;    leaf vpn-id {

1273:      leaf s= vc-id {

2577:        = ;  leaf vpn-id {

-- points to ANY vpn, regardless= of which customer

 

2832:        = ;    leaf profile {

-- points to ANY qos-profile

 

 

 

Then we have the XML examples. I= refer to them by page number in the spec, with "a" and "b&qu= ot; suffix when there is more than one on a single page.

 

p24a, p24b, p25:

The /l2vpn-svc/vpn-services/vpn-= service["123456487"]/frame-delivery/multicast-gp-port-mapping is m= andatory and not set by the example. After working a bit with the model, I'd= suggest removing mandatory here and add a default instead. It's really a bit annoying to have to care about multicast= properties as soon as I define a vpn-service.

 

p26:

Example broken in a couple of pl= aces:

 

1.

        &nbs= p; <vpn-service-topology>hub-spoke</vpn-service-topology>

=3D=3D>

        &nbs= p; <svc-topo>hub-spoke</svc-topo>

 

2.

        &nbs= p; <vpn-service-topology>any-to-any</vpn-service-topology><= /o:p>

=3D=3D>

        &nbs= p; <svc-topo>any-to-any</svc-topo>

 

3.

        &nbs= p;         <site-role>spoke-role</site-role>=

=3D=3D>

        &nbs= p;         <local-sites-role>spoke-role</local-= sites-role>

 

p39:

Example broken in a couple of pl= aces:

 

1.

        &nbs= p;<site-network-access-id>LA1</site-network-access-id>

= =3D=3D>
         <network-access-id>LA1</network-a= ccess-id>

2.

        &nbs= p;<site-network-access-id>LA2</site-network-access-id>

=3D=3D>
         <network-access-id>LA2</network-a= ccess-id>

And a few things are omitted:

/l2vpn-svc/sites/site["SITE1"]/service/svc-mtu is mandatory and no= t included in the example. I'd suggest adding a default instead, the MTU is= perhaps not the first thing you think about when defining a new service. No= w it has to be given immediately.

 

/l2vpn-svc/sites/site["SITE= 1"]/management/type is mandatory and not included in the example. As so= on as a type is set, a number of other things become mandatory too. Which on= es depends on what type you select.

 

/l2vpn-svc/sites/site["SITE= 1"]/site-network-accesses/site-network-access["LA1"]/vpn-atta= chment/vpn-id refers to a VPN that is not defined, but I guess that's accept= able.

 

p41:

Example broken:

 

        &nbs= p;<site-network-access-id>LA1</site-network-access-id>

=3D=3D>

        &nbs= p;<network-access-id>LA1</network-access-id>

 

Same things omitted as on p39.

 

p42:

Example broken in a couple of pl= aces:

 

1.

        &nbs= p;      <filter>

        &nbs= p;        <lan-tag>LAN1</lan-tag>=

=3D=3D>

        &nbs= p;      <filter>

        &nbs= p;        <type>lan</type>=

        &nbs= p;        <lan-tag>17</lan-tag>

 

2.

        &nbs= p;      <filter>

        &nbs= p;        <lan-tag>LAN2</lan-tag>=

=3D=3D>

        &nbs= p;      <filter>

        &nbs= p;        <type>lan</type>=

        &nbs= p;        <lan-tag>18</lan-tag>

 

3.

        &nbs= p;   <site-network-access-id>LA1</site-network-access-id>

= =3D=3D>
            <network-access-id>LA1</n= etwork-access-id>

Omits service/svc-mtu and manage= ment/type like on p39.

 

p60:

Example broken in a number of pl= aces:

 

1.

        &nbs= p;   <location>
              <city>NY</city>=
              <country-code>US</= country-code>
           </location>=

=3D=3D>

&= nbsp;         <locations>
            <location>
              <location-id>NY1</= location-id>
              <city>NY</city>=
              <country-code>US</= country-code>
           </location>
         </locations>

2.

        &nbs= p;      <site-network-access-id>CSP_A_VN1</site-netw= ork-access-id>

= =3D=3D>
               <network-access-id= >CSP_A_VN1</network-access-id-->

3.

        &nbs= p;              <eth-inf-type>tagge= d<eth-inf-type>

= =3D=3D>
                     =  <eth-inf-type>tagged</eth-inf-type>

4.

        &nbs= p;                <tagged-inf-typ= e>dot1q-vlan</tagged-inf-type>

= =3D=3D>
                     =    <tagged-inf-type>dot1q</tagged-inf-type>

5.

        &nbs= p;                 <vlan-id>17= </vlan-id>

=3D=3D>

        &nbs= p;                 <cvlan-id>1= 7</cvlan-id>

 

6.

Need to move <service> out= of <site-network-accesses/>

 

7.

Missing end tag

        &nbs= p;                  </bandwi= dth>

 

8.

Not making up our mind on how to= spell signaling/signalling bites us:

 

        &nbs= p;                    <= signaling-type>bgp</signaling-type>

= =3D=3D>
                     =        <signalling-type>bgp</signalling-type&g= t;

Same omissions as on p39.

 

p68a:

Example broken:

 

Some unwanted whitespace crept i= n:

        &nbs= p;            <svc-type>vpws</svc -ty= pe >

=3D=3D>

        &nbs= p;            <svc-type>vpws</svc-typ= e>

 

/l2vpn-svc/vpn-services/vpn-serv= ice["12456487" and "12456488"]/frame-delivery/multicast-= gp-port-mapping is mandatory and not configured

 

p68b:

Example broken in a number of pl= aces:

 

1.

        &nbs= p;       <location>

        &nbs= p;          <city>NY</city><= /span>

        &nbs= p;          <country-code>US</country-code= >

        &nbs= p;       </location>

=3D=3D>

        &nbs= p;       <locations>

        &nbs= p;       <location>

        &nbs= p;         <location-id>NY1</location-id>

        &nbs= p;          <city>NY</city><= /span>

        &nbs= p;          <country-code>US</country-code= >

        &nbs= p;       </location>

        &nbs= p;       </locations>

 

2.

Double start tags

        &nbs= p;           <access-diversity>

= =3D=3D>
                    </a= ccess-diversity>

3.

I'm guessing the author means &q= uot;vlan" when saying "dot1q" ?

        &nbs= p;            <encapsulation-type>dot1q&= lt;/encapsulation-type>

=3D=3D>

        &nbs= p;            <encapsulation-type>vlan&l= t;/encapsulation-type>

 

4.

Wrong end tag<= /p>

        &nbs= p;             </untagged-interface>

= =3D=3D>
                     = </tagged-interface>

5.

Needs to be lowercase=

        &nbs= p;               <stp-rstp-mstp>TUN= NEL</stp-rstp-mstp>

= =3D=3D>
                     =   <stp-rstp-mstp>tunnel</stp-rstp-mstp><= /p>

6.

        &nbs= p;               <lldp>TRUE</lld= p>

= =3D=3D>
                     =   <lldp>true</lldp>

7.

Need to move <service> out= of <site-network-accesses/>

 

8.

        &nbs= p;              <signaling-type>bgp= </signaling-type>

=3D=3D>
                     =  <signalling-type>bgp</signalling-type><= /p>

 

Same omissions as on p39.

 

 

 

Obviously, these XML fixes assum= e an unchanged YANG model. As they YANG is fixed/changed, the examples shoul= d follow suit.

 

That's all I found.

 

Thanks!

/jan

 

 

 

From: = Jan Lindblad [mailto:janl@tail-f.com] 
Sent: 17 January 20= 18 11:29
To: Adrian Farrel Cc: bclaise@cisco.com; Qin Wu
Subject: Re: Cheeky= request

 

Adrian,

 

You did such a good job with the= L3SMbis draft that it should come as no
surprise that we are all queueing up to have you as a reviewer.

https://datatracker.ietf.org/doc/draft-ie= tf-l2sm-l2vpn-service-model/ is now
very close to WG last call and we just made a request for "early"= YANG Doctor
review.

But if you were able to look at it as well, that would be rather good. Of course, you are allowed to be tired/bored/busy :-)

 

Flattery is often effective ;-)= Thank you for asking. I would certainly be interested to have a good look a= t all IETF service models, and perhaps better to get into the habit of doing= that before the publication rather than after :-/ I guess it's primarily going to be a question of when you ne= ed the answer. By when would you need it?

 

Best Regards,<= /p>

/jan

--

Jan Lindblad, janl@ta= il-f.com, +46 702855728

Solutions Architect, Busi= ness Development, Tail-f

Tail-f is now a part of C= isco

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle= persone indicate. La diffusione, copia o qualsiasi altra azione derivante d= alla conoscenza di queste informazioni sono rigorosamente vietate. Qualora a= bbiate ricevuto questo documento per errore siete cortesemente pregati di da= rne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying,= printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the s= ender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessa= rio.
--_000_01ef378c564b4c9697f2db73ba7caa0dTELMBXB02RM001telecomit_-- From nobody Fri Feb 9 01:07:37 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B99DB1200E5; Fri, 9 Feb 2018 01:07:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: l2sm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151816725273.1208.5571729404029497114@ietfa.amsl.com> Date: Fri, 09 Feb 2018 01:07:32 -0800 Archived-At: Subject: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-06.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 09:07:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the L2VPN Service Model WG of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-06.txt Pages : 162 Date : 2018-02-09 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The data model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-06 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 9 01:15:43 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BA512420B; Fri, 9 Feb 2018 01:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 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] 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 3MucPe9JzFfw; Fri, 9 Feb 2018 01:15:36 -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 781FC127735; Fri, 9 Feb 2018 01:15:35 -0800 (PST) X-AuditID: d9a97918-55fff70000006b07-10-5a7d66b5291f Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id 9E.D9.27399.5B66D7A5; Fri, 9 Feb 2018 10:15:33 +0100 (CET) From: Fioccola Giuseppe To: "l2sm@ietf.org" CC: "l2sm-chairs@ietf.org" , "'Jan Lindblad' (janl@tail-f.com)" Thread-Topic: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-06.txt Thread-Index: AQHToYVwYsZYbinsakqc1CaVzO/rUaObx/Yw Date: Fri, 9 Feb 2018 09:15:32 +0000 Message-ID: <60b269494a7040eaad06497bbb9f4233@TELMBXB02RM001.telecomitalia.local> References: <151816725273.1208.5571729404029497114@ietfa.amsl.com> In-Reply-To: <151816725273.1208.5571729404029497114@ietfa.amsl.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.251] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsXCxfdHWndrWm2UQd8hEYv/s/oYLR7svMhm ceflS0YHZo8lS34yeWz8tZglgCmqgdEmMS8vvySxJFUhJbU42VbJJbM4OScxMze1SCEkNSc1 OT9XSSEzxVbJWEmhICcxOTU3Na/EVimxoCA1L0XJjksBA9gAlWXmKaTmJeenZOal2yp5Bvvr WliYWuoaKtkFlqYWl+Qr5KYWFyemp2fmK6QmrBfMmL2kibFgvljF31udTA2MOwW7GDk5JARM JKb82sYEYgsJTGGS6L5VA2KzCdhIHHx1gg3EFhFQltj6rIMVxGYWyJS4e2kDWFxYwFPixr7F zBA13hJf9n9lgrCNJJYtegAWZxFQkXh7bDtYPa9AoMTf/xdYIXY5SUz91sbSxcjBwSngLNG8 jwMkzCggKzFh9yJGiFXiEi+mn2CHOFNAYsme88wQtqjEy8f/WCFsA4mtS/exQNiKEkdbTzNB 2DISC49MhjpZT+LG1ClsELa2xLKFr5khzhGUODnzCcsERrFZSNbNQtIyC0nLLCQtCxhZVjGK 5lYYmOiVQGIvsyQxJzNRL7NkEyMwadxcWSmxg7F7rfMhRgEORiUe3n8WtVFCrIllxZW5hxgl OJiVRHjLYoFCvCmJlVWpRfnxRaU5qcWHGH2AATaRWUo0OR+Y0PJK4g1NLCwNjS0sjAwtzExx CCuJ8/5LBZolkA5MXtmpqQWpRTDjmDg4pRoYRRec5z57bt8xi0ADsWNlwdPmnpk5fUXnt6cK sdXpscdeLHnt930P21XnBW737uzfzX2iyMP+8X1bfeMYxt28Fd7ydoz1m33jPqZtfpnH/WhV y87UrbycrTW3eVau3arYMiVqU8jRapVubi6O5R+z73CGna2/5eX7O+0M7yyHoAj2ip8n95n8 VGIpzkg01GIuKk4EAKu43NFHAwAA Archived-At: Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service-model-06.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 09:15:42 -0000 Hi All, This is the new version of the draft-ietf-l2sm-l2vpn-service-model. This revision addresses mainly the comments from Jan, plus other minor nits. Feedbacks are always welcome. Best Regards, Giuseppe -----Messaggio originale----- Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di internet-drafts@ietf.or= g Inviato: venerd=EC 9 febbraio 2018 10:08 A: i-d-announce@ietf.org Cc: l2sm@ietf.org Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directori= es. This draft is a work item of the L2VPN Service Model WG of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-06.txt Pages : 162 Date : 2018-02-09 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The data model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-06 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l2vpn-service-model-06 Please note that it may take a couple of minutes from the time of submission= until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ L2sm mailing list L2sm@ietf.org https://www.ietf.org/mailman/listinfo/l2sm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, 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 =E8 necessario. From nobody Sun Feb 11 11:13:59 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5F5126B72; Sun, 11 Feb 2018 11:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] 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 HhG6QDNQ7bDR; Sun, 11 Feb 2018 11:13:51 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 554C51243FE; Sun, 11 Feb 2018 11:13:50 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1BJDm8i007220; Sun, 11 Feb 2018 19:13:48 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3E59022044; Sun, 11 Feb 2018 19:13:48 +0000 (GMT) Received: from asmtp4.iomartmail.com (unknown [10.12.10.175]) by vs2.iomartmail.com (Postfix) with ESMTPS id 284DB22042; Sun, 11 Feb 2018 19:13:48 +0000 (GMT) Received: from 950129200 ([209.48.7.126]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w1BJDhgK005923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Feb 2018 19:13:47 GMT Reply-To: From: "Adrian Farrel" To: , Date: Sun, 11 Feb 2018 19:13:42 -0000 Message-ID: <005901d3a36c$70927c00$51b77400$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOjK9daaKUBCvAyTESntR1zWqpjtg== Content-Language: en-gb X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23658.002 X-TM-AS-Result: No--2.167-10.0-31-10 X-imss-scan-details: No--2.167-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23658.002 X-TMASE-Result: 10--2.167300-10.000000 X-TMASE-MatchedRID: xvWEVPhHiIRjDV//SvkH3lPjo7D4SFg4fkuZtv/FS5oKXKtfi06bFKPF jJEFr+olfeZdJ1XsorgUBfgS1SLQ+AtuKBGekqUpbGVEmIfjf3t0CV0JDZEk2aUUT8Lqmrjmmah 0n7Hde8HCrtHPcn00tvmKGwB8KbPfuet5r9Bdhvd06cjxY8Ylm1csa0AGV/SbwvwdumFAO/g= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [L2sm] IPR on draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2018 19:13:54 -0000 All authors of draft-ietf-l2sm-l2vpn-service-model, Please respond saying whether you know of any IPR that relates to this draft. For example: - Yes I know of IPR and it has already been disclosed - Yes I know of IPR and it will be disclosed according to IETF procedures - No, I am unaware of any IPR Thanks. Adrian From nobody Sun Feb 11 11:14:18 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B6C127599; Sun, 11 Feb 2018 11:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 XhVCeREVe9SC; Sun, 11 Feb 2018 11:14:11 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 86F40126B72; Sun, 11 Feb 2018 11:14:06 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1BJE28P007291; Sun, 11 Feb 2018 19:14:02 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A6DFD22044; Sun, 11 Feb 2018 19:14:02 +0000 (GMT) Received: from asmtp4.iomartmail.com (unknown [10.12.10.175]) by vs2.iomartmail.com (Postfix) with ESMTPS id 918F422042; Sun, 11 Feb 2018 19:14:02 +0000 (GMT) Received: from 950129200 ([209.48.7.126]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w1BJDhgP005923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Feb 2018 19:14:00 GMT Reply-To: From: "Adrian Farrel" To: Cc: , Date: Sun, 11 Feb 2018 19:13:42 -0000 Message-ID: <007201d3a36c$792771e0$6b7655a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOjJ9a1xhsWqfLCSUqk2KTFnI7LWA== Content-Language: en-gb X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23658.002 X-TM-AS-Result: No--7.311-10.0-31-10 X-imss-scan-details: No--7.311-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23658.002 X-TMASE-Result: 10--7.311200-10.000000 X-TMASE-MatchedRID: gcvckLgaTw2pIthzmcY7MTPDkSOzeDWWfKhbGg458tYQ248dkYhJfCGZ 6VVOVYeWqGojulZCNLRAJxrPiFXE0KXgCCul34T6ma6DzXaohvNhqttENCWmJ8naL1ri/ilXDl3 gO6j1HeaUiQppmDEdtHQJpsmqtg2cTX7PJ/OU3vL+xOhjarOnHmrz/G/ZSbVq+gtHj7OwNO0UBC 9Bhrukg5YgAgG7Uq+r2H1RsLM2SYqLfoCXY2eitpVeiZQ48JKk X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [L2sm] Working Group Last Call draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2018 19:14:15 -0000 Hi working group, Our draft has had some polish in the last few weeks. Thanks to Jan for a careful review of the YANG and to Qin for his supervision. But most of all, thanks to Giuseppe for the work as editor. This email starts a two week working group last call on draft-ietf-l2sm-l2vpn-service-model. Please send your comments and opinions to the mailing list before close of business on February 25th. Thanks, Adrian From nobody Wed Feb 14 06:44:41 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C5F126BFD; Wed, 14 Feb 2018 06:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 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] 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 inU-g-VLc-ma; Wed, 14 Feb 2018 06:44:36 -0800 (PST) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 4DD67124E15; Wed, 14 Feb 2018 06:44:35 -0800 (PST) X-AuditID: d9a97916-04fff7000000a80b-f9-5a844b526b68 Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id D2.B0.43019.25B448A5; Wed, 14 Feb 2018 15:44:34 +0100 (CET) From: Fioccola Giuseppe To: "adrian@olddog.co.uk" , "l2sm@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" Thread-Topic: IPR on draft-ietf-l2sm-l2vpn-service-model Thread-Index: AdOjK9daaKUBCvAyTESntR1zWqpjtgCdYqMQ Date: Wed, 14 Feb 2018 14:44:32 +0000 Message-ID: References: <005901d3a36c$70927c00$51b77400$@olddog.co.uk> In-Reply-To: <005901d3a36c$70927c00$51b77400$@olddog.co.uk> 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.231] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXCxfdHWjfIuyXKoOs4h8WPnhvMFj2PG5ks 7rx8yejA7LFkyU8mjxWbVzIGMEU1MNok5uXllySWpCqkpBYn2yq5ZBYn5yRm5qYWKYSk5qQm 5+cqKWSm2CoZKykU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9d CwtTS11DJbvA0tTiknyF3NTi4sT09Mx8hdSE9YIZnT+3MxbMZK2YdOofYwPjXJYuRk4OCQET idZT05i7GLk4hASmMEkcn76IHSTBJmAjcfDVCTYQW0RgM6PEjKOOILawgJnE6/ULGSHiFhJv f19lgrCNJD6emM4MYrMIqEo09OwGW8ArECixeM13oDgH0AIrifVzwMZwClhL3J13EmwMo4Cs xITdi8BsZgFxiRfTT7BD3CYgsWTPeWYIW1Ti5eN/rBC2gcTWpfug7leU6D7aC1UjI7HwyGRW iDk6Egt2f2KDsLUlli18zQxxjqDEyZlPWCYwis5Csm4WkpZZSFpmIWlZwMiyilE0t8LASK8E EmWZJYk5mYl6mSWbGIHp4ebKSrEdjK1rnQ8xCnAwKvHwcnm2RAmxJpYVV+YeYpTgYFYS4TU+ 3xwlxJuSWFmVWpQfX1Sak1p8iNEHGGATmaVEk/OBqSuvJN7QxMLS0NjCwsjQwswUh7CSOG8N L9B4gXRgmspOTS1ILYIZx8TBKdXAyP9c/kfsN7PPdn957lWULin+3qZ2e7dE9MtbF16ZnNCR frxOWi1jU8OtJcdfhNzgUTTOurrug9BWllC3DRMM/d0yYt6nsWzSk07aeeBQSeOOTpuFTWtW GbIeqBZax14gtdmn8+lZ7me957IPrMmRqwq1+aXY2rJYjOES95/1J+/vnFB12lssT4mlOCPR UIu5qDgRAM0u+588AwAA Archived-At: Subject: [L2sm] R: IPR on draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 14:44:40 -0000 Hi All, I'm not aware of any IPR related to this draft. Best Regards, Giuseppe -----Messaggio originale----- Da: Adrian Farrel [mailto:adrian@olddog.co.uk] Inviato: domenica 11 febbraio 2018 20:14 A: l2sm@ietf.org; draft-ietf-l2sm-l2vpn-service-model@ietf.org Oggetto: IPR on draft-ietf-l2sm-l2vpn-service-model All authors of draft-ietf-l2sm-l2vpn-service-model, Please respond saying whether you know of any IPR that relates to this draft= . For example: - Yes I know of IPR and it has already been disclosed - Yes I know of IPR and it will be disclosed according to IETF procedures - No, I am unaware of any IPR Thanks. Adrian Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, 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 =E8 necessario. From nobody Wed Feb 14 06:55:57 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCF8127AD4; Wed, 14 Feb 2018 06:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 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] 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 gf7CD5H9dEnK; Wed, 14 Feb 2018 06:55:49 -0800 (PST) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 78091126BFD; Wed, 14 Feb 2018 06:55:48 -0800 (PST) X-AuditID: d9a97916-04fff7000000a80b-d3-5a844df2b826 Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id A6.02.43019.2FD448A5; Wed, 14 Feb 2018 15:55:46 +0100 (CET) From: Fioccola Giuseppe To: "adrian@olddog.co.uk" , "l2sm@ietf.org" CC: "bclaise@cisco.com" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" Thread-Topic: Working Group Last Call draft-ietf-l2sm-l2vpn-service-model Thread-Index: AdOjJ9a1xhsWqfLCSUqk2KTFnI7LWACe0DuQ Date: Wed, 14 Feb 2018 14:55:45 +0000 Message-ID: References: <007201d3a36c$792771e0$6b7655a0$@olddog.co.uk> In-Reply-To: <007201d3a36c$792771e0$6b7655a0$@olddog.co.uk> 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.231] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsXCxfdHWveTb0uUwb7f4hY/em4wWxx9LGHR 87iRyeLOy5eMDiweU35vZPVYsuQnk8eKzSsZA5ijGhhtEvPy8ksSS1IVUlKLk22VXDKLk3MS M3NTixRCUnNSk/NzlRQyU2yVjJUUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+ SmZeuq2SZ7C/roWFqaWuoZJdYGlqcUm+Qm5qcXFienpmvkJqwnrBjP7lX1kLHrBVLH+7iLWB 8SBrFyMnh4SAicScRUuBbC4OIYEpTBJPlt9lA0mwCdhIHHx1AswWEQiSeNK6ix2kiFmgj1Fi YeMXZpCEsIC7xMuVEJNEBDwlFp1/xg5hG0m03H3DBGKzCKhKrNy2FMzmFQiU6Fh+H6xeSMBK 4u/ch4wgNqeAtUTnw4VgNqOArMSE3YvAbGYBcYkX00+wQ1wqILFkz3lmCFtU4uXjf1AfGEhs XbqPBcJWlOg+2gtVIyOx8MhkVog5OhILdn9ig7C1JZYtfM0McY+gxMmZT1gmMIrNQrJuFpKW WUhaZiFpWcDIsopRNLfCwEivBBKBmSWJOZmJepklmxiByeTmykqxHYyta50PMQpwMCrx8HJ5 tkQJsSaWFVfmHmKU4GBWEuE1Pt8cJcSbklhZlVqUH19UmpNafIjRBxhiE5mlRJPzgYkuryTe 0MTC0tDYwsLI0MLMFIewkjhvDS/QeIF0YArLTk0tSC2CGcfEwSnVwNgVOL2/+IprTOyKRcs/ HVmcvV8481WsgnbWf4Erxi2yG6w23w3s3RZUyl4mVZqnLBnCPefahqrb978q7Dpg9NW3t75b u7FmW7+V+PbyGIb7sV9nzQlQPV5rV7OleNXGe6X3/f9PnaWVfzJX08vKyFa5illaln9d6d1O TsdZyeqBL67W3rl1V4mlOCPRUIu5qDgRAPJHDiFTAwAA Archived-At: Subject: [L2sm] R: Working Group Last Call draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 14:55:56 -0000 Hi All, I want to thank L2SM chairs for starting WGLC phase. I support its publication as co-author. Best Regards, Giuseppe -----Messaggio originale----- Da: Adrian Farrel [mailto:adrian@olddog.co.uk] Inviato: domenica 11 febbraio 2018 20:14 A: l2sm@ietf.org Cc: bclaise@cisco.com; draft-ietf-l2sm-l2vpn-service-model@ietf.org Oggetto: Working Group Last Call draft-ietf-l2sm-l2vpn-service-model Hi working group, Our draft has had some polish in the last few weeks. Thanks to Jan for a careful review of the YANG and to Qin for his supervisio= n. But most of all, thanks to Giuseppe for the work as editor. This email starts a two week working group last call on draft-ietf-l2sm-l2vp= n-service-model. Please send your comments and opinions to the mailing list= before close of business on February 25th. Thanks, Adrian Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, 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 =E8 necessario. From nobody Wed Feb 14 09:37:13 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BABE12D777; Wed, 14 Feb 2018 09:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vHXg-4zNtXpA; Wed, 14 Feb 2018 09:37:09 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6243E126D85; Wed, 14 Feb 2018 09:37:09 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id e15so17044677oiy.2; Wed, 14 Feb 2018 09:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IAdZ52Qs6lqE9/adN30LK2n9qI1KL/t3Rvy5D+UGwIU=; b=KEFkVjV/NKtOcaeUUam2w2hnbLcsz5AvnTvhIiR/eYocBsYKQPbcoUOPSEos7TFvoO L/ui4VTSaazS+iHl5WyqvdjvCTeCaxHCY5N7EdTLEd0mmCGR8PwJD9D8tX209JAtIY+B dyyf/LoEdXts7BC47m8blCfdAsAGV3Ue/D/JlxrtcUBZOnR9uFetfX5r/iv1+mcc6iRQ CSYH77+gN3gYtv0LzrKVj7hr7iwAubT6iOkC8qq5MHnEcsuPDZJkPcAHxeLdYvXaQ5j2 Qa7mMKLSctt2q7c/551qb1AZ7npZ02jInglLHwDDJs/sJmBx4hvRr4BBU4tKDNfF0dgy 4fPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IAdZ52Qs6lqE9/adN30LK2n9qI1KL/t3Rvy5D+UGwIU=; b=T4JEUSsn+YupoYF/lwz5EahKG3uQ2EMlEgBfPa2oklnVR6mlJjJLVdEObaTUqvP4ST +FPk/cJhtQcv/TmRnFzJZS9LKdrb2hMIjLjxhpfK2ZSxNN6eIDBPjAvP9pGNfm0l0oCH 3UHgLehbQDm566EJ1ToLmFTEYujyke6YGMnIFwcBhSNRpGBJb1L4pBXEOEgOoZ8khVCg UEjs0Lnfs5XIp6NLQzoXKWgI46RtjrQKRdZh+kC6TS1RLa1x9bHRBQOO0tlAgNRbmutF VG13wB3K578zLUJ2PMQ5OHH6vC7oZ5TSJnkGTMCMZUVqFQr/p/eDVEToMhoU3GUos36x EQTg== X-Gm-Message-State: APf1xPA7eY6466bytpJhhk0X5TrWnBXM8GKfiPQ3Gs19nBUr6mt42ato BG2vO3tpYGAbkZanvv/soHoeiGITatvWN2wJbXA= X-Google-Smtp-Source: AH8x224osy1FGxHfttiQ4u7LEvQE3/SinpaBkhimswlncppP3HufxTSSUGHFRwQpsAS0JKmNLgjoMNGnBJbBe5hOEbI= X-Received: by 10.202.6.132 with SMTP id 126mr3853481oig.188.1518629828570; Wed, 14 Feb 2018 09:37:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.74.82 with HTTP; Wed, 14 Feb 2018 09:37:08 -0800 (PST) Received: by 10.157.74.82 with HTTP; Wed, 14 Feb 2018 09:37:08 -0800 (PST) In-Reply-To: <005901d3a36c$70927c00$51b77400$@olddog.co.uk> References: <005901d3a36c$70927c00$51b77400$@olddog.co.uk> From: Luay Jalil Date: Wed, 14 Feb 2018 11:37:08 -0600 Message-ID: To: Adrian Farrel Cc: l2sm@ietf.org, draft-ietf-l2sm-l2vpn-service-model@ietf.org Content-Type: multipart/alternative; boundary="94eb2c13dcd27a341905652f8f3a" Archived-At: Subject: Re: [L2sm] IPR on draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 17:37:11 -0000 --94eb2c13dcd27a341905652f8f3a Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR related to this draft Best regards, Luay On Feb 11, 2018 1:14 PM, "Adrian Farrel" wrote: All authors of draft-ietf-l2sm-l2vpn-service-model, Please respond saying whether you know of any IPR that relates to this draft. For example: - Yes I know of IPR and it has already been disclosed - Yes I know of IPR and it will be disclosed according to IETF procedures - No, I am unaware of any IPR Thanks. Adrian _______________________________________________ L2sm mailing list L2sm@ietf.org https://www.ietf.org/mailman/listinfo/l2sm --94eb2c13dcd27a341905652f8f3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I= am not aware of any IPR related to this draft

Best regards,=C2=A0
Luay


On Feb 11, 2018 1:14 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
All authors of draft-ietf-l2sm-l2= vpn-service-model,

Please respond saying whether you know of any IPR that relates to this draf= t.
For example:

- Yes I know of IPR and it has already been disclosed
- Yes I know of IPR and it will be disclosed according to IETF procedures - No, I am unaware of any IPR

Thanks.
Adrian

_______________________________________________
L2sm mailing list
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm

--94eb2c13dcd27a341905652f8f3a-- From nobody Wed Feb 14 10:02:41 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD5012D7F9; Wed, 14 Feb 2018 10:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SzoygFNn7irh; Wed, 14 Feb 2018 10:02:36 -0800 (PST) Received: from pacdcmhout02.cable.comcast.com (pacdcmhout02.cable.comcast.com [68.87.96.15]) (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 55B5612D77E; Wed, 14 Feb 2018 10:02:36 -0800 (PST) X-AuditID: 4457600f-3ef029e000002f83-24-5a8479bacc11 Received: from PACDCEX14.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by pacdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id AE.CB.12163.AB9748A5; Wed, 14 Feb 2018 13:02:34 -0500 (EST) Received: from PACDCEX15.cable.comcast.com (24.40.1.138) by PACDCEX14.cable.comcast.com (24.40.1.137) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 14 Feb 2018 13:01:16 -0500 Received: from PACDCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a28]) by PACDCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a28%19]) with mapi id 15.00.1365.000; Wed, 14 Feb 2018 13:01:16 -0500 From: "Wen, Bin" To: Luay Jalil CC: Adrian Farrel , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" , "l2sm@ietf.org" Thread-Topic: [L2sm] IPR on draft-ietf-l2sm-l2vpn-service-model Thread-Index: AdOjK9daaKUBCvAyTESntR1zWqpjtgCuIEoAAADXnoA= Date: Wed, 14 Feb 2018 18:01:16 +0000 Message-ID: <3DE2C177-A7F1-43E9-B8B2-CCF47983C3BC@cable.comcast.com> References: <005901d3a36c$70927c00$51b77400$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_3DE2C177A7F143E9B8B2CCF47983C3BCcablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsXiEq4ko7ursiXKYPEaNYsfPTeYLXoeNzJZ 3Hn5ktHi06XF7A4sHjtn3WX3WLLkJ5PHis0rGQOYo7hsUlJzMstSi/TtErgyLrf9Zi2YoF5x eJNeA+NP1S5GTg4JAROJA5O/sHYxcnEICexiknh96xc7lMMo8XfiZFaQKiGBk4wSl88Zgths AmoST2dNZQexRQRUJCbv3sMCYjMLrGWUmDE7G8QWFrCTeHrqERNEjb3E9CNL2CBsK4l9cxrA ZrIIqEp0n1oHNodXwEVi6b67jBCLGxklPq/ZCNbMKRAo8fbvdbAiRgExie+n1jBBLBOXuPVk PhPECwISS/acZ4awRSVePv7HCmEbSGxdug/quHSJTa0ToZYJSpyc+YQFokZc4vCRHawTGMVm IRk7C0nLLCQtsxg5gOKaEut36UOUKEpM6X7IDmFrSLTOmQtlW0nMP9fAhqxmASPHKkZuMws9 C3M9SzM9Q9NNjOBITeDfwXh0uschRgEORiUeXrv4ligh1sSy4srcQ4wSHMxKIrzG55ujhHhT EiurUovy44tKc1KLDzFKc7AoifNy8zVFCQmkJ5akZqemFqQWwWSZODilGhht14m/kGvf0e8U zGR1X0/ba5XEwkeclVPqe3Zv1K0uk6oLdzd/dCrws1lFAnv9wvT7T+ZpcqxZKcejP7ssoJD9 6+K0AI7bWrndWqp17y1E764uPD+rYnPkQdvSVblTlHquZkT7lydJbfTlPflRXNaiwYrjfE2Q Ma/P25KVt3vT3OoCjr8MUWIpzkg01GIuKk4EAB8JvCPQAgAA Archived-At: Subject: Re: [L2sm] IPR on draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 18:02:38 -0000 --_000_3DE2C177A7F143E9B8B2CCF47983C3BCcablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4NCg0KVGhh bmtzLA0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEZlYiAxNCwgMjAxOCwgYXQgMTI6Mzcg UE0sIEx1YXkgSmFsaWwgPGx1YXlqYWxpbEBnbWFpbC5jb208bWFpbHRvOmx1YXlqYWxpbEBnbWFp bC5jb20+PiB3cm90ZToNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRo aXMgZHJhZnQNCg0KQmVzdCByZWdhcmRzLA0KTHVheQ0KDQoNCk9uIEZlYiAxMSwgMjAxOCAxOjE0 IFBNLCAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWs+PiB3cm90ZToNCkFsbCBhdXRob3JzIG9mIGRyYWZ0LWlldGYtbDJzbS1sMnZw bi1zZXJ2aWNlLW1vZGVsLA0KDQpQbGVhc2UgcmVzcG9uZCBzYXlpbmcgd2hldGhlciB5b3Uga25v dyBvZiBhbnkgSVBSIHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0Lg0KRm9yIGV4YW1wbGU6DQoN Ci0gWWVzIEkga25vdyBvZiBJUFIgYW5kIGl0IGhhcyBhbHJlYWR5IGJlZW4gZGlzY2xvc2VkDQot IFllcyBJIGtub3cgb2YgSVBSIGFuZCBpdCB3aWxsIGJlIGRpc2Nsb3NlZCBhY2NvcmRpbmcgdG8g SUVURiBwcm9jZWR1cmVzDQotIE5vLCBJIGFtIHVuYXdhcmUgb2YgYW55IElQUg0KDQpUaGFua3Mu DQpBZHJpYW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkwyc20gbWFpbGluZyBsaXN0DQpMMnNtQGlldGYub3JnPG1haWx0bzpMMnNtQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnNtDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMMnNtIG1haWxpbmcgbGlz dA0KTDJzbUBpZXRmLm9yZzxtYWlsdG86TDJzbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbDJzbQ0K --_000_3DE2C177A7F143E9B8B2CCF47983C3BCcablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <3C5D4FD529B2E445824C0ED4302D26AA@comcast.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0iYXV0 byI+DQo8ZGl2IGRpcj0iYXV0byI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+SSBhbSBub3QgYXdhcmUg b2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuJm5ic3A7PC9zcGFuPjwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NClRoYW5rcyw8YnI+ DQo8YnI+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlNlbnQgZnJvbSBteSBpUGhvbmU8 L2Rpdj4NCjxkaXY+PGJyPg0KT24gRmViIDE0LCAyMDE4LCBhdCAxMjozNyBQTSwgTHVheSBKYWxp bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1YXlqYWxpbEBnbWFpbC5jb20iPmx1YXlqYWxpbEBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdj4NCjxkaXYgZGlyPSJhdXRvIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpzYW5zLXNlcmlmIiBkaXI9ImF1dG8iPkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIg cmVsYXRlZCB0byB0aGlzIGRyYWZ0PC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImZvbnQt ZmFtaWx5OnNhbnMtc2VyaWYiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJm b250LWZhbWlseTpzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHMsJm5ic3A7PC9kaXY+DQo8ZGl2IGRp cj0iYXV0byIgc3R5bGU9ImZvbnQtZmFtaWx5OnNhbnMtc2VyaWYiPkx1YXk8L2Rpdj4NCjxicj4N CjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gRmViIDExLCAyMDE4IDE6MTQgUE0sICZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9h PiZndDsgd3JvdGU6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJx dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KQWxsIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1sMnNtLWwydnBu LXNlcnZpY2UtPHdicj5tb2RlbCw8YnI+DQo8YnI+DQpQbGVhc2UgcmVzcG9uZCBzYXlpbmcgd2hl dGhlciB5b3Uga25vdyBvZiBhbnkgSVBSIHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0Ljxicj4N CkZvciBleGFtcGxlOjxicj4NCjxicj4NCi0gWWVzIEkga25vdyBvZiBJUFIgYW5kIGl0IGhhcyBh bHJlYWR5IGJlZW4gZGlzY2xvc2VkPGJyPg0KLSBZZXMgSSBrbm93IG9mIElQUiBhbmQgaXQgd2ls bCBiZSBkaXNjbG9zZWQgYWNjb3JkaW5nIHRvIElFVEYgcHJvY2VkdXJlczxicj4NCi0gTm8sIEkg YW0gdW5hd2FyZSBvZiBhbnkgSVBSPGJyPg0KPGJyPg0KVGhhbmtzLjxicj4NCkFkcmlhbjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19f X188YnI+DQpMMnNtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpMMnNtQGlldGYu b3JnIj5MMnNtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbDJzbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL2wyc208L2E+PGJyPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+ DQo8c3Bhbj5MMnNtIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWls dG86TDJzbUBpZXRmLm9yZyI+TDJzbUBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sMnNtIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wyc208L2E+PC9zcGFuPjxicj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3DE2C177A7F143E9B8B2CCF47983C3BCcablecomcastcom_-- From nobody Tue Feb 20 03:44:34 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B4612706D; Tue, 20 Feb 2018 03:44:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: l2sm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151912706764.29652.9962202744402775517@ietfa.amsl.com> Date: Tue, 20 Feb 2018 03:44:27 -0800 Archived-At: Subject: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-07.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 11:44:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the L2VPN Service Model WG of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-07.txt Pages : 162 Date : 2018-02-20 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The data model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-07 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 20 03:50:45 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BCE12711D; Tue, 20 Feb 2018 03:50:44 -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 mearkdwFqy0Q; Tue, 20 Feb 2018 03:50:41 -0800 (PST) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 137FC12706D; Tue, 20 Feb 2018 03:50:40 -0800 (PST) X-AuditID: d9a97916-037ff7000000a80b-4e-5a8c0b8ed5a3 Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id 1C.A7.43019.E8B0C8A5; Tue, 20 Feb 2018 12:50:38 +0100 (CET) From: Fioccola Giuseppe To: "l2sm@ietf.org" CC: "l2sm-chairs@ietf.org" Thread-Topic: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-07.txt Thread-Index: AQHTqkAvlHPMZzxEdkexrK+krItJGKOtK+eg Date: Tue, 20 Feb 2018 11:50:37 +0000 Message-ID: <2e8e8c5079b541948ca43b3769a01e8f@TELMBXB02RM001.telecomitalia.local> References: <151912706764.29652.9962202744402775517@ietfa.amsl.com> In-Reply-To: <151912706764.29652.9962202744402775517@ietfa.amsl.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.234] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCxfdHWrePuyfKYHO/vsWDnRfZLO68fMno wOSxZMlPpgDGqAZGm8S8vPySxJJUhZTU4mRbJZfM4uScxMzc1CKFkNSc1OT8XCWFzBRbJWMl hYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r5Bnsr2thYWqpa6hkF1ia WlySr5CbWlycmJ6ema+QmrBeMGPLx0VMBc9EK9asXcLWwNgn2MXIySEhYCLx8/oW9i5GLg4h gSlMErtftLGBJNgEbCQOvjoBZosIKEtsfdbB2sXIwcEsYCgxf28lSFhYwFNix7klLBAl3hL3 G2ZB2UYS21ZuZwexWQRUJY5sXc8IYvMKBEosedcDZgsJOEts2fSPFcTmFHCRuLL/FxOIzSgg KzFh9yKwGmYBcYkX00+wQ9wpILFkz3lmCFtU4uVjiF4JAQOJrUv3sUDYihJTfu9khLBlJBYe mcwKMUdP4sbUKWwQtrbEsoWvmSHuEZQ4OfMJywRGsVlI1s1C0jILScssJC0LGFlWMYrmVhgY 6ZVAoi+zJDEnM1Evs2QTIzBF3FxZKbaDsXWt8yFGAQ5GJR5en9/dUUKsiWXFlbmHGCU4mJVE eC9/BwrxpiRWVqUW5ccXleakFh9i9AGG2ERmKdHkfGD6yiuJNzSxsDQ0trAwMrQwM8UhrCTO yzu5K0pIIB2YvrJTUwtSi2DGMXFwSjUwGqrKZQYKRjy8w3V38eJ5J8RWcHceEDBPPaHrftzh yMkYtgKdzh7Zi1dPbHXTWP32d9qEJr7anIJlV7wCluy27lv3J5z1vMbvOvl1ZWUpXzh2Jyxk C3v8YYfzPB6bafss7v9/e3fV758+ESf3Xzt2WOQa61aRxStMFis6/nbLea8p3yZeGrzNTYml OCPRUIu5qDgRAOJDClU+AwAA Archived-At: Subject: [L2sm] I: I-D Action: draft-ietf-l2sm-l2vpn-service-model-07.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 11:50:44 -0000 Hi All, This new version of the draft-ietf-l2sm-l2vpn-service-model addresses some c= osmetic problems from the shepherd write-up. Best Regards, Giuseppe -----Messaggio originale----- Da: L2sm [mailto:l2sm-bounces@ietf.org] Per conto di internet-drafts@ietf.or= g Inviato: marted=EC 20 febbraio 2018 12:44 A: i-d-announce@ietf.org Cc: l2sm@ietf.org Oggetto: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directori= es. This draft is a work item of the L2VPN Service Model WG of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-07.txt Pages : 162 Date : 2018-02-20 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The data model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-07 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2sm-l2vpn-service-model-07 Please note that it may take a couple of minutes from the time of submission= until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ L2sm mailing list L2sm@ietf.org https://www.ietf.org/mailman/listinfo/l2sm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, 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 =E8 necessario. From nobody Tue Feb 20 04:54:20 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 573F4127337; Tue, 20 Feb 2018 04:54:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adrian Farrel To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Cc: Adrian Farrel , adrian@olddog.co.uk, l2sm-chairs@ietf.org, iesg-secretary@ietf.org, l2sm@ietf.org Message-ID: <151913125835.29699.13277968509864871501.idtracker@ietfa.amsl.com> Date: Tue, 20 Feb 2018 04:54:18 -0800 Archived-At: Subject: [L2sm] Publication has been requested for draft-ietf-l2sm-l2vpn-service-model-07 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 12:54:18 -0000 Adrian Farrel has requested publication of draft-ietf-l2sm-l2vpn-service-model-07 as Proposed Standard on behalf of the L2SM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ From nobody Tue Feb 20 09:46:31 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4A512D959; Tue, 20 Feb 2018 09:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 itjmQf3H-6JL; Tue, 20 Feb 2018 09:46:27 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id B11BE12D94A; Tue, 20 Feb 2018 09:46:25 -0800 (PST) HMM_SOURCE_IP: 172.18.0.80:36751.1182755793 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-172.58.16.214 (unknown [172.18.0.80]) by chinatelecom.cn (HERMES) with ESMTP id 2AD63280090; Wed, 21 Feb 2018 01:46:14 +0800 (CST) Received: from ip<172.58.16.214> ([172.18.0.80]) by App0022 with ESMTP id 7cad6ccc-7031-4490-9beb-02d7c353460d for bin_wen@comcast.com; Wed Feb 21 01:46:22 2018 0/X-Total-Score: 0: X-Real-From: xiechf.bri@chinatelecom.cn X-Receive-IP: 172.18.0.80 X-MEDUSA-Status: 0 Date: Tue, 20 Feb 2018 09:46:14 -0800 From: "xiechf.bri@chinatelecom.cn" To: 'Bin_Wen' , "Luay Jalil" Cc: "adrian@olddog.co.uk" , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" , "l2sm@ietf.org" References: <005901d3a36c$70927c00$51b77400$@olddog.co.uk>, , <3DE2C177-A7F1-43E9-B8B2-CCF47983C3BC@cable.comcast.com>, <2018022009441722532010@ctbri.com.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 8, 379[cn] Mime-Version: 1.0 Message-ID: <2018022009461143146813@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart170814242172_=----" Archived-At: Subject: Re: [L2sm] IPR on draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 17:46:29 -0000 This is a multi-part message in MIME format. ------=_001_NextPart170814242172_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQoNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuIFRo YW5rIHlvdSENCg0KQ2hvbmdmZW5nIFhpZQ0KDQoNCg0KeGllY2hmQGN0YnJpLmNvbS5jbg0KIA0K RnJvbTogV2VuLCBCaW4NCkRhdGU6IDIwMTgtMDItMTQgMTA6MDENClRvOiBMdWF5IEphbGlsDQpD QzogQWRyaWFuIEZhcnJlbDsgZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWxAaWV0 Zi5vcmc7IGwyc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDJzbV0gSVBSIG9uIGRyYWZ0LWll dGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIg cmVsYXRlZCB0byB0aGlzIGRyYWZ0LiANCg0KVGhhbmtzLA0KDQpTZW50IGZyb20gbXkgaVBob25l DQoNCk9uIEZlYiAxNCwgMjAxOCwgYXQgMTI6MzcgUE0sIEx1YXkgSmFsaWwgPGx1YXlqYWxpbEBn bWFpbC5jb20+IHdyb3RlOg0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8g dGhpcyBkcmFmdA0KDQpCZXN0IHJlZ2FyZHMsIA0KTHVheQ0KDQoNCk9uIEZlYiAxMSwgMjAxOCAx OjE0IFBNLCAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+IHdyb3RlOg0KQWxs IGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwsDQoNClBsZWFz ZSByZXNwb25kIHNheWluZyB3aGV0aGVyIHlvdSBrbm93IG9mIGFueSBJUFIgdGhhdCByZWxhdGVz IHRvIHRoaXMgZHJhZnQuDQpGb3IgZXhhbXBsZToNCg0KLSBZZXMgSSBrbm93IG9mIElQUiBhbmQg aXQgaGFzIGFscmVhZHkgYmVlbiBkaXNjbG9zZWQNCi0gWWVzIEkga25vdyBvZiBJUFIgYW5kIGl0 IHdpbGwgYmUgZGlzY2xvc2VkIGFjY29yZGluZyB0byBJRVRGIHByb2NlZHVyZXMNCi0gTm8sIEkg YW0gdW5hd2FyZSBvZiBhbnkgSVBSDQoNClRoYW5rcy4NCkFkcmlhbg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDJzbSBtYWlsaW5nIGxpc3QNCkwy c21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJzbQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTDJzbSBt YWlsaW5nIGxpc3QNCkwyc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbDJzbQ0K ------=_001_NextPart170814242172_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A

=
=0A


I am not aware of any IPR related to th= is draft. Thank you!

Chongfeng Xie
=0A
<= br>
=0A
xiechf@ctbri.com.cn
=0A
 
From:&nb= sp;Wen, Bin
Date:<= /b> 2018-02-14 10:01
= Subject: Re: [L2sm] IPR on draft-ietf-l2sm-l2vpn-service-model=
=0A
<= br>=0A
=0A
=0A
=0A
I am not aware of any IPR related to this draft. 
=0A
=0A
=0A

=0A
=0AThanks,
=0A<= br>=0A
Sent from my iPhone
=0A

= =0AOn Feb 14, 2018, at 12:37 PM, Luay Jalil <luayjalil@gmail.com> wrote:
=0A
=0A
=0A=0A
=0A
=0A
=0A
I am not aware of any IPR related to this = draft
=0A

=0A=0A
Best regards,&nb= sp;
=0A
Luay
= =0A
=0A

=0A
On = Feb 11, 2018 1:14 PM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
=0A=0AAll authors of draft-ietf-l2sm-l2vpn-service-m= odel,
=0A
=0APlease respond saying whether you know of any IPR that = relates to this draft.
=0AFor example:
=0A
=0A- Yes I know of IPR= and it has already been disclosed
=0A- Yes I know of IPR and it will b= e disclosed according to IETF procedures
=0A- No, I am unaware of any I= PR
=0A
=0AThanks.
=0AAdrian
=0A
=0A________________________= _______________________
=0AL2sm mailing list
=0AL2sm@ietf.org
=0Ahttps://www.ie= tf.org/mailman/listinfo/l2sm
=0A
=0A
=0A
= =0A
=0A
=0A=0A=0A
=0A
= =0A
_______________________________________________
= =0AL2sm mailing list
=0AL2sm@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/l2sm
=0A
=0A
=0A=0A= =0A ------=_001_NextPart170814242172_=------ From nobody Wed Feb 21 18:24:49 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9483E12E852 for ; Wed, 21 Feb 2018 18:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 g4G4grGn0q2u for ; Wed, 21 Feb 2018 18:24:45 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDE512E05C for ; Wed, 21 Feb 2018 18:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4462; q=dns/txt; s=iport; t=1519266285; x=1520475885; h=from:subject:to:message-id:date:mime-version; bh=+dCToQ+LPv0TAkBMktLaiIUr1QY2rtTpPoIRPQQyEnw=; b=Th2uRhsPX3jzWxW3KFBaGJUdHA+wsCusHse3D4O0J+1lCBUV3yFeVOi5 Kn7bvPZLLC3cWjFnQh4dUaC7g7TtzRZOM7i0mZDtCJhBBcL9RSkq3JvPE D1pj6QhNijjRiJ8WRSPmUEzTuQne1VPiUJQe2Gc562h1RkiF5A9fgkrnm 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAwCRKY5a/5ldJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZnAog2iYHIFbgT6QboVcFIICCiOIC1YWAQIBAQEBAQE?= =?us-ascii?q?Cax0LhU11DjACSxQNCAEBih8Qmk2QHIInJoRag3iCEwEBAQEGAQEBAQEeBYU?= =?us-ascii?q?RgieBV4FnKQyGKQEBAgEBgTWDT4JlBYp7iG+GRYoMCYgnjWaCIIYpg3GIC44?= =?us-ascii?q?JggGIHIE8JgMvgVEzGggbFYJ9hRQjNwELjFABAQE?= X-IronPort-AV: E=Sophos;i="5.47,376,1515456000"; d="scan'208,217";a="361943758" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 02:24:31 +0000 Received: from [10.82.244.207] (rtp-vpn2-1231.cisco.com [10.82.244.207]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1M2OUo3005242 for ; Thu, 22 Feb 2018 02:24:30 GMT From: Benoit Claise To: "l2sm@ietf.org" Message-ID: <267629e4-dd94-8979-b67c-0cc961625dfe@cisco.com> Date: Wed, 21 Feb 2018 21:24:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B5EDD632CBD37221D2345261" Content-Language: en-US Archived-At: Subject: [L2sm] AD review of draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 02:24:47 -0000 This is a multi-part message in MIME format. --------------B5EDD632CBD37221D2345261 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is the AD review. - Section 1.2. You want to use the YANG tree diagrams in draft-ietf-netmod-yang-tree-diagrams-04 I advice a section similar to https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3 - The draft is NMDA compliant. It should be mentioned. Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. - The references to RFC6020 should be changed to RFC7950, except in the IANA considerations. The YANG module is YANG 1.1 - revision 2018-02-05 { description "Initial revision -04 version"; reference "draft-ietf-l2sm-l2vpn-service-model-05.txt A YANG Data Model for L2VPN Service Delivery."; } This should be changed to revision 2018-02-05 { description "Initial revision -04 version"; reference "RFC XXXX: A YANG Data Model for L2VPN Service Delivery."; } - https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines Please doublecheck the template. The first sentence is: The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. Please publish a new version asap. Note that those changes doesn't prevent the IETF LC to start now. Hopefully, we could shoot for the March 8th IESDG telechat. Regards, Benoit --------------B5EDD632CBD37221D2345261 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

Here is the AD review.

- Section 1.2.
You want to use the YANG tree diagrams in draft-ietf-netmod-yang-tree-diagrams-04
I advice a section similar to https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-1.3

- The draft is NMDA compliant. It should be mentioned.
Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.
- The references to RFC6020 should be changed to RFC7950, except in the IANA considerations.
The YANG module is YANG 1.1

- 
 revision 2018-02-05 {
    description
      "Initial revision -04 version";
    reference
      "draft-ietf-l2sm-l2vpn-service-model-05.txt
       A YANG Data Model for L2VPN Service Delivery.";
  }

This should be changed to 
 revision 2018-02-05 {
    description
      "Initial revision -04 version";
    reference
      "RFC XXXX: A YANG Data Model for L2VPN Service Delivery.";
  }
- https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
Please doublecheck the template.
The first sentence is:
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
 

Please publish a new version asap.
Note that those changes doesn't prevent the IETF LC to start now.
Hopefully, we could shoot for the March 8th IESDG telechat.

Regards, Benoit

--------------B5EDD632CBD37221D2345261-- From nobody Wed Feb 21 21:57:23 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16789126FDC; Wed, 21 Feb 2018 21:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 ytfdPR1PozOo; Wed, 21 Feb 2018 21:57:19 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 CB61D126D3F; Wed, 21 Feb 2018 21:57:18 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E3EAC97A8A33A; Thu, 22 Feb 2018 05:57:14 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 22 Feb 2018 05:57:05 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Thu, 22 Feb 2018 13:56:57 +0800 From: Qin Wu To: "draft-ietf-l2sm-l2vpn-service-model@ietf.org" CC: "l2sm@ietf.org" , "adrian@olddog.co.uk" Thread-Topic: [L2sm] AD review of draft-ietf-l2sm-l2vpn-service-model Thread-Index: AQHTq4RWHf0G7IVNAkKpE0YPrIvSyaOv6rfQ Date: Thu, 22 Feb 2018 05:56:56 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.67] Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABA9AD6486Enkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [L2sm] AD review of draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 05:57:21 -0000 --_004_B8F9A780D330094D99AF023C5877DABA9AD6486Enkgeml513mbschi_ Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AD6486Enkgeml513mbschi_" --_000_B8F9A780D330094D99AF023C5877DABA9AD6486Enkgeml513mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEJlbm9pdC4NCkF1dGhvcnMsIHBsZWFzZSB0YWtlIGNhcmUgb2YgQUQgcmV2aWV34oCZ cyBjb21tZW50cy4NCkl0IHJlcXVpcmVzIHNvbWUgZWRpdG9yaWFsIGNoYW5nZXMgdG8gYWRkcmVz cyB0aGVtLg0KDQotUWluDQrlj5Hku7bkuro6IEwyc20gW21haWx0bzpsMnNtLWJvdW5jZXNAaWV0 Zi5vcmddIOS7o+ihqCBCZW5vaXQgQ2xhaXNlDQrlj5HpgIHml7bpl7Q6IDIwMTjlubQy5pyIMjLm l6UgMTA6MjUNCuaUtuS7tuS6ujogbDJzbUBpZXRmLm9yZw0K5Li76aKYOiBbTDJzbV0gQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsDQoNCkRlYXIgYWxsLA0K DQpIZXJlIGlzIHRoZSBBRCByZXZpZXcuDQoNCi0gU2VjdGlvbiAxLjIuDQpZb3Ugd2FudCB0byB1 c2UgdGhlIFlBTkcgdHJlZSBkaWFncmFtcyBpbiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUt ZGlhZ3JhbXMtMDQ8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1u ZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zLz4NCkkgYWR2aWNlIGEgc2VjdGlvbiBzaW1pbGFyIHRv IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlz LTAzI3NlY3Rpb24tMS4zDQoNCi0gVGhlIGRyYWZ0IGlzIE5NREEgY29tcGxpYW50LiBJdCBzaG91 bGQgYmUgbWVudGlvbmVkLg0KRXg6IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMtMDMsIGlu IHRoZSBhYnN0cmFjdCBhbmQgaW50cm8NCg0KICAgVGhlIFlBTkcgbW9kZWwgaW4gdGhpcyBkb2N1 bWVudCBjb25mb3JtcyB0byB0aGUgTmV0d29yayBNYW5hZ2VtZW50DQoNCiAgIERhdGFzdG9yZSBB cmNoaXRlY3R1cmUgZGVmaW5lZCBpbiBJLUQuaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVz Lg0KDQoNCi0gVGhlIHJlZmVyZW5jZXMgdG8gUkZDNjAyMCBzaG91bGQgYmUgY2hhbmdlZCB0byBS RkM3OTUwLCBleGNlcHQgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMuDQpUaGUgWUFORyBtb2R1 bGUgaXMgWUFORyAxLjENCg0KLQ0KDQogcmV2aXNpb24gMjAxOC0wMi0wNSB7DQoNCiAgICBkZXNj cmlwdGlvbg0KDQogICAgICAiSW5pdGlhbCByZXZpc2lvbiAtMDQgdmVyc2lvbiI7DQoNCiAgICBy ZWZlcmVuY2UNCg0KICAgICAgImRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTA1 LnR4dDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNl cnZpY2UtbW9kZWwtMDUudHh0Pg0KDQogICAgICAgQSBZQU5HIERhdGEgTW9kZWwgZm9yIEwyVlBO IFNlcnZpY2UgRGVsaXZlcnkuIjsNCg0KICB9DQoNCg0KDQpUaGlzIHNob3VsZCBiZSBjaGFuZ2Vk IHRvDQoNCiByZXZpc2lvbiAyMDE4LTAyLTA1IHsNCg0KICAgIGRlc2NyaXB0aW9uDQoNCiAgICAg ICJJbml0aWFsIHJldmlzaW9uIC0wNCB2ZXJzaW9uIjsNCg0KICAgIHJlZmVyZW5jZQ0KDQogICAg ICAiUkZDIFhYWFg6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBMMlZQTiBTZXJ2aWNlIERlbGl2ZXJ5 LiI7DQoNCiAgfQ0KDQoNCi0gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvb3BzL3dpa2kveWFu Zy1zZWN1cml0eS1ndWlkZWxpbmVzDQpQbGVhc2UgZG91YmxlY2hlY2sgdGhlIHRlbXBsYXRlLg0K VGhlIGZpcnN0IHNlbnRlbmNlIGlzOg0KVGhlIFlBTkcgbW9kdWxlIHNwZWNpZmllZCBpbiB0aGlz IGRvY3VtZW50IGRlZmluZXMgYSBzY2hlbWEgZm9yIGRhdGEgdGhhdCBpcyBkZXNpZ25lZCB0byBi ZSBhY2Nlc3NlZCB2aWEgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBzdWNoIGFzIE5FVENP TkYgW1JGQzYyNDFdIG9yIFJFU1RDT05GIFtSRkM4MDQwXS4NCg0KDQpQbGVhc2UgcHVibGlzaCBh IG5ldyB2ZXJzaW9uIGFzYXAuDQpOb3RlIHRoYXQgdGhvc2UgY2hhbmdlcyBkb2Vzbid0IHByZXZl bnQgdGhlIElFVEYgTEMgdG8gc3RhcnQgbm93Lg0KSG9wZWZ1bGx5LCB3ZSBjb3VsZCBzaG9vdCBm b3IgdGhlIE1hcmNoIDh0aCBJRVNERyB0ZWxlY2hhdC4NCg0KUmVnYXJkcywgQmVub2l0DQo= --_000_B8F9A780D330094D99AF023C5877DABA9AD6486Enkgeml513mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFj azt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE 6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBCZW5vaXQuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF1dGhvcnMsIHBsZWFzZSB0YWtlIGNhcmUg b2YgQUQgcmV2aWV34oCZcyBjb21tZW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SXQgcmVxdWlyZXMgc29tZSBlZGl0b3JpYWwgY2hhbmdlcyB0byBhZGRy ZXNzIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1RaW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2lu ZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4 dCI+IEwyc20gW21haWx0bzpsMnNtLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Luj6KGoIDwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRv d3RleHQiPkJlbm9pdCBDbGFpc2U8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+IDIwMTg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjI8L3NwYW4+ 5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIyPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiAx MDoyNTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBsMnNtQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mi mDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFtMMnNt XSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWw8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBhbGwsPGJyPg0KPGJyPg0K SGVyZSBpcyB0aGUgQUQgcmV2aWV3Ljxicj4NCjxicj4NCi0gU2VjdGlvbiAxLjIuPGJyPg0KWW91 IHdhbnQgdG8gdXNlIHRoZSBZQU5HIHRyZWUgZGlhZ3JhbXMgaW4gPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdy YW1zLyI+DQpkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMtMDQ8L2E+PGJyPg0K SSBhZHZpY2UgYSBzZWN0aW9uIHNpbWlsYXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMtMDMjc2VjdGlvbi0xLjMiPg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMt MDMjc2VjdGlvbi0xLjM8L2E+PGJyPg0KPGJyPg0KLSBUaGUgZHJhZnQgaXMgTk1EQSBjb21wbGlh bnQuIEl0IHNob3VsZCBiZSBtZW50aW9uZWQuPGJyPg0KRXg6IDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmRyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNi aXMtMDMsIGluIHRoZSBhYnN0cmFjdCBhbmQgaW50cm88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu YnNwOyBUaGUgWUFORyBtb2RlbCBpbiB0aGlzIGRvY3VtZW50IGNvbmZvcm1zIHRvIHRoZSBOZXR3 b3JrIE1hbmFnZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIGRlZmluZWQgaW4gSS1E LmlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gVGhlIHJlZmVyZW5jZXMg dG8gUkZDNjAyMCBzaG91bGQgYmUgY2hhbmdlZCB0byBSRkM3OTUwLCBleGNlcHQgaW4gdGhlIElB TkEgY29uc2lkZXJhdGlvbnMuPGJyPg0KVGhlIFlBTkcgbW9kdWxlIGlzIFlBTkcgMS4xPGJyPg0K PGJyPg0KLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDtyZXZpc2lvbiAyMDE4LTAyLTA1IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0luaXRpYWwgcmV2aXNpb24gLTA0IHZlcnNpb24mcXVvdDs7 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsmbmJzcDsgcmVmZXJlbmNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2 aWNlLW1vZGVsLTA1LnR4dCI+ZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwtMDUu dHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgWUFORyBEYXRhIE1vZGVsIGZv ciBMMlZQTiBTZXJ2aWNlIERlbGl2ZXJ5LiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgc2hvdWxkIGJlIGNoYW5nZWQgdG8gPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDtyZXZpc2lv biAyMDE4LTAyLTA1IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZxdW90O0luaXRpYWwgcmV2aXNpb24gLTA0IHZlcnNpb24mcXVvdDs7PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsg cmVmZXJlbmNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7UkZDIFhYWFg6IEEgWUFORyBE YXRhIE1vZGVsIGZvciBMMlZQTiBTZXJ2aWNlIERlbGl2ZXJ5LiZxdW90Ozs8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyB9PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3Jn L3RyYWMvb3BzL3dpa2kveWFuZy1zZWN1cml0eS1ndWlkZWxpbmVzIj4NCmh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL29wcy93aWtpL3lhbmctc2VjdXJpdHktZ3VpZGVsaW5lczwvYT48YnI+DQpQ bGVhc2UgZG91YmxlY2hlY2sgdGhlIHRlbXBsYXRlLiA8YnI+DQpUaGUgZmlyc3Qgc2VudGVuY2Ug aXM6PGJyPg0KVGhlIFlBTkcgbW9kdWxlIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGRlZmlu ZXMgYSBzY2hlbWEgZm9yIGRhdGEgdGhhdCBpcyBkZXNpZ25lZCB0byBiZSBhY2Nlc3NlZCB2aWEg bmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBzdWNoIGFzIE5FVENPTkYgW1JGQzYyNDFdIG9y IFJFU1RDT05GIFtSRkM4MDQwXS4NCjxicj4NCiZuYnNwOzxicj4NCjxicj4NClBsZWFzZSBwdWJs aXNoIGEgbmV3IHZlcnNpb24gYXNhcC48YnI+DQpOb3RlIHRoYXQgdGhvc2UgY2hhbmdlcyBkb2Vz bid0IHByZXZlbnQgdGhlIElFVEYgTEMgdG8gc3RhcnQgbm93Ljxicj4NCkhvcGVmdWxseSwgd2Ug Y291bGQgc2hvb3QgZm9yIHRoZSBNYXJjaCA4dGggSUVTREcgdGVsZWNoYXQuPGJyPg0KPGJyPg0K UmVnYXJkcywgQmVub2l0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_B8F9A780D330094D99AF023C5877DABA9AD6486Enkgeml513mbschi_-- --_004_B8F9A780D330094D99AF023C5877DABA9AD6486Enkgeml513mbschi_ Content-Type: text/plain; name="ATT00002.txt" Content-Description: ATT00002.txt Content-Disposition: attachment; filename="ATT00002.txt"; size=127; creation-date="Thu, 22 Feb 2018 02:25:00 GMT"; modification-date="Thu, 22 Feb 2018 02:25:00 GMT" Content-ID: <96715D1F642E994BB3ABD3E871D6BCC8@huawei.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkwyc20gbWFp bGluZyBsaXN0DQpMMnNtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2wyc20NCg== --_004_B8F9A780D330094D99AF023C5877DABA9AD6486Enkgeml513mbschi_-- From nobody Thu Feb 22 00:25:44 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883141270A7; Thu, 22 Feb 2018 00:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 zX5M-ss5yZaB; Thu, 22 Feb 2018 00:25:40 -0800 (PST) Received: from mx03.telecomitalia.it (mx03.telecomitalia.it [217.169.121.23]) (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 7BC8B1242EA; Thu, 22 Feb 2018 00:25:39 -0800 (PST) X-AuditID: d9a97917-c4dff7000000441d-fb-5a8e7e8115fa Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id 2C.0D.17437.18E7E8A5; Thu, 22 Feb 2018 09:25:37 +0100 (CET) From: Fioccola Giuseppe To: Benoit Claise , "l2sm@ietf.org" CC: "adrian@olddog.co.uk" , Qin Wu , "draft-ietf-l2sm-l2vpn-service-model@ietf.org" Thread-Topic: [L2sm] AD review of draft-ietf-l2sm-l2vpn-service-model Thread-Index: AQHTq4RWxL2eA/ZrH0GCkwnBWg2N5qOv6rfQgAAqTFA= Date: Thu, 22 Feb 2018 08:25:36 +0000 Message-ID: References: In-Reply-To: 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.233] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_ed7f6bfc54444b3497ea5210c584322cTELMBXB02RM001telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIKsWRmVeSWpSXmKPExsXCxfdHWrexri/KYFcTr8WPnhvMFkcfS1g8 nruA1aLncSOTxZ2XLxkdWD2m/N7I6tFy5C2rx5IlP5k8VmxeyRjAEtXAaJOYl5dfkliSqpCS Wpxsq+SSWZyck5iZm1qkEJKak5qcn6ukkJliq2SspFCQk5icmpuaV2KrlFhQkJqXomTHpYAB bIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7AJLU4tL8hVyU4uLE9PTM/MVUhPWC2acvLOE rWDNCsaKvgWrWRoYPyxm7GLk4JAQMJF4s6qoi5GLQ0hgCpNEx6+9QHFODjYBG4mDr06wgdgi Am4SjR/2s4EUMQusZ5RYM/MAE0hCWMBZouvnVqgiV4n3SzZC2VYSb272gg1iEVCVuN+9lAlk Ga9AoMT6g7ogYSGBUInt076ygticAmESXZMgbEYBWYkJuxeBtTILiEu8mH6CHcSWEBCQWLLn PDOELSrx8vE/VgjbQGLr0n0sELaixKPmbjYIW0Zi4ZHJrBBz8iXWzH8EVsMrIChxcuYTlgmM orOQrJiFpGwWkrJZQFczC2hKrN+lD1GiKDGl+yFUuYZE65y57MjiCxjZVzGK5lYYGOuVQOI1 syQxJzNRL7NkEyMwHd1cWSm+g7F9pfMhRgEORiUe3sSSvigh1sSy4srcQ4wSHMxKIrxLQ4FC vCmJlVWpRfnxRaU5qcWHGH2A4TiRWUo0OR+YKvNK4g1NLCwNjS0sjAwtzExxCCuJ816Z2Bsl JJAOTHjZqakFqUUw45g4OKUaGB+Yflp81uLPNtuTzdu2Tao3+PSqxuTUnzNPXRiXTpC/23fi vVri/ZVRXYe/r/jRnpOn3XdtpZ2DeWGg3wxthfNCCYtm1T4tmSp8M/TIZr7gcy+5Ai2qCnqP WNSq8Mef0dgg//fqNOXW++/Fb6yez6W7+KzcrKPnVcRYvzyuNJkx9R+fUM/bs9FKLMUZiYZa zEXFiQDTbcfPdAMAAA== Archived-At: Subject: [L2sm] R: AD review of draft-ietf-l2sm-l2vpn-service-model X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 08:25:44 -0000 --_000_ed7f6bfc54444b3497ea5210c584322cTELMBXB02RM001telecomit_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IEJlbm9pdCENCldlIHdpbGwgYWRkcmVzcyB5b3VyIGNvbW1lbnRzIGFuZCB3 aWxsIHB1Ymxpc2ggYSBuZXcgdmVyc2lvbiBsYXRlciB0b2RheS4NCg0KQmVzdCBSZWdhcmRz LA0KDQpHaXVzZXBwZQ0KDQpEYTogUWluIFd1IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29t XQ0KSW52aWF0bzogZ2lvdmVkw6wgMjIgZmViYnJhaW8gMjAxOCAwNjo1Nw0KQTogZHJhZnQt aWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWxAaWV0Zi5vcmcNCkNjOiBsMnNtQGlldGYu b3JnOyBhZHJpYW5Ab2xkZG9nLmNvLnVrDQpPZ2dldHRvOiBSRTogW0wyc21dIEFEIHJldmll dyBvZiBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbA0KDQpUaGFua3MgQmVu b2l0Lg0KQXV0aG9ycywgcGxlYXNlIHRha2UgY2FyZSBvZiBBRCByZXZpZXfigJlzIGNvbW1l bnRzLg0KSXQgcmVxdWlyZXMgc29tZSBlZGl0b3JpYWwgY2hhbmdlcyB0byBhZGRyZXNzIHRo ZW0uDQoNCi1RaW4NCuWPkeS7tuS6ujogTDJzbSBbbWFpbHRvOmwyc20tYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoIEJlbm9pdCBDbGFpc2UNCuWPkemAgeaXtumXtDogMjAxOOW5tDLmnIgy MuaXpSAxMDoyNQ0K5pS25Lu25Lq6OiBsMnNtQGlldGYub3JnPG1haWx0bzpsMnNtQGlldGYu b3JnPg0K5Li76aKYOiBbTDJzbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbDJzbS1sMnZw bi1zZXJ2aWNlLW1vZGVsDQoNCkRlYXIgYWxsLA0KDQpIZXJlIGlzIHRoZSBBRCByZXZpZXcu DQoNCi0gU2VjdGlvbiAxLjIuDQpZb3Ugd2FudCB0byB1c2UgdGhlIFlBTkcgdHJlZSBkaWFn cmFtcyBpbiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMtMDQ8aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVl LWRpYWdyYW1zLz4NCkkgYWR2aWNlIGEgc2VjdGlvbiBzaW1pbGFyIHRvIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAzI3NlY3Rp b24tMS4zDQoNCi0gVGhlIGRyYWZ0IGlzIE5NREEgY29tcGxpYW50LiBJdCBzaG91bGQgYmUg bWVudGlvbmVkLg0KRXg6IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMtMDMsIGluIHRo ZSBhYnN0cmFjdCBhbmQgaW50cm8NCg0KICAgVGhlIFlBTkcgbW9kZWwgaW4gdGhpcyBkb2N1 bWVudCBjb25mb3JtcyB0byB0aGUgTmV0d29yayBNYW5hZ2VtZW50DQoNCiAgIERhdGFzdG9y ZSBBcmNoaXRlY3R1cmUgZGVmaW5lZCBpbiBJLUQuaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRh c3RvcmVzLg0KDQoNCi0gVGhlIHJlZmVyZW5jZXMgdG8gUkZDNjAyMCBzaG91bGQgYmUgY2hh bmdlZCB0byBSRkM3OTUwLCBleGNlcHQgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMuDQpU aGUgWUFORyBtb2R1bGUgaXMgWUFORyAxLjENCg0KLQ0KDQogcmV2aXNpb24gMjAxOC0wMi0w NSB7DQoNCiAgICBkZXNjcmlwdGlvbg0KDQogICAgICAiSW5pdGlhbCByZXZpc2lvbiAtMDQg dmVyc2lvbiI7DQoNCiAgICByZWZlcmVuY2UNCg0KICAgICAgImRyYWZ0LWlldGYtbDJzbS1s MnZwbi1zZXJ2aWNlLW1vZGVsLTA1LnR4dDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwtMDUudHh0Pg0KDQogICAgICAg QSBZQU5HIERhdGEgTW9kZWwgZm9yIEwyVlBOIFNlcnZpY2UgRGVsaXZlcnkuIjsNCg0KICB9 DQoNCg0KDQpUaGlzIHNob3VsZCBiZSBjaGFuZ2VkIHRvDQoNCiByZXZpc2lvbiAyMDE4LTAy LTA1IHsNCg0KICAgIGRlc2NyaXB0aW9uDQoNCiAgICAgICJJbml0aWFsIHJldmlzaW9uIC0w NCB2ZXJzaW9uIjsNCg0KICAgIHJlZmVyZW5jZQ0KDQogICAgICAiUkZDIFhYWFg6IEEgWUFO RyBEYXRhIE1vZGVsIGZvciBMMlZQTiBTZXJ2aWNlIERlbGl2ZXJ5LiI7DQoNCiAgfQ0KDQoN Ci0gaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvb3BzL3dpa2kveWFuZy1zZWN1cml0eS1n dWlkZWxpbmVzDQpQbGVhc2UgZG91YmxlY2hlY2sgdGhlIHRlbXBsYXRlLg0KVGhlIGZpcnN0 IHNlbnRlbmNlIGlzOg0KVGhlIFlBTkcgbW9kdWxlIHNwZWNpZmllZCBpbiB0aGlzIGRvY3Vt ZW50IGRlZmluZXMgYSBzY2hlbWEgZm9yIGRhdGEgdGhhdCBpcyBkZXNpZ25lZCB0byBiZSBh Y2Nlc3NlZCB2aWEgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBzdWNoIGFzIE5FVENP TkYgW1JGQzYyNDFdIG9yIFJFU1RDT05GIFtSRkM4MDQwXS4NCg0KDQpQbGVhc2UgcHVibGlz aCBhIG5ldyB2ZXJzaW9uIGFzYXAuDQpOb3RlIHRoYXQgdGhvc2UgY2hhbmdlcyBkb2Vzbid0 IHByZXZlbnQgdGhlIElFVEYgTEMgdG8gc3RhcnQgbm93Lg0KSG9wZWZ1bGx5LCB3ZSBjb3Vs ZCBzaG9vdCBmb3IgdGhlIE1hcmNoIDh0aCBJRVNERyB0ZWxlY2hhdC4NCg0KUmVnYXJkcywg QmVub2l0DQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRp cml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1 c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEg Y29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIg ZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBj b211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0 cnV6aW9uZSwgR3JhemllLiANCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBp cyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g aW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29w eWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVy IGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4gDQoNClJpc3BldHRhIGwnYW1iaWVudGUuIE5v biBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg== --_000_ed7f6bfc54444b3497ea5210c584322cTELMBXB02RM001telecomit_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3Nl LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47DQoJY29sb3I6Ymxh Y2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHJlZm9ybWF0 dGF0byBIVE1MIENhcmF0dGVyZSI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47DQoJY29s b3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRlc3RvIGZ1 bWV0dG8gQ2FyYXR0ZXJlIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUHJlZm9ybWF0dGF0b0hUTUxDYXJhdHRlcmUN Cgl7bXNvLXN0eWxlLW5hbWU6IlByZWZvcm1hdHRhdG8gSFRNTCBDYXJhdHRlcmUiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHJlZm9ybWF0dGF0byBI VE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLkhUTUws IGxpLkhUTUwsIGRpdi5IVE1MDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8 jyI7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6U2ltU3VuOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5TdGlsZU1l c3NhZ2dpb0RpUG9zdGFFbGV0dHJvbmljYTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uVGVzdG9mdW1ldHRvQ2FyYXR0ZXJl DQoJe21zby1zdHlsZS1uYW1lOiJUZXN0byBmdW1ldHRvIENhcmF0dGVyZSI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXN0byBmdW1ldHRvIjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJJVCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGFuayB5b3UgQmVub2l0ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+V2Ugd2lsbCBhZGRyZXNzIHlvdXIgY29tbWVudHMgYW5kIHdp bGwgcHVibGlzaCBhIG5ldyB2ZXJzaW9uIGxhdGVyIHRvZGF5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdpdXNlcHBl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EYTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFFpbiBXdSBbbWFpbHRv OmJpbGwud3VAaHVhd2VpLmNvbV0NCjxicj4NCjxiPkludmlhdG86PC9iPiBnaW92ZWTDrCAy MiBmZWJicmFpbyAyMDE4IDA2OjU3PGJyPg0KPGI+QTo8L2I+IGRyYWZ0LWlldGYtbDJzbS1s MnZwbi1zZXJ2aWNlLW1vZGVsQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBsMnNtQGlldGYu b3JnOyBhZHJpYW5Ab2xkZG9nLmNvLnVrPGJyPg0KPGI+T2dnZXR0bzo8L2I+IFJFOiBbTDJz bV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFua3MgQmVub2l0Lg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5BdXRob3JzLCBwbGVhc2UgdGFrZSBjYXJlIG9mIEFEIHJldmlld+KAmXMg Y29tbWVudHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkl0IHJlcXVpcmVzIHNvbWUgZWRp dG9yaWFsIGNoYW5nZXMgdG8gYWRkcmVzcyB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tUWluPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7lj5Hku7bkuro8 L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQogTDJzbSBbPGEgaHJl Zj0ibWFpbHRvOmwyc20tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmwyc20tYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIDwvc3Bhbj4NCjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj7ku6PooagNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPkJlbm9pdCBDbGFpc2U8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4NCiAyMDE4PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjI8L3Nw YW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndp bmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaciDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dDtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+MjI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04i IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+DQogMTA6MjU8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPuaUtuS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4NCjxhIGhyZWY9Im1haWx0bzpsMnNtQGlldGYub3JnIj5sMnNtQGlldGYub3JnPC9h Pjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5Li7 6aKYPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KIFtMMnNtXSBB RCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RGVh ciBhbGwsPGJyPg0KPGJyPg0KSGVyZSBpcyB0aGUgQUQgcmV2aWV3Ljxicj4NCjxicj4NCi0g U2VjdGlvbiAxLjIuPGJyPg0KWW91IHdhbnQgdG8gdXNlIHRoZSBZQU5HIHRyZWUgZGlhZ3Jh bXMgaW4gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zLyI+DQpkcmFmdC1pZXRmLW5ldG1vZC15 YW5nLXRyZWUtZGlhZ3JhbXMtMDQ8L2E+PGJyPg0KSSBhZHZpY2UgYSBzZWN0aW9uIHNpbWls YXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0bW9kLXJmYzcyMjNiaXMtMDMjc2VjdGlvbi0xLjMiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMtMDMjc2VjdGlvbi0xLjM8 L2E+PGJyPg0KPGJyPg0KLSBUaGUgZHJhZnQgaXMgTk1EQSBjb21wbGlhbnQuIEl0IHNob3Vs ZCBiZSBtZW50aW9uZWQuPGJyPg0KRXg6IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmRyYWZ0 LWlldGYtbmV0bW9kLXJmYzcyMjNiaXMtMDMsIGluIHRoZSBhYnN0cmFjdCBhbmQgaW50cm88 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsgVGhlIFlB TkcgbW9kZWwgaW4gdGhpcyBkb2N1bWVudCBjb25mb3JtcyB0byB0aGUgTmV0d29yayBNYW5h Z2VtZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyBEYXRh c3RvcmUgQXJjaGl0ZWN0dXJlIGRlZmluZWQgaW4gSS1ELmlldGYtbmV0bW9kLXJldmlzZWQt ZGF0YXN0b3Jlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tIFRoZSByZWZlcmVu Y2VzIHRvIFJGQzYwMjAgc2hvdWxkIGJlIGNoYW5nZWQgdG8gUkZDNzk1MCwgZXhjZXB0IGlu IHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zLjxicj4NClRoZSBZQU5HIG1vZHVsZSBpcyBZQU5H IDEuMTxicj4NCjxicj4NCi0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDty ZXZpc2lvbiAyMDE4LTAyLTA1IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtJbml0aWFsIHJldmlz aW9uIC0wNCB2ZXJzaW9uJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2Ut bW9kZWwtMDUudHh0Ij5kcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0wNS50 eHQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTDJWUE4gU2Vydmlj ZSBEZWxpdmVyeS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw OyB9PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5UaGlzIHNob3VsZCBiZSBjaGFuZ2VkIHRvIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDtyZXZpc2lvbiAyMDE4LTAyLTA1IHs8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9u PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtJbml0aWFsIHJldmlzaW9uIC0wNCB2ZXJzaW9uJnF1b3Q7OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtSRkMgWFhYWDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIEwyVlBOIFNl cnZpY2UgRGVsaXZlcnkuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+LQ0KPGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvb3Bz L3dpa2kveWFuZy1zZWN1cml0eS1ndWlkZWxpbmVzIj5odHRwczovL3RyYWMuaWV0Zi5vcmcv dHJhYy9vcHMvd2lraS95YW5nLXNlY3VyaXR5LWd1aWRlbGluZXM8L2E+PGJyPg0KUGxlYXNl IGRvdWJsZWNoZWNrIHRoZSB0ZW1wbGF0ZS4gPGJyPg0KVGhlIGZpcnN0IHNlbnRlbmNlIGlz Ojxicj4NClRoZSBZQU5HIG1vZHVsZSBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBkZWZp bmVzIGEgc2NoZW1hIGZvciBkYXRhIHRoYXQgaXMgZGVzaWduZWQgdG8gYmUgYWNjZXNzZWQg dmlhIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbHMgc3VjaCBhcyBORVRDT05GIFtSRkM2 MjQxXSBvciBSRVNUQ09ORiBbUkZDODA0MF0uDQo8YnI+DQombmJzcDs8YnI+DQo8YnI+DQpQ bGVhc2UgcHVibGlzaCBhIG5ldyB2ZXJzaW9uIGFzYXAuPGJyPg0KTm90ZSB0aGF0IHRob3Nl IGNoYW5nZXMgZG9lc24ndCBwcmV2ZW50IHRoZSBJRVRGIExDIHRvIHN0YXJ0IG5vdy48YnI+ DQpIb3BlZnVsbHksIHdlIGNvdWxkIHNob290IGZvciB0aGUgTWFyY2ggOHRoIElFU0RHIHRl bGVjaGF0Ljxicj4NCjxicj4NClJlZ2FyZHMsIEJlbm9pdDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGh0bWw+DQoJPGJvZHk+DQoJCTx0YWJsZSBzdHlsZT0id2lkdGg6NjAw cHg7Ij4NCgkJCTx0ZCBzdHlsZT0id2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5h OyBmb250LXNpemU6Ny41cHQ7IGNvbG9yOiMwMDA7IHRleHQtYWxpZ246IGp1c3RpZnkiIHdp ZHRoPSIzOTUiPg0KCQkJCVF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29u byBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExh IGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUg ZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2Ft ZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50 byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVk aWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1 YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KCQkJCTxicj48YnI+DQoJCQkJPGk+DQoJCQkJCVRo aXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkg IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJl c3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2Ug YnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBh dHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuICBlLW1haWwsIFRo YW5rcy4NCgkJCQk8L2k+DQoJCQkJPGJyPjxicj4NCgkJCQk8Yj5SaXNwZXR0YSBsJ2FtYmll bnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uICZlZ3JhdmU7IG5lY2Vzc2Fy aW8uPC9iPg0KCQkJPC90ZD4NCgkJPC90YWJsZT4NCgk8L2JvZHk+DQo8L2h0bWw+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_ed7f6bfc54444b3497ea5210c584322cTELMBXB02RM001telecomit_-- From nobody Thu Feb 22 02:19:54 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 431D71242F5; Thu, 22 Feb 2018 02:19:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: l2sm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151929478724.21157.8724105164741138795@ietfa.amsl.com> Date: Thu, 22 Feb 2018 02:19:47 -0800 Archived-At: Subject: [L2sm] I-D Action: draft-ietf-l2sm-l2vpn-service-model-08.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 10:19:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the L2VPN Service Model WG of the IETF. Title : A YANG Data Model for L2VPN Service Delivery Authors : Bin Wen Giuseppe Fioccola Chongfeng Xie Luay Jalil Filename : draft-ietf-l2sm-l2vpn-service-model-08.txt Pages : 163 Date : 2018-02-22 Abstract: This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The YANG model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-l2sm-l2vpn-service-model-08 https://datatracker.ietf.org/doc/html/draft-ietf-l2sm-l2vpn-service-model-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 22 04:36:47 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0213812EA9F for ; Thu, 22 Feb 2018 04:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 pOuN8uv40JmO for ; Thu, 22 Feb 2018 04:36:43 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BADB12EA94 for ; Thu, 22 Feb 2018 04:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5908; q=dns/txt; s=iport; t=1519303003; x=1520512603; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=FljL1+mBa642Lrtj9vOxYe4UB+qNgESfH6JSjOlKHDY=; b=bhayqClJpG4VfOtlWuAAVfb1LDsmo3vD/qJqNGrxHALrdu8d6ngO6guA YkwUMJ9Ooazd40zdXxPy6ZT5ysy3NyEsmQzWuIn6Vdye3SNX1IlqK3reP eXJW8Jrd4M08cXUQGlIpxVKNvvNjDGgfPaRoR/ATBYn2NDcHe1VG7rERL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AgDPuI5a/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAog2iYHYFQCyeBFpBwhV6CFgolhQ8CgipVFwECAQEBAQE?= =?us-ascii?q?BAmsdC4UjAQYjVBIcAwECKwICTQIIBg0GAgEBih8Qql2CJyaEWoN1ghMBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBH4URgieBV4IQDIJ5gzABAQIBAReBdoJ3gmUFk2qGSYo?= =?us-ascii?q?MCYgojWaCIGeFQYNxJodljgyCAYgdgTwhATaBUTMaCBsVOoJDCYULIzcBjEMBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos; i="5.47,377,1515456000"; d="scan'208,217"; a="74340703" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 12:36:42 +0000 Received: from [10.82.171.153] ([10.82.171.153]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w1MCafxW021156 for ; Thu, 22 Feb 2018 12:36:42 GMT References: <151929478738.21157.5981612205351423352.idtracker@ietfa.amsl.com> To: "l2sm@ietf.org" From: Benoit Claise X-Forwarded-Message-Id: <151929478738.21157.5981612205351423352.idtracker@ietfa.amsl.com> Message-ID: <969219ff-1493-fcf0-0cc5-5e78de0ee11f@cisco.com> Date: Thu, 22 Feb 2018 07:36:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151929478738.21157.5981612205351423352.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------743ACFD0C119C190877B5D3C" Content-Language: en-US Archived-At: Subject: [L2sm] Fwd: New Version Notification - draft-ietf-l2sm-l2vpn-service-model-08.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 12:36:46 -0000 This is a multi-part message in MIME format. --------------743ACFD0C119C190877B5D3C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thank you for the new version. A minor editorial point in section 1.2. For consistency with other YANG module drafts, please remove: A simplified graphical representation of the data model is presented inSection 5 . The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. o Abbreviations before data node names: "rw" means configuration (read-write), and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node and "*" denotes a "list" or "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. No need to post a new draft version for now, just keep this change in your temp version. Regards, Benoit -------- Forwarded Message -------- Subject: New Version Notification - draft-ietf-l2sm-l2vpn-service-model-08.txt Date: Thu, 22 Feb 2018 02:19:47 -0800 From: internet-drafts@ietf.org To: bclaise@cisco.com, Adrian Farrel A new version (-08) has been submitted for draft-ietf-l2sm-l2vpn-service-model: https://www.ietf.org/internet-drafts/draft-ietf-l2sm-l2vpn-service-model-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-08 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. . --------------743ACFD0C119C190877B5D3C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Thank you for the new version.
A minor editorial point in section 1.2.
For consistency with other YANG module drafts, please remove:
   A simplified graphical representation of the data model is presented
   in Section 5.

   The meaning of the symbols in these diagrams is as follows:

   o  Brackets "[" and "]" enclose list keys.

   o  Curly braces "{" and "}" contain names of optional features that
      make the corresponding node conditional.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write), and "ro" state data (read-only).

   o  Symbols after data node names: "?" means an optional node and "*"
      denotes a "list" or "leaf-list".

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.
No need to post a new draft version for now, just keep this change in your temp version.

Regards, Benoit


-------- Forwarded Message --------
Subject: New Version Notification - draft-ietf-l2sm-l2vpn-service-model-08.txt
Date: Thu, 22 Feb 2018 02:19:47 -0800
From: internet-drafts@ietf.org
To: bclaise@cisco.com, Adrian Farrel <adrian@olddog.co.uk> 


A new version (-08) has been submitted for draft-ietf-l2sm-l2vpn-service-model:
https://www.ietf.org/internet-drafts/draft-ietf-l2sm-l2vpn-service-model-08.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l2sm-l2vpn-service-model-08

Please note that it may take a couple of minutes from the time of submission
until the diff is available at tools.ietf.org.

IETF Secretariat.

.
--------------743ACFD0C119C190877B5D3C-- From nobody Thu Feb 22 06:32:51 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5725712EAD4; Thu, 22 Feb 2018 06:32:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk CC: l2sm-chairs@ietf.org, l2sm@ietf.org, Adrian Farrel , bclaise@cisco.com, adrian@olddog.co.uk, draft-ietf-l2sm-l2vpn-service-model@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151930997034.8088.4869361677380186744.idtracker@ietfa.amsl.com> Date: Thu, 22 Feb 2018 06:32:50 -0800 Archived-At: Subject: [L2sm] Last Call: (A YANG Data Model for L2VPN Service Delivery) to Proposed Standard X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 14:32:50 -0000 The IESG has received a request from the L2VPN Service Model WG (l2sm) to consider the following document: - 'A YANG Data Model for L2VPN Service Delivery' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The YANG model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Feb 22 07:20:26 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF806127077 for ; Thu, 22 Feb 2018 07:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 jRaGFCtGVkjO for ; Thu, 22 Feb 2018 07:20:22 -0800 (PST) Received: from mx03.telecomitalia.it (mx03.telecomitalia.it [217.169.121.23]) (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 BDFF81241F3 for ; Thu, 22 Feb 2018 07:20:21 -0800 (PST) X-AuditID: d9a97917-c4dff7000000441d-b4-5a8edfb3750d Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id E2.99.17437.3BFDE8A5; Thu, 22 Feb 2018 16:20:19 +0100 (CET) From: Fioccola Giuseppe To: Benoit Claise , "l2sm@ietf.org" Thread-Topic: [L2sm] Fwd: New Version Notification - draft-ietf-l2sm-l2vpn-service-model-08.txt Thread-Index: AQHTq9nQZIYSR72ZJUaq/8GGt3aFVaOwiNfQ Date: Thu, 22 Feb 2018 15:20:19 +0000 Message-ID: <14e296089a3b48919ec39867226dd093@TELMBXB02RM001.telecomitalia.local> References: <151929478738.21157.5981612205351423352.idtracker@ietfa.amsl.com> <969219ff-1493-fcf0-0cc5-5e78de0ee11f@cisco.com> In-Reply-To: <969219ff-1493-fcf0-0cc5-5e78de0ee11f@cisco.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.232] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_14e296089a3b48919ec39867226dd093TELMBXB02RM001telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsXCxfdHWnfz/b4og6Xf9S2OPpawuPPyJaMD k8eU3xtZPZYs+ckUwBTVwGiTmJeXX5JYkqqQklqcbKvkklmcnJOYmZtapBCSmpOanJ+rpJCZ YqtkrKRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLzFFLzkvNTMvPSbZU8g/11LSxMLXUN lewCS1OLS/IVclOLixPT0zPzFVIT1gtmvHj2hbHgQXnFzGNnmBoYj5R0MXJySAiYSEy60M7S xcjFISQwhUli+6YuRpAEm4CNxMFXJ9hAbBEBN4nGD/vBbGGBeIknd2ayQ8QTJdbO/cwIYRtJ TLh0gRnEZhFQldg66QYriM0rECjxacsJVogFDYwSvxbPB2vmFLCVeNWyBKyZUUBWYsLuRWA2 s4C4xIvpJ9ghrhOQWLLnPDOELSrx8vE/VgjbQGLr0n0sELaixJITEMdJCMhILDwymRViTr7E 2YbDUEcISpyc+YRlAqPILCQrZiEpm4WkbBYjB1BcU2L9Ln2IEkWJKd0Poco1JFrnzGVHFl/A yL6KUTS3wsBYrwQSl5kliTmZiXqZJZsYgUnk5spK8R2M7SudDzEKcDAq8fAG7u2LEmJNLCuu zD3EKMHBrCTCW7YVKMSbklhZlVqUH19UmpNafIjRBxiSE5mlRJPzgQkuryTe0MTC0tDYwsLI 0MLMFIewkjhv11mgWQLpwMSWnZpakFoEM46Jg1OqgXGb57NDj5W57tZ6PJnBLVv9WUjCPZlP UbPtYaz468Nsa+seic/YtbNV6rOzxUMdn7dlciUMB9efmfnoemQ3E2P4gacPnnNW/DzD4yI2 91i0WfbiKzaLvqw6FSX47NMVHU+hqs+vluziVdZYeEf0EOecx9NuxEUlsv2PYtxyUkXVM+K4 S9z2N2VKLMUZiYZazEXFiQDOffBWTwMAAA== Archived-At: Subject: [L2sm] R: Fwd: New Version Notification - draft-ietf-l2sm-l2vpn-service-model-08.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 15:20:25 -0000 --_000_14e296089a3b48919ec39867226dd093TELMBXB02RM001telecomit_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIHdlIHdpbGwgdGFrZSBub3RlIG9mIHRoaXMgY2hhbmdlIGluIHZpZXcgb2YgdGhlIG5l eHQgcmV2aXNpb24uDQpUaGFuayB5b3UsDQoNCkdpdXNlcHBlDQoNCkRhOiBMMnNtIFttYWls dG86bDJzbS1ib3VuY2VzQGlldGYub3JnXSBQZXIgY29udG8gZGkgQmVub2l0IENsYWlzZQ0K SW52aWF0bzogZ2lvdmVkw6wgMjIgZmViYnJhaW8gMjAxOCAxMzozNw0KQTogbDJzbUBpZXRm Lm9yZw0KT2dnZXR0bzogW0wyc21dIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0g ZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwtMDgudHh0DQoNClRoYW5rIHlv dSBmb3IgdGhlIG5ldyB2ZXJzaW9uLg0KQSBtaW5vciBlZGl0b3JpYWwgcG9pbnQgaW4gc2Vj dGlvbiAxLjIuDQpGb3IgY29uc2lzdGVuY3kgd2l0aCBvdGhlciBZQU5HIG1vZHVsZSBkcmFm dHMsIHBsZWFzZSByZW1vdmU6DQoNCiAgIEEgc2ltcGxpZmllZCBncmFwaGljYWwgcmVwcmVz ZW50YXRpb24gb2YgdGhlIGRhdGEgbW9kZWwgaXMgcHJlc2VudGVkDQoNCiAgIGluIFNlY3Rp b24gNTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sMnNtLWwydnBu LXNlcnZpY2UtbW9kZWwtMDgjc2VjdGlvbi01Pi4NCg0KDQoNCiAgIFRoZSBtZWFuaW5nIG9m IHRoZSBzeW1ib2xzIGluIHRoZXNlIGRpYWdyYW1zIGlzIGFzIGZvbGxvd3M6DQoNCg0KDQog ICBvICBCcmFja2V0cyAiWyIgYW5kICJdIiBlbmNsb3NlIGxpc3Qga2V5cy4NCg0KDQoNCiAg IG8gIEN1cmx5IGJyYWNlcyAieyIgYW5kICJ9IiBjb250YWluIG5hbWVzIG9mIG9wdGlvbmFs IGZlYXR1cmVzIHRoYXQNCg0KICAgICAgbWFrZSB0aGUgY29ycmVzcG9uZGluZyBub2RlIGNv bmRpdGlvbmFsLg0KDQoNCg0KICAgbyAgQWJicmV2aWF0aW9ucyBiZWZvcmUgZGF0YSBub2Rl IG5hbWVzOiAicnciIG1lYW5zIGNvbmZpZ3VyYXRpb24NCg0KICAgICAgKHJlYWQtd3JpdGUp LCBhbmQgInJvIiBzdGF0ZSBkYXRhIChyZWFkLW9ubHkpLg0KDQoNCg0KICAgbyAgU3ltYm9s cyBhZnRlciBkYXRhIG5vZGUgbmFtZXM6ICI/IiBtZWFucyBhbiBvcHRpb25hbCBub2RlIGFu ZCAiKiINCg0KICAgICAgZGVub3RlcyBhICJsaXN0IiBvciAibGVhZi1saXN0Ii4NCg0KDQoN CiAgIG8gIFBhcmVudGhlc2VzIGVuY2xvc2UgY2hvaWNlIGFuZCBjYXNlIG5vZGVzLCBhbmQg Y2FzZSBub2RlcyBhcmUgYWxzbw0KDQogICAgICBtYXJrZWQgd2l0aCBhIGNvbG9uICgiOiIp Lg0KDQoNCg0KICAgbyAgRWxsaXBzaXMgKCIuLi4iKSBzdGFuZHMgZm9yIGNvbnRlbnRzIG9m IHN1YnRyZWVzIHRoYXQgYXJlIG5vdA0KDQogICAgICBzaG93bi4NCk5vIG5lZWQgdG8gcG9z dCBhIG5ldyBkcmFmdCB2ZXJzaW9uIGZvciBub3csIGp1c3Qga2VlcCB0aGlzIGNoYW5nZSBp biB5b3VyIHRlbXAgdmVyc2lvbi4NCg0KUmVnYXJkcywgQmVub2l0DQoNCg0KLS0tLS0tLS0g Rm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTA4LnR4 dA0KDQpEYXRlOg0KDQpUaHUsIDIyIEZlYiAyMDE4IDAyOjE5OjQ3IC0wODAwDQoNCkZyb206 DQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPg0KDQpUbzoNCg0KYmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lz Y28uY29tPiwgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az48bWFpbHRvOmFk cmlhbkBvbGRkb2cuY28udWs+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uICgtMDgpIGhhcyBiZWVu IHN1Ym1pdHRlZCBmb3IgZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWw6DQoN Cmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWwyc20t bDJ2cG4tc2VydmljZS1tb2RlbC0wOC50eHQNCg0KDQoNCg0KDQpUaGUgSUVURiBkYXRhdHJh Y2tlciBwYWdlIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2Rl bC8NCg0KDQoNCkRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9k ZWwtMDgNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCg0KdW50aWwgdGhlIGRpZmYg aXMgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQoNCg0KSUVURiBTZWNyZXRhcmlh dC4NCg0KDQoNCi4NCg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUu IExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFu dGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jv c2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3Vt ZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxh IHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLiANCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5h dGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0 aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4gDQoNClJpc3BldHRhIGwnYW1i aWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4N Cg== --_000_14e296089a3b48919ec39867226dd093TELMBXB02RM001telecomit_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJ cGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUHJlZm9ybWF0dGF0byBIVE1MIENhcmF0dGVyZSI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUHJlZm9ybWF0dGF0b0hUTUxD YXJhdHRlcmUNCgl7bXNvLXN0eWxlLW5hbWU6IlByZWZvcm1hdHRhdG8gSFRNTCBDYXJhdHRl cmUiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHJlZm9y bWF0dGF0byBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9 DQpzcGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDIu MGNtIDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IklU IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9rLCB3ZSB3aWxsIHRha2Ugbm90ZSBv ZiB0aGlzIGNoYW5nZSBpbiB2aWV3IG9mIHRoZSBuZXh0IHJldmlzaW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HaXVzZXBw ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RGE6PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBMMnNtIFttYWlsdG86 bDJzbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+UGVyIGNvbnRvIGRpIDwvYj5CZW5vaXQgQ2xh aXNlPGJyPg0KPGI+SW52aWF0bzo8L2I+IGdpb3ZlZMOsIDIyIGZlYmJyYWlvIDIwMTggMTM6 Mzc8YnI+DQo8Yj5BOjwvYj4gbDJzbUBpZXRmLm9yZzxicj4NCjxiPk9nZ2V0dG86PC9iPiBb TDJzbV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLWwyc20t bDJ2cG4tc2VydmljZS1tb2RlbC0wOC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIHRoZSBuZXcgdmVyc2lvbi48 YnI+DQpBIG1pbm9yIGVkaXRvcmlhbCBwb2ludCBpbiBzZWN0aW9uIDEuMi48YnI+DQpGb3Ig Y29uc2lzdGVuY3kgd2l0aCBvdGhlciBZQU5HIG1vZHVsZSBkcmFmdHMsIHBsZWFzZSByZW1v dmU6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBBIHNpbXBsaWZpZWQgZ3Jh cGhpY2FsIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBkYXRhIG1vZGVsIGlzIHByZXNlbnRlZDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpbiA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9k ZWwtMDgjc2VjdGlvbi01Ij5TZWN0aW9uIDU8L2E+LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGUgbWVhbmlu ZyBvZiB0aGUgc3ltYm9scyBpbiB0aGVzZSBkaWFncmFtcyBpcyBhcyBmb2xsb3dzOjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyBvJm5ic3A7IEJyYWNrZXRzICZxdW90O1smcXVvdDsgYW5kICZxdW90O10mcXVv dDsgZW5jbG9zZSBsaXN0IGtleXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQ3VybHkgYnJhY2Vz ICZxdW90O3smcXVvdDsgYW5kICZxdW90O30mcXVvdDsgY29udGFpbiBuYW1lcyBvZiBvcHRp b25hbCBmZWF0dXJlcyB0aGF0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1ha2UgdGhlIGNvcnJlc3BvbmRpbmcgbm9kZSBjb25kaXRp b25hbC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBBYmJyZXZpYXRpb25zIGJlZm9yZSBkYXRhIG5v ZGUgbmFtZXM6ICZxdW90O3J3JnF1b3Q7IG1lYW5zIGNvbmZpZ3VyYXRpb248bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKHJlYWQtd3Jp dGUpLCBhbmQgJnF1b3Q7cm8mcXVvdDsgc3RhdGUgZGF0YSAocmVhZC1vbmx5KS48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgbyZuYnNwOyBTeW1ib2xzIGFmdGVyIGRhdGEgbm9kZSBuYW1lczogJnF1b3Q7PyZx dW90OyBtZWFucyBhbiBvcHRpb25hbCBub2RlIGFuZCAmcXVvdDsqJnF1b3Q7PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlbm90ZXMg YSAmcXVvdDtsaXN0JnF1b3Q7IG9yICZxdW90O2xlYWYtbGlzdCZxdW90Oy48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgbyZuYnNwOyBQYXJlbnRoZXNlcyBlbmNsb3NlIGNob2ljZSBhbmQgY2FzZSBub2Rlcywg YW5kIGNhc2Ugbm9kZXMgYXJlIGFsc288bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFya2VkIHdpdGggYSBjb2xvbiAoJnF1b3Q7OiZx dW90OykuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgRWxsaXBzaXMgKCZxdW90Oy4uLiZxdW90Oykg c3RhbmRzIGZvciBjb250ZW50cyBvZiBzdWJ0cmVlcyB0aGF0IGFyZSBub3Q8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hvd24uPG86 cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vIG5lZWQgdG8gcG9zdCBh IG5ldyBkcmFmdCB2ZXJzaW9uIGZvciBub3csIGp1c3Qga2VlcCB0aGlzIGNoYW5nZSBpbiB5 b3VyIHRlbXAgdmVyc2lvbi48YnI+DQo8YnI+DQpSZWdhcmRzLCBCZW5vaXQ8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLS0tLS0t LSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBj bGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5TdWJqZWN0OiA8 bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gLSBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0wOC50eHQ8bzpwPjwv bzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkRhdGU6IDxv OnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRodSwgMjIgRmViIDIwMTggMDI6MTk6 NDcgLTA4MDA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3Jh cD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxiPkZyb206IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3Jh cD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxiPlRvOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJt YWlsdG86YmNsYWlzZUBjaXNjby5jb20iPmJjbGFpc2VAY2lzY28uY29tPC9hPiwgQWRyaWFu IEZhcnJlbA0KPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPiZsdDthZHJp YW5Ab2xkZG9nLmNvLnVrJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT5BIG5ldyB2ZXJz aW9uICgtMDgpIGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgZHJhZnQtaWV0Zi1sMnNtLWwydnBu LXNlcnZpY2UtbW9kZWw6PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbDJzbS1sMnZwbi1z ZXJ2aWNlLW1vZGVsLTA4LnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTA4LnR4dDwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgSUVURiBkYXRhdHJhY2tlciBwYWdlIGZv ciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbDJzbS1s MnZwbi1zZXJ2aWNlLW1vZGVsLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwvPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkRpZmYgZnJvbSBwcmV2 aW91cyB2ZXJzaW9uOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2Vydmlj ZS1tb2RlbC0wOCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTA4PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT51bnRpbCB0aGUgZGlmZiBpcyBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+SUVURiBTZWNyZXRhcmlhdC48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4uPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8aHRtbD4N Cgk8Ym9keT4NCgkJPHRhYmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KCQkJPHRkIHN0eWxl PSJ3aWR0aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTo3LjVwdDsg Y29sb3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lkdGg9IjM5NSI+DQoJCQkJUXVl c3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1 c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEg byBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRp IHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxv cmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUg Y29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUg YWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6 aWUuDQoJCQkJPGJyPjxicj4NCgkJCQk8aT4NCgkJCQkJVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSAgY29udGFpbiBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3Nl bWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMg dW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZp c2UgdGhlIHNlbmRlciBieSByZXR1cm4gIGUtbWFpbCwgVGhhbmtzLg0KCQkJCTwvaT4NCgkJ CQk8YnI+PGJyPg0KCQkJCTxiPlJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBx dWVzdGEgbWFpbCBzZSBub24gJmVncmF2ZTsgbmVjZXNzYXJpby48L2I+DQoJCQk8L3RkPg0K CQk8L3RhYmxlPg0KCTwvYm9keT4NCjwvaHRtbD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_14e296089a3b48919ec39867226dd093TELMBXB02RM001telecomit_-- From nobody Fri Feb 23 08:08:16 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65A7126DFB; Fri, 23 Feb 2018 08:08:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.3 Auto-Submitted: auto-generated Precedence: bulk CC: l2sm-chairs@ietf.org, l2sm@ietf.org, Adrian Farrel , bclaise@cisco.com, adrian@olddog.co.uk, draft-ietf-l2sm-l2vpn-service-model@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151940208681.24155.9439950383838413364.idtracker@ietfa.amsl.com> Date: Fri, 23 Feb 2018 08:08:06 -0800 Archived-At: Subject: [L2sm] UPDATED Last Call: (A YANG Data Model for L2VPN Service Delivery) to Proposed Standard X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 16:08:07 -0000 The IESG has received a request from the L2VPN Service Model WG (l2sm) to consider the following document: - 'A YANG Data Model for L2VPN Service Delivery' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model that can be used to configure a Layer 2 Provider Provisioned VPN service. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements, but provides an abstracted view of the Layer 2 VPN service configuration components. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The YANG model in this document includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624. The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Feb 24 17:00:30 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5907E126BF7; Sat, 24 Feb 2018 17:00:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: Cc: l2sm@ietf.org, ietf@ietf.org, draft-ietf-l2sm-l2vpn-service-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151952041929.12995.5895779377191010604@ietfa.amsl.com> Date: Sat, 24 Feb 2018 17:00:19 -0800 Archived-At: Subject: [L2sm] Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 01:00:19 -0000 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 . 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. 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. 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. 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. 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.) 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. 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.) 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. 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. 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? 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, ...) 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. 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. 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. 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.) 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. 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? 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. 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? Section 5.17 has a short paragraph in the middle that uses the term OVC that is not otherwise used in this document. 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? 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 "" From nobody Sun Feb 25 01:11:35 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7112126BFD; Sun, 25 Feb 2018 01:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rwo-piS7Ew73; Sun, 25 Feb 2018 01:11:30 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 0D269126DFF; Sun, 25 Feb 2018 01:11:14 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1P9BBFN031900; Sun, 25 Feb 2018 09:11:11 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7A25122040; Sun, 25 Feb 2018 09:11:11 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 648FE2203D; Sun, 25 Feb 2018 09:11:11 +0000 (GMT) Received: from 950129200 ([193.57.121.27]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1P9B8NK005151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Feb 2018 09:11:10 GMT Reply-To: From: "Adrian Farrel" To: "'Joel Halpern'" , Cc: , , References: <151952041929.12995.5895779377191010604@ietfa.amsl.com> In-Reply-To: <151952041929.12995.5895779377191010604@ietfa.amsl.com> Date: Sun, 25 Feb 2018 09:11:09 -0000 Message-ID: <065401d3ae18$949f1ca0$bddd55e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGVP3SqKJY89/RdTeyFQpQq0QAo9KQxscZQ Content-Language: en-gb X-Originating-IP: 193.57.121.27 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23684.006 X-TM-AS-Result: No--20.040-10.0-31-10 X-imss-scan-details: No--20.040-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23684.006 X-TMASE-Result: 10--20.040000-10.000000 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wkhEDfw/93BuyeUl7aCTy8jjsTquy0JRiyA8 rnY0U1KzMKCFIoZOZBDxTwx4UJIMck5RCTiYesCKTIzrNCbT62obTwzYj2zQuuQydRUvl3QT+1y eRNwXFNzMjyttkaAdtLBMgJuhfWMi2rvYheZgBXtwUSK4/EeOxXJrB0Cu3DDnEd+K6O5Nt506wo IcQIJqTVWThGBLBxQbcw016UDmVKkNDmNqb6OmSq91/YHX0i1lzJmqByfAaS1Y/2pi7PK0EuD+b NUbvCNRlTJXKqh1ne3LJ3PSkfYjxkEzWu30xbMcJhb388hdoo9m43Ht6SePHu0lRPbZZsJJQfXe xN3meZCczXEIRLVzwev4h1UdnDHwpkkXpMSpG5wtR8fVMTBo3cBZPOJYZoM8SSUXkvSVAdzimg9 4X0eg/tuZalamwBXt7taqnOMBaKE9dF/Bzwh+4Az4VsCc1YW+ERzrQ87nh6pZps+y1VXzqXkDxC 8oBMkz1GEeRzIMZZOVku+AOFtK6teMRzCcJKBBbBu6+EIezdyEQiKo28GuYw2G3vz8l/IEsUxOW MsTCHLMU8uAdH6XmhiqtznBCN+1JTKg1fMqYHDDg+U1NSmcubnXAHYFSPMZyPRAwD/3abajkBpU 34bhn+26WDOAe8Sfr9dasV69MmyYWjOlAjIj68+ayFtEW0uYN/BTU5ZfZRK0Vg+MnSE2GPRm0km qtH+DezJybqTXDzLc8HL6slabEAQ4uF25dsUI3FqOVb7PDELEGBoHKd3a+bCXtJ14sCJ3fecMAQ BtYyTXgsFAU4DkYs0TtqW/TWarIWv+DotxFxueAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [L2sm] Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 09:11:34 -0000 Thanks Joel, There's a lot to digest here. The chairs will work with the authors on a = response. Adrian > -----Original Message----- > From: Joel Halpern [mailto:jmh@joelhalpern.com] > Sent: 25 February 2018 01:00 > To: gen-art@ietf.org > Cc: l2sm@ietf.org; ietf@ietf.org; = draft-ietf-l2sm-l2vpn-service-model.all@ietf.org > Subject: Genart telechat review of = draft-ietf-l2sm-l2vpn-service-model-08 >=20 > Reviewer: Joel Halpern > Review result: On the Right Track >=20 > 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. >=20 > For more information, please see the FAQ at >=20 > . >=20 > 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 >=20 > Summary: Given the number of Major and minor issues, this document is = not yet > ready for publication as a Proposed Standard RFC. >=20 > 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. >=20 > 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. >=20 > 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. 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. >=20 > 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.) >=20 > 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. >=20 > 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.) >=20 > 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. >=20 > 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. >=20 > 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? 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, ...) = 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. >=20 > 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. >=20 > 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. >=20 > 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.) >=20 > 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. >=20 > 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? >=20 > 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. >=20 > 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? >=20 > Section 5.17 has a short paragraph in the middle that uses the = term OVC > that is not otherwise used in this document. >=20 > 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? >=20 > 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. >=20 > 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"? >=20 > 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. >=20 > The indenting of the XML in section 5.5.2.1 should be repaired. = All of the > XML examples should have their indenting checked. >=20 > 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)"? >=20 > 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. >=20 > 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 "" From nobody Mon Feb 26 04:35:13 2018 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 456CE126DD9; Mon, 26 Feb 2018 04:35:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ladislav Lhotka To: Cc: l2sm@ietf.org, ietf@ietf.org, draft-ietf-l2sm-l2vpn-service-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151964851123.31353.1471509914124380207@ietfa.amsl.com> Date: Mon, 26 Feb 2018 04:35:11 -0800 Archived-At: Subject: [L2sm] Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 12:35:11 -0000 Reviewer: Ladislav Lhotka Review result: Ready with Issues **** General comments - The 'ietf-l2vpn-svc' module contained in this document is rather large: it defines 386 schema nodes, 35 features and 175 identities. It is therefore natural to ask whether the authors considered splitting the definitions into multiple modules. This would make the data model more modular and probably also make some of the features unnecessary. See also draft-ietf-netmod-rfc6087bis-18, sec. 4.17. - The module defines most containers, lists and even individual leaves in a grouping that is then used only once. This approach has its pros nad cons but it is not the common practice in YANG modelling - groupings are mostly defined only if they are used (or expected to be used) repeatedly and/or in different modules. - Some of the groupings (e.g. 'site-device') reference nodes outside the grouping, which is discouraged, see draft-ietf-netmod-rfc6087bis-18, sec. 4.13. - Names are sometimes overloaded in that the same name is used for different purposes. For example, 'cloud-access' is used as the name of both a list and a feature. In one case ('bum-frame-delivery'), the same name is used for a list, the container that encloses it, and the grouping in which the container is defined. This should be avoided. **** Specific comments - Most when expressions correctly use the XPath function 'derived-from-or-self()'. In two cases ('vpn-id' and 'cos-id' leaves) identities are compared in XPath expressions using plain string equality. These XPath expressions need to be changed to use 'derived-from-or-self()' as well. - The when expression for container 'devices' user a disjunction of two 'derived-from-or-self()' checks. This usually indicates that a new identity can be defined from which both or-ed identities are derived. **** Instance examples The example instance documents contained in the document require to be carefully checked because they are often invalid or even not well-formed. I would also suggest to use examples in JSON encoding that is easier to read: The problems that I discovered include: - extra space in opening and closing XML tags < network-access-id> and - p. 28: wrong namespace URI "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc" - p. 28: in the first 'vpn-service' entry (key 'VPNB'), two mandatory leaves are missing: 'ce-vlan-preservation' and 'ce-vlan-cos-perservation'. **** Nits - The name of 'ce-vlan-cos-perservation' should most likely be 'ce-vlan-cos-preservation' - Inconsistent indentation: features 'cfm' and 'y-1731' have less spaces of indentation than other features - When concatenating literal strings, the widely accepted convention is to put the '+' sign ot the second line, and align the string components. That is, instead of path "/l2vpn-svc/vpn-profiles/valid-provider-identifiers"+ "/cloud-identifier/id"; use path "/l2vpn-svc/vpn-profiles/valid-provider-identifiers" + "/cloud-identifier/id"; From nobody Wed Feb 28 03:23:02 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9BA12EB08; Wed, 28 Feb 2018 03:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_TEMPERROR=0.01] 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 uf11FXGVvFMU; Wed, 28 Feb 2018 03:22:39 -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 3DEC612EB09; Wed, 28 Feb 2018 03:22:27 -0800 (PST) X-AuditID: d9a97918-55fff70000006b07-73-5a9690f188d2 Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id F8.19.27399.1F0969A5; Wed, 28 Feb 2018 12:22:25 +0100 (CET) From: Fioccola Giuseppe To: Joel Halpern , "gen-art@ietf.org" CC: "l2sm@ietf.org" , "ietf@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model.all@ietf.org" Thread-Topic: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08 Thread-Index: AQHTrdQE5atJ829Vik2Zfwxn3fWyhKO5pwJA Date: Wed, 28 Feb 2018 11:22:24 +0000 Message-ID: <295aa6644a884df5843f065508bbdf2e@TELMBXB02RM001.telecomitalia.local> References: <151952041929.12995.5895779377191010604@ietfa.amsl.com> In-Reply-To: <151952041929.12995.5895779377191010604@ietfa.amsl.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.250] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsXCxfdHWvfjhGlRBi+P81hsm9bCaHH11WcW i2cb57NYfDz1hsnizsuXjA6sHkuW/GTyODflO2MAU1QDo01iXl5+SWJJqkJKanGyrZJLZnFy TmJmbmqRQkhqTmpyfq6SQmaKrZKxkkJBTmJyam5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1L zk/JzEu3VfIM9te1sDC11DVUsgssTS0uyVfITS0uTkxPz8xXSE1YL5jxau9U1oJ7mxkr1h+c z9bAOGE9YxcjJ4eEgInElX0TmLoYuTiEBKYwSUz+fIUFJMEmYCNx8NUJNhBbRMBX4vjfTWBF zALrGSVmbFsO1i0s4CNxdscrFogiP4mfk96xQthGEm/av4E1swioSnRc28kOYvMKBEp8WfYW LC4k4Cwx9fBesDingIvEhAVdzCA2o4CsxITdi8DmMwuIS7yYfoId4lIBiSV7zjND2KISLx// Y4WwDSS2Lt3HAmErSkw69RQqLiOx8MhkIJsDaI6mxPpd+hAjFSWmdD+EOkdQ4uTMJywTGMVm Idk2C6FjFpKOWUg6FjCyrGIUza0wMNErgURgZkliTmaiXmbJJkZgOrm5slJiB2P3WudDjAIc jEo8vE+8p0UJsSaWFVfmHmKU4GBWEuFNKwEK8aYkVlalFuXHF5XmpBYfYvQBhtdEZinR5Hxg qssriTc0sbA0NLawMDK0MDPFIawkzru8EmiWQDowhWWnphakFsGMY+LglGpgVF1R5im1bdE5 b+kInqWPzu2oL3jy4vrW9TX6d6+JXXj6tcljdY2aSMAt6UtTde4ErF9TGpT1T0UuY/Z+ldNW D1i2HVxQWLTfZs3/xaL/f1kFsNv9E9O1u3ig82gTy8Ppz56HP3Ra6xN5uuVWVrBPvMQFtSdt FTXLpnKsZbZyaOdnirWYuL9KQomlOCPRUIu5qDgRAB/IlZ9UAwAA Archived-At: Subject: [L2sm] R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 11:22:56 -0000 SGkgSm9lbCwNClRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXchIEl0IGlzIHZlcnkg dXNlZnVsLg0KTXkgYW5zd2VycyBpbmxpbmUgdGFnZ2VkIGFzIFtHRl0NCg0KQmVzdCBSZWdh cmRzLA0KDQpHaXVzZXBwZQ0KDQotLS0tLU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6 IEpvZWwgSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dIA0KSW52aWF0bzog ZG9tZW5pY2EgMjUgZmViYnJhaW8gMjAxOCAwMjowMA0KQTogZ2VuLWFydEBpZXRmLm9yZw0K Q2M6IGwyc21AaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbDJzbS1sMnZw bi1zZXJ2aWNlLW1vZGVsLmFsbEBpZXRmLm9yZw0KT2dnZXR0bzogR2VuYXJ0IHRlbGVjaGF0 IHJldmlldyBvZiBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0wOA0KDQpS ZXZpZXdlcjogSm9lbCBIYWxwZXJuDQpSZXZpZXcgcmVzdWx0OiBPbiB0aGUgUmlnaHQgVHJh Y2sNCg0KSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFm dC4gVGhlIEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwg SUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVU RiBDaGFpci4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQg c2hlcGhlcmQgb3IgQUQgYmVmb3JlIHBvc3RpbmcgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJh ZnQuDQoNCkZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCg0K PGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2dlbi93aWtpL0dlbkFydGZhcT4uDQoNCkRv Y3VtZW50OiBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0wOA0KUmV2aWV3 ZXI6IEpvZWwgSGFscGVybg0KUmV2aWV3IERhdGU6IDIwMTgtMDItMjQNCklFVEYgTEMgRW5k IERhdGU6IDIwMTgtMDMtMjYNCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxOC0wNC0wNQ0KDQpT dW1tYXJ5OiBHaXZlbiB0aGUgbnVtYmVyIG9mIE1ham9yIGFuZCBtaW5vciBpc3N1ZXMsIHRo aXMgZG9jdW1lbnQgaXMgbm90IHlldCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYSBQcm9w b3NlZCBTdGFuZGFyZCBSRkMuDQoNCk1ham9yOg0KICAgIEludHJvZHVjdGlvbjogVGhlIHBo cmFzaW5nIG9mICJhbiBhYnN0cmFjdCBtb2RlbCIsICJ0aGlzIG1vZGVsIGlzIG5vdCBhDQog ICAgY29uZmlndXJhdGlvbiBtb2RlbC4uLiIgY3JlYXRlcyBzb21lIGNvbmZ1c2lvbiBpbiB0 aGUgcmVhZGVyIGFzIHRvIHdoZXRoZXINCiAgICB0aGlzIG1vZGVsIHJlcHJlc2VudCB0aGUg Y3VycmVudCBzdGF0ZSBvZiBzZXJ2aWNlIGRlbGl2ZXlyLCB0aGUgZGVzaXJlZA0KICAgIHN0 YXRlIG9mIHNlcnZpY2UgZGVsaXZlcnkgKHdoaWNoIHdvdWxkIGRyaXZlIGNvbmZpZ3VyYXRp b24pIG9yIGJvdGguIA0KICAgIFBsZWFzZSBjbGFyaWZ5Lg0KDQpbR0ZdOiBPayBJIHVuZGVy c3RhbmQgYW5kIHdlIGNhbiBjbGFyaWZ5IHRoaXMgcG9pbnQgaW4gYSBuZXcgcmV2aXNpb24u IFRoaXMgbW9kZWwgaXMgdXNlZCB0byBkZXNjcmliZSBzZXJ2aWNlIGludGVudCBvciBzZXJ2 aWNlIHJlcXVpcmVtZW50cyBhbmQgY2hhcmFjdGVyaXN0aWMgYXNzb2NpYXRlZCB3aXRoIGNv bm5lY3Rpdml0eSBzZXJ2aWNlLiBDb25zaWRlciB0aGF0IGFsc28gaW4gUkZDIDgyOTkgKEwz U00pIHRoZXJlIGlzIHRoZSBzYW1lIHBocmFzaW5nLg0KDQogICAgVGhlICJ2YWxpZC1wcm92 aWRlci1pZGVudGlmaWVycycgZGlzdGluZ3Vpc2ggYmV0d2VlbiBjbG91ZC1pZGVudGlmaWVy IGFuZA0KICAgIHJlbW90ZS1jYXJyaWVyLWlkZW50aWZpZXIuICBJdCBpIHVuY2xlYXIgd2h5 IHRoZSBWUE4gc2VydmljZSBwcm92aWRlcg0KICAgIHNob3VsZCBrbm93IG9yIGNhcmUgd2hl dGhlciB0aGUgcmVtb3RlIHByb3ZpZGVyIGhlIGlzIGNvbm5lY3Rpbmcgd2l0aCBpcyBhDQog ICAgY2xvdWQgcHJvdmlkZXIsIGFuZCBhbm90aGVyIEwyIHNlcnZpY2UgcHJvdmlkZXIsIG9y IGJvdGguICBBbmQgaWYgaXQgaXMNCiAgICBib3RoLCB3aGljaCBpZGVudGlmaWVyIHNob3Vs ZCBiZSB1c2VkLg0KDQpbR0ZdOiBSZW1vdGUtY2FycnJpZXItaWRlbnRpZmllciBpcyB1c2Vk IGluIHRoZSBOTkkgY2FzZSwgc2VlIHRoZSBjb2RlIHdpdGhpbiBZQU5HIG1vZHVsZToNCuKA nA0KICAgICAgICAgICAgbGVhZiByZW1vdGUtY2Fycmllci1uYW1lIHsNCiAgICAgICAgICAg ICAgd2hlbiAiZGVyaXZlZC1mcm9tLW9yLXNlbGYoLi4vLi4vLi4vc2l0ZS12cG4tZmxhdm9y LCIrDQogICAgICAgICAgICAgICAgIidsMnZwbi1zdmM6c2l0ZS12cG4tZmxhdm9yLW5uaScp IiB7DQogICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICJS ZWxldmFudCB3aGVuIFNpdGUgdnBuIGZsYXZvciBpcw0KICAgICAgICAgICAgICAgICAgc2l0 ZS12cG4tZmxhdm9yLW5uaS4iOw0KICAgICAgICAgICAgICB9DQoNCuKAnQ0KW0dGXTogSW4g dGhlIE5OSSBjYXNlLCB0aGUgY3VycmVudCBWUE4gU2VydmljZSBwcm92aWRlciBjYW4gY29u bmVjdCB0byBhbm90aGVyIEwyVlBOIG9yIERhdGEgQ2VudGVyIG5ldHdvcmsgb3IgQ2xvdWQg UHJvdmlkZXLigJlzIG5ldHdvcmsuIFBsZWFzZSBhbHNvIHNlZSBzZWN0aW9uIDUuMTYgZm9y IE5OSSBzdXBwb3J0IGRldGFpbHMuDQpZb3UgYXJlIHJpZ2h0LCB0aGUgVlBOIHNlcnZpY2Ug cHJvdmlkZXIgZG9lc27igJl0ICBjYXJlIHdoZXRoZXIgdGhlIHJlbW90ZSBwcm92aWRlciBp cyBhIGNsb3VkIHByb3ZpZGVyIG9yIEwyVlBOIHNlcnZpY2UgcHJvdmlkZXIuIFNvIHJlbW90 ZSBjYXJyaWVyLW5hbWUgZG9lc27igJl0IG5lZWQgdG8gZGlzdGluZ3Vpc2ggY2xvdWQgcHJv dmlkZXIgb3IgTDJWUE4gc2VydmljZSBwcm92aWRlciwgaWYgeW91IGJlbGlldmUgd2Ugc2hv dWxkIGRpc3Rpbmd1aXNoIHdlIGNhbiByZW1vdmUgcmVtb3RlIGNhcnJpZXIgbmFtZSwgd2Ug dGhpbmsgaXQgYWRkIGNvbXBsZXhpdHkgYW5kIG5vdGUgdGhhdCByZW1vdGUgY2FycmllciBu YW1lIGlzIGFuIG9wdGlvbmFsIHBhcmFtZXRlci4gUmVnYXJkaW5nIGNsb3VkLWlkZW50aWZp ZXIgZGVmaW5lZCB3aXRoaW4g4oCcdmFsaWQtcHJvdmlkZXItaWRlbnRpZmllcnPigJ0sIGNs b3VkLWlkZW50aWZpZXIgaXMgb25seSBhcHBsaWVkIHRvIHB1YmxpYyBjbG91ZCBvciBpbnRl cm5ldCBhY2Nlc3MsIHdoaWxlIHJlbW90ZS1jYXJyaWVyLW5hbWUgY2FuIGJlIHJlZmVycmVk IHRvIHByaXZhdGUgY2xvdWQvZGF0YSBjZW50ZXIgb3IgYW5vdGhlciBMMlZQTi4gVGhhdOKA mXMgd2h5IHdlIHVzZSBjbG91ZC1pZGVudGlmaWVyIHdpdGhpbiBjbG91ZC1hY2Nlc3MuDQoN CiAgICBBbHNvLCBpdCBpcyB2ZXJ5IHVuY2xlYXIgaG93IHRoZXNlIGlkZW50aWZpZXJzIHdp bGwgYmUgdXNlZC4gIFRoZXkNCiAgICBwcmVzdW1hYmx5IGFyZSBuYW1lcyBvZiBzb21ldGhp bmcuICBCdXQgb2Ygd2hhdD8gIEFzIGtub3duIHRvIHdob20/IA0KICAgIERlcml2ZWQgZnJv bSB3aGVyZT8gIEkgZG8gbm90IHNlZSBob3cgYSBwcm92aWRlciAvIGN1c3RvbWVyIHBhaXIg dXNpbmcgdGhpcw0KICAgIG1vZGVsIHdpbGwga25vdyB3aGF0IHZhbHVlcyB0byB1c2UgZm9y IHRoaXMuICANCg0KW0dGXTogV2UgdGhpbmsgb25lIGlzIG5hbWUgb2YgdGhlIHB1YmxpYyBj bG91ZCBvciBpbnRlcm5ldCBhY2Nlc3MsIHRoZSBvdGhlciBpcyBjYXJyaWVyIG5hbWUsIHRo ZXkgYXJlIGRpZmZlcmVudC4gV2UgYXNzdW1lIGluIHRoaXMgbW9kZWwgdG8gdXNlIOKAnGNs b3VkIGFjY2Vzc+KAnSB0byBnZXQgYWNjZXNzIHRvIHB1YmxpYyBjbG91ZCBvciBpbnRlcm5l dCwgd2UgdXNlIOKAnE5OSeKAnSB0byBnZXQgYWNjZXNzIHRvIHByaXZhdGUgY2xvdWQsIGRh dGEgY2VudGVyIG9yIGFub3RoZXIgTDJWUE4sIHRoZXJlZm9yZSBDbG91ZCBpZGVudGlmaWVy IHNob3VsZCBiZSBrbm93biBieSBib3RoIHRoZSBjdXJyZW50IEwyVlBOIFNlcnZpY2UgcHJv dmlkZXIgYW5kIHRoZSBjdXN0b21lci4gUmVtb3RlIENhcnJpZXIgbmFtZSBpbiBOTkkgY2Fz ZSBzaG91bGQgYmUga25vd24gYnkgdGhlIGN1cnJlbnQgTDJWUE4gc2VydmljZSBwcm92aWRl ciBpdCBpcyBjb25uZWN0aW5nLg0KDQpFdmVuIGlmIHRoZSBpbnRlbnRpb24gaXMgdGhhdA0K ICAgIHRoZXNlIGJlIG5hbWVzIG1hZGUgYXZhaWxhYmxlIGJ5IHRoZSBwcm92aWRlciBieSBl eHRlcm5hbCBtZWFucywgdGhlIFlBTkcNCiAgICBtb2RlbCBuZWVkcyB0byBzYXkgdGhhdCBp ZiBpdCBpcyB0byBiZSB1c2FibGUuIEkgZGlkIGV2ZW50dWFsbHkgZmluZCBzb21lDQogICAg ZXhwbGFuYXRpb24gaW4gc2VjdGlvbiA1LjE1LiAgQXQgdGhlIHZlcnkgbGVhc3QgYSBmb3J3 YXJkIHJlZmVyZW5jZSBpcw0KICAgIG5lZWRlZC4gIEkgdGhpbmsgbW9yZSBleHBsYW5hdGlv biBvZiB3aGF0IHRoZXNlIHRoaW5ncyBuYW1lcyB3b3VsZCBhbHNvDQogICAgaGVscC4NCg0K W0dGXTogT2sNCg0KICAgIFRoZSB1c2Ugb2YgZGlmZmVyZW50IHNldHMgb2Ygd2hhdCByZWFk IGxpa2Ugc2VydmljZSB0eXBlcyAoaXMgY2xvdWQgYWNjZXNzDQogICAgYSBzZXJ2aWNlIHR5 cGU/ICBJcyByZW1vdGUtYWNjZXNzIGEgc2VydmljZSB0eXBlPykgYW5kIHRoZSB1c2Ugb2Yg c2ltaWxhcg0KICAgIGJ1dCBub3QgdGhlIHNhbWUgdGVybWlub2xvZ3kgYmV0d2VlbiBwcm92 aWRlciBkZXNjcmlwdGlvbnMsIHNlcnZpY2UgdHlwZXMsDQogICAgYW5kIHNlcnZpY2UgdG9w b2xvZ2llcywgbGVhdmVzIHRoZSByZWFkZXIgVkVSWSBjb25mdXNlZC4gIFBsZWFzZSwgZG8g bm90DQogICAgdXNlIHRoZSBzYW1lIHRlcm0gZm9yIGtpbmRzIG9mIHByb3ZpZGVycywga2lu ZHMgb2Ygc2VydmljZXMsIGFuZCBraW5kcyBvZg0KICAgIHRvcG9sb2dpZXMgdW5sZXNzIHRo ZSBuYW1lcyBhcmUgZnVsbHkgY29uZ3J1ZW50ICh3aGljaCB0aGV5IGN1cnJlbnRseSBhcmUN CiAgICBub3QuKQ0KDQpbR0ZdOiBObywgdGhlIHNlcnZpY2UtdHlwZSBpcyBvbmx5IHJlZmVy cmVkIHRvIEwyVlBOIHNlcnZpY2UgdHlwZXMuDQoNCiAgICAgSXQgaXMgdW5jbGVhciB3aHkg IkNsb3VkLUFjY2VzcyIgaXMgbGlzdGVkIGluIHRoZSBWUE4gU2VydmljZSBPdmVydmlldw0K ICAgICAoc2VjdGlvbiA1LjIpLCAgb3IgZXZlbiB3aHkgQ2xvdWQgQWNjZXNzIGlzIGFueSBk aWZmZXJlbnQgZnJvbSBhbnkgb3RoZXINCiAgICAgYWNjZXNzLiAgUHJlc3VtYWJseSwgdGhl IGN1c3RvbWVyIGNhbiBjb25maWd1cmUgYXV0aG9yaXphdGlvbiBmb3IgdGhlDQogICAgIHNp dGVzIHRvIG1lZXQgaGlzIG5lZWRzLiAgIEFueSB0b3BvbG9naWNhbCBlZmZlY3Qgd291bGQg YmUgY2FwdHVyZSBpbg0KICAgICA1LjIuMiBvbiBWUE4gU2VydmljZSBUb3BvbG9neSwgbm90 IGFzIGEgZGlmZmVyZW50IGtpbmQgb2YgVlBOIFNlcnZpY2UuDQoNCltHRl06IEl0IGlzIGlu dGVuZGVkIHRvIGxpc3Qg4oCcQ2xvdWQtQWNjZXNz4oCdIGluIFZQTiBzZXJ2aWNlIE92ZXJ2 aWV3LCBzaW5jZSDigJxDbG91ZC1BY2Nlc3PigJ0gaXMgYXBwbGljYWJsZSB0byBhbGwgdGhl IHNpdGVzIHJhdGhlciB0aGFuIHNpdGUtbGV2ZWwgcGFyYW1ldGVyLiBOb3RlIHRoYXQgdGhp cyBtb2RlbCBpcyBhIFZQTiBtb2RlbCwgc28gcHVibGljIENsb3VkIGFuZCBwcml2YXRlIGNs b3VkLCBkYXRhY2VudGVyIGFyZSBub3QgcGFydCBvZiBWUE4gdGhlcmVmb3JlIHdlIHNlcGFy YXRlIENsb3VkIEFjY2VzcyBmcm9tIE5ldHdvcmsgQWNjZXNzIHdpdGhpbiBWUE4uIFZQTiBz ZXJ2aWNlIHRvcG9sb2d5IGRlc2NyaWJlIGhvdyBzaXRlIHdpdGhpbiBWUE4gYXJlIGNvbm5l Y3RlZCB0byBlYWNoIG90aGVyIHJhdGhlciB0aGFuIGRlc2NyaWJlIGhvdyBWUE4gaXMgY29u bmVjdGluZyB0byBwdWJsaWMgQ2xvdWQuDQoNCiAgICAgUmVnYXJkaW5nIFZQTiBTZXJ2aWNl IFR5cGUgKHN2Yy10eXBlKSB0aGUgdGV4dCBpbiBzZWN0aW9uIDUuMiBzYXlzIHRoYXQNCiAg ICAgdGhpcyBpcyBleHBsaWNpdGx5IGZvciB0aGUgbG9jYWwgYWRtaW5pc3RyYXRvciB0byB1 c2UgdG8gZmxleGlibHkgZGVmaW5lDQogICAgIHRoZSBDUE4gc2VydmljZSB0eXBlLiAgU2Vj dGlvbiA1LjIuMSB0aGVuIHNheXMgdGhhdCBpdCBoYXMgb25lIG9mIHNpeA0KICAgICB2YWx1 ZXMsIGltcGx5aW5nIHRoYXQgaWYgb3RoZXIgdmFsdWVzIGFyZSBuZWVkZWQgdGhleSB3aWxs IG5lZWQgdG8gYmUNCiAgICAgZGVmaW5lZCBpbiBhbiBleHRlbnNpb24gdG8gdGhlIG1vZGVs LiAgSWYgdGhleSBhcmUgZm9yIG1vZGVsIHVzZSwgYW5kIGZvcg0KICAgICBtb2RlbCBleHRl bnNpb24sIHRoZW4gdGhleSBzaG91bGQgYmUgdXNpbmcgYSB0d28tbGV2ZWwgaWRlbnRpdHkg KHdoZXJlIHRoZQ0KICAgICBzZWNvbmQgbGV2ZWwgcHJvdmlkZXMgdGhlIHBvc3NpYmxlIHZh bHVlcy4pDQoNCltHRl06IFR3byBsZXZlbCBpZGVudGl0eSBoYXMgYWxyZWFkeSBiZWVuIGFj aGlldmVkIGJ5IHVzaW5nIGlkZW50aXR5IGRhdGEgdHlwZSBpbiB0aGlzICBtb2RlbCwgU2lu Y2Ugd2UgaGF2ZSBkZWZpbmVkIGJhc2UgaWRlbnRpdHkgaW4gdGhlIG1vZGVsLCBvdGhlciBp ZGVudGl0eSBjYW4gYmUgZXh0ZW5zaW9uIG9mIHRoZSBiYXNlIGlkZW50aXR5LiBTZWUgdGhl IGNvZGUgaW4gdGhlIG1vZHVsZToNCuKAnA0KDQogIGlkZW50aXR5IHNlcnZpY2UtdHlwZSB7 DQogICAgZGVzY3JpcHRpb24NCiAgICAgICJCYXNlIElkZW50aXR5IG9mIHNlcnZpY2UgdHlw ZS4iOw0KICB9DQoNCiAgIGxlYWYgc3ZjLXR5cGUgew0KICAgICAgdHlwZSBpZGVudGl0eXJl ZiB7DQogICAgICAgIGJhc2Ugc2VydmljZS10eXBlOw0KICAgICAgIH0NCiAgICAgZGVmYXVs dCAidnB3cyI7DQrigJ0NCg0KICAgIEdpdmVuIHRhaHQgdGhpcyBpcyBhIG1vZGVsIGZvciBw cm92aWRlcnMgYW5kIGN1c3RvbWVycyB0byB1c2UgdG8NCiAgICBjb2xsYWJvcmF0ZSBvbiB0 aGUgY29uZmlndXJhdGlvbiBvZiBWUE5zLCBJIHdvdWxkIGV4cGVjdCB0byBzZWUgc29tZQ0K ICAgIGRpc2N1c3Npb24gb2YgaG93IHRoaXMgaXMgdXNlZCBvbiB0aGUgcHJvdmlkZXIgZW5k IHNvIGFzIHRvIGNvbGxhYm9yYXRlDQogICAgd2l0aCBtdWx0aXBsZSBjdXN0b21lcnMsIHdv cmtpbmcgd2l0aCBlYWNoIG9ubHkgYWJvdXQgdGhlaXIgVlBOcy4gIEkgbWlzc2VkDQogICAg YW55IHN1Y2ggZGVzY3JpcHRpb24uDQoNCltHRl06IFNpbWlsYXIgdG8gTDNTTSAoUkZDIDgy OTkpLCB1bmRlciBWUE4tc2VydmljZXMsIHRoZSBjdXN0b21lci1uYW1lIGlzIGRlZmluZWQg YW5kIGFzc29jaWF0ZWQgd2l0aCBlYWNoIFZQTi1zZXJ2aWNlLiBVbmRlciBTaXRlcywgVlBO LWF0dGFjaG1lbnQgaXMgZGVmaW5lZCB0byBkZXNjcmliZSB3aGljaCBzaXRlIGlzIGF0dGFj aGVkIHRvIHdoaWNoIFZQTi4gVGhlbiB3ZSBjYW4gaGF2ZSBTaXRlIEEsIFNpdGUgQiwgU2l0 ZSBDLCBTaXRlIEQsIFNpdGUgQSwgU2l0ZSBCLCBTaXRlIEMgYXJlIGF0dGFjaGVkIHRvIFZQ Ti1BLCBTaXRlIEIsIFNpdGUgQyBhbmQgU2l0ZSBEIGFyZSBhdHRhY2hlZCB0byBWUE4gQiAo aS5lLiwgdnBuLWlkIGlzIHNldCB0byBWUE4tQiksIFZQTiBBIGFuZCBWUE4gQiBiZWxvbmcg dG8gdGhlIHNhbWUgcHJvdmlkZXIsIHRoZW4gb25lIHByb3ZpZGVyIGVuZCBjYW4gdGFsa3Mg dG8gdHdvIGN1c3RvbWVycy4NCg0KTWlub3I6DQogICAgSSB3b3VsZCBoYXZlIGV4cGVjdGVk IHNvbWUgcmVmZXJlbmNlIHRvIHRoZSBNRUYgRXRoZXJuZXQgc2VydmljZQ0KICAgIGRlZmlu aXRpb25zIGFuZCBNRUYgZGVmaW5lZCBwYXJhbWV0ZXJzIG9mIGludGVyZXN0LCBhcyBpbmR1 c3RyeSB1c2FnZSBzZWVtcw0KICAgIHRvIHJlZmxlY3QgdGhvc2UgYXMgdGhlIGNvbW1vbiBi YXNpcyBmb3IgTDIgc2VydmljZXMuICBJIHVkbmVyc3RhbmQgdGhhdA0KICAgIHRoaXMgbW9k ZWwgaXMgbm90IG1hbmRhdGVkIHRvIGNvbmZvcm0gdG8gdGhlIE1FRiBGb3J1bSB3b3JrLiAg SSB3b3VsZA0KICAgIGV4cGVjdCBzb21lIGRpc2N1c3Npb24gb2YgdGhlIHJlbGF0aW9uc2hp cC4gIFRoaXMgbWF5IGJlIGEgZGVsaWJlcmF0ZQ0KICAgIHdvcmtpbmcgZ3JvdXAgY2hvaWNl LCBhcyBJIHNlZSBpbiB0ZWggY2hhbmdlIGxvZyB0aGF0IHRoZXJlIHdlcmUgcmVmZXJlbmNl cw0KICAgIHRvIEVWQyBhbmQgT1ZDLiAgSXQgc3RpbGwgc2VlbXMgdGhhdCBpdCB3b3VsZCBo ZWxwIHJlYWRlcnMgdG8gaGF2ZQ0KICAgIHNvbWV0aGluZy4NCg0KW0dGXTogV2UgdHJpZWQg dG8gY29vcGVyYXRlIGFuZCB3ZSBwYXJ0aWNpcGF0ZSBhbHNvIHRvIHNvbWUgTUVGIGNvbmZl cmVuY2UgY2FsbHMgYnV0IHdlIG5vdGljZWQgdGhhdCB0aGVyZSBhcmUgc29tZSBkaWZmZXJl bmNlcyBpbiBwYXJ0aWN1bGFyIGJldHdlZW4gdGhlIE1FRiBMU08gKExpZmVjeWNsZSBTZXJ2 aWNlIE9yY2hlc3RyYXRpb24pIGFyY2hpdGVjdHVyZSBhbmQgdGhlIElFVEYgU0ROIGFyY2hp dGVjdHVyZS4NCg0KICAgIFRoZSBzdHJ1Y3R1cmUgb2YgdGhlIHZwbi1wcm9maWxlLWNmZyBn cm91cGluZyBzZWVtcyB2ZXJ5IHN0cmFuZ2UuICBJdCBpcyBhDQogICAgc2VyaWVzIG9mIDQg bGlzdHMsIGVhY2ggb2Ygd2hpY2ggb25seSBjb250YWlucyBhbiBpZCBsZWFmLiAgRmlyc3Qs IGFuZCBsZXNzDQogICAgaW1wb3J0YW50LCB0aGF0IG1ha2VzIHRoZW0gbGVhZi1saXN0cywg ZG9lc24ndCBpdD8gIE9yIGlzIGl0IHN0cnVjdHVyZWQNCiAgICB0aGlzIHdheSB3aXRoIG5v IGV4cGxhbmF0aW9uIHRvIGFsbG93IGZvciB1bmV4cGxhaW5lZCB0eXBlIHNwZWNpZmljDQog ICAgYXVnbWVudGF0aW9uPw0KDQpbR0ZdOiBZZXMsIGl0IGFsbG93cyBhdWdtZW50YXRpb24s IHlvdSBtYXkgYWRkIHNvbWUgbmV3IHBhcmFtZXRlcnMgdW5kZXIgZWFjaCBsaXN0Lg0KDQog SWYgbm8gQXVnbWVudGF0aW9uIGlzIG5lZWRlZCwgaXQgd291bGQgc2VlbSBtb3JlIGdlbmVy YWwgdG8NCiAgICB1c2UgYSB0d28gbGV2ZWwgaWRlbnRpdHkgKGlkZW50aXR5IGJhc2VkIGVu dW1lcmF0aW9uKSBmb3IgdGhlIHR5cGUgb2YgVlBOcywNCiAgICB1c2UgYSBzaW5nbGUgbGlz dCBjb250YWluaW5nIGFuIGlkIGFuZCBhIHR5cGUgZmllbGQsIHdoZXJlIGJvdGggYXJlIGtl eXMNCiAgICBhbmQgdGhlIHR5cGUgZmllbGQgdXNlcyB0aGUgZW51bWVyYXRpb24uICBUaGlz IHdvdWxkIHN0aWxsIGVhc2lseSBhbGxvdyBmb3INCiAgICBhZGRpbmcgbmV3IHR5cGVzLCBh bmQgd291bGQgYXZvaWQgdXNpbmcgdGhlIHNhbWUgbGVhZiBuYW1lIGluIGRpZmZlcmVudA0K ICAgIGxpc3RzICh3aGljaCB3aGlsZSBsZWdhbCBvZnRlbiBsZWFkcyB0byBlcnJvcnMuKSBJ ZiB3ZSByZWFsbHkgbmVlZCBmb3VyDQogICAgZGlzdGluY3QgbGlzdHMsIHRoZW4gSSB3b3Vs ZCByZWNvbW1lbmQgY2hhbmdpbmcgdGhlIG5hbWVzIG9mIHRoZSBpZCBmaWVsZA0KICAgIHNv IGVhY2ggb25lIGhhcyBhIHVuaXF1ZSBsZWFmIG5hbWUgKGNsb3VkLWlkLCBxb3MtaWQsIGJm ZC1pZCwgLi4uKQ0KDQpbR0ZdOiBXZSBjb3VsZCwgYnV0IHRoZXNlIGxlYWYgYXJlIGxvY2F0 ZWQgaW4gZGlmZmVyZW50IHBhdGhzLCB0aGVyZWZvcmUgdW5pcXVlIGxlYWYgbmFtZSB1bmRl ciBkaWZmZXJlbnQgcGFyZW50IG5vZGUgZG9lc27igJl0IG1hdHRlci4NCg0KIEl0DQogICAg YXBwZWFycyB0aGF0IHRoZSBwdXJwb3NlIG9mIHRoaXMgbGlzdCBpcyB0byBiZSB1c2VkIGFz IHRhcmdldHMgZm9yDQogICAgbGVhZnJlZnMuICBBcyBzdWNoLCBpdCBkb2VzIG5vdCBzZWVt IHRoYXQgZGlzdGluY3QgbGlzdHMgYXJlIG5lZWRlZC4NCg0KW0dGXTogVG8gZ2V0IGNvbnNp c3RlbnQgd2l0aCBSRkM4Mjk5LCB3ZSBwcmVmZXIgdG8ga2VlcCBhcyBpdCBkb2VzLg0KDQog ICAgVGhlIHBsYWNlbWVudCBvZiBzZWN0aW9uIDUuMi4yLjEgKGFuZCB0aGUgcmVzdWx0aW5n IFlBTkcgb2JqZWN0cykgc2VlbXMNCiAgICBvZGQuICAiUm91dGUgVGFyZ2V0IEFsbG9jYXRp b24iIGlzIGEgbWVjaGFuaXNtLCBub3QgYSB0b3BvbG9neS4gIEl0IGlzIG5vdA0KICAgIGV2 ZW4gbGlzdGVkIGluIHRoZSBvcHRpb25zIG1lbnRpb25lZCBpbiA1LjIuMi4NCg0KW0dGXTog Um91dGUgVGFyZ2V0IEFsbG9jYXRpb24gc2VjdGlvbiBpcyBWUE4gc2VydmljZSB0b3BvbG9n eSByZWxldmFudCBzaW5jZSBSb3V0ZSBUYXJnZXQgaXMgYWxsb2NhdGVkIGJhc2VkIG9uIHRo ZSByZXF1ZXN0ZWQgVlBOIHNlcnZpY2UgdG9wb2xvZ3kuIFNlZSBTZWN0aW9uIDUuMi4yLjEg Zm9yIG1vcmUgZGV0YWlscy4NCg0KICAgIFNlY3Rpb24gNS4yLjMgb24gQ2xvdWQgQWNjZXNz IHVzZXMgYSB2YXJpYW50IG9uIHRoZSB1bmZvcnR1bmF0ZSAiTVVTVCAuLi4NCiAgICBleGNl cHQgLi4uIE1BWSIgY29uc3RydWN0aW9uLiAgQXMgZmFyIGFzIEkgY2FuIHRlbGwsIHRoYXQg aXMgYSB2ZXJ5IG5pY2UNCiAgICBTSE9VTEQsIHdpdGggYW4gZXhwbGFuYXRpb24gb2Ygd2hl biB0aGUgU0hPVUxEIGRvZXMgbm90IGFwcGx5LiAgRXZlbiBpZg0KICAgIHRoaXMgaXMgbm90 IGZpeGVkLCB0aGUgaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIGhhdmluZyBhbiBleGNlcHRpb24g aGVyZSwgYW5kDQogICAgdGhlIHN0cmljdCByZXF1aXJlbWVudCAodXBwZXIgY2FzZSBNVVNU IHdpdGggbm8gZXhjZXB0aW9uKSBpbiBzZWN0aW9uIDUuMg0KICAgIG5lZWRzIHRvIGJlIGZp eGVkLg0KDQpbR0ZdOiBPaw0KDQogICAgU2VjdGlvbiA1LjMgb24gYSBTaXRlIE92ZXJ2aWV3 IGhhcyBhbiBpdGVtIGZvciAiTWFuYWdlbWVudCIgd2hpY2ggIkRlZmluZXMNCiAgICB0aGUg bW9kZWwgb2YgbWFuYWdlbWVudCBmb3IgdGhlIHNpdGUiLiAgSXQgaXMgY29tcGxldGVseSB1 bmNsZWFyIGZyb20gdGhpcw0KICAgIHRleHQgd2hhdCBpdCBpcyBpbnRlbmRlZCB0byBtZWFu LCBhbmQgdGhlIGV4YW1wbGUgZG9lcyBub3QgaGVscC4gKDUuMTEgaXMNCiAgICBiZXR0ZXIs IGJ1dCBzdGlsbCB2YWd1ZS4pDQoNCltHRl06IERlZmluZSB0aGUgbW9kZWwgb2YgbWFuYWdl bWVudCBmb3IgdGhlIHNpdGUgbWVhbnM6IHdobyBoYXMgb3duZXJzaGlwIG9mIENFIGRldmlj ZSwgd2hvIG1hbmFnZSBDRSBkZXZpY2U7IHRoaXMgd2lsbCBkZWNpZGUgdGhlIGJvdW5kYXJ5 IGJldHdlZW4gc2VydmljZSBwcm92aWRlciBhbmQgY3VzdG9tZXIuDQoNCiAgICBXaGVuIEkg cmVhY2hlZCB0aGUgbm90ZSBpbiBzZWN0aW9uIDUuMy4xIHRoYXQgYSBzaXRlIG1heSBoYXZl IG11bHRpcGxlDQogICAgbG9jYXRpb25zLCBJIHJlYWxpemVkIHRoYXQgSSBkaWQgbm90IHNl ZSBhbnl0aGluZyBleHBsaWNpdCBhcyB0byB3aGV0aGVyIGENCiAgICBzaXRlIGlzIGFzc3Vt ZWQgdG8gaGF2ZSBmdWxsIGludGVybmFsIGNvbm5lY3Rpdml0eSAoc28gdGhhdCBmcm9tIHRo ZSBwb2ludA0KICAgIG9mIHZpZXcgb2YgdGhlIFZQTiBhbnkgb2YgdGhlIGFjY2VzcyBsaW5r cyB0byB0aGUgc2l0ZSBhcmUgaW50ZXJjaGFuZ2VhYmxlLA0KICAgIG9yIGlmIGl0IGlzIGZ1 bGx5IG1lc2hlZCBidXQgdGhlcmUgbWF5IGJlIHByZWZlcmVuY2VzIGZvciBlbnRyYW5jZSBm b3INCiAgICBkaWZmZXJlbnQgZGlzdGluYXRpb25zLCBvciB3aGV0aGVyIHNpdGVzIG1heSBh Y3R1YWxseSBiZSBwYXJ0aXRpb25lZCwgd2hlcmUNCiAgICBvbmUgcGFydCBvZiBhIHNpdGUg aXMgb25seSByZWFjaGFibGUgZnJvbSBhbm90aGVyIHBhcnQgb2YgYSBzaXRlIGZpYSB0aGUN CiAgICBWUE4gKHRoZSB1c3VhbCBhc3N1bXB0aW9uIHdoZW4gdG9sZCB0aGF0IHRoZXJlIGFy ZSBtdWx0aXBsZSBsb2NhdGlvbnMgaW4gYQ0KICAgIHNpdGUpLiAgSSB0aGluayB0aGlzIHNo b3VsZCBiZSBjbGFyaWZpZWQuDQoNCltHRl06IFRoZSBzaXRlIG1heSBzdXBwb3J0IHNpbmds ZS1ob21lZCBvciBtdWx0aS1ob21lZC4gSW4gY2FzZSBvZiBtdWx0aS1ob21lZCwgdGhlIHNp dGUgY2FuIHN1cHBvcnQgbXVsdGlwbGUgc2l0ZS1uZXR3b3JrLWFjY2Vzc2VzLCB1bmRlciBl YWNoIHNpdGUtbmV0d29yay1hY2Nlc3MsIHZwbi1hdHRhY2htZW50IGlzIGRlZmluZWQgYW5k IGl0IHdpbGwgZGVzY3JpYmUgd2hpY2ggc2l0ZS1uZXR3b3JrLWFjY2VzcyBhc3NvY2lhdGVk IHdpdGggd2hpY2ggc2l0ZSB3aWxsIGNvbm5lY3QgdG8gd2hpY2ggdnBuLg0KDQogICAgSW4g c2VjdGlvbiA1LjUuMS4yIG9uIE11bHRpVlBOIGF0dGFjaG1lbnQsIHRoZSB0ZXh0IHNheXMg IlJlYWNoaW5nIFZQTiBBIG9yDQogICAgVlBOIGZyb20gdGhlIE5ldyBZb3JrIG9mZmljZSB3 aWxsIGJlIGRvbmUgdmlhIGRlc3RpbmF0aW9uLWJhc2VkIHJvdXRpbmcuIiANCiAgICBSb3V0 aW5nIHVzdWFsbHkgcmVmZXJzIHRvIHRoZSBoYW5kbGluZyBvZiBJUCBwYWNrZXRzLiAgSXMg dGhlIGludGVudGlvbg0KICAgIHRoYXQgdGhpcyBkaXN0aW5jdGlvbiBpcyBiYXNlZCBvbiBJ UCBkZXN0aW5hdGlvbiBldmVuIHRob3VnaCB3ZSBhcmUNCiAgICBwcm92aWRpbmcgYW4gTDIg c2VydmljZT8gIElzIHRoZSBpbnRlbnRpb24gdGhhdCBNQUMgYWRkcmVzc2VzIGFyZSB1bmlx dWUNCiAgICBhY3Jvc3MgdGhlIHR3byBWUE5zLCBhbmQgdGhlIGJyaWRnaW5nIHRhYmxlcyB3 aWxsIGtub3cgd2hpY2ggVlBOIGNvbnRhaW5zDQogICAgd2hpY2ggZGVzdGluYXRpb25zPyAg SWYgdGhlIGxhdGVyIGlzIHRoZSBpbnRlbnRpb24sIGhvdyBkb2VzIHRoYXQgaW50ZXJhY3QN CiAgICB3aXRoIEIvVS9NIGZyYW1lcz8NCg0KW0dGXTogVGhlIHVzZXIgY2FuIHVzZSBhIHRh cmdldC1zaXRlcyB0byBpZGVudGlmeSB0aGUgZGVzdGluYXRpb24gb2YgYSBmbG93IHJhdGhl ciB0aGFuIHVzaW5nIGRlc3RpbmF0aW9uIGFkZHJlc3Nlcy4gSW4gc29tZSBvdGhlciBjYXNl LCB0aGUgdXNlciBjYW4gdXNlIFZQTi1pZCBjb21iaW5pbmcgd2l0aCBNQUMgYWRkcmVzcyB0 byBpZGVudGlmeSB0aGUgZGVzdGluYXRpb24gb2YgYSBmbG93LiBUaGlzIGhhcyBiZWVuIHNw ZWNpZmllZCBpbiBzZWN0aW9uIDUuMTAuMi4xLg0KDQogICAgIEluIHNlY3Rpb24gNS41LjIu MiBvbiBzaXRlIHBvbGljeSwgdGhlIHRleHQgYXBwZWFycyB0byBiZSBhdHRlbXB0aW5nIHRv DQogICAgIGFuc3dlciB0aGUgcXVlc3Rpb24gb2Ygd2hpY2ggZGVzdGluYXRpb25zIGluIGEg c2l0ZSBzaG91bGQgYmUgcmVhY2hhYmxlDQogICAgIG92ZXIgKHBvc3NpYmx5IHNob3VsZCBo YXZlIHJlYWNoYWJpbGl0eSB0bykgd2hpY2ggVlBOcy4gIEl0IGRvZXMgdGhpcyB2aWENCiAg ICAgYSAibGFuIiB0YWcuICBUaGUgbWVhbmluZyBvZiB0aGlzIHRhZyBpcyB1bmNsZWFyLiAg UmVhZGluZyBiZXR3ZWVuIHRoZQ0KICAgICBsaW5lcywgdGhpcyBhcHBlYXJzIHRvIGJlIGlu dGVuZGVkIHRvIHNheSB0aGF0IHRoZSBzZWdyZWdhdGlvbiBpcyBvbiB0aGUNCiAgICAgYmFz aXMgdmxhbiB0YWcgKGFsdGhvdWdoIHRoZSBzdHJpbmcgaXMgImxhbiIgbm90ICJ2bGFuIiBt dWNoIGxlc3MgInZsYW4NCiAgICAgdGFnIi4pICBpZiB0aGUgaW50ZW50aW9uIGlzIHRoYXQg cG9saWN5IGlzIG9uIHRoZSBiYXNpcyBvZiB2bGFuLCBpdCBpcw0KICAgICB1bmNsZWFyIGhv dyB0aGlzIHJlbGF0ZXMgdG8gdGhlIGFzc2VydCBpbiA1LjUuMS4yIHRoYXQgc2VsZWN0aW9u IGlzIG9uIHRoZQ0KICAgICBiYXNpcyBvZiBkZXN0aW5hdGlvbiBhZGRyZXNzLg0KDQpbR0Zd OiBTZWN0aW9uIDUuMTAuMi4xIGluc3RlYWQgb2Ygc2VjdGlvbiA1LjUuMS4yIGFuc3dlciB5 b3VyIHF1ZXN0aW9uLiBTaXRlIHBvbGljeSBqdXN0IGRlc2NyaWJlIHdoaWNoIHNpdGUgaXMg YXR0YWNoZWQgdG8gd2hpY2ggdnBuLCBpbiBtb3JlIGdyYW51bGFyaXR5IGNhc2UsIGl0IGRl c2NyaWJlIHdoaWNoIGxhbiBmcm9tIHdoaWNoIHNpdGUgaXMgYXR0YWNoZWQgdG8gd2hpY2gg VlBOLg0KDQogICAgU2VjdGlvbiA1LjYgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCBwYXJhbWV0 ZXJzIGFuZCBjb25zdHJhaW50cyBhcmUgZGlmZmVyZW50DQogICAgdGhpbmdzLiAgU2V2ZXJh bCBvZiB0aGUgc3Vic2VjdGlvbnMgb2YgNS42IHN1Y2ggYXMgYWNjZXNzLXR5cGUgc2VlbSB0 bw0KICAgIGluZGljYXRlIHRoYXQgaW5mb3JtYXRpb24gbWF5IGJlIGVpdGhlciBhIHBhcmFt ZXRlciBvciBhIGNvbnN0cmFpbnQuICBHaXZlbg0KICAgIHRoYXQgdGhlIGRpZmZlcmVuY2Ug c2VlbXMgdG8gYmUgYmV0d2VlbiBhIGN1c3RvbWVyIGhpbnQgYW5kIGEgY3VzdG9tZXINCiAg ICByZXF1aXJlbWVudCwgaG93IGNhbiBzb21ldGhpbmcgYmUgYm90aD8NCg0KW0dGXTogTm8N Cg0KICAgIFNlY3Rpb24gNS4xNyBoYXMgYSBzaG9ydCBwYXJhZ3JhcGggaW4gdGhlIG1pZGRs ZSB0aGF0IHVzZXMgdGhlIHRlcm0gT1ZDDQogICAgdGhhdCBpcyBub3Qgb3RoZXJ3aXNlIHVz ZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KW0dGXTogR29vZCBjYXRjaCwgVGhhbmtzISB3ZSB3 aWxsIGZpeCB0aGlzLg0KDQogICAgV2h5IGRvIHRoZSBleGFtcGxlcyBpbiBzZWN0aW9uIDcg aW5jbHVkZSBxb3MtcHJvZmlsZS1pZGVudGlmaWVycyB3aGVuIHRoZQ0KICAgIGRlc2NyaXB0 aW9uIGRvZXMgbm90IGluY2x1ZGUgYW55IHJlZmVyZW5jZSB0byBtdWx0aXBsZSBRb1MgYmVo YXZpb3JzLCBhbmQNCiAgICBub3RoaW5nIGluIHRoZSBleGFtcGxlIG1ha2VzIHVzZSBvZiB0 aGUgZGVmaW5lZCBpZGVudGlmaWVycz8NCg0KW0dGXTogTm90ZSB0aGF0IFFvUyBwYXJhbWV0 ZXIgZGVmaW5lZCB1bmRlciBzaXRlIGlzIGFuIG9wdGlvbmFsIHBhcmFtZXRlci4gRm9yIHNp bXBsaWNpdHksIFFvUyBiZWhhdmlvcnMgYXJlIG5vdCBpbmNsdWRlZCBpbiB0aGUgRXhhbXBs ZS4NCg0KRWRpdG9yaWFsOg0KICAgIFRoZSB3b3JkaW5nIGF0IHRoZSBmcm9udCBvZiBzZWN0 aW9uIDUuMi41IGNvdWxkIHVzZSB0dW5pbmcuICBJdCBjdXJyZW50bHkNCiAgICBzYXlzICJJ ZiBGcmFtZSBEZWxpdmVyeSBTZXJ2aWNlIHN1cHBvcnQgaXMgcmVxdWlyZWQuLi4iICBJdCBz ZWVtcyB0byBtZQ0KICAgIHRoYXQgYnkgZGVmaW5pdGlvbiBhbGwgTDJWUE5zIHJlcXVpcmUg c3VwcG9ydCBmb3IgZGVsaXZlcnkgb2YgTDIgZnJhbWVzLiANCiAgICBUaGlzIHNlZW1zIGlu c3RlYWQgdG8gYmUgYWJvdXQgcGFyYW1ldGVycyBmb3IgaGFuZGxpbmcgQlVNIChCcm9hZGNh c3QgLw0KICAgIFVua293biAvIE11bHRpY2FzdCkgZGVsaXZlcnkuICBJZiBzbywgdGhpcyBz aG91bGQgYmUgbmFtZWQgc3VpdGFibHkuICBJdA0KICAgIHdvdWxkIGFsc28gYmUgaGVscGZ1 bCBpZiB0aGlzIHdlcmUgZXhwbGljaXRseSByZWxhdGVkIHRvIHRoZSBzdXBwb3J0DQogICAg cGFyYW1ldGVyIGluIDUuMTAuMy4NCg0KICAgIFNlY3Rpb24gNS4zLjIgcmVmZXJzIHRvIHRo ZSAiYmVhcmVyIiBwYXJhbWV0ZXJzIGFzICJiZWxvdyBsYXllciAyIi4gDQogICAgU2VjdGlv biA1LjMuMi4xIG9uIEJlYXJlciByZWZlcnMgdG8gaXQgYXMgImJlbG93IGxheWVyIDMiLiAg SSBwcmVzdW1lIHRoYXQNCiAgICBzaG91bGQgYmUgImJlbG93IGxheWVyIDIiPw0KDQogICAg SW4gU2VjdGlvbiA1LjUuMSB0aGUgdGV4dCBzdGF0ZXMgdGhhdCAiVGhlcmUgYXJlIHRocmVl IHBvc3NpYmxlIHR5cGVzIG9mIC4uDQogICAgVGhlcmVmb3JlIHRoZSBtb2RlbCBzdXBwb3J0 cyB0aHJlZSBmbGF2b3JzOiIgIFdoaWNoIGlzIHRoZW4gZm9sbG93ZWQgYnkgYQ0KICAgIGxp c3Qgb2YgZm91ciBidWxsZXRzLg0KDQogICAgVGhlIGluZGVudGluZyBvZiB0aGUgWE1MIGlu IHNlY3Rpb24gNS41LjIuMSBzaG91bGQgYmUgcmVwYWlyZWQuICBBbGwgb2YgdGhlDQogICAg WE1MIGV4YW1wbGVzIHNob3VsZCBoYXZlIHRoZWlyIGluZGVudGluZyBjaGVja2VkLg0KDQog ICAgVGhlIHRleHQgaW4gc2VjdGlvbiA1LjYgc2F5cyAiVGhlIG1hbmFnZW1lbnQgc3lzdGVt IE1VU1QgaG9ub3IgYWxsIGN1c3RvbWVyDQogICAgY29uc3RyYWludHMuLi4iLiAgVGhlbiBp dCBzYXlzICJQYXJhbWV0ZXJzIHN1Y2ggYXMgc2l0ZSBsb2NhdGlvbiAuLi4gYXJlDQogICAg anVzdCBoaW50cy4iICBJIHRoaW5rIHRoYXQgdGhlIGludGVudGlvbiBpcyB0aGF0ICJwYXJh bWV0ZXJzIiBhbmQNCiAgICAiY29uc3RyYWludHMiIGFyZSBkaWZmZXJlbnQgdGhpbmdzLiAg SWYgc28sIHRoZSBwYXJhZ3JhcGggYWJvdmUgd2hlcmUgdGhvc2UNCiAgICB0ZXJtcyBhcmUg aW50cm9kdWNlZCBzaG91bGQgYXQgbGVhc3QgaW5kaWNhdGUgc29tZXRoaW5nIGFib3V0IHRo ZSBkaWZmZW5jZS4NCiAgICAgTWF5YmUgInBhcmFtZXRlcnMgKGhpbnRzKSBhbmQgY29uc3Ry YWludHMgKGN1c3RvbWVyIHJlcXVpcmVtZW50cykiPw0KDQogICAgSXQgc2VlbXMgc3VycHJp c2luZyBpbiA1LjYuNCBvbiBBY2Nlc3MgRGl2ZXJzaXR5IGZvciBhIGN1c3RvbWVyIHRvIGJl IGFibGUNCiAgICB0byB0YWxrIGFib3V0IHdoZXRoZXIgdGhpbmdzIGFyZSBwcmVtaXR0ZWQg dG8gYmUgb24gdGhlIHNhbWUgbGluZSBjYXJkLiANCiAgICBUaGF0IHNlZW1zIGEgbGV2ZWwg dGhhdCBhbiBvcGVyYXRvciBpcyB1bmxpa2VseSB0byBleHBvc2UuDQoNCiAgICBJdCBpcyBz dXJwcmlzaW5nIHRoYXQgY29tbWl0dGVkIHZzIGV4Y2VzcyBiYW5kd2lkdGggaXMgdHJlYXRl ZCBhcyBhIFFvUw0KICAgIHBhcmFtZXRlciwgd2l0aCBubyBtZW50aW9uIG9mIGl0IGluIDUu MTAuMSAiQmFuZHdpZHRoIi4gIFBhcnRpY3VsYXJseSBzaW5jZQ0KICAgIHRoZXNlIGFyZSBh Y3R1YWxseSBwYXJhbWV0ZXJzIG9mICI8YmFuZHdpZHRoPiINCg0KW0dGXTogV2lsbCBmaXgg dGhlbSwgdGhhbmtzLg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUu IExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFu dGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jv c2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3Vt ZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxh IHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLiANCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5h dGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0 aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4gDQoNClJpc3BldHRhIGwnYW1i aWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4N Cg== From nobody Wed Feb 28 05:15:58 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC1D128959; Wed, 28 Feb 2018 05:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 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] 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 8LzUPIkWqxQt; Wed, 28 Feb 2018 05:15:47 -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 EE55A126CB6; Wed, 28 Feb 2018 05:15:41 -0800 (PST) X-AuditID: d9a97918-547ff70000006b07-8e-5a96ab7c6d2f Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id 9E.05.27399.C7BA69A5; Wed, 28 Feb 2018 14:15:40 +0100 (CET) From: Fioccola Giuseppe To: Ladislav Lhotka , "yang-doctors@ietf.org" CC: "l2sm@ietf.org" , "ietf@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model.all@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08 Thread-Index: AQHTrv5AYyIDdm1EX0ihG0H5S7yR0qO5rvBQ Date: Wed, 28 Feb 2018 13:15:39 +0000 Message-ID: References: <151964851123.31353.1471509914124380207@ietfa.amsl.com> In-Reply-To: <151964851123.31353.1471509914124380207@ietfa.amsl.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.250] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsXCxfdHWrdm9bQog+sLuC22TWthtHi2cT6L xZ2XLxktLqyay2bRt+sAowOrx5IlP5k8Nl2+wxjAFNXAaJOYl5dfkliSqpCSWpxsq+SSWZyc k5iZm1qkEJKak5qcn6ukkJliq2SspFCQk5icmpuaV2KrlFhQkJqXomTHpYABbIDKMvMUUvOS 81My89JtlTyD/XUtLEwtdQ2V7AJLU4tL8hVyU4uLE9PTM/MVUhPWC2b8+3aEqeCZQcWjoz3M DYxH9LsYOTkkBEwkLjf/Y+li5OIQEpjCJLHg3B9GkASbgI3EwVcn2EBsEYEwiR37v7KDFDEL rGeUmLFtOVARB4ewgJ/E/LsyIKaIQJDE6edmEOVGEov3HmcBCbMIqEqc6FEFCfMKBEpMbVvC DmILCThLfLq/ixXE5hRwkbgwYwbYJkYBWYkJuxeBXcAsIC7xYvoJdogzBSSW7DnPDGGLSrx8 /I8VwjaQ2Lp0HwuErSgx6dRTqLiMxMIjk1lBTmAW0JRYv0sfYqSixJTuh+wQ5whKnJz5hGUC o9gsJNtmIXTMQtIxC0nHAkaWVYyiuRUGJnolkLjLLEnMyUzUyyzZxAhMIjdXVkrsYOxe63yI UYCDUYmHt3PBtCgh1sSy4srcQ4wSHMxKIrxpJUAh3pTEyqrUovz4otKc1OJDjD7A4JrILCWa nA9McHkl8YYmFpaGxhYWRoYWZqY4hJXEeZdXAs0SSAcmruzU1ILUIphxTBycUg2M17Q3RHgW pDnfVK4uWvvxCOve/0xFejJ7Xl1UzSjtbNvueM7/czO3hm/b1IkLOi617JLOVbmyf+6Da2Wu /49XqeVn2s9ln9UQb+31bWv0p7Tdz9L0Uk6Iq85RlVeWCCtP2u41Mzlnjdb2lptOyTe3VrUc fLi3N883g1FpkVJLNcMjp9xDj92VWIozEg21mIuKEwGTa0rpTwMAAA== Archived-At: Subject: [L2sm] R: Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 13:15:51 -0000 SGkgTGFkaXNsYXYsDQpUaGFuayB5b3UhIFdlIGFyZSB3b3JraW5nIG9uIGEgbmV3IHJldmlz aW9uIHRoYXQgaW5jb3Jwb3JhdGVzIHlvdXIgY29tbWVudHMuDQpNeSBhbnN3ZXJzIGlubGlu ZSB0YWdnZWQgYXMgW0dGXS4NCg0KQmVzdCBSZWdhcmRzLA0KDQpHaXVzZXBwZQ0KDQotLS0t LU1lc3NhZ2dpbyBvcmlnaW5hbGUtLS0tLQ0KRGE6IExhZGlzbGF2IExob3RrYSBbbWFpbHRv Omxob3RrYUBuaWMuY3pdIA0KSW52aWF0bzogbHVuZWTDrCAyNiBmZWJicmFpbyAyMDE4IDEz OjM1DQpBOiB5YW5nLWRvY3RvcnNAaWV0Zi5vcmcNCkNjOiBsMnNtQGlldGYub3JnOyBpZXRm QGlldGYub3JnOyBkcmFmdC1pZXRmLWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC5hbGxAaWV0 Zi5vcmcNCk9nZ2V0dG86IFlhbmdkb2N0b3JzIGVhcmx5IHJldmlldyBvZiBkcmFmdC1pZXRm LWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC0wOA0KDQpSZXZpZXdlcjogTGFkaXNsYXYgTGhv dGthDQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KDQoqKioqIEdlbmVyYWwg Y29tbWVudHMNCg0KICAgICAtIFRoZSAnaWV0Zi1sMnZwbi1zdmMnIG1vZHVsZSBjb250YWlu ZWQgaW4gdGhpcyBkb2N1bWVudCBpcw0KICAgICAgIHJhdGhlciBsYXJnZTogaXQgZGVmaW5l cyAzODYgc2NoZW1hIG5vZGVzLCAzNSBmZWF0dXJlcyBhbmQgMTc1DQogICAgICAgaWRlbnRp dGllcy4gSXQgaXMgdGhlcmVmb3JlIG5hdHVyYWwgdG8gYXNrIHdoZXRoZXIgdGhlIGF1dGhv cnMNCiAgICAgICBjb25zaWRlcmVkIHNwbGl0dGluZyB0aGUgZGVmaW5pdGlvbnMgaW50byBt dWx0aXBsZQ0KICAgICAgIG1vZHVsZXMuIFRoaXMgd291bGQgbWFrZSB0aGUgZGF0YSBtb2Rl bCBtb3JlIG1vZHVsYXIgYW5kDQogICAgICAgcHJvYmFibHkgYWxzbyBtYWtlIHNvbWUgb2Yg dGhlIGZlYXR1cmVzIHVubmVjZXNzYXJ5LiBTZWUgYWxzbw0KICAgICAgIGRyYWZ0LWlldGYt bmV0bW9kLXJmYzYwODdiaXMtMTgsIHNlYy4gNC4xNy4NCg0KW0dGXTogT2ssIFRoYW5rcyBm b3IgdGhlIHN1Z2dlc3Rpb24uIFdlIHdpbGwgcmVtb3ZlIHVubmVjZXNzYXJ5IGlkZW50aXRp ZXMsIGZlYXR1cmVzLiBOb3RlIHRoYXQgdW5saWtlIG5ldHdvcmsgZWxlbWVudCBtb2RlbCwg c2VydmljZSBtb2RlbCB3aWxsIGRlc2NyaWJlIHZhcmlvdXMgYXNwZWN0cyBvZiBuZXR3b3Jr IGluZnJhc3RydWN0dXJlLCBpbmNsdWRpbmcgZGV2aWNlcyBhbmQgdGhlaXIgc3Vic3lzdGVt cywgYW5kIHJlbGV2YW50IHByb3RvY29scyBvcGVyYXRpbmcgYXQgdGhlIGxpbmsgYW5kIG5l dHdvcmsgbGF5ZXJzIGFjcm9zcyBtdWx0aXBsZSBkZXZpY2UuIFNvIGl0IGlzIGludGVudGlv bmFsIHRvIGhhdmUgc3VjaCBtb2RlbCBkZXNpZ24uDQoNCiAgICAgLSBUaGUgbW9kdWxlIGRl ZmluZXMgbW9zdCBjb250YWluZXJzLCBsaXN0cyBhbmQgZXZlbiBpbmRpdmlkdWFsDQogICAg ICAgbGVhdmVzIGluIGEgZ3JvdXBpbmcgdGhhdCBpcyB0aGVuIHVzZWQgb25seSBvbmNlLiBU aGlzIGFwcHJvYWNoDQogICAgICAgaGFzIGl0cyBwcm9zIG5hZCBjb25zIGJ1dCBpdCBpcyBu b3QgdGhlIGNvbW1vbiBwcmFjdGljZSBpbiBZQU5HDQogICAgICAgbW9kZWxsaW5nIC0gZ3Jv dXBpbmdzIGFyZSBtb3N0bHkgZGVmaW5lZCBvbmx5IGlmIHRoZXkgYXJlIHVzZWQgKG9yDQog ICAgICAgZXhwZWN0ZWQgdG8gYmUgdXNlZCkgcmVwZWF0ZWRseSBhbmQvb3IgaW4gZGlmZmVy ZW50IG1vZHVsZXMuDQoNCltHRl06IEl0IGlzIGV4cGVjdGVkIHNvbWUgb2YgdGhlc2UgZ3Jv dXBpbmdzIGNhbiBiZSByZXVzZWQgaW4gc29tZSBvdGhlciBleHRlcm5hbCBtb2R1bGVzLCBv ciBtb2RlbCBleHRlbnNpb24uDQoNCiAgICAgLSBTb21lIG9mIHRoZSBncm91cGluZ3MgKGUu Zy4gJ3NpdGUtZGV2aWNlJykgcmVmZXJlbmNlIG5vZGVzDQogICAgICAgb3V0c2lkZSB0aGUg Z3JvdXBpbmcsIHdoaWNoIGlzIGRpc2NvdXJhZ2VkLCBzZWUNCiAgICAgICBkcmFmdC1pZXRm LW5ldG1vZC1yZmM2MDg3YmlzLTE4LCBzZWMuIDQuMTMuDQoNCltHRl06IFdpbGwgZml4IGl0 LiBUaGFua3MuDQoNCiAgICAgLSBOYW1lcyBhcmUgc29tZXRpbWVzIG92ZXJsb2FkZWQgaW4g dGhhdCB0aGUgc2FtZSBuYW1lIGlzIHVzZWQNCiAgICAgICBmb3IgZGlmZmVyZW50IHB1cnBv c2VzLiBGb3IgZXhhbXBsZSwgJ2Nsb3VkLWFjY2VzcycgaXMgdXNlZCBhcw0KICAgICAgIHRo ZSBuYW1lIG9mIGJvdGggYSBsaXN0IGFuZCBhIGZlYXR1cmUuIEluIG9uZSBjYXNlDQogICAg ICAgKCdidW0tZnJhbWUtZGVsaXZlcnknKSwgdGhlIHNhbWUgbmFtZSBpcyB1c2VkIGZvciBh IGxpc3QsIHRoZQ0KICAgICAgIGNvbnRhaW5lciB0aGF0IGVuY2xvc2VzIGl0LCBhbmQgdGhl IGdyb3VwaW5nIGluIHdoaWNoIHRoZQ0KICAgICAgIGNvbnRhaW5lciBpcyBkZWZpbmVkLiBU aGlzIHNob3VsZCBiZSBhdm9pZGVkLg0KDQpbR0ZdOiBPaw0KDQoqKioqIFNwZWNpZmljIGNv bW1lbnRzDQoNCiAgICAgLSBNb3N0IHdoZW4gZXhwcmVzc2lvbnMgY29ycmVjdGx5IHVzZSB0 aGUgWFBhdGggZnVuY3Rpb24NCiAgICAgICAnZGVyaXZlZC1mcm9tLW9yLXNlbGYoKScuIElu IHR3byBjYXNlcyAoJ3Zwbi1pZCcgYW5kICdjb3MtaWQnDQogICAgICAgbGVhdmVzKSBpZGVu dGl0aWVzIGFyZSBjb21wYXJlZCBpbiBYUGF0aCBleHByZXNzaW9ucyB1c2luZw0KICAgICAg IHBsYWluIHN0cmluZyBlcXVhbGl0eS4gVGhlc2UgWFBhdGggZXhwcmVzc2lvbnMgbmVlZCB0 byBiZQ0KICAgICAgIGNoYW5nZWQgdG8gdXNlICdkZXJpdmVkLWZyb20tb3Itc2VsZigpJyBh cyB3ZWxsLg0KDQogW0dGXTogT2sNCg0KICAgICAtIFRoZSB3aGVuIGV4cHJlc3Npb24gZm9y IGNvbnRhaW5lciAnZGV2aWNlcycgdXNlciBhIGRpc2p1bmN0aW9uDQogICAgICAgb2YgdHdv ICdkZXJpdmVkLWZyb20tb3Itc2VsZigpJyBjaGVja3MuIFRoaXMgdXN1YWxseSBpbmRpY2F0 ZXMNCiAgICAgICB0aGF0IGEgbmV3IGlkZW50aXR5IGNhbiBiZSBkZWZpbmVkIGZyb20gd2hp Y2ggYm90aCBvci1lZA0KICAgICAgIGlkZW50aXRpZXMgYXJlIGRlcml2ZWQuDQoNCiBbR0Zd OiBPaw0KDQoqKioqIEluc3RhbmNlIGV4YW1wbGVzDQoNCiAgICAgVGhlIGV4YW1wbGUgaW5z dGFuY2UgZG9jdW1lbnRzIGNvbnRhaW5lZCBpbiB0aGUgZG9jdW1lbnQgcmVxdWlyZQ0KICAg ICB0byBiZSBjYXJlZnVsbHkgY2hlY2tlZCBiZWNhdXNlIHRoZXkgYXJlIG9mdGVuIGludmFs aWQgb3IgZXZlbg0KICAgICBub3Qgd2VsbC1mb3JtZWQuIEkgd291bGQgYWxzbyBzdWdnZXN0 IHRvIHVzZSBleGFtcGxlcyBpbiBKU09ODQogICAgIGVuY29kaW5nIHRoYXQgaXMgZWFzaWVy IHRvIHJlYWQ6DQoNCiAgICAgVGhlIHByb2JsZW1zIHRoYXQgSSBkaXNjb3ZlcmVkIGluY2x1 ZGU6DQoNCiAgICAgLSBleHRyYSBzcGFjZSBpbiBvcGVuaW5nIGFuZCBjbG9zaW5nIFhNTCB0 YWdzDQogICAgICAgPCBuZXR3b3JrLWFjY2Vzcy1pZD4gYW5kIDwvIG5ldHdvcmstYWNjZXNz LWlkPg0KDQogW0dGXTogV2lsbCBmaXggaXQuDQoNCiAgICAgLSBwLiAyODogd3JvbmcgbmFt ZXNwYWNlIFVSSQ0KICAgICAgICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1s M3Zwbi1zdmMiDQoNCltHRl06IFdpbGwgZml4IGl0Lg0KDQogICAgIC0gcC4gMjg6IGluIHRo ZSBmaXJzdCAndnBuLXNlcnZpY2UnIGVudHJ5IChrZXkgJ1ZQTkInKSwgdHdvDQogICAgICAg bWFuZGF0b3J5IGxlYXZlcyBhcmUgbWlzc2luZzogJ2NlLXZsYW4tcHJlc2VydmF0aW9uJyBh bmQNCiAgICAgICAnY2Utdmxhbi1jb3MtcGVyc2VydmF0aW9uJy4NCg0KW0dGXTogV2lsbCBm aXggaXQuDQoNCioqKiogTml0cw0KDQogICAgIC0gVGhlIG5hbWUgb2YgJ2NlLXZsYW4tY29z LXBlcnNlcnZhdGlvbicgc2hvdWxkIG1vc3QgbGlrZWx5IGJlDQogICAgICAgJ2NlLXZsYW4t Y29zLXByZXNlcnZhdGlvbicNCg0KW0dGXTogV2lsbCBmaXggaXQuDQoNCiAgICAgLSBJbmNv bnNpc3RlbnQgaW5kZW50YXRpb246IGZlYXR1cmVzICdjZm0nIGFuZCAneS0xNzMxJyBoYXZl IGxlc3MNCiAgICAgICBzcGFjZXMgb2YgaW5kZW50YXRpb24gdGhhbiBvdGhlciBmZWF0dXJl cw0KDQpbR0ZdOiBXaWxsIGZpeCBpdC4NCg0KICAgICAtIFdoZW4gY29uY2F0ZW5hdGluZyBs aXRlcmFsIHN0cmluZ3MsIHRoZSB3aWRlbHkgYWNjZXB0ZWQNCiAgICAgICBjb252ZW50aW9u IGlzIHRvIHB1dCB0aGUgJysnIHNpZ24gb3QgdGhlIHNlY29uZCBsaW5lLCBhbmQgYWxpZ24N CiAgICAgICB0aGUgc3RyaW5nIGNvbXBvbmVudHMuIFRoYXQgaXMsIGluc3RlYWQgb2YNCg0K ICAgICAgIHBhdGggIi9sMnZwbi1zdmMvdnBuLXByb2ZpbGVzL3ZhbGlkLXByb3ZpZGVyLWlk ZW50aWZpZXJzIisNCiAgICAgICAgICIvY2xvdWQtaWRlbnRpZmllci9pZCI7DQoNCiAgICAg ICB1c2UNCg0KICAgICAgIHBhdGggIi9sMnZwbi1zdmMvdnBuLXByb2ZpbGVzL3ZhbGlkLXBy b3ZpZGVyLWlkZW50aWZpZXJzIg0KICAgICAgICAgICsgIi9jbG91ZC1pZGVudGlmaWVyL2lk IjsNCg0KW0dGXTogV2lsbCBmaXggaXQuDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kg YWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUg aW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9u ZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNv bm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVl c3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRp IGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZl ZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLiANCg0KVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4g RGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxz ZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5k IGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4gDQoNClJpc3Bl dHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVj ZXNzYXJpby4NCg== From nobody Wed Feb 28 06:58:11 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E03C12EAF9; Wed, 28 Feb 2018 06:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 PTGxz_sbEzvN; Wed, 28 Feb 2018 06:58:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 8481312DA4C; Wed, 28 Feb 2018 06:58:05 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:3038:3cff:fe84:3622]) by mail.nic.cz (Postfix) with ESMTPSA id 3268162430; Wed, 28 Feb 2018 15:58:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1519829883; bh=TG2WB/CPxdHuS2IJLcENyHbHZWizw8+edchPu3wFmIE=; h=From:To:Date; b=SDtDYM02yo2dvVKj32z9Rb+ezHcyjSSYSrtsYX1zen/dQcR+b6wp1nAfxeVSoIlhn JSOqn2OfMmh41PSxyptaMZMu5dfy/Z+GZ5onOS4ETIEIEI4JSpe2YtlgoT/hE1L/pb jCXOZs2tKhAJlEJmzuH/XvY+aF28z146BrOZjkgs= Message-ID: <1519829883.31583.17.camel@nic.cz> From: Ladislav Lhotka To: Fioccola Giuseppe , "yang-doctors@ietf.org" Cc: "l2sm@ietf.org" , "ietf@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model.all@ietf.org" Date: Wed, 28 Feb 2018 15:58:03 +0100 In-Reply-To: References: <151964851123.31353.1471509914124380207@ietfa.amsl.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [L2sm] R: Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 14:58:09 -0000 Hi Giuseppe, please see inline. On Wed, 2018-02-28 at 13:15 +0000, Fioccola Giuseppe wrote: > Hi Ladislav, > Thank you! We are working on a new revision that incorporates your comments. > My answers inline tagged as [GF]. > > Best Regards, > > Giuseppe > > -----Messaggio originale----- > Da: Ladislav Lhotka [mailto:lhotka@nic.cz] > Inviato: lunedì 26 febbraio 2018 13:35 > A: yang-doctors@ietf.org > Cc: l2sm@ietf.org; ietf@ietf.org; draft-ietf-l2sm-l2vpn-service-model.all@ietf > .org > Oggetto: Yangdoctors early review of draft-ietf-l2sm-l2vpn-service-model-08 > > Reviewer: Ladislav Lhotka > Review result: Ready with Issues > > **** General comments > > - The 'ietf-l2vpn-svc' module contained in this document is > rather large: it defines 386 schema nodes, 35 features and 175 > identities. It is therefore natural to ask whether the authors > considered splitting the definitions into multiple > modules. This would make the data model more modular and > probably also make some of the features unnecessary. See also > draft-ietf-netmod-rfc6087bis-18, sec. 4.17. > > [GF]: Ok, Thanks for the suggestion. We will remove unnecessary identities, > features. Note that unlike network element model, service model will describe > various aspects of network infrastructure, including devices and their > subsystems, and relevant protocols operating at the link and network layers > across multiple device. So it is intentional to have such model design. Yes, but RFC 8199 also talks about monolithic versus component-based approaches in relation to network service models. I am not saying that your design is wrong, just suggesting to consider the alternatives that could possibly make this relatively big data model easier to comprehend. > > - The module defines most containers, lists and even individual > leaves in a grouping that is then used only once. This approach > has its pros nad cons but it is not the common practice in YANG > modelling - groupings are mostly defined only if they are used (or > expected to be used) repeatedly and/or in different modules. > > [GF]: It is expected some of these groupings can be reused in some other > external modules, or model extension. If only some of them are intended to be reused, then I would suggest to remove those that aren't. Model extensions are usually implemented with an augment, and groupings don't help in this case. Thanks, Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 28 10:07:49 2018 Return-Path: X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ABF120727; Wed, 28 Feb 2018 10:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 YBVYVFU_DcP1; Wed, 28 Feb 2018 10:07:45 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 1F91F12008A; Wed, 28 Feb 2018 10:07:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0500B24057B; Wed, 28 Feb 2018 10:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1519841265; bh=sVHH87YBJOHYsg3P2fPx+zesKAysI6uSF5CnQ1hyWpU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GmG4DQxMSmyINg7eadr/VBls0XdeuL5FaDTIC1Z+mI7WQl/FvJLbJMADb5uMVNi4/ EGOCgiA+pV0zTOxZjBS4/U2OacBxbut1jYCe8cd4HrM7QLvGJyg/8GG6QLAtptc9HM EBFkenMu93zNvqenleAZhcjkEdsqkiMmdZ+d98Dc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A42A524B45F; Wed, 28 Feb 2018 10:07:34 -0800 (PST) To: Fioccola Giuseppe , "gen-art@ietf.org" Cc: "l2sm@ietf.org" , "ietf@ietf.org" , "draft-ietf-l2sm-l2vpn-service-model.all@ietf.org" References: <151952041929.12995.5895779377191010604@ietfa.amsl.com> <295aa6644a884df5843f065508bbdf2e@TELMBXB02RM001.telecomitalia.local> From: "Joel M. Halpern" Message-ID: Date: Wed, 28 Feb 2018 13:07:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <295aa6644a884df5843f065508bbdf2e@TELMBXB02RM001.telecomitalia.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [L2sm] R: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08 X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 18:07:48 -0000 Further comments in line, marked ... 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 > > . > > 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. Thank you. I think clarifying this will help the reader. > > 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. 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. > > 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. 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?) > > 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 ack > > 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. The same names are used for different things. Pleaes give them different names. > > 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. 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. > > 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: 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. > “ > > 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. 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. > > 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. 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. > > 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. 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. > > 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. 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. > > 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. Okay. I will get off this point. I can live with what you have. > > 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. Yes, it is "relevant", but it is not itself a property of the topology. So the placement seemed very odd. > > 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 ack > > 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. Then please put words to that effect in that place in the document. > > 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. I think the text needs to be explicit about what is assumed about internal connectivity of a mult-homed site. > > 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. Please add explanatory text and a forward reference to 5.10.2.1. > > 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. If 5.10.2.1 answers the question, then what is 5.5.1.2 doing> > > 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 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. > > 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. ack > > 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. Then please remove the qoa-profile-identifiers. > > 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 "" > > [GF]: Will fix them, thanks. ack.