From narten@us.ibm.com Mon Oct 3 14:09:22 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9131D21F8ECC for ; Mon, 3 Oct 2011 14:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei3Ge+WRIc6h for ; Mon, 3 Oct 2011 14:09:21 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id 57C1221F8ECA for ; Mon, 3 Oct 2011 14:09:21 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p93L5QEk027986 for ; Mon, 3 Oct 2011 15:05:28 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p93L3rBJ154836 for ; Mon, 3 Oct 2011 15:05:42 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p93L3r6l018095 for ; Mon, 3 Oct 2011 15:03:53 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-206-44.mts.ibm.com [9.65.206.44]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p93L3qkG018019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Oct 2011 15:03:53 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p93L3khA008244 for ; Mon, 3 Oct 2011 17:03:51 -0400 Message-Id: <201110032103.p93L3khA008244@cichlid.raleigh.ibm.com> To: opsawg@ietf.org Date: Mon, 03 Oct 2011 17:03:46 -0400 From: Thomas Narten Subject: [OPSAWG] FWD: Call for Participation: Using IP Overlays to provide L2 Virtualization X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 21:09:22 -0000 FYI ------- Forwarded Message From: Thomas Narten To: ietf@ietf.org Cc: nvo3@ietf.org Date: Fri, 30 Sep 2011 20:03:34 -0400 Subject: Call for Participation: Using IP Overlays to provide L2 Virtualization A new mailing list has been set up to explore possible IETF work in the area of providing L2 network virtualization service over an L3 (IP) overlay network. As background, there are a number of drafts that relate to this area, including: http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-00 http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-00 http://tools.ietf.org/html/draft-wkumari-dcops-l3-vmmobility-00 I've put together a first-cut at a problem statement that focuses on the issues and potential work areas, without getting into solution specifics. See: http://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-statement-00.txt There have also been some related vendor announcements and presentations as well (these are ones I happen to know of, there are surely others). For example: http://blogs.cisco.com/datacenter/introducing-vxlan/ http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-685115.html http://blogs.vmware.com/console/2011/08/towards-virtualized-networking-for-the-cloud.html http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-442T The list is called nvo3, for "Network Virtualization Over L3", aka N-Vee-Oh-3 (we'll see how well that acronym sticks...). I've put in a formal request to hold a BOF in Taipai, so we can explore whether it makes sense to form a WG in this area. Subscription information for the mailing list can be found at List address: nvo3@ietf.org Archive: http://www.ietf.org/mail-archive/web/nvo3/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/nvo3 I look forward to your participation! Thomas _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ------- End of Forwarded Message From wesley.george@twcable.com Tue Oct 4 07:51:04 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4980C21F8C0E for ; Tue, 4 Oct 2011 07:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCtrEmL8O-bT for ; Tue, 4 Oct 2011 07:51:03 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1978621F8BDC for ; Tue, 4 Oct 2011 07:51:00 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,631,1309752000"; d="scan'208";a="281282493" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Oct 2011 10:50:54 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 4 Oct 2011 10:54:03 -0400 From: "George, Wes" To: "opsawg@ietf.org" Date: Tue, 4 Oct 2011 10:54:41 -0400 Thread-Topic: comments on draft-weil-shared-transition-space-request-07 Thread-Index: AcyCpYwLPGVqYhebQkeX0KtoanjGbw== Message-ID: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-weil-shared-transition-space-request@tools.ietf.org" , "Weil, Jason" Subject: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 14:51:04 -0000 I've reviewed the last two versions of this document. Generally it's in muc= h better shape, but I have a few questions. First, in -06, RFC1918 was listed as formally updated as I (and others) hav= e recommended. Then in -07 that update was removed. What is the rationale f= or the change? The general idea I had was that RFC1918 is updated because o= f the address scope assumptions that you discuss in section 4.1 of -06 and = in 5.1 of -07, and 5735 is updated to cover the new reservation itself. Second, the introduction section still conflicts with itself and with secti= on 4 regarding its instructions on usage. I think we need to make a decisio= n one way or another on the usage - either it is only to be used for CGN (M= UST) or it is not and there are additional cases to be defined in draft-bdg= ks (SHOULD). Personally, I think that this document needs to stand on its own. If others= wish to identify additional use cases for this space after it is defined, = they are welcome to suggest them in draft-bdgks or another draft revising t= he guidance provided here, but I don't think it makes sense to say "use thi= s space only for this use" and "see draft-bdgks for other uses". Perhaps si= mply removing the reference to bdgks will be a solution. In section 3 alternatives - I don't see much point in the "MUST NOT number = interfaces in question from squat space" This is a SHOULD NOT if it belongs in the document at all. Squat space is b= eing used today in quite a number of networks as a part of NAT applications= . There are risks as the document notes, but MUST is too strong here, espec= ially since this is a document allocating space for CGN, not discussing all= details of the proper way to implement it. "use of squat space considered = harmful" is another draft all by itself. You can make the point that this s= hared space allocation is preferable to squat space without needing a "must= not use." Section 4: "Service Providers MUST filter incoming advertisements regarding Shared CGN Space." This needs to include text + a note to the RFC Editor that it also formally= updates RFCxxxx (the number eventually assigned to draft-ietf-grow-no-more= -unallocated-slash8s, currently in IETF LC), as it currently recommends tha= t all route filtering be removed except for a list of the currently reserve= d IANA IPv4 space. Also, typically MUST means no exceptions. If there's exceptions, the more a= ppropriate thing would be SHOULD...Unless Section 4/6 - "service providers MUST filter such packets on ingress" - thi= s is too strong. This needs to be a SHOULD. Not all SPs even do ingress fil= tering, due to hardware limitations or other considerations. Section 5.2 - I don't understand the subheading "empirical data" - this all= seems a discussion of known issues for CGN, which is largely a rehash of t= he cited draft. I think that you can make the point that the proposed CGN s= pace doesn't materially make this better or worse without the discussion of= consoles, etc, by simply saying " Based on testing documented in [I-D.donley-nat444-impacts], the CGN impacts on most applications that are not dependent on [application know= ledge of scope or some similar qualifier] are comparable regardless of whet= her globally unique, Shared CGN Space, or [RFC1918] addresses are used. There is, however, a difference between the three alternatives in the treatment of 6to4. And then go on to discuss the details of 6to4 as you do in the next two par= agraphs. Nit : In the abstract I believe you mean Carrier Grade NAT or Network Addre= ss translation, rather than just "carrier grade network" Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From ning.so@verizon.com Tue Oct 4 14:00:24 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5234921F8E2E for ; Tue, 4 Oct 2011 14:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQHcoPv3Fj3B for ; Tue, 4 Oct 2011 14:00:22 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0498521F8E27 for ; Tue, 4 Oct 2011 14:00:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 04 Oct 2011 21:03:26 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,487,1312156800"; d="scan'208,217";a="151869030" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 04 Oct 2011 21:03:24 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.60]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Tue, 4 Oct 2011 17:03:13 -0400 To: "opsawg@ietf.org" Date: Tue, 4 Oct 2011 17:03:10 -0400 Thread-Topic: VPN4DC work will move forward in L3VPN Thread-Index: AcyC1/1AgRZ3dKhzSPWc0/tf9jqp4Q== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08E2172C2@FHDP1LUMXC7V41.us.one.verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6665BC1FEA04AB47B1F75FA641C43BC08E2172C2FHDP1LUMXC7V41u_" MIME-Version: 1.0 Subject: [OPSAWG] VPN4DC work will move forward in L3VPN X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 21:00:24 -0000 --_000_6665BC1FEA04AB47B1F75FA641C43BC08E2172C2FHDP1LUMXC7V41u_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just want to let you know that Routing Area ADs have instructed VPN4DC work= previously held in this WG to progress through L3VPN WG. Please join L3VP= N WG mail list for discussions and draft updates if you are interested in t= he work. The scope of work has been significantly narrowed. I have posted= the new scope in L3VPN already, so please pardon me if you have seen the i= nformation below already. The purpose of VPN4DC is to define requirements and solutions for hosts and= applications in Data Centers to automatically join or leave an IP VPN whic= h interconnects multiple customer premises and data centers. Today when two or more data centers are inter-connected through VPNs or any= WAN networks, hosts or VMs within data centers are managed separately from= the VPN provider's management system. The provisioning process for servic= es provided by Service Providers' data centers to join enterprise VPNs, is = often manual, and thus has long turn up time. Security, scalability, and op= erational efficiency are issues due to lack of standardized automation proc= edure for hosts in provider data centers to join VPN. Modern data-centers require multi-tenant support for applications. For secu= rity and administrative reasons it is desirable to isolate the resources as= sociated with a particular tenant in a VPN. VPN4DC will define requirements= and protocol solutions to enable hosts in a data center to join a specific= layer 3 VPN automatically through control protocols, using IP VPN to provi= de secure any to any connections. The VPN Gateway function which provides s= eamless VPN connectivity between the segments of the networks will be defin= ed. There are two ways for hosts/applications within a data center to join a sp= ecific VPN which interconnect multiple sites: via Management plane or via i= n-band data plane. 1. Management Plane: i.e. having the wide area VPN's management = system communicate with data center management system to allow a group of h= osts or applications to join a specific VPN. If the two management systems can communicate directly to allow a group of = VMs in a Data Center to join a VPN, then the automation can be achieved wit= hout any new protocol work for IETF. 2. In-band data plane: However, several service providers have i= ndicated that their VPN management system can't communicate with Data Cente= r management system automatically. They want the automation to go through i= n-band signal between DC gateway and VPN PEs. Then new protocol work is nee= ded for IETF: like request to join (or leave), authentication, etc. The design principle for the protocols and solution development is to lever= age existing layer 3 VPN technologies already defined in IETF whenever poss= ible, including various IP and MPLS VPN technologies. This work supports th= e creation of new protocols, extension to existing protocols, and solutions= proposed to use new and existing protocols. Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 --_000_6665BC1FEA04AB47B1F75FA641C43BC08E2172C2FHDP1LUMXC7V41u_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just want to let= you know that Routing Area ADs have instructed VPN4DC work previously held= in this WG to progress through L3VPN WG.  Please join L3VPN WG mail l= ist for discussions and draft updates if you are interested in the work.&nb= sp; The scope of work has been significantly narrowed.  I have posted = the new scope in L3VPN already, so please pardon me if you have seen the in= formation below already.

 

The purpose of VPN4DC is to define requiremen= ts and solutions for hosts and applications in Data Centers to automaticall= y join or leave an IP VPN which interconnects multiple customer premises an= d data centers.

 

Today when two or more data centers are inter-conn= ected through VPNs or any WAN networks, hosts or VMs within data centers ar= e managed separately from the VPN provider’s management system. = The provisioning process for services provided by Service Providers’= data centers to join enterprise VPNs, is often manual, and thus has long t= urn up time. Security, scalability, and operational efficiency are issues d= ue to lack of standardized automation procedure for hosts in provider data = centers to join VPN.

=

Modern data-centers require multi-tenant support fo= r applications. For security and administrative reasons it is desirable to = isolate the resources associated with a particular tenant in a VPN. VPN4DC = will define requirements and protocol solutions to enable hosts in a data c= enter to join a specific layer 3 VPN automatically through control protocol= s, using IP VPN to provide secure any to any connections. The VPN Gateway f= unction which provides seamless VPN connectivity between the segments of th= e networks will be defined.

&nbs= p;

There are two ways for hosts/applicatio= ns within a data center to join a specific VPN which interconnect multiple = sites: via Management plane or via in-band data plane.

 

1. &nb= sp;          Management Plane:= i.e. having the wide area VPN’s management system communicate with d= ata center management system to allow a group of hosts or applications to j= oin a specific VPN.

If the two manag= ement systems can communicate directly to allow a group of VMs in a Data Ce= nter to join a VPN, then the automation can be achieved without any new pro= tocol work for IETF.

2.  &= nbsp;         In-band data plane: H= owever, several service providers have indicated that their VPN management = system can't communicate with Data Center management system automatically. = They want the automation to go through in-band signal between DC gateway an= d VPN PEs. Then new protocol work is needed for IETF: like request to join = (or leave), authentication, etc.

 

The design principle for the proto= cols and solution development is to leverage existing layer 3 VPN technolog= ies already defined in IETF whenever possible, including various IP and MPL= S VPN technologies. This work supports the creation of new protocols, exten= sion to existing protocols, and solutions proposed to use new and existing = protocols.

 

 

 

 

Best regards,=

 

Ning S= o

Verizon Corporate Technology<= /span>

(office) 972-729-7905

(Cell) 972-955-0914

 

 

= --_000_6665BC1FEA04AB47B1F75FA641C43BC08E2172C2FHDP1LUMXC7V41u_-- From Tina.Tsou.Zouting@huawei.com Tue Oct 4 18:23:31 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269AC21F8D37 for ; Tue, 4 Oct 2011 18:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdfCK7uBetyH for ; Tue, 4 Oct 2011 18:23:31 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8AB21F8CE8 for ; Tue, 4 Oct 2011 18:23:28 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK005VNK08QA@szxga05-in.huawei.com> for opsawg@ietf.org; Wed, 05 Oct 2011 09:26:32 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00EQBK07BR@szxga05-in.huawei.com> for opsawg@ietf.org; Wed, 05 Oct 2011 09:26:32 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEG54315; Wed, 05 Oct 2011 09:26:29 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 05 Oct 2011 09:26:26 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.147]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 05 Oct 2011 09:26:21 +0800 Date: Wed, 05 Oct 2011 01:26:21 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.158] To: "George, Wes" , "opsawg@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: comments on draft-weil-shared-transition-space-request-07 Thread-index: AcyCpYwLPGVqYhebQkeX0KtoanjGbwAVufagAABRkcA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> Cc: "draft-weil-shared-transition-space-request@tools.ietf.org" , "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 01:23:31 -0000 Hi, In some cases, if we use https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/ https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/ https://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite/ draft-weil-shared-transition-space-request-07 seems not absolutely necessary. I do not oppose draft-weil, on the contrary, I support it. But some clarification text may be needed. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of George, Wes Sent: Tuesday, October 04, 2011 7:55 AM To: opsawg@ietf.org Cc: draft-weil-shared-transition-space-request@tools.ietf.org; Weil, Jason Subject: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 I've reviewed the last two versions of this document. Generally it's in much better shape, but I have a few questions. First, in -06, RFC1918 was listed as formally updated as I (and others) have recommended. Then in -07 that update was removed. What is the rationale for the change? The general idea I had was that RFC1918 is updated because of the address scope assumptions that you discuss in section 4.1 of -06 and in 5.1 of -07, and 5735 is updated to cover the new reservation itself. Second, the introduction section still conflicts with itself and with section 4 regarding its instructions on usage. I think we need to make a decision one way or another on the usage - either it is only to be used for CGN (MUST) or it is not and there are additional cases to be defined in draft-bdgks (SHOULD). Personally, I think that this document needs to stand on its own. If others wish to identify additional use cases for this space after it is defined, they are welcome to suggest them in draft-bdgks or another draft revising the guidance provided here, but I don't think it makes sense to say "use this space only for this use" and "see draft-bdgks for other uses". Perhaps simply removing the reference to bdgks will be a solution. In section 3 alternatives - I don't see much point in the "MUST NOT number interfaces in question from squat space" This is a SHOULD NOT if it belongs in the document at all. Squat space is being used today in quite a number of networks as a part of NAT applications. There are risks as the document notes, but MUST is too strong here, especially since this is a document allocating space for CGN, not discussing all details of the proper way to implement it. "use of squat space considered harmful" is another draft all by itself. You can make the point that this shared space allocation is preferable to squat space without needing a "must not use." Section 4: "Service Providers MUST filter incoming advertisements regarding Shared CGN Space." This needs to include text + a note to the RFC Editor that it also formally updates RFCxxxx (the number eventually assigned to draft-ietf-grow-no-more-unallocated-slash8s, currently in IETF LC), as it currently recommends that all route filtering be removed except for a list of the currently reserved IANA IPv4 space. Also, typically MUST means no exceptions. If there's exceptions, the more appropriate thing would be SHOULD...Unless Section 4/6 - "service providers MUST filter such packets on ingress" - this is too strong. This needs to be a SHOULD. Not all SPs even do ingress filtering, due to hardware limitations or other considerations. Section 5.2 - I don't understand the subheading "empirical data" - this all seems a discussion of known issues for CGN, which is largely a rehash of the cited draft. I think that you can make the point that the proposed CGN space doesn't materially make this better or worse without the discussion of consoles, etc, by simply saying " Based on testing documented in [I-D.donley-nat444-impacts], the CGN impacts on most applications that are not dependent on [application knowledge of scope or some similar qualifier] are comparable regardless of whether globally unique, Shared CGN Space, or [RFC1918] addresses are used. There is, however, a difference between the three alternatives in the treatment of 6to4. And then go on to discuss the details of 6to4 as you do in the next two paragraphs. Nit : In the abstract I believe you mean Carrier Grade NAT or Network Address translation, rather than just "carrier grade network" Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From rbonica@juniper.net Tue Oct 4 18:39:11 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E703C21F8C35 for ; Tue, 4 Oct 2011 18:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+EEX-UNc73d for ; Tue, 4 Oct 2011 18:39:11 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id D591A21F8C33 for ; Tue, 4 Oct 2011 18:39:04 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP; Tue, 04 Oct 2011 18:42:17 PDT Received: from P-EMHUB11-HQ.jnpr.net (172.24.192.58) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 4 Oct 2011 18:39:36 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB11-HQ.jnpr.net (172.24.192.58) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 4 Oct 2011 18:39:35 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 4 Oct 2011 21:39:34 -0400 From: Ronald Bonica To: "George, Wes" , "opsawg@ietf.org" Date: Tue, 4 Oct 2011 21:39:38 -0400 Thread-Topic: comments on draft-weil-shared-transition-space-request-07 Thread-Index: AcyCpYwLPGVqYhebQkeX0KtoanjGbwAWa7Ow Message-ID: <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-weil-shared-transition-space-request@tools.ietf.org" , "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 01:39:12 -0000 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of George, Wes > Sent: Tuesday, October 04, 2011 10:55 AM > To: opsawg@ietf.org > Cc: draft-weil-shared-transition-space-request@tools.ietf.org; Weil, > Jason > Subject: [OPSAWG] comments on draft-weil-shared-transition-space- > request-07 >=20 [snip] >=20 > Second, the introduction section still conflicts with itself and with > section 4 regarding its instructions on usage. I think we need to make > a decision one way or another on the usage - either it is only to be > used for CGN (MUST) or it is not and there are additional cases to be > defined in draft-bdgks (SHOULD). > Personally, I think that this document needs to stand on its own. If > others wish to identify additional use cases for this space after it is > defined, they are welcome to suggest them in draft-bdgks or another > draft revising the guidance provided here, but I don't think it makes > sense to say "use this space only for this use" and "see draft-bdgks > for other uses". Perhaps simply removing the reference to bdgks will be > a solution. >=20 IMHO, this draft stands pretty well on its own. Would the authors be averse= to removing the sentence that references draft-bdgks and also removing the= reference to that draft? Would this be acceptable to the larger community? Ron From brian.e.carpenter@gmail.com Tue Oct 4 19:10:33 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D465321F8C17 for ; Tue, 4 Oct 2011 19:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RRDOpmxqxrG for ; Tue, 4 Oct 2011 19:10:33 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B21821F8BB2 for ; Tue, 4 Oct 2011 19:10:33 -0700 (PDT) Received: by vws5 with SMTP id 5so1187959vws.31 for ; Tue, 04 Oct 2011 19:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4x5XmsPQPtQU1Yzmw7jhS6zm+man1Qg+PiCgAOzxwtQ=; b=lwhT9ZRv+rvfo13yogtSexf7ck2oLmtOHVWRbZbAJKzKzmgG6ddZWk9zfCKQ5R9SkD IiMziF9932HbYNSygZqE7NBHsr9pc3vC7qI+6/YUd+R0fTI+BmxmaCugPCamsyWMH2NG CA38XEo5cAXLpV/QUlsLoLUjGsaOdDL2ymPWs= Received: by 10.52.66.136 with SMTP id f8mr1894483vdt.344.1317780819594; Tue, 04 Oct 2011 19:13:39 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ix4sm72548vdb.21.2011.10.04.19.13.35 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 19:13:38 -0700 (PDT) Message-ID: <4E8BBD57.601@gmail.com> Date: Wed, 05 Oct 2011 15:13:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , draft-weil-shared-transition-space-request@tools.ietf.org, "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 02:10:33 -0000 Hi Ron, On 2011-10-05 14:39, Ronald Bonica wrote: > >> -----Original Message----- >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On >> Behalf Of George, Wes >> Sent: Tuesday, October 04, 2011 10:55 AM >> To: opsawg@ietf.org >> Cc: draft-weil-shared-transition-space-request@tools.ietf.org; Weil, >> Jason >> Subject: [OPSAWG] comments on draft-weil-shared-transition-space- >> request-07 >> > > [snip] > >> Second, the introduction section still conflicts with itself and with >> section 4 regarding its instructions on usage. I think we need to make >> a decision one way or another on the usage - either it is only to be >> used for CGN (MUST) or it is not and there are additional cases to be >> defined in draft-bdgks (SHOULD). >> Personally, I think that this document needs to stand on its own. If >> others wish to identify additional use cases for this space after it is >> defined, they are welcome to suggest them in draft-bdgks or another >> draft revising the guidance provided here, but I don't think it makes >> sense to say "use this space only for this use" and "see draft-bdgks >> for other uses". Perhaps simply removing the reference to bdgks will be >> a solution. >> > > IMHO, this draft stands pretty well on its own. Would the authors be averse to removing the sentence that references draft-bdgks and also removing the reference to that draft? Would this be acceptable to the larger community? > > Ron Hmm. Back in August I said: >>> However, I do think that *if* draft-weil- >>> is to be published, draft-bdgks needs to be published >>> simultaneously. Therefore, I think that synchronised Last Calls >>> are needed. But now, draft-weil says: Unlike [RFC1918] address space, Shared CGN Space is not available for any purpose other than numbering the interfaces that connect a CGN to CPE. Additional applicability and analysis of Shared CGN Space is described in [I-D.bdgks-arin-shared-transition-space]. If the first sentence is true, it needs to use MUST NOT language. But then, not only is draft-bdgks unnecessary as a reference, but also it is describing practices that MUST NOT be used. In that case, draft-bdgks needs to be completely dropped - any other result is contradictory. Brian From randy@psg.com Tue Oct 4 19:42:14 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADBE21F8B13 for ; Tue, 4 Oct 2011 19:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBQwmtjNq5TL for ; Tue, 4 Oct 2011 19:42:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2D521F8AF1 for ; Tue, 4 Oct 2011 19:42:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RBHTr-000IPw-PZ; Wed, 05 Oct 2011 02:45:12 +0000 Date: Wed, 05 Oct 2011 11:45:10 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4E8BBD57.601@gmail.com> References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "opsawg@ietf.org" , draft-weil-shared-transition-space-request@tools.ietf.org, "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 02:42:14 -0000 > Unlike [RFC1918] address space, Shared CGN Space is not available for > any purpose other than numbering the interfaces that connect a CGN to > CPE. and anyone who believes that is a serious fool. put the crap out there, and it will be used. randy From matthew@matthew.at Tue Oct 4 19:57:39 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AD721F8797 for ; Tue, 4 Oct 2011 19:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBciK2VMPcpy for ; Tue, 4 Oct 2011 19:57:38 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A9621F86FF for ; Tue, 4 Oct 2011 19:57:38 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 28A0614800F; Tue, 4 Oct 2011 20:00:45 -0700 (PDT) Message-ID: <4E8BC814.4010400@matthew.at> Date: Tue, 04 Oct 2011 19:59:32 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> In-Reply-To: <4E8BBD57.601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , draft-weil-shared-transition-space-request@tools.ietf.org, "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: matthew@matthew.at List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 02:57:39 -0000 On 10/4/2011 7:13 PM, Brian E Carpenter wrote: > > > But now, draft-weil says: > > Unlike [RFC1918] address space, Shared > CGN Space is not available for any purpose other than numbering the > interfaces that connect a CGN to CPE. Additional applicability and > analysis of Shared CGN Space is described in > [I-D.bdgks-arin-shared-transition-space]. > > If the first sentence is true, it needs to use MUST NOT language. But > then, not only is draft-bdgks unnecessary as a reference, but also it is > describing practices that MUST NOT be used. In that case, draft-bdgks > needs to be completely dropped - any other result is contradictory. > > I think this is almost what I said back in August as well. Either you can use the space for other things (in which case Shared CGN Space *is* available for purposes other than numbering the interfaces that connect a CGN to CPE) or you cannot (in which case we most certainly won't need a second document describing how it is used in these other cases). Matthew Kaufman ps. Randy is correct anyway, in that no matter what this says (even if "MUST NOT"), it'll get used for the other purposes... and at this point there's some great suggestions of *what* other purposes over in braft-bdgks... From wherrin@gmail.com Tue Oct 4 20:13:53 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF8721F8B88 for ; Tue, 4 Oct 2011 20:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2kbUvMYEdhU for ; Tue, 4 Oct 2011 20:13:52 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB5421F8B74 for ; Tue, 4 Oct 2011 20:13:52 -0700 (PDT) Received: by bkaq10 with SMTP id q10so1799562bka.31 for ; Tue, 04 Oct 2011 20:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=u9B9MSn/mUsE+2VfkxBlKA6QqSxQb0EQ+XhtRsvsAhc=; b=bVfLZ2Rc3UTi2zPIM+YpHvgQ6d3xhw1CcXV40EwRvc0RPXoMD7F4IVfFKbZpauAnuQ T0tNd1W3t8A8dJkdbSXLLjMTCUypOq9RevMGaWGnWGJvqFWQhHZmW2bwt76YrQajVEOw Kvq/dWsHXPBygCDrzg/E3Kx4qJ3F8av2FFTXo= Received: by 10.204.157.154 with SMTP id b26mr1107939bkx.148.1317784617142; Tue, 04 Oct 2011 20:16:57 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.57.197 with HTTP; Tue, 4 Oct 2011 20:16:37 -0700 (PDT) In-Reply-To: References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> From: William Herrin Date: Tue, 4 Oct 2011 23:16:37 -0400 X-Google-Sender-Auth: 2zYUjIo-PohprjBXNB7QiOdzBEE Message-ID: To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsawg@ietf.org" , draft-weil-shared-transition-space-request@tools.ietf.org, "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 03:13:53 -0000 On Tue, Oct 4, 2011 at 10:45 PM, Randy Bush wrote: >> Unlike [RFC1918] address space, Shared CGN Space is not available for >> any purpose other than numbering the interfaces that connect a CGN to >> CPE. > > and anyone who believes that is a serious fool. =A0put the crap out there= , > and it will be used. Hi Randy, People will do what people will do. That generally includes anything physically possible and a few things that no one would have believed were possible until someone does them The point of MUST and MUST NOT in this draft is to identify the party at fault when something malfunctions. If packets from CGN space leak in to or out of my network, is it my fault for failing to filter or is it yours? If the end-user assignment from my network collides with the DNS resolver setting from yours, is it your fault for misusing the space or is it just bad luck? Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy@psg.com Tue Oct 4 20:17:41 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4DE21F8B9E for ; Tue, 4 Oct 2011 20:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3lm7CHZj989 for ; Tue, 4 Oct 2011 20:17:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFEC21F8B95 for ; Tue, 4 Oct 2011 20:17:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RBI2H-000IUf-0d; Wed, 05 Oct 2011 03:20:45 +0000 Date: Wed, 05 Oct 2011 12:20:43 +0900 Message-ID: From: Randy Bush To: William Herrin In-Reply-To: References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsawg@ietf.org" , draft-weil-shared-transition-space-request@tools.ietf.org, "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 03:17:41 -0000 >>> Unlike [RFC1918] address space, Shared CGN Space is not available for >>> any purpose other than numbering the interfaces that connect a CGN to >>> CPE. >> and anyone who believes that is a serious fool. =A0put the crap out ther= e, >> and it will be used. > People will do what people will do. That generally includes anything > physically possible and a few things that no one would have believed > were possible until someone does them the sentence is in there to pander to those who worry that this is just another rfc 1918 extension. as it actually *is* just another rfc 1918 extension, the sentence is not only incorrect, as it *will* be available, but intentionally misleading. randy From owen@delong.com Tue Oct 4 21:09:09 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE52621F8A58 for ; Tue, 4 Oct 2011 21:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrJlEgTK7air for ; Tue, 4 Oct 2011 21:09:09 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C890221F8AD8 for ; Tue, 4 Oct 2011 21:09:08 -0700 (PDT) Received: from baikal.delong.com (baikal.delong.com [192.159.10.49]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p954Ak72022919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Oct 2011 21:10:47 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p954Ak72022919 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1317787851; bh=5bQrnKuynGnbir6qpagVYNHCzyA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GcsxWxV41dFl3pYghauznKwemKbwM17nC7riSu96F76obcIMy1omyDEuxQ9Py7LC8 rgxg48zfkRkgWWcaAKfEShXiGzWH8biXqilAxHxqAiJhdWn1KeEM+DhUJldWrSpUzK EGB+qo6gZWXVUu5XS/sab7IziBjIOnxO0PX9Yvsg= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Owen DeLong In-Reply-To: <4E8BC814.4010400@matthew.at> Date: Tue, 4 Oct 2011 21:10:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27BC0C9A-B227-4E5A-A136-F5394E976AEC@delong.com> References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> <4E8BC814.4010400@matthew.at> To: matthew@matthew.at X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Tue, 04 Oct 2011 21:10:51 -0700 (PDT) Cc: "opsawg@ietf.org" , draft-weil-shared-transition-space-request@tools.ietf.org, "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 04:09:09 -0000 I think that the categorical denial should be removed from draft-weil. I believe that the other purposes mentioned in bdgks are useful and = carefully considered so as not t ocreate conflicts (or at least not conflicts outside of any = given ISPs own actions) and render the space more,not less, useful. I think that the two-document approach is sound and that eliminating the = second document would cause more problems than it would solve at this point. Owen On Oct 4, 2011, at 7:59 PM, Matthew Kaufman wrote: > On 10/4/2011 7:13 PM, Brian E Carpenter wrote: >>=20 >>=20 >> But now, draft-weil says: >>=20 >> Unlike [RFC1918] address space, Shared >> CGN Space is not available for any purpose other than numbering = the >> interfaces that connect a CGN to CPE. Additional applicability = and >> analysis of Shared CGN Space is described in >> [I-D.bdgks-arin-shared-transition-space]. >>=20 >> If the first sentence is true, it needs to use MUST NOT language. But >> then, not only is draft-bdgks unnecessary as a reference, but also it = is >> describing practices that MUST NOT be used. In that case, draft-bdgks >> needs to be completely dropped - any other result is contradictory. >>=20 >> =20 > I think this is almost what I said back in August as well. Either you = can use the space for other things (in which case Shared CGN Space *is* = available for purposes other than numbering the interfaces that connect = a CGN to CPE) or you cannot (in which case we most certainly won't need = a second document describing how it is used in these other cases). >=20 > Matthew Kaufman >=20 > ps. Randy is correct anyway, in that no matter what this says (even if = "MUST NOT"), it'll get used for the other purposes... and at this point = there's some great suggestions of *what* other purposes over in = braft-bdgks... > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From matthew@matthew.at Tue Oct 4 21:31:01 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85DE21F8BBB for ; Tue, 4 Oct 2011 21:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebqaRIUHM7Ai for ; Tue, 4 Oct 2011 21:31:01 -0700 (PDT) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516EA21F8BB0 for ; Tue, 4 Oct 2011 21:31:01 -0700 (PDT) Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id 1E698148030; Tue, 4 Oct 2011 21:34:08 -0700 (PDT) Message-ID: <4E8BDDF7.9020209@matthew.at> Date: Tue, 04 Oct 2011 21:32:55 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Randy Bush References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , draft-weil-shared-transition-space-request@tools.ietf.org, "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: matthew@matthew.at List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 04:31:01 -0000 On 10/4/2011 8:20 PM, Randy Bush wrote: >>>> Unlike [RFC1918] address space, Shared CGN Space is not available for >>>> any purpose other than numbering the interfaces that connect a CGN to >>>> CPE. >>> and anyone who believes that is a serious fool. put the crap out there, >>> and it will be used. >> People will do what people will do. That generally includes anything >> physically possible and a few things that no one would have believed >> were possible until someone does them > the sentence is in there to pander to those who worry that this is just > another rfc 1918 extension. as it actually *is* just another rfc 1918 > extension, the sentence is not only incorrect, as it *will* be > available, but intentionally misleading. > Or we do what Owen suggests and remove that and just admit that it is just another RFC 1918 extension. And then those of us opposed to another RFC 1918 extension can be opposed without having to fend off claims that it isn't. Matthew Kaufman From owen@delong.com Tue Oct 4 22:02:51 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B124A21F84C2 for ; Tue, 4 Oct 2011 22:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn+5ckBp6Kee for ; Tue, 4 Oct 2011 22:02:51 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4D521F84BC for ; Tue, 4 Oct 2011 22:02:50 -0700 (PDT) Received: from baikal.delong.com (baikal.delong.com [192.159.10.49]) (authenticated bits=0) by owen.delong.com (8.14.1/8.14.1) with ESMTP id p9555gcc023935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Oct 2011 22:05:43 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com p9555gcc023935 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1317791147; bh=7UYV7hZY/SbYlWESo8Cgg7U6w5A=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=L2sGhcnfnYV5FK55UwyYcSkun8lrwiu+2af+n8AQYz+eMZCOzCbgYMkz5MMT/IlS0 2uJEWp2lFUpJIPeKGBmvb1aGLroIp5gDBpGk4kMPqy5n0Y/c4OO212xTzgymq1vjpW ThQLwMkTDAyHJHAteY5fOIldSSWBA3uawB5a6Aog= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Owen DeLong In-Reply-To: <4E8BDDF7.9020209@matthew.at> Date: Tue, 4 Oct 2011 22:05:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> <4E8BDDF7.9020209@matthew.at> To: matthew@matthew.at X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (owen.delong.com [192.159.10.2]); Tue, 04 Oct 2011 22:05:47 -0700 (PDT) Cc: "opsawg@ietf.org" , draft-weil-shared-transition-space-request@tools.ietf.org, "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 05:02:51 -0000 On Oct 4, 2011, at 9:32 PM, Matthew Kaufman wrote: > On 10/4/2011 8:20 PM, Randy Bush wrote: >>>>> Unlike [RFC1918] address space, Shared CGN Space is not available = for >>>>> any purpose other than numbering the interfaces that connect a CGN = to >>>>> CPE. >>>> and anyone who believes that is a serious fool. put the crap out = there, >>>> and it will be used. >>> People will do what people will do. That generally includes anything >>> physically possible and a few things that no one would have believed >>> were possible until someone does them >> the sentence is in there to pander to those who worry that this is = just >> another rfc 1918 extension. as it actually *is* just another rfc = 1918 >> extension, the sentence is not only incorrect, as it *will* be >> available, but intentionally misleading. >>=20 >=20 > Or we do what Owen suggests and remove that and just admit that it is = just another RFC 1918 extension. >=20 Whoa=85 I'm suggesting we strike that sentence and recognize that there = are additional use cases beyond just NAT intermediate space that are = applicable. However, there is reason to partition those use cases from the intended = use cases of RFC-1918 and it is important that this address space not be = used in a manner which could conflict with the manners prescribed in = draft-bdgks. > And then those of us opposed to another RFC 1918 extension can be = opposed without having to fend off claims that it isn't. >=20 It is not another RFC 1918 extension. There is a distinct need here = where the existing uses of RFC-1918 render the use of RFC-1918 space infeasible = for the application(s). This space does not need to be globally unique. The = current uses of RFC-1918 do not need to be globally unique. That is where the = similarity ends. The uses of this space are specifically cases where conflicting = with existing use of RFC-1918 space would create significant problems for the provider = in question requiring impractical if not implausible solutions (such as = coordinating customer use of RFC-1918 space so as not to conflict with ISP's use) = which would, instead, drive providers to the other less desirable solutions = discussed in draft-bdgks such as squatting or independent use of GUA. Owen From wherrin@gmail.com Tue Oct 4 23:58:52 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A777121F8AB0 for ; Tue, 4 Oct 2011 23:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnWvv9C4MumG for ; Tue, 4 Oct 2011 23:58:52 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2121F8AAA for ; Tue, 4 Oct 2011 23:58:51 -0700 (PDT) Received: by bkaq10 with SMTP id q10so2017156bka.31 for ; Wed, 05 Oct 2011 00:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=b7pEKwAYy2uRsjiEtxm7kkclCc0jXJd/5aBCaqEEbSk=; b=IHj8AjE+Hed9UHpmXMCD72/ZqGR38/zsOEG6WMk0aHE3y0cwGIOJmDzn4UUeyzz6v8 x3x6M1tjq+W1jaLeiWby72oC0IJeXlUJ2JctR1gTpRo0dGugC+5aNNNI4BxW+BMqQI1x s3bIjKCJHYogtB1y0/d1QkWgGB0JbMGR/Pglg= Received: by 10.204.133.141 with SMTP id f13mr1231451bkt.304.1317798118099; Wed, 05 Oct 2011 00:01:58 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.57.197 with HTTP; Wed, 5 Oct 2011 00:01:38 -0700 (PDT) In-Reply-To: References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> From: William Herrin Date: Wed, 5 Oct 2011 03:01:38 -0400 X-Google-Sender-Auth: U_CtYa9YHBZ-zh1EY86co6PXxDY Message-ID: To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:58:52 -0000 On Tue, Oct 4, 2011 at 11:20 PM, Randy Bush wrote: >>>> Unlike [RFC1918] address space, Shared CGN Space is not available for >>>> any purpose other than numbering the interfaces that connect a CGN to >>>> CPE. >>> and anyone who believes that is a serious fool. =A0put the crap out the= re, >>> and it will be used. >> People will do what people will do. That generally includes anything >> physically possible and a few things that no one would have believed >> were possible until someone does them > > the sentence is in there to pander to those who worry that this is just > another rfc 1918 extension. =A0as it actually *is* just another rfc 1918 > extension, the sentence is not only incorrect, as it *will* be > available, but intentionally misleading. Randy, I fail to see how process supporting functional requirements for address uniqueness amounts to "pandering." The sentence (and many like it) is in there because Shared CGN space has a different scope than RFC1918 within which uniqueness must be maintained. Like with the registries for global unicast space, there has to be a process by which facilitates maintaining uniqueness within the defined scope. The authors have selected "assigned by the ISP and only to CPE interfaces" as their process. Maybe that's what it should be. Maybe it isn't. But you're mistaken to describe it as pandering. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rbonica@juniper.net Wed Oct 5 06:08:08 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE9821F8C49 for ; Wed, 5 Oct 2011 06:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmAm3AszYdFW for ; Wed, 5 Oct 2011 06:08:08 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 12BDA21F8C48 for ; Wed, 5 Oct 2011 06:08:01 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP; Wed, 05 Oct 2011 06:11:16 PDT Received: from P-EMHUB11-HQ.jnpr.net (172.24.192.58) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 5 Oct 2011 06:10:07 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB11-HQ.jnpr.net (172.24.192.58) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 5 Oct 2011 06:10:07 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 5 Oct 2011 09:10:06 -0400 From: Ronald Bonica To: Brian E Carpenter Date: Wed, 5 Oct 2011 09:10:07 -0400 Thread-Topic: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 Thread-Index: AcyDBGftQJyssBDpTgizIi9KRjdvoAAWxzpA Message-ID: <13205C286662DE4387D9AF3AC30EF456D74606E18B@EMBX01-WF.jnpr.net> References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> In-Reply-To: <4E8BBD57.601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "draft-weil-shared-transition-space-request@tools.ietf.org" , "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 13:08:08 -0000 SGkgQnJpYW4sDQoNCkkgc3VzcGVjdCB0aGF0IGRyYWZ0LXdlaWwgd291bGQgYmUgbW9yZSBwYWxh dGFibGUgdG8gdGhlIGdlbmVyYWwgY29tbXVuaXR5IGlmIHRoZSBmaXJzdCBzZW50ZW5jZSB3ZXJl IHRydWUgYW5kIHRoZSBzZWNvbmQgc2VudGVuY2Ugd2FzIGRyb3BwZWQuIFRoaXMgd291bGQgZGl2 b3JjZSB0aGUgdHdvIGRyYWZ0cyBmcm9tIG9uZSBhbm90aGVyLCBhbGxvd2luZyBlYWNoIHRvIHNp bmsgb3Igc3dpbSBvbiBpdHMgb3duIG1lcml0cy4NCg0KRG8gSSBoYXZlIHRoYXQgcmlnaHQ/DQoN CiAgICAgICAgICAgICAgICAgICAgICBSb24NCg0KDQoNCj4gQnV0IG5vdywgZHJhZnQtd2VpbCBz YXlzOg0KPiANCj4gICAgVW5saWtlIFtSRkMxOTE4XSBhZGRyZXNzIHNwYWNlLCBTaGFyZWQNCj4g ICAgQ0dOIFNwYWNlIGlzIG5vdCBhdmFpbGFibGUgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4g bnVtYmVyaW5nIHRoZQ0KPiAgICBpbnRlcmZhY2VzIHRoYXQgY29ubmVjdCBhIENHTiB0byBDUEUu ICBBZGRpdGlvbmFsIGFwcGxpY2FiaWxpdHkgYW5kDQo+ICAgIGFuYWx5c2lzIG9mIFNoYXJlZCBD R04gU3BhY2UgaXMgZGVzY3JpYmVkIGluDQo+ICAgIFtJLUQuYmRna3MtYXJpbi1zaGFyZWQtdHJh bnNpdGlvbi1zcGFjZV0uDQo+IA0KPiBJZiB0aGUgZmlyc3Qgc2VudGVuY2UgaXMgdHJ1ZSwgaXQg bmVlZHMgdG8gdXNlIE1VU1QgTk9UIGxhbmd1YWdlLiBCdXQNCj4gdGhlbiwgbm90IG9ubHkgaXMg ZHJhZnQtYmRna3MgdW5uZWNlc3NhcnkgYXMgYSByZWZlcmVuY2UsIGJ1dCBhbHNvIGl0DQo+IGlz DQo+IGRlc2NyaWJpbmcgcHJhY3RpY2VzIHRoYXQgTVVTVCBOT1QgYmUgdXNlZC4gSW4gdGhhdCBj YXNlLCBkcmFmdC1iZGdrcw0KPiBuZWVkcyB0byBiZSBjb21wbGV0ZWx5IGRyb3BwZWQgLSBhbnkg b3RoZXIgcmVzdWx0IGlzIGNvbnRyYWRpY3RvcnkuDQo+IA0KPiAgICAgQnJpYW4NCj4gDQo+IA0K DQo= From Tina.Tsou.Zouting@huawei.com Tue Oct 4 18:19:00 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77EC21F8D39 for ; Tue, 4 Oct 2011 18:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfW+Sw0f6dMh for ; Tue, 4 Oct 2011 18:18:59 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA3421F8D37 for ; Tue, 4 Oct 2011 18:18:59 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK0062JJSTCL@szxga04-in.huawei.com> for opsawg@ietf.org; Wed, 05 Oct 2011 09:22:05 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00FQ9JSTGU@szxga04-in.huawei.com> for opsawg@ietf.org; Wed, 05 Oct 2011 09:22:05 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEB13822; Wed, 05 Oct 2011 09:22:03 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 05 Oct 2011 09:21:57 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.147]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Wed, 05 Oct 2011 09:21:55 +0800 Date: Wed, 05 Oct 2011 01:21:54 +0000 From: Tina TSOU In-reply-to: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> X-Originating-IP: [10.193.34.158] To: "George, Wes" , "opsawg@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: comments on draft-weil-shared-transition-space-request-07 Thread-index: AcyCpYwLPGVqYhebQkeX0KtoanjGbwAVufag X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> X-Mailman-Approved-At: Wed, 05 Oct 2011 08:01:02 -0700 Cc: "draft-weil-shared-transition-space-request@tools.ietf.org" , "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 01:19:00 -0000 Hi, In some cases, if we use https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/ https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/ https://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite/ draft-weil-shared-transition-space-request-07 seems not absolutely necessary. I do not oppose draft-weil, on the contrary, I support it. But some clarification text may be needed. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of George, Wes Sent: Tuesday, October 04, 2011 7:55 AM To: opsawg@ietf.org Cc: draft-weil-shared-transition-space-request@tools.ietf.org; Weil, Jason Subject: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 I've reviewed the last two versions of this document. Generally it's in much better shape, but I have a few questions. First, in -06, RFC1918 was listed as formally updated as I (and others) have recommended. Then in -07 that update was removed. What is the rationale for the change? The general idea I had was that RFC1918 is updated because of the address scope assumptions that you discuss in section 4.1 of -06 and in 5.1 of -07, and 5735 is updated to cover the new reservation itself. Second, the introduction section still conflicts with itself and with section 4 regarding its instructions on usage. I think we need to make a decision one way or another on the usage - either it is only to be used for CGN (MUST) or it is not and there are additional cases to be defined in draft-bdgks (SHOULD). Personally, I think that this document needs to stand on its own. If others wish to identify additional use cases for this space after it is defined, they are welcome to suggest them in draft-bdgks or another draft revising the guidance provided here, but I don't think it makes sense to say "use this space only for this use" and "see draft-bdgks for other uses". Perhaps simply removing the reference to bdgks will be a solution. In section 3 alternatives - I don't see much point in the "MUST NOT number interfaces in question from squat space" This is a SHOULD NOT if it belongs in the document at all. Squat space is being used today in quite a number of networks as a part of NAT applications. There are risks as the document notes, but MUST is too strong here, especially since this is a document allocating space for CGN, not discussing all details of the proper way to implement it. "use of squat space considered harmful" is another draft all by itself. You can make the point that this shared space allocation is preferable to squat space without needing a "must not use." Section 4: "Service Providers MUST filter incoming advertisements regarding Shared CGN Space." This needs to include text + a note to the RFC Editor that it also formally updates RFCxxxx (the number eventually assigned to draft-ietf-grow-no-more-unallocated-slash8s, currently in IETF LC), as it currently recommends that all route filtering be removed except for a list of the currently reserved IANA IPv4 space. Also, typically MUST means no exceptions. If there's exceptions, the more appropriate thing would be SHOULD...Unless Section 4/6 - "service providers MUST filter such packets on ingress" - this is too strong. This needs to be a SHOULD. Not all SPs even do ingress filtering, due to hardware limitations or other considerations. Section 5.2 - I don't understand the subheading "empirical data" - this all seems a discussion of known issues for CGN, which is largely a rehash of the cited draft. I think that you can make the point that the proposed CGN space doesn't materially make this better or worse without the discussion of consoles, etc, by simply saying " Based on testing documented in [I-D.donley-nat444-impacts], the CGN impacts on most applications that are not dependent on [application knowledge of scope or some similar qualifier] are comparable regardless of whether globally unique, Shared CGN Space, or [RFC1918] addresses are used. There is, however, a difference between the three alternatives in the treatment of 6to4. And then go on to discuss the details of 6to4 as you do in the next two paragraphs. Nit : In the abstract I believe you mean Carrier Grade NAT or Network Address translation, rather than just "carrier grade network" Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From wherrin@gmail.com Wed Oct 5 10:01:44 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2370E21F8CC7 for ; Wed, 5 Oct 2011 10:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdtRkIM-BEJ2 for ; Wed, 5 Oct 2011 10:01:42 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C92521F8CC6 for ; Wed, 5 Oct 2011 10:01:42 -0700 (PDT) Received: by bkaq10 with SMTP id q10so2713935bka.31 for ; Wed, 05 Oct 2011 10:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=TIoDZ5UNy8eAdTEVqqALp3nYn4RSIPvAHamImmkU3ZM=; b=r+Vc4ySk0z2HUHSUd/uPLMGyj6Xz75ImNGaGZacSk+ZAFYmO04LHdtdxoi+qecjxQF iRNQrZDN4aENLXVcFPGtC3GEXk/5cFQk5edrbDbF0P4AUUa2VHOBcCEDVRewYpee6SI2 6A/WpdH9gphAVG7DjKF0/ikUo6nC2IU9wyGoA= Received: by 10.204.157.154 with SMTP id b26mr1592613bkx.148.1317834290263; Wed, 05 Oct 2011 10:04:50 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.57.197 with HTTP; Wed, 5 Oct 2011 10:04:29 -0700 (PDT) In-Reply-To: References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> From: William Herrin Date: Wed, 5 Oct 2011 13:04:29 -0400 X-Google-Sender-Auth: YSvFDojO1HVrRp_TqeyEzApqdrw Message-ID: To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:01:44 -0000 On Tue, Oct 4, 2011 at 9:21 PM, Tina TSOU wr= ote: > In some cases, if we use > https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/ > https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/ > https://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite= / > > draft-weil-shared-transition-space-request-07 seems not absolutely necess= ary. Hi Tina, Thanks for the references! One common residential Internet use case where the reuse of RFC1918 for CGNs may fail without recourse is this: 1. Home user on CGN using RFC1918 space 2. Establishes VPN to workplace 3. Workplace uses RFC1918 inside its network overlapping the CGN IP address assignment. For example, Home User is assigned 10.1.2.3 with a gateway of 10.1.2.1. Establishes VPN from 10.1.2.3 to 192.51.100.1 (10.1.2.3 translated to 203.0.113.4 by the CGN). VPN client assigns 192.168.1.55 and reroutes the default through the VPN. Home user then attempts to connect to the company Intranet server at 10.1.2.3. This collides with the 10.1.2.3 assignment on the local ethernet interface. How does the equipment in the referenced drafts react in that scenario? Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Tina.Tsou.Zouting@huawei.com Wed Oct 5 10:43:54 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0A31F0C72 for ; Wed, 5 Oct 2011 10:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.352 X-Spam-Level: X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y58zJFWv5JmB for ; Wed, 5 Oct 2011 10:43:53 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 737D41F0C5A for ; Wed, 5 Oct 2011 10:43:53 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSL00JDHTE6LU@szxga05-in.huawei.com> for opsawg@ietf.org; Thu, 06 Oct 2011 01:46:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSL00E0PTDWVF@szxga05-in.huawei.com> for opsawg@ietf.org; Thu, 06 Oct 2011 01:46:54 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEB40744; Thu, 06 Oct 2011 01:46:52 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 06 Oct 2011 01:46:46 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.58]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Thu, 06 Oct 2011 01:46:42 +0800 Date: Wed, 05 Oct 2011 17:46:40 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.158] To: William Herrin Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 Thread-index: AcyCpYwLPGVqYhebQkeX0KtoanjGbwAVufagABBVf4AAEjExYA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:43:54 -0000 Bill, Good question. Would you show us a picture for precise understanding of this use case? Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: wherrin@gmail.com [mailto:wherrin@gmail.com] On Behalf Of William Her= rin Sent: Wednesday, October 05, 2011 10:04 AM To: Tina TSOU Cc: opsawg@ietf.org Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-reques= t-07 On Tue, Oct 4, 2011 at 9:21 PM, Tina TSOU wr= ote: > In some cases, if we use > https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/ > https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/ > https://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite= / > > draft-weil-shared-transition-space-request-07 seems not absolutely necess= ary. Hi Tina, Thanks for the references! One common residential Internet use case where the reuse of RFC1918 for CGNs may fail without recourse is this: 1. Home user on CGN using RFC1918 space 2. Establishes VPN to workplace 3. Workplace uses RFC1918 inside its network overlapping the CGN IP address assignment. For example, Home User is assigned 10.1.2.3 with a gateway of 10.1.2.1. Establishes VPN from 10.1.2.3 to 192.51.100.1 (10.1.2.3 translated to 203.0.113.4 by the CGN). VPN client assigns 192.168.1.55 and reroutes the default through the VPN. Home user then attempts to connect to the company Intranet server at 10.1.2.3. This collides with the 10.1.2.3 assignment on the local ethernet interface. How does the equipment in the referenced drafts react in that scenario? Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From brian.e.carpenter@gmail.com Wed Oct 5 12:58:30 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F359811E80F3 for ; Wed, 5 Oct 2011 12:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLckpo4E8gq5 for ; Wed, 5 Oct 2011 12:58:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBEF11E80C9 for ; Wed, 5 Oct 2011 12:58:29 -0700 (PDT) Received: by qadb12 with SMTP id b12so1997477qad.31 for ; Wed, 05 Oct 2011 13:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9fisgjPqdF2eTaoFKtRKcItD1Iri5gZhGfhjPcIC5xE=; b=xQgnaXTFo+x2f9XGjyE3woooYXt0rpNVgla5YhAgBnh5P5702s6LF7nsPq/u+KwSAo yrRz8G5pA7K5VU6U7iGQmPmZMFSfbdwdXg9/1vSrE7FZpDsxLr/rhx+w/RrM5kFHGYGQ OAiG7sSiGn8yO3z9RB5r4lnxmTr/mCJCMVAhE= Received: by 10.224.214.70 with SMTP id gz6mr2121359qab.343.1317844897914; Wed, 05 Oct 2011 13:01:37 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id dk4sm3314010qab.13.2011.10.05.13.01.33 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 13:01:36 -0700 (PDT) Message-ID: <4E8CB78E.8020209@gmail.com> Date: Thu, 06 Oct 2011 09:01:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> <13205C286662DE4387D9AF3AC30EF456D74606E18B@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74606E18B@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , "draft-weil-shared-transition-space-request@tools.ietf.org" , "Weil, Jason" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 19:58:30 -0000 Hi Ron, I think that is correct. This whole proposal will *never* be palatable to me, for reasons eloquently stated by Randy Bush. But (unlike Randy) I think it's better for the IETF to lay down appropriate restrictions, even though we know that ISPs will ignore them. IMNSHO it would have been much better if the IAB had agreed that this allocation was a policy matter to be left to IANA and the RIRs. Since the IAB chose to define it as a technical allocation, it is the IETF that has to take responsibility, and it is a lose-lose game for us. Whatever we decide is wrong. Also IMNSHO, RFC 1597 was a true disaster for the Internet. All these problems stem from there. Regards Brian On 2011-10-06 02:10, Ronald Bonica wrote: > Hi Brian, > > I suspect that draft-weil would be more palatable to the general community if the first sentence were true and the second sentence was dropped. This would divorce the two drafts from one another, allowing each to sink or swim on its own merits. > > Do I have that right? > > Ron > > > >> But now, draft-weil says: >> >> Unlike [RFC1918] address space, Shared >> CGN Space is not available for any purpose other than numbering the >> interfaces that connect a CGN to CPE. Additional applicability and >> analysis of Shared CGN Space is described in >> [I-D.bdgks-arin-shared-transition-space]. >> >> If the first sentence is true, it needs to use MUST NOT language. But >> then, not only is draft-bdgks unnecessary as a reference, but also it >> is >> describing practices that MUST NOT be used. In that case, draft-bdgks >> needs to be completely dropped - any other result is contradictory. >> >> Brian >> >> > From wherrin@gmail.com Wed Oct 5 15:16:19 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF99821F8CF2 for ; Wed, 5 Oct 2011 15:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxGfNRLNguLs for ; Wed, 5 Oct 2011 15:16:19 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C03D321F8C93 for ; Wed, 5 Oct 2011 15:16:18 -0700 (PDT) Received: by eye22 with SMTP id 22so910544eye.31 for ; Wed, 05 Oct 2011 15:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=26M1SC3/k0im8ASDpoMYpc+b2TCa9bj9bSXGkJocRwk=; b=sKEPOQOJrfJaAj/EoTalTMUKvygXxB4WX6ltPjxyYlDvf9rGn1HhBiqPqIhF2/DLNc tbs82n7grNAEzeaWANiF+tJW5aLT6mW70jcwutqW2wsA8YWrVFzVwUL39hkXSlOAIp+H oHMXKmRfp7b8rvdvvbnTqqgSXGJhVZXo9vL1I= Received: by 10.204.4.84 with SMTP id 20mr706bkq.119.1317853165307; Wed, 05 Oct 2011 15:19:25 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.57.197 with HTTP; Wed, 5 Oct 2011 15:19:04 -0700 (PDT) In-Reply-To: References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> From: William Herrin Date: Wed, 5 Oct 2011 18:19:04 -0400 X-Google-Sender-Auth: XdWMr3fNsY2QPQT2a_ZnPNsO3GI Message-ID: To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 22:16:19 -0000 On Wed, Oct 5, 2011 at 1:46 PM, Tina TSOU wr= ote: > Bill, > Good question. > Would you show us a picture for precise understanding of this use case? http://bill.herrin.us/network/cgn-example.gif Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja@bogus.com Thu Oct 6 21:41:06 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F004D21F8B68 for ; Thu, 6 Oct 2011 21:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjzNpHIXMWsH for ; Thu, 6 Oct 2011 21:41:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 594FD21F8B65 for ; Thu, 6 Oct 2011 21:41:05 -0700 (PDT) Received: from Zorch.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p974iApU021521 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 7 Oct 2011 04:44:11 GMT (envelope-from joelja@bogus.com) Message-ID: <4E8E839B.7000905@bogus.com> Date: Thu, 06 Oct 2011 21:44:11 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Owen DeLong References: <34E4F50CAFA10349A41E0756550084FB105D742B@PRVPEXVS04.corp.twcable.com> <13205C286662DE4387D9AF3AC30EF456D74606DF5A@EMBX01-WF.jnpr.net> <4E8BBD57.601@gmail.com> <4E8BC814.4010400@matthew.at> <27BC0C9A-B227-4E5A-A136-F5394E976AEC@delong.com> In-Reply-To: <27BC0C9A-B227-4E5A-A136-F5394E976AEC@delong.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 07 Oct 2011 04:44:14 +0000 (UTC) Cc: "opsawg@ietf.org" , "Weil, Jason" , draft-weil-shared-transition-space-request@tools.ietf.org Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 04:41:07 -0000 On 10/4/11 21:10 , Owen DeLong wrote: > I think that the categorical denial should be removed from > draft-weil. > > I believe that the other purposes mentioned in bdgks are useful and > carefully considered so as not to create conflicts (or at least not > conflicts outside of any given ISPs own actions) and render the space > more,not less, useful. > > I think that the two-document approach is sound and that eliminating > the second document would cause more problems than it would solve at > this point. section 2.1.2 of bdgks-03 clearly conflicts with with weil-07 requirements language, at a minimum that requires reconciliation. the former at least recognizes applications consistent with other private scope address ranges. > Owen > > On Oct 4, 2011, at 7:59 PM, Matthew Kaufman wrote: > >> On 10/4/2011 7:13 PM, Brian E Carpenter wrote: >>> >>> >>> But now, draft-weil says: >>> >>> Unlike [RFC1918] address space, Shared CGN Space is not available >>> for any purpose other than numbering the interfaces that connect >>> a CGN to CPE. Additional applicability and analysis of Shared >>> CGN Space is described in >>> [I-D.bdgks-arin-shared-transition-space]. >>> >>> If the first sentence is true, it needs to use MUST NOT language. >>> But then, not only is draft-bdgks unnecessary as a reference, but >>> also it is describing practices that MUST NOT be used. In that >>> case, draft-bdgks needs to be completely dropped - any other >>> result is contradictory. >>> >>> >> I think this is almost what I said back in August as well. Either >> you can use the space for other things (in which case Shared CGN >> Space *is* available for purposes other than numbering the >> interfaces that connect a CGN to CPE) or you cannot (in which case >> we most certainly won't need a second document describing how it is >> used in these other cases). >> >> Matthew Kaufman >> >> ps. Randy is correct anyway, in that no matter what this says (even >> if "MUST NOT"), it'll get used for the other purposes... and at >> this point there's some great suggestions of *what* other purposes >> over in braft-bdgks... >> _______________________________________________ OPSAWG mailing >> list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ OPSAWG mailing list > OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg > From mark@ellisonsoftware.com Fri Oct 7 07:41:24 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DC921F8BDB for ; Fri, 7 Oct 2011 07:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LNKenf5jc8Z for ; Fri, 7 Oct 2011 07:41:24 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F16F21F8BD8 for ; Fri, 7 Oct 2011 07:41:23 -0700 (PDT) Received: by wwf22 with SMTP id 22so4253725wwf.13 for ; Fri, 07 Oct 2011 07:44:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.134.157 with SMTP id s29mr572686wei.57.1317998674910; Fri, 07 Oct 2011 07:44:34 -0700 (PDT) Sender: mark@ellisonsoftware.com Received: by 10.216.23.149 with HTTP; Fri, 7 Oct 2011 07:44:34 -0700 (PDT) In-Reply-To: <20111007143330.6945.7834.idtracker@ietfa.amsl.com> References: <20111007143330.6945.7834.idtracker@ietfa.amsl.com> Date: Fri, 7 Oct 2011 10:44:34 -0400 X-Google-Sender-Auth: d5bdIkOdhgmTBgNho9pp32ACsf8 Message-ID: From: Mark Ellison To: opsawg@ietf.org, opsawg-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=0016e6dd97dcd51f1504aeb67af9 Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 14:41:24 -0000 --0016e6dd97dcd51f1504aeb67af9 Content-Type: text/plain; charset=ISO-8859-1 Hi- The initial (-00) draft for mapping SMIv2 Textual Conventions to XSD is now posted and available for review. This draft represents follow-on work to RFC 5935. Critical review and comments welcome! Regards, Mark ---------- Forwarded message ---------- From: Date: Fri, Oct 7, 2011 at 10:33 AM Subject: I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Expressing SNMP SMI Textual Conventions in XML Schema Definition Language Author(s) : Mark Ellison Bob Natale Filename : draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt Pages : 84 Date : 2011-10-07 This memo defines the IETF standard expression of Structure of Management Information (SMI) textual conventions in Extensible Markup Language (XML) Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --0016e6dd97dcd51f1504aeb67af9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi-

The initial (-00) draft for mapping SMIv2 Textual Co= nventions to XSD is now posted and available for review. =A0This draft repr= esents follow-on work to RFC 5935.

Critical review= and comments welcome!

Regards,

Mark

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Oct 7, 2011 at 10:33 AM
Subject: I-D Action: draft-ellison-op= sawg-smi-textual-conventions-xsd-00.txt
To: i-d-announce@ietf.org


A New Internet-Draft is a= vailable from the on-line Internet-Drafts directories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Expressing SNMP SMI Textual Con= ventions in XML Schema Definition Language
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mark Ellison
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Bob Natale
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ellison-opsawg-smi-textual-= conventions-xsd-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 84
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-07

=A0 This memo defines the IETF standard expression of Structure of
=A0 Management Information (SMI) textual conventions in Extensible Markup<= br> =A0 Language (XML) Schema Definition (XSD) language. =A0The primary
=A0 objective of this memo is to enable the production of XML documents =A0 that are as faithful to the SMI as possible, using XSD as the
=A0 validation mechanism.


A URL for this Internet-Draft is:
http://www.ietf.org/internet= -drafts/draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-d= rafts/draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--0016e6dd97dcd51f1504aeb67af9-- From j.schoenwaelder@jacobs-university.de Fri Oct 7 07:58:48 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8121F8C13 for ; Fri, 7 Oct 2011 07:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzmcKSelIB7X for ; Fri, 7 Oct 2011 07:58:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 576CA21F8C15 for ; Fri, 7 Oct 2011 07:58:43 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82B8520C7C; Fri, 7 Oct 2011 17:01:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BWVP-oLJFEwp; Fri, 7 Oct 2011 17:01:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E09F820CE7; Fri, 7 Oct 2011 17:01:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1A1DB1B07BB8; Fri, 7 Oct 2011 17:01:36 +0200 (CEST) Date: Fri, 7 Oct 2011 17:01:36 +0200 From: Juergen Schoenwaelder To: Mark Ellison Message-ID: <20111007150136.GA60009@elstar.local> Mail-Followup-To: Mark Ellison , opsawg@ietf.org References: <20111007143330.6945.7834.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 14:58:48 -0000 On Fri, Oct 07, 2011 at 10:44:34AM -0400, Mark Ellison wrote: > Hi- > > The initial (-00) draft for mapping SMIv2 Textual Conventions to XSD is now > posted and available for review. This draft represents follow-on work to > RFC 5935. > > Critical review and comments welcome! I like to know the difference (if any) between running 'smidump -f yang' and converting the resulting yang to XSD using pyang and your proposed mapping of TCs. Note that the translation done by smidump is currently a working group item of the NETMOD working group. http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-01 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sob@harvard.edu Fri Oct 7 13:26:52 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1BB21F8B06 for ; Fri, 7 Oct 2011 13:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRLL0gCqExgN for ; Fri, 7 Oct 2011 13:26:52 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id 49C0121F8AF3 for ; Fri, 7 Oct 2011 13:26:51 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 74702FC5F6E; Fri, 7 Oct 2011 16:30:05 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20111007203005.74702FC5F6E@newdev.eecs.harvard.edu> Date: Fri, 7 Oct 2011 16:30:05 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] draft-ellison-opsawg-smi-textual-conventions-xsd X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 20:26:52 -0000 from Mark Ellison: The authors would like the OPSAWG to consider this draft as a work item for the working group and request an agenda slot during the upcoming IETF meeting for the group to discuss and consider. please take a look at the ID and let the list know if you thing the WG should take this on. thanks Scott From j.schoenwaelder@jacobs-university.de Sun Oct 9 09:10:39 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945A421F8797 for ; Sun, 9 Oct 2011 09:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV0H02vo8IsM for ; Sun, 9 Oct 2011 09:10:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B82F721F8713 for ; Sun, 9 Oct 2011 09:10:38 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BC9720D06; Sun, 9 Oct 2011 18:10:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9AhiEDz3yXPH; Sun, 9 Oct 2011 18:10:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7823620D00; Sun, 9 Oct 2011 18:10:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43EDB1B17D5E; Sun, 9 Oct 2011 18:10:19 +0200 (CEST) Date: Sun, 9 Oct 2011 18:10:19 +0200 From: Juergen Schoenwaelder To: Benoit Claise , opsawg@ietf.org Message-ID: <20111009161019.GC99820@elstar.local> Mail-Followup-To: Benoit Claise , opsawg@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E919435.4010200@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 16:10:39 -0000 On Sun, Oct 09, 2011 at 02:31:49PM +0200, Benoit Claise wrote: > Hi Juergen, > > If you can find a few moments to give your feedback to this WGLC, > this would be appreciated. > This is a difficult draft as it requires broad knowledge of OPS, > which you have ;-) As stated before, I very much dislike section 4 - IETF data models are not organized around FCAPS. I will not explain again why or make another proposal how to fix this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From prvs=02632d179d=simon.leinen@switch.ch Sun Oct 9 10:20:04 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D9A21F8B28 for ; Sun, 9 Oct 2011 10:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV7tY52qpcwb for ; Sun, 9 Oct 2011 10:20:04 -0700 (PDT) Received: from bernina.switch.ch (bernina.switch.ch [IPv6:2001:620:0:14::22]) by ietfa.amsl.com (Postfix) with ESMTP id 388B221F8B39 for ; Sun, 9 Oct 2011 10:20:04 -0700 (PDT) Received: from macsl.switch.ch ([2001:620:0:4:226:8ff:fe05:cfee]) by bernina.switch.ch with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1RCx2f-00074P-Nb; Sun, 09 Oct 2011 19:20:01 +0200 From: Simon Leinen To: sob@harvard.edu (Scott O. Bradner) In-Reply-To: <20110916195501.6D4E9F6AE22@newdev.eecs.harvard.edu> (Scott O. Bradner's message of "Fri, 16 Sep 2011 15:55:01 -0400 (EDT)") References: <20110916195501.6D4E9F6AE22@newdev.eecs.harvard.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (darwin) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Sun, 09 Oct 2011 19:20:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2011 17:20:04 -0000 I have quickly reviewed those sub-areas of the document with which I'm familiar (SNMP/SMI, IPFIX, NETCONF) and browsed some of the others. On the whole I think that this is a useful document. Nit: I suggest to change text on page 16 as follows: OLD: The extension offers several advantages over IPFIX export, e.g. the NEW: The extension offers several advantages for IPFIX export, e.g. the (Because even with the extension in question, we're still doing IPFIX export, just better.) -- Simon. From bclaise@cisco.com Mon Oct 10 07:35:46 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E664221F85A8 for ; Mon, 10 Oct 2011 07:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgi9wwMe+RNv for ; Mon, 10 Oct 2011 07:35:46 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4CC21F8591 for ; Mon, 10 Oct 2011 07:35:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9AETxFo011654; Mon, 10 Oct 2011 16:29:59 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9AETxYc008091; Mon, 10 Oct 2011 16:29:59 +0200 (CEST) Message-ID: <4E930166.1060009@cisco.com> Date: Mon, 10 Oct 2011 16:29:58 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Simon Leinen References: <20110916195501.6D4E9F6AE22@newdev.eecs.harvard.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 14:35:47 -0000 Thanks Simon, Your proposed change makes sense. Regards, Benoit. > I have quickly reviewed those sub-areas of the document with which I'm > familiar (SNMP/SMI, IPFIX, NETCONF) and browsed some of the others. On > the whole I think that this is a useful document. > > Nit: I suggest to change text on page 16 as follows: > > OLD: > > The extension offers several advantages over IPFIX export, e.g. the > > NEW: > > The extension offers several advantages for IPFIX export, e.g. the > > (Because even with the extension in question, we're still doing IPFIX > export, just better.) From cdl@asgaard.org Mon Oct 10 09:59:06 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A8B21F8B8A for ; Mon, 10 Oct 2011 09:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwY--ClOaYev for ; Mon, 10 Oct 2011 09:59:05 -0700 (PDT) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 90EBD21F8B80 for ; Mon, 10 Oct 2011 09:59:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 862887ACD7C for ; Mon, 10 Oct 2011 16:59:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TGgDmHWxd1h for ; Mon, 10 Oct 2011 16:59:03 +0000 (UTC) Received: from [192.168.254.20] (74-93-4-130-sfba.hfc.comcastbusiness.net [74.93.4.130]) by asgaard.org (Postfix) with ESMTPSA id 8DF847ACD71 for ; Mon, 10 Oct 2011 16:59:03 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Oct 2011 09:59:02 -0700 Message-Id: To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [OPSAWG] Requests for slots X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 16:59:06 -0000 Greetings all, Please send your requests for agenda slots to the list this = week, if possible. Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf From bclaise@cisco.com Mon Oct 10 13:35:47 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C87821F85A8 for ; Mon, 10 Oct 2011 13:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtusA5Lg3mrL for ; Mon, 10 Oct 2011 13:35:46 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 88FA721F8591 for ; Mon, 10 Oct 2011 13:35:46 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9AKX4lt022740; Mon, 10 Oct 2011 22:33:04 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9AKWniI006404; Mon, 10 Oct 2011 22:32:49 +0200 (CEST) Message-ID: <4E935671.7060503@cisco.com> Date: Mon, 10 Oct 2011 22:32:49 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: opsawg@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> In-Reply-To: <20111009161019.GC99820@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:35:47 -0000 Juergen, Thanks for your feedback. While I understand your concern, I don't have a better classification in mind When I meet some of my customers who are not that experienced in network management and who wants "to do network management" , this is still the most suitable question. What do you want to do mister customer: Fault, Configuration, Accounting, Performance, and Security. And from there, we can drill down into each area. Exactly like the appendix A is an overview, this document goal is to give pointers. Regards, Benoit. > On Sun, Oct 09, 2011 at 02:31:49PM +0200, Benoit Claise wrote: >> Hi Juergen, >> >> If you can find a few moments to give your feedback to this WGLC, >> this would be appreciated. >> This is a difficult draft as it requires broad knowledge of OPS, >> which you have ;-) > As stated before, I very much dislike section 4 - IETF data models are > not organized around FCAPS. I will not explain again why or make > another proposal how to fix this. > > /js > From Tina.Tsou.Zouting@huawei.com Mon Oct 10 16:08:02 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56BA21F8B6D for ; Mon, 10 Oct 2011 16:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQJ9jhZ8RmMK for ; Mon, 10 Oct 2011 16:08:01 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 02CB221F8B7E for ; Mon, 10 Oct 2011 16:08:01 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV00M8VHLC5K@szxga04-in.huawei.com> for opsawg@ietf.org; Tue, 11 Oct 2011 07:08:00 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV00BBLHLCNR@szxga04-in.huawei.com> for opsawg@ietf.org; Tue, 11 Oct 2011 07:08:00 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI79505; Tue, 11 Oct 2011 07:07:59 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 07:07:57 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.58]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Tue, 11 Oct 2011 07:07:52 +0800 Date: Mon, 10 Oct 2011 23:07:51 +0000 From: Tina TSOU In-reply-to: <4E919478.4010107@cisco.com> X-Originating-IP: [10.193.34.158] To: Benoit Claise Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nJFGVYJsnDWeFqP2gf1E1A)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Thread-index: AQHMhn+cjZFsyMMxgUyN0mRKWci+jJV2MI8g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110916195501.6D4E9F6AE22@newdev.eecs.harvard.edu> <4E919478.4010107@cisco.com> Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 23:08:02 -0000 --Boundary_(ID_nJFGVYJsnDWeFqP2gf1E1A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, It's a good intention of having such a document to guide people who use them. Some quick comments: 1. It would be useful if a figure can be given describing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages. 2. Should network automation be included? 3. There are more work going on about 3.2. IPv6 Network Operations, would this document only include the RFCs or that ongoing work even for the transition technologies? 4. Some texts for how these protocols and data models be used for data center applications may be needed, if you are aware of the discussion in configuration and management group in ONF. That's about it, so far. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -------- Original Message -------- Subject: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Date: Fri, 16 Sep 2011 15:55:01 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) To: opsawg@ietf.org this starts a WGLC on draft-ietf-opsawg-management-stds-01 comments to the list by the end of Sept please Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --Boundary_(ID_nJFGVYJsnDWeFqP2gf1E1A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi all,

It’s a good intention of having such a docume= nt to guide people who use them.

 

Some quick comments:

1. It would be useful if a figure can be given desc= ribing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages.


-------- Original Message --------

Subject:

[OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01<= /o:p>

Date:

Fri, 16 Sep 2011 15:55:01 -0400 (EDT)

From:

sob@harvard.edu (Sco= tt O. Bradner)

To:

opsawg@ietf.org=

 

this starts a WGLC on draft-ietf-opsawg-management-stds-01 =

 
comments to the list by the end of Sept please
 
Scott
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org

https://www.i=
etf.org/mailman/listinfo/opsawg


 
--Boundary_(ID_nJFGVYJsnDWeFqP2gf1E1A)-- From j.schoenwaelder@jacobs-university.de Mon Oct 10 21:39:43 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25F921F8D27 for ; Mon, 10 Oct 2011 21:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.716 X-Spam-Level: X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzgjnicIVmZX for ; Mon, 10 Oct 2011 21:39:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3D08121F8D21 for ; Mon, 10 Oct 2011 21:39:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BA2020DDA; Tue, 11 Oct 2011 06:39:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nM9dQ7GWIDTV; Tue, 11 Oct 2011 06:39:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3B9020DD7; Tue, 11 Oct 2011 06:39:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 937DD1B1B48F; Tue, 11 Oct 2011 06:39:20 +0200 (CEST) Date: Tue, 11 Oct 2011 06:39:20 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20111011043920.GA9033@elstar.local> Mail-Followup-To: Benoit Claise , opsawg@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E935671.7060503@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 04:39:43 -0000 On Mon, Oct 10, 2011 at 10:32:49PM +0200, Benoit Claise wrote: > Juergen, > > Thanks for your feedback. > While I understand your concern, I don't have a better > classification in mind > When I meet some of my customers who are not that experienced in > network management and who wants "to do network management" , this > is still the most suitable question. What do you want to do mister > customer: Fault, Configuration, Accounting, Performance, and > Security. And from there, we can drill down into each area. Exactly > like the appendix A is an overview, this document goal is to give > pointers. I thought the purpose of the document is to educate people what the IETF has to offer and how the IETF organizes its data models. I fail to see how pretending data models are organized around FCAPS while this is de-facto not true can be a good approach if the goal is to achieve better understanding. And I am not talking about appendix A. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Tue Oct 11 02:05:53 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C04521F8B8A for ; Tue, 11 Oct 2011 02:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hRGZzauW+10 for ; Tue, 11 Oct 2011 02:05:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 541B221F8B8B for ; Tue, 11 Oct 2011 02:05:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9B8rEUO015129; Tue, 11 Oct 2011 10:53:14 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9B8rDmP007813; Tue, 11 Oct 2011 10:53:13 +0200 (CEST) Message-ID: <4E9403F9.6080800@cisco.com> Date: Tue, 11 Oct 2011 10:53:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: opsawg@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com> <20111011043920.GA9033@elstar.local> In-Reply-To: <20111011043920.GA9033@elstar.local> Content-Type: multipart/alternative; boundary="------------040504010306070505050509" Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 09:05:53 -0000 This is a multi-part message in MIME format. --------------040504010306070505050509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, > On Mon, Oct 10, 2011 at 10:32:49PM +0200, Benoit Claise wrote: >> Juergen, >> >> Thanks for your feedback. >> While I understand your concern, I don't have a better >> classification in mind >> When I meet some of my customers who are not that experienced in >> network management and who wants "to do network management" , this >> is still the most suitable question. What do you want to do mister >> customer: Fault, Configuration, Accounting, Performance, and >> Security. And from there, we can drill down into each area. Exactly >> like the appendix A is an overview, this document goal is to give >> pointers. > I thought the purpose of the document is to educate people what the > IETF has to offer Yes > and how the IETF organizes its data models. Organized, not really. This document is a list of pointers. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. > I fail > to see how pretending data models are organized around FCAPS We certainly don't pretend that data models are organized around FCAPS at the IETF. Here is an attempt to stress that point. OLD: 4. Network Management Data Models This section lists management data models standardized at IETF, which can be reused and applied to different management solutions. The subsections below are structured following the management application view and focus mainly on the management data models for the network management tasks fault, configuration, accounting, performance, and security management. NEW: 4. Network Management Data Models This section lists management data models standardized at IETF, which can be reused and applied to different management solutions. The subsections below are structured following the management application view and focus mainly on the management data models for the network management tasks fault, configuration, accounting, performance, and security (FCAPS) management. While the IETF does not logically organize data models around FCAPS, this classification was presented in this document to help the audience to review and select the appropriate data models based on his management needs. Regards, Benoit. > while > this is de-facto not true can be a good approach if the goal is to > achieve better understanding. And I am not talking about appendix A. > > /js > --------------040504010306070505050509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen, 
On Mon, Oct 10, 2011 at 10:32:49PM +0200, Benoit Claise wrote:

Juergen,

Thanks for your feedback.
While I understand your concern, I don't have a better
classification in mind
When I meet some of my customers who are not that experienced in
network management and who wants "to do network management" , this
is still the most suitable question. What do you want to do mister
customer: Fault, Configuration, Accounting, Performance, and
Security. And from there, we can drill down into each area. Exactly
like the appendix A is an overview, this document goal is to give
pointers.

I thought the purpose of the document is to educate people what the
IETF has to offer
Yes
and how the IETF organizes its data models.
Organized, not really. This document is a list of pointers.
   The purpose of this document is on the one hand to help system developers
   and users to select appropriate standard management protocols and
   data models to address relevant management needs.  On the other hand
   the document can be used as an overview and guideline by other
   Standard Development Organizations or bodies planning to use IETF
   management technologies and data models.


I fail
to see how pretending data models are organized around FCAPS
We certainly don't pretend that data models are organized around FCAPS at the IETF.
Here is an attempt to stress that point.
OLD:
4.  Network Management Data Models
   This section lists management data models standardized at IETF, which
   can be reused and applied to different management solutions.  The
   subsections below are structured following the management application
   view and focus mainly on the management data models for the network
   management tasks fault, configuration, accounting, performance, and
   security management.

NEW:

 
4.  Network Management Data Models

   This section lists management data models standardized at IETF, which
   can be reused and applied to different management solutions.  The
   subsections below are structured following the management application
   view and focus mainly on the management data models for the network
   management tasks fault, configuration, accounting, performance, and
   security (FCAPS) management. While the IETF does not logically organize 
   data models around FCAPS, this classification was presented in this 
   document to help the audience to review and select the appropriate data 
   models based on his management needs.

Regards, Benoit.

while
this is de-facto not true can be a good approach if the goal is to
achieve better understanding. And I am not talking about appendix A.

/js

--------------040504010306070505050509-- From j.schoenwaelder@jacobs-university.de Tue Oct 11 02:35:37 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186EC21F8541 for ; Tue, 11 Oct 2011 02:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbzGL5wVVijX for ; Tue, 11 Oct 2011 02:35:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 263D621F8461 for ; Tue, 11 Oct 2011 02:35:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8331520DB5; Tue, 11 Oct 2011 11:35:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OVQFWU6DNDWb; Tue, 11 Oct 2011 11:35:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9E4A20DAD; Tue, 11 Oct 2011 11:35:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6C7081B1BA3D; Tue, 11 Oct 2011 11:35:19 +0200 (CEST) Date: Tue, 11 Oct 2011 11:35:19 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20111011093519.GA9661@elstar.local> Mail-Followup-To: Benoit Claise , opsawg@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com> <20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9403F9.6080800@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 09:35:37 -0000 On Tue, Oct 11, 2011 at 10:53:13AM +0200, Benoit Claise wrote: > Juergen, > >On Mon, Oct 10, 2011 at 10:32:49PM +0200, Benoit Claise wrote: > >>Juergen, > >> > >>Thanks for your feedback. > >>While I understand your concern, I don't have a better > >>classification in mind > >>When I meet some of my customers who are not that experienced in > >>network management and who wants "to do network management" , this > >>is still the most suitable question. What do you want to do mister > >>customer: Fault, Configuration, Accounting, Performance, and > >>Security. And from there, we can drill down into each area. Exactly > >>like the appendix A is an overview, this document goal is to give > >>pointers. > >I thought the purpose of the document is to educate people what the > >IETF has to offer > Yes > >and how the IETF organizes its data models. > Organized, not really. This document is a list of pointers. > > The purpose of this document is on the one hand to help system developers > and users to select appropriate standard management protocols and > data models to address relevant management needs. On the other hand > the document can be used as an overview and guideline by other > Standard Development Organizations or bodies planning to use IETF > management technologies and data models. > > > > >I fail > >to see how pretending data models are organized around FCAPS > We certainly don't pretend that data models are organized around > FCAPS at the IETF. > Here is an attempt to stress that point. > OLD: > > > 4. Network Management Data Models > > This section lists management data models standardized at IETF, which > can be reused and applied to different management solutions. The > subsections below are structured following the management application > view and focus mainly on the management data models for the network > management tasks fault, configuration, accounting, performance, and > security management. > > NEW: > > > > 4. Network Management Data Models > > > This section lists management data models standardized at IETF, which > can be reused and applied to different management solutions. The > subsections below are structured following the management application > view and focus mainly on the management data models for the network > management tasks fault, configuration, accounting, performance, and > security (FCAPS) management. While the IETF does not logically organize > data models around FCAPS, this classification was presented in this > document to help the audience to review and select the appropriate data > models based on his management needs. > > Regards, Benoit. > > >while > >this is de-facto not true can be a good approach if the goal is to > >achieve better understanding. And I am not talking about appendix A. You don't get my point. I believe the whole section 4 needs to be replaced. The simple facts are that we have a few base abstractions that are key to understand (e.g. interfaces and interface stacks; physical entities) plus lots of interface type specific data models (usually in the transmission branches) plus a bunch of protocol specific data models (e.g. layers three routing protocols and layer four protocols). While attempts were made to create more generic functions, they only rarely have been successful. Most successful have been monitoring data models. Writable configuration data models have been successful only in a few cases, but tend to have higher changes of success the lower they are in the protocol stack. The hope is that NETCONF/YANG will have more success in the future but we need to wait and see. Perhaps it is also necessary to mention that technology specific data models can be happily be defined by other SDOs and that in some cases the IETF even transferred stuff to other SDOs (e.g. in the IEEE 802 case). I think somethine along these lines is the news that needs to be conveyed, backed up by pointers to prominent examples. If I look at the current text, I read about the Meter MIB (which box on the market implements that?), about the DISMAN-EXPRESSION-MIB (which vendors do support that?), and I could probably name a few more candidates. To sum up: I have a serious problem with the _whole_ section 4. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Tue Oct 11 04:04:11 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD621F8C35 for ; Tue, 11 Oct 2011 04:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcuFQr2zKATk for ; Tue, 11 Oct 2011 04:04:11 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7778721F87D9 for ; Tue, 11 Oct 2011 04:04:10 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9BB42jq003227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2011 13:04:03 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9BB3xOs011026; Tue, 11 Oct 2011 13:04:01 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 13:03:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Oct 2011 13:03:56 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402C42A39@DEMUEXC006.nsn-intra.net> In-Reply-To: <20111011093519.GA9661@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 Thread-Index: AcyH+SKH+cka8v9zRpSyz6nES6x6sAAB6qOQ References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com> <20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Benoit Claise" X-OriginalArrivalTime: 11 Oct 2011 11:03:57.0987 (UTC) FILETIME=[79666730:01CC8805] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 11:04:12 -0000 Dear Juergen, it is correct that IETF developed MIBs for different technologies, interfaces and protocols. I believe, it is also correct that a huge number of IETF data models can be used for the realization of network management tasks like fault management. The main audience of this particular document is the developers and SDOs outside of IETF, which want to use IETF Network Management standards. This specific audience does not know much about the IETF MIBs. They rather think on Network Management from the application point of view and have the management tasks like fault, configuration and performance management in mind. With this management task view in mind they are not interested in transmission or protocol related MIBs. The current structure of the document aims to address this need and categorizes the data models fitting the view of management tasks. I reported in recent IETF meetings the positive feedback from SGIP and IEC guys on the current document. IOW the document is not for IETF insiders like us and IETF guys wouldn't need such a document at all. I think we can easily find the appropriate MIB for an issue in focus and others interested on different technology MIBs can easily find them in the Internet (e.g. at http://www.simpleweb.org/ietf/rfcs/rfcbytopic.php). As discussed and noted in the Prague meeting it might be interesting to have an overall list of MIBs as additional information in the draft, by listing the technology related MIBs and other categories, not matching to management tasks. For this we need your help as contributor. Another option could be to write a supplementary Internet-Draft, which aims to give an exhaustive overview of all IETF MIBs focusing also on the technology and protocol related MIBs, as you described, if there is sufficient interest. For addressing the needs of the aimed audience and to achieve better understanding I believe the current document structure is justifiable. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, October 11, 2011 11:35 AM > To: Benoit Claise > Cc: opsawg@ietf.org; Ersue, Mehmet (NSN - DE/Munich) > Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 >=20 > On Tue, Oct 11, 2011 at 10:53:13AM +0200, Benoit Claise wrote: > > Juergen, > > >On Mon, Oct 10, 2011 at 10:32:49PM +0200, Benoit Claise wrote: > > >>Juergen, > > >> > > >>Thanks for your feedback. > > >>While I understand your concern, I don't have a better > > >>classification in mind > > >>When I meet some of my customers who are not that experienced in > > >>network management and who wants "to do network management" , this > > >>is still the most suitable question. What do you want to do mister > > >>customer: Fault, Configuration, Accounting, Performance, and > > >>Security. And from there, we can drill down into each area. Exactly > > >>like the appendix A is an overview, this document goal is to give > > >>pointers. > > >I thought the purpose of the document is to educate people what the > > >IETF has to offer > > Yes > > >and how the IETF organizes its data models. > > Organized, not really. This document is a list of pointers. > > > > The purpose of this document is on the one hand to help system > developers > > and users to select appropriate standard management protocols and > > data models to address relevant management needs. On the other hand > > the document can be used as an overview and guideline by other > > Standard Development Organizations or bodies planning to use IETF > > management technologies and data models. > > > > > > > > >I fail > > >to see how pretending data models are organized around FCAPS > > We certainly don't pretend that data models are organized around > > FCAPS at the IETF. > > Here is an attempt to stress that point. > > OLD: > > > > > > 4. Network Management Data Models > > > > This section lists management data models standardized at IETF, which > > can be reused and applied to different management solutions. The > > subsections below are structured following the management application > > view and focus mainly on the management data models for the network > > management tasks fault, configuration, accounting, performance, and > > security management. > > > > NEW: > > > > > > > > 4. Network Management Data Models > > > > > > This section lists management data models standardized at IETF, which > > can be reused and applied to different management solutions. The > > subsections below are structured following the management application > > view and focus mainly on the management data models for the network > > management tasks fault, configuration, accounting, performance, and > > security (FCAPS) management. While the IETF does not logically organize > > data models around FCAPS, this classification was presented in this > > document to help the audience to review and select the appropriate data > > models based on his management needs. > > > > Regards, Benoit. > > > > >while > > >this is de-facto not true can be a good approach if the goal is to > > >achieve better understanding. And I am not talking about appendix A. >=20 > You don't get my point. I believe the whole section 4 needs to be > replaced. >=20 > The simple facts are that we have a few base abstractions that are key > to understand (e.g. interfaces and interface stacks; physical > entities) plus lots of interface type specific data models (usually in > the transmission branches) plus a bunch of protocol specific data > models (e.g. layers three routing protocols and layer four > protocols). While attempts were made to create more generic functions, > they only rarely have been successful. Most successful have been > monitoring data models. Writable configuration data models have been > successful only in a few cases, but tend to have higher changes of > success the lower they are in the protocol stack. The hope is that > NETCONF/YANG will have more success in the future but we need to wait > and see. Perhaps it is also necessary to mention that technology > specific data models can be happily be defined by other SDOs and that > in some cases the IETF even transferred stuff to other SDOs (e.g. in > the IEEE 802 case). >=20 > I think somethine along these lines is the news that needs to be > conveyed, backed up by pointers to prominent examples. If I look at > the current text, I read about the Meter MIB (which box on the market > implements that?), about the DISMAN-EXPRESSION-MIB (which vendors do > support that?), and I could probably name a few more candidates. >=20 > To sum up: I have a serious problem with the _whole_ section 4. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Oct 11 04:12:58 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A976F21F8D75 for ; Tue, 11 Oct 2011 04:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDu50YQXTERm for ; Tue, 11 Oct 2011 04:12:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7A54421F8D7B for ; Tue, 11 Oct 2011 04:12:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6046820DDD; Tue, 11 Oct 2011 13:12:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MAJp5C8DThaQ; Tue, 11 Oct 2011 13:12:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8ECD20DA9; Tue, 11 Oct 2011 13:12:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B70041B1C536; Tue, 11 Oct 2011 13:12:40 +0200 (CEST) Date: Tue, 11 Oct 2011 13:12:40 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20111011111240.GB10251@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Benoit Claise , opsawg@ietf.org References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com> <20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402C42A39@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6402C42A39@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 11:12:58 -0000 On Tue, Oct 11, 2011 at 01:03:56PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear Juergen, > > it is correct that IETF developed MIBs for different technologies, > interfaces and protocols. I believe, it is also correct that a huge > number of IETF data models can be used for the realization of network > management tasks like fault management. > > The main audience of this particular document is the developers and SDOs > outside of IETF, which want to use IETF Network Management standards. > This specific audience does not know much about the IETF MIBs. They > rather think on Network Management from the application point of view > and have the management tasks like fault, configuration and performance > management in mind. With this management task view in mind they are not > interested in transmission or protocol related MIBs. I believe we are better off telling people working in other SDOs what the IETF has to provide instead of just making them read what they like to read in the first place. [...] > For addressing the needs of the aimed audience and to achieve better > understanding I believe the current document structure is justifiable. I do not agree - we simply waste time and energy if we do not manage to convey how things are done in the IETF. We have 20+ years of data models history and experience in the IETF. I have been involved for about 15 years. There simply is no FCAPS structure in what is being done in the IETF. And how can pointing to data models that are hardly implemented be of any help? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Tue Oct 11 05:47:34 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D5921F8D96 for ; Tue, 11 Oct 2011 05:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTZtOCBQeDlx for ; Tue, 11 Oct 2011 05:47:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4303021F8D66 for ; Tue, 11 Oct 2011 05:47:33 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9BClW22015651; Tue, 11 Oct 2011 14:47:32 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9BClVUL000829; Tue, 11 Oct 2011 14:47:31 +0200 (CEST) Message-ID: <4E943AE3.1040902@cisco.com> Date: Tue, 11 Oct 2011 14:47:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: opsawg@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com> <20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> In-Reply-To: <20111011093519.GA9661@elstar.local> Content-Type: multipart/alternative; boundary="------------010406090604020500090400" Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:47:34 -0000 This is a multi-part message in MIME format. --------------010406090604020500090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, [Dear all, please share your view on the usefulness of section 4.] >>> while >>> this is de-facto not true can be a good approach if the goal is to >>> achieve better understanding. And I am not talking about appendix A. > You don't get my point. I believe the whole section 4 needs to be > replaced. > > The simple facts are that we have a few base abstractions that are key > to understand (e.g. interfaces and interface stacks; physical > entities) plus lots of interface type specific data models (usually in > the transmission branches) plus a bunch of protocol specific data > models (e.g. layers three routing protocols and layer four > protocols). BC: But they're not key to understand for the audience (referring to the abstract for that) when the question is to able to compare the different characteristics of data models such as MIB modules, IPFIX Information Elements, SYSLOG Structured Data Elements, and YANG modules... with some examples. This would be key to understand to explain the ifIndex, the interface stacks, etc... if this document would be MIB centric only. > While attempts were made to create more generic functions, > they only rarely have been successful. Most successful have been > monitoring data models. Writable configuration data models have been > successful only in a few cases, but tend to have higher changes of > success the lower they are in the protocol stack. The hope is that > NETCONF/YANG will have more success in the future but we need to wait > and see. > Perhaps it is also necessary to mention that technology > specific data models can be happily be defined by other SDOs and that > in some cases the IETF even transferred stuff to other SDOs (e.g. in > the IEEE 802 case). BC: Agreed on the last point. This should be mentioned. > > I think somethine along these lines is the news that needs to be > conveyed, backed up by pointers to prominent examples. If I look at > the current text, I read about the Meter MIB (which box on the market > implements that?), BC: Btw, the Meter MIB has been identified has to be removed, as we removed RTFM in a previous version. So the following paragraph will disappear. Traffic Flow Measurement: Meter MIB [RFC2720 ] defines a MIB for use in the 'Traffic Flow Measurement: Architecture' [RFC2722 ], in particular for specifying the flows to be measured and provides a mechanism for retrieving flow data from the meter using SNMP. > about the DISMAN-EXPRESSION-MIB (which vendors do > support that?), BC: My company does, btw, > and I could probably name a few more candidates. > > To sum up: I have a serious problem with the _whole_ section 4. BC: Ideally what do you want to do from here? 1. remove the entire section 4? Well, on one side, when the read the charter, it doesn't mention the data models (A) Development of a BCP document that will provide guidelines for authors and a reference for reviewers of IETF documents that specify new protocols or protocol extensions about the information about operational and manageability requirements that needs to be covered in these documents However, if we don't cover the data models, then I question the usefulness of the document. 2. complete the section 4 with way more MIB modules. Some years ago, I discussed with Dave Harrington about producing a draft containing the most useful MIB modules at the IETF. Sound interested, but how to classify them? The only solution was to query all vendors and to rank the MIB modules accordingly. Obviously, this was a gigantic task... which never took off. And I don't want to do that. 3. change the section 4 structure, but as you mentioned "I will not make another proposal how to fix this" Regards, Benoit. > > /js > --------------010406090604020500090400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen,

[Dear all, please share your view on the usefulness of section 4.]
while
this is de-facto not true can be a good approach if the goal is to
achieve better understanding. And I am not talking about appendix A.

You don't get my point. I believe the whole section 4 needs to be
replaced.

The simple facts are that we have a few base abstractions that are key
to understand (e.g. interfaces and interface stacks; physical
entities) plus lots of interface type specific data models (usually in
the transmission branches) plus a bunch of protocol specific data
models (e.g. layers three routing protocols and layer four
protocols).
BC: But they're not key to understand for the audience (referring to the abstract for that) when the question is to able to compare the different characteristics of data models such as MIB modules, IPFIX Information Elements, SYSLOG Structured Data Elements, and YANG modules... with some examples.
This would be key to understand to explain the ifIndex, the interface stacks, etc... if this document would be MIB centric only.
While attempts were made to create more generic functions,
they only rarely have been successful. Most successful have been
monitoring data models. Writable configuration data models have been
successful only in a few cases, but tend to have higher changes of
success the lower they are in the protocol stack. The hope is that
NETCONF/YANG will have more success in the future but we need to wait
and see. 

Perhaps it is also necessary to mention that technology
specific data models can be happily be defined by other SDOs and that
in some cases the IETF even transferred stuff to other SDOs (e.g. in
the IEEE 802 case).
BC: Agreed on the last point. This should be mentioned.

I think somethine along these lines is the news that needs to be
conveyed, backed up by pointers to prominent examples. If I look at
the current text, I read about the Meter MIB (which box on the market
implements that?),
BC: Btw, the Meter MIB has been identified has to be removed, as we removed RTFM in a previous version.
So the following paragraph will disappear.
   Traffic Flow Measurement: Meter MIB [RFC2720] defines a MIB for use
   in the 'Traffic Flow Measurement: Architecture' [RFC2722], in
   particular for specifying the flows to be measured and provides a
   mechanism for retrieving flow data from the meter using SNMP.

about the DISMAN-EXPRESSION-MIB (which vendors do
support that?),
BC: My company does, btw,
and I could probably name a few more candidates.

To sum up: I have a serious problem with the _whole_ section 4.
BC:
Ideally what do you want to do from here?
1. remove the entire section 4?
Well, on one side, when the read the charter, it doesn't mention the data models
(A) Development of a BCP document that will provide guidelines for
authors and a reference for reviewers of IETF documents that specify
new protocols or protocol extensions about the information about
operational and manageability requirements that needs to be covered in
these documents
However, if we don't cover the data models, then I question the usefulness of the document.

2. complete the section 4 with way more MIB modules. Some years ago, I discussed with Dave Harrington about producing a draft containing the most useful MIB modules at the IETF. Sound interested, but how to classify them? The only solution was to query all vendors and to rank the MIB modules accordingly. Obviously, this was a gigantic task... which never took off. And I don't want to do that.

3. change the section 4 structure, but as you mentioned "I will not  make another proposal how to fix this"

Regards, Benoit.

/js

--------------010406090604020500090400-- From j.schoenwaelder@jacobs-university.de Tue Oct 11 06:17:13 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D286B21F8D8B for ; Tue, 11 Oct 2011 06:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KxPWUmyybxT for ; Tue, 11 Oct 2011 06:17:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 18DD221F8CE5 for ; Tue, 11 Oct 2011 06:17:13 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 771D520D10; Tue, 11 Oct 2011 15:17:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aGZAcOj8LqH7; Tue, 11 Oct 2011 15:17:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFF2620CBF; Tue, 11 Oct 2011 15:17:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B97891B1C952; Tue, 11 Oct 2011 15:16:56 +0200 (CEST) Date: Tue, 11 Oct 2011 15:16:56 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20111011131654.GA10662@elstar.local> Mail-Followup-To: Benoit Claise , opsawg@ietf.org, "Ersue, Mehmet (NSN - DE/Munich)" References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com> <20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> <4E943AE3.1040902@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E943AE3.1040902@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:17:13 -0000 On Tue, Oct 11, 2011 at 02:47:31PM +0200, Benoit Claise wrote: > >To sum up: I have a serious problem with the _whole_ section 4. > BC: > Ideally what do you want to do from here? > 1. remove the entire section 4? > Well, on one side, when the read the charter, it doesn't mention the > data models > > (A) Development of a BCP document that will provide guidelines for > authors and a reference for reviewers of IETF documents that specify > new protocols or protocol extensions about the information about > operational and manageability requirements that needs to be covered in > these documents > > However, if we don't cover the data models, then I question the > usefulness of the document. > > 2. complete the section 4 with way more MIB modules. Some years ago, > I discussed with Dave Harrington about producing a draft containing > the most useful MIB modules at the IETF. Sound interested, but how > to classify them? The only solution was to query all vendors and to > rank the MIB modules accordingly. Obviously, this was a gigantic > task... which never took off. And I don't want to do that. > > 3. change the section 4 structure, but as you mentioned "I will not > make another proposal how to fix this" It seems I am expressing myself extremely badly. (And taking words out of context does not really help either I think.) Lets simply hear other opinions from people who have read section 4. /js PS: The charter axe does not really swing well because the quoted text dates back to at least 2007-06-13 while Mehmet's I-D first appeared on 2010-10-18, and Mehmet's I-D is on purpose very different from the quoted charter text. See also Mehmet's Beijing slides that subsequently lead to the WG adoption of this document. (As a matter of fact, adopted work items do not make it into the charter in the opsawg.) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Tue Oct 11 08:32:48 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD0921F8DD8 for ; Tue, 11 Oct 2011 08:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9LsS6bgplqV for ; Tue, 11 Oct 2011 08:32:48 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 839BF21F8CA3 for ; Tue, 11 Oct 2011 08:32:46 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr09.btconnect.com with SMTP id ESS14968; Tue, 11 Oct 2011 16:32:41 +0100 (BST) Message-ID: <02de01cc8821$fb680ba0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Benoit Claise" References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com><20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com><20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> Date: Tue, 11 Oct 2011 16:27:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E946199.001C, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.11.145415:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4E94619B.00B1,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:32:49 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" To: "Benoit Claise" Cc: Sent: Tuesday, October 11, 2011 11:35 AM > On Tue, Oct 11, 2011 at 10:53:13AM +0200, Benoit Claise wrote: > > Juergen, > > >On Mon, Oct 10, 2011 at 10:32:49PM +0200, Benoit Claise wrote: > > >>Juergen, > > >> > > >>Thanks for your feedback. > > >>While I understand your concern, I don't have a better > > >>classification in mind > > >>When I meet some of my customers who are not that experienced in > > >>network management and who wants "to do network management" , this > > >>is still the most suitable question. What do you want to do mister > > >>customer: Fault, Configuration, Accounting, Performance, and > > >>Security. And from there, we can drill down into each area. Exactly > > >>like the appendix A is an overview, this document goal is to give > > >>pointers. > > >I thought the purpose of the document is to educate people what the > > >IETF has to offer > > Yes > > >and how the IETF organizes its data models. > > Organized, not really. This document is a list of pointers. > > > > The purpose of this document is on the one hand to help system developers > > and users to select appropriate standard management protocols and > > data models to address relevant management needs. On the other hand > > the document can be used as an overview and guideline by other > > Standard Development Organizations or bodies planning to use IETF > > management technologies and data models. > > > > >I fail > > >to see how pretending data models are organized around FCAPS > > We certainly don't pretend that data models are organized around > > FCAPS at the IETF. > > Here is an attempt to stress that point. > > OLD: > > > > 4. Network Management Data Models > > > > This section lists management data models standardized at IETF, which > > can be reused and applied to different management solutions. The > > subsections below are structured following the management application > > view and focus mainly on the management data models for the network > > management tasks fault, configuration, accounting, performance, and > > security management. > > > > NEW: > > > > 4. Network Management Data Models > > > > This section lists management data models standardized at IETF, which > > can be reused and applied to different management solutions. The > > subsections below are structured following the management application > > view and focus mainly on the management data models for the network > > management tasks fault, configuration, accounting, performance, and > > security (FCAPS) management. While the IETF does not logically organize > > data models around FCAPS, this classification was presented in this > > document to help the audience to review and select the appropriate data > > models based on his management needs. > > > > Regards, Benoit. > > > > >while > > >this is de-facto not true can be a good approach if the goal is to > > >achieve better understanding. And I am not talking about appendix A. > > You don't get my point. I believe the whole section 4 needs to be > replaced. > > The simple facts are that we have a few base abstractions that are key > to understand (e.g. interfaces and interface stacks; physical > entities) plus lots of interface type specific data models (usually in > the transmission branches) plus a bunch of protocol specific data > models (e.g. layers three routing protocols and layer four > protocols). While attempts were made to create more generic functions, > they only rarely have been successful. Most successful have been > monitoring data models. Writable configuration data models have been > successful only in a few cases, but tend to have higher changes of > success the lower they are in the protocol stack. The hope is that > NETCONF/YANG will have more success in the future but we need to wait > and see. Perhaps it is also necessary to mention that technology > specific data models can be happily be defined by other SDOs and that > in some cases the IETF even transferred stuff to other SDOs (e.g. in > the IEEE 802 case). > > I think somethine along these lines is the news that needs to be > conveyed, backed up by pointers to prominent examples. If I look at > the current text, I read about the Meter MIB (which box on the market > implements that?), about the DISMAN-EXPRESSION-MIB (which vendors do > support that?), and I could probably name a few more candidates. > > To sum up: I have a serious problem with the _whole_ section 4. My concern is with all the other sections as well:-) I do not believe that we have the resources to do the subject justice, which is similar to a view that Juergen expressed some time ago. Juergen's suggestion of a narrower, more tightly-focused (and, I would say, stand-alone) document, would make a lot more sense. If we stay with the all encompassing approach, then I do think that FCAPS is needed, since it is how other organisaitions approach the topic, even though we do not. And by including the MPLS/ITU-T definition of OAM, but excluding any of the protocols which would be understood by those to come under that name, given the current fiery debate about which way OAM for MPLS-TP should go, on the IETF and MPLS lists, seems like tossing a hand grenade into a petrol tanker. Uh huh, not very helpful:-( Tom Petch > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ From randy_presuhn@mindspring.com Tue Oct 11 11:04:03 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D9F21F86EC for ; Tue, 11 Oct 2011 11:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZWRqZWXdARF for ; Tue, 11 Oct 2011 11:04:03 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 61B0D21F8BD8 for ; Tue, 11 Oct 2011 11:04:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ldoBjFAx5j2qStDJlVLISIliJVro+b8cDOw2qB8e19ZaLzn2i1pA3wyh1NexMpuR; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.38.144.235] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RDggK-0007hM-He for opsawg@ietf.org; Tue, 11 Oct 2011 14:04:00 -0400 Message-ID: <006301cc8840$6260d760$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com><20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com><20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com><20111011093519.GA9661@elstar.local><80A0822C5E9A4440A5117C2F4CD36A6402C42A39@DEMUEXC006.nsn-intra.net> <20111011111240.GB10251@elstar.local> Date: Tue, 11 Oct 2011 11:05:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288c480ca20c68e7107c99e94e855e9e20c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.235 Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:04:03 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Ersue, Mehmet (NSN - DE/Munich)" > Cc: > Sent: Tuesday, October 11, 2011 4:12 AM > Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 ... > I do not agree - we simply waste time and energy if we do not manage > to convey how things are done in the IETF. We have 20+ years of data > models history and experience in the IETF. I have been involved for > about 15 years. There simply is no FCAPS structure in what is being > done in the IETF. ... Experience shows that FCAPS is pretty useless for purposes of *structuring* models. FCAPS can be helpful for sorting out application requirements, but at the level of the models it might be better to consider FCAPS as "aspects" - but that'd be a research topic, since the tools we've given ourselves provide woefully inadequate support for aspect- oriented model building. If we mention FCAPS, we need to immediately note that this is a theory that has had little effect on IETF model-building practice, and is not used as an organizing priciple in our models. Randy From mark@ellisonsoftware.com Wed Oct 12 07:22:52 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3208F21F8C14 for ; Wed, 12 Oct 2011 07:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo5hGfT8GznF for ; Wed, 12 Oct 2011 07:22:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4C221F8BC5 for ; Wed, 12 Oct 2011 07:22:51 -0700 (PDT) Received: by iaby26 with SMTP id y26so69491iab.31 for ; Wed, 12 Oct 2011 07:22:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.132.67 with SMTP id ht3mr33855053icc.35.1318429370491; Wed, 12 Oct 2011 07:22:50 -0700 (PDT) Sender: mark@ellisonsoftware.com Received: by 10.231.206.7 with HTTP; Wed, 12 Oct 2011 07:22:50 -0700 (PDT) In-Reply-To: <20111007150136.GA60009@elstar.local> References: <20111007143330.6945.7834.idtracker@ietfa.amsl.com> <20111007150136.GA60009@elstar.local> Date: Wed, 12 Oct 2011 10:22:50 -0400 X-Google-Sender-Auth: _6cGf_LUGK8aKwE1fAb1JcS0834 Message-ID: From: Mark Ellison To: Juergen Schoenwaelder , opsawg@ietf.org Content-Type: multipart/alternative; boundary=20cf307f34ee4a23a504af1ac2c5 Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:22:52 -0000 --20cf307f34ee4a23a504af1ac2c5 Content-Type: text/plain; charset=ISO-8859-1 inline... On Fri, Oct 7, 2011 at 11:01 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Oct 07, 2011 at 10:44:34AM -0400, Mark Ellison wrote: > > Hi- > > > > The initial (-00) draft for mapping SMIv2 Textual Conventions to XSD is > now > > posted and available for review. This draft represents follow-on work to > > RFC 5935. > > > > Critical review and comments welcome! > > I like to know the difference (if any) between running 'smidump -f > yang' and converting the resulting yang to XSD using pyang and your > proposed mapping of TCs. Note that the translation done by smidump is > currently a working group item of the NETMOD working group. > > http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-01 > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > Juergen, The draft-ellison-opsawg-smi-textual-conventions-xsd is simply the anticipated follow-on to a previous OPSAWG work item- see RFC 5935. The mapping in draft-ellison-opsawg-smi-textual-conventions-xsd, as compared to the SMIv2-->YANG-->XSD production is more faithful to and better reflects the semantics and base data types of SMIv2 textual conventions. I believe you will see that the proposed mapping in draft-ellison-opsawg-smi-textual-conventions-xsd is simpler, more direct and lends itself to a less complex tool set. The mapping described in draft-ellison-opsawg-smi-textual-conventions-xsd has no dependencies on YANG and the resulting XSD has no dependencies upon YANG namespaces. Rather, there is a dependency upon the namespace established within RFC 5935. In other words, when TCs are mapped from SMIv2 to XSD using the algorithms described in draft-ellison-opsawg-smi-textual-conventions-xsd, the resulting XSD is built upon the XSD simple types, as defined in RFC 5935, representing the mapped SMIv2 base type. Thus the relationship between TC refinement and base type as established within the SMIv2 is maintained within the XSD. I believe this essential relationship is lost in the SMIv2-->YANG-->XSD mapping currently produced by smidump and pyang. My hope is that participants of the OPSAWG see the value of such an algorithmic, direct mapping from SMIv2 to XSD for textual conventions, that is faithful to the original SMIv2, that deterministically extends from the mapped SMIv2 base types and, that has no dependencies on YANG intermediate forms or YANG namespaces in the resulting XSD. Kindly review and consider draft-ellison-opsawg-smi-textual-conventions-xsd as a work item for the OPSAWG... Regards, Mark -- Mark Ellison http://EllisonSoftware.com/ --20cf307f34ee4a23a504af1ac2c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
inline...

On Fri, Oct 7, 2011 at 11:01 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= :
On Fri, Oct 07, 2011 at 10:44:34AM -0400, Mark Ellison wrote:
> Hi-
>
> The initial (-00) draft for mapping SMIv2 Textual Conventions to XSD i= s now
> posted and available for review. =A0This draft represents follow-on wo= rk to
> RFC 5935.
>
> Critical review and comments welcome!

I like to know the difference (if any) between running 'smidump -= f
yang' and converting the resulting yang to XSD using pyang and your
proposed mapping of TCs. Note that the translation done by smidump is
currently a working group item of the NETMOD working group.

http://tools.ietf.org/html/draft-ietf-netmod-smi-yang-01
/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>

Juergen,

The=A0draft-ellis= on-opsawg-smi-textual-conventions-xsd is simply the anticipated follow-on t= o a previous OPSAWG work item- see RFC 5935.

The m= apping in=A0draft-ellison-opsawg-smi-textual-conventions-xsd, as compared t= o the SMIv2-->YANG-->XSD production is more faithful to and better re= flects the semantics and base data types of SMIv2 textual conventions. =A0I= believe you will see that the proposed mapping in=A0draft-ellison-opsawg-s= mi-textual-conventions-xsd is simpler, more direct and lends itself to a le= ss complex tool set.

The mapping described in=A0draft-ellison-opsawg-smi-tex= tual-conventions-xsd has no dependencies on YANG and the resulting XSD has = no dependencies upon YANG namespaces. =A0Rather, there is a dependency upon= the namespace established within RFC 5935.

In other words, when TCs are mapped from SMIv2 to XSD u= sing the algorithms described in=A0draft-ellison-opsawg-smi-textual-convent= ions-xsd, the resulting XSD is built upon the XSD simple types, as defined = in RFC 5935, representing the mapped SMIv2 base type. =A0Thus the relations= hip between TC refinement and base type as established within the SMIv2 is = maintained within the XSD. =A0I believe this essential relationship is lost= in the SMIv2-->YANG-->XSD mapping currently produced by smidump and = pyang.

My hope is that participants of the OPSAWG see the valu= e of such an algorithmic, direct mapping from SMIv2 to XSD for textual conv= entions, that is faithful to the original SMIv2, that deterministically=A0e= xtends=A0from the mapped SMIv2 base types and, that has no dependencies on = YANG intermediate forms or YANG namespaces in the resulting XSD.

Kindly review and consider=A0draft-ellison-opsawg-smi-t= extual-conventions-xsd as a work item for the OPSAWG...

Regards,

Mark
--
--20cf307f34ee4a23a504af1ac2c5-- From j.schoenwaelder@jacobs-university.de Wed Oct 12 07:42:12 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C911821F8B70 for ; Wed, 12 Oct 2011 07:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.093 X-Spam-Level: X-Spam-Status: No, score=-103.093 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N-sUxZpOijg for ; Wed, 12 Oct 2011 07:42:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A99E821F8B68 for ; Wed, 12 Oct 2011 07:42:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0D4820CC0; Wed, 12 Oct 2011 16:42:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NxVlpnqOr8ZC; Wed, 12 Oct 2011 16:42:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A32F320E30; Wed, 12 Oct 2011 16:41:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66B7B1B2084A; Wed, 12 Oct 2011 16:41:38 +0200 (CEST) Date: Wed, 12 Oct 2011 16:41:38 +0200 From: Juergen Schoenwaelder To: Mark Ellison Message-ID: <20111012144138.GA18898@elstar.local> Mail-Followup-To: Mark Ellison , opsawg@ietf.org, "Natale, Bob" References: <20111007143330.6945.7834.idtracker@ietfa.amsl.com> <20111007150136.GA60009@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:42:12 -0000 On Wed, Oct 12, 2011 at 10:22:50AM -0400, Mark Ellison wrote: > The mapping in draft-ellison-opsawg-smi-textual-conventions-xsd, as compared > to the SMIv2-->YANG-->XSD production is more faithful to and better reflects > the semantics and base data types of SMIv2 textual conventions. I believe > you will see that the proposed mapping > in draft-ellison-opsawg-smi-textual-conventions-xsd is simpler, more direct > and lends itself to a less complex tool set. My concern is that multiple mappings to XSD likely are more costly than having a single one. > The mapping described in draft-ellison-opsawg-smi-textual-conventions-xsd > has no dependencies on YANG and the resulting XSD has no dependencies upon > YANG namespaces. Rather, there is a dependency upon the namespace > established within RFC 5935. Putting all TCs into a single namespace won't work if you have TCs in different SMIv2 modules that happen to have the same name. > In other words, when TCs are mapped from SMIv2 to XSD using the algorithms > described in draft-ellison-opsawg-smi-textual-conventions-xsd, the resulting > XSD is built upon the XSD simple types, as defined in RFC 5935, representing > the mapped SMIv2 base type. Thus the relationship between TC refinement and > base type as established within the SMIv2 is maintained within the XSD. I > believe this essential relationship is lost in the SMIv2-->YANG-->XSD > mapping currently produced by smidump and pyang. Not sure what is lost. Perhaps an example helps me to understand. > My hope is that participants of the OPSAWG see the value of such an > algorithmic, direct mapping from SMIv2 to XSD for textual conventions, that > is faithful to the original SMIv2, that deterministically extends from the > mapped SMIv2 base types and, that has no dependencies on YANG intermediate > forms or YANG namespaces in the resulting XSD. I am concerned about having multiple mappings that lead not just to different namespaces but also different XSD data types. I am also kind of missing the description of the actual algorithm in the document (OK its a first draft so probably too much to ask for). What I see are a collection of examples and it is not always clear how the algorithm would actually work (e.g. how does the pattern you have for DateAndTime work faithfully with base="smi:OctetString")? It is not really clear from the document whether you want to standardize an algorithm or the outcome of executing an algorithm on a certain collection of TCs (in that case a single namespace might work but then extending the collection will be painful). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Oct 12 08:41:28 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D9B21F8BA0 for ; Wed, 12 Oct 2011 08:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7K7W5+GLWj4 for ; Wed, 12 Oct 2011 08:41:26 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B252A21F8B8E for ; Wed, 12 Oct 2011 08:41:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9CFfE7C019839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 17:41:14 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9CFfDgQ021453; Wed, 12 Oct 2011 17:41:13 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 17:41:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC88F5.5E98CBE8" Date: Wed, 12 Oct 2011 17:41:11 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402C8EA29@DEMUEXC006.nsn-intra.net> In-Reply-To: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Thread-Index: AQHMhn+cjZFsyMMxgUyN0mRKWci+jJV2MI8ggAFuuGA= References: <20110916195501.6D4E9F6AE22@newdev.eecs.harvard.edu> <4E919478.4010107@cisco.com> A From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Tina TSOU" , "Benoit Claise" X-OriginalArrivalTime: 12 Oct 2011 15:41:12.0984 (UTC) FILETIME=[5F0B4180:01CC88F5] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 15:41:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC88F5.5E98CBE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tina, =20 thank you for your comments. =20 > Some quick comments: > 1. It would be useful if a figure can be given describing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages. [Me]: Appendix A has been prepared with the intention to show the relation between the protocols and data models and provides also a dispatcher for quick access of the appropriate section. Please let me know if there is something missing. =20 > 2. Should network automation be included? [Me]: The draft aims to give an overview on IETF management standards. References to Internet-Drafts are not allowed, as they are short-living. All drafts I have in the document right now will be cleaned up before publishing. I will check where it could fit and mention as ongoing work. =20 > 3. There are more work going on about 3.2. IPv6 Network Operations, would this document only include the RFCs or that ongoing work even for the transition technologies? [Me]: We can mention transition technologies as "ongoing work" in section 3.2. =20 > 4. Some texts for how these protocols and data models be used for data center applications may be needed, if you are aware of the discussion in configuration and management group in ONF. [Me]: Unfortunately I am not aware of the discussion in configuration and management group in ONF. I am afraid the documents related to data center applications we discussed in Quebec are not stable enough for this kind of standard overview. =20 Cheers,=20 Mehmet=20 =20 From: ext Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20 Sent: Tuesday, October 11, 2011 1:08 AM To: Benoit Claise Cc: Ersue, Mehmet (NSN - DE/Munich); opsawg@ietf.org Subject: RE: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 =20 Hi all, It's a good intention of having such a document to guide people who use them. =20 Some quick comments: 1. It would be useful if a figure can be given describing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages. 2. Should network automation be included? 3. There are more work going on about 3.2. IPv6 Network Operations, would this document only include the RFCs or that ongoing work even for the transition technologies? 4. Some texts for how these protocols and data models be used for data center applications may be needed, if you are aware of the discussion in configuration and management group in ONF. =20 That's about it, so far. =20 =20 =20 Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html =20 -------- Original Message --------=20 Subject:=20 [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Date:=20 Fri, 16 Sep 2011 15:55:01 -0400 (EDT) From:=20 sob@harvard.edu (Scott O. Bradner) To:=20 opsawg@ietf.org =20 this starts a WGLC on draft-ietf-opsawg-management-stds-01=20 =20 comments to the list by the end of Sept please =20 Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg =20 ------_=_NextPart_001_01CC88F5.5E98CBE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Tina,

=  

= thank you for your comments.

=  

> Some quick comments:

> 1. It would be useful if a figure can be given describing the = relationship among some of the protocols and data models. There are many = other papers in IEEE explorers and other web = pages.

= [Me]: Appendix A has been prepared with the intention to show the = relation between the protocols and data models and provides also a = dispatcher for quick access of the appropriate section. Please let me = know if there is something missing.

 

> 2. Should network automation be = included?

= [Me]: The draft aims to give an overview on IETF management standards. = References to Internet-Drafts are not allowed, as they are short-living. = All drafts I have in the document right now will be cleaned up before = publishing. I will check where it could fit and mention as ongoing = work.

 

> 3. There are more work going on about 3.2.  = IPv6 Network Operations, would this document only include the RFCs or = that ongoing work even for the transition = technologies?

= [Me]: We can mention = transition technologies as “ongoing work” in section = 3.2.=

 =

> = 4. Some = texts for how these protocols and data models be used for data center = applications may be needed, if you are aware of the discussion in = configuration and management group in ONF.

= [Me]: Unfortunately I am not aware of = the discussion in configuration and management group in ONF. I am afraid = the documents related to data center applications we discussed in Quebec = are not stable enough for this kind of standard overview.=

=  

= Cheers,=
= Mehmet=

=  

From: ext Tina TSOU [mailto:Tina.Tsou.Z= outing@huawei.com]
Sent: Tuesday, October 11, 2011 1:08 = AM
To: Benoit Claise
Cc: Ersue, Mehmet (NSN - = DE/Munich); opsawg@ietf.org
Subject: = RE: [OPSAWG] WGLC on = draft-ietf-opsawg-management-stds-01

 

Hi all,

It’s a good intention of having such a document to guide people = who use them.

 

Some quick comments:

1. It would be useful if a figure can be given describing the = relationship among some of the protocols and data models. There are many = other papers in IEEE explorers and other web = pages.


-------- Original Message -------- =

<= td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>

Date: =

Subject:

[OPSAWG] WGLC on = draft-ietf-opsawg-management-stds-01

Fri, 16 Sep 2011 15:55:01 -0400 = (EDT)

From:

sob@harvard.edu (Scott O. = Bradner)

To:

opsawg@ietf.org

 

this =
starts a WGLC on draft-ietf-opsawg-management-stds-01 =

 
comments to the list by the end of Sept =
please
 
Scott
_______________________________________________
OPSAWG mailing =
list
OPSAWG@ietf.org
https://www.ietf.or=
g/mailman/listinfo/opsawg
 
------_=_NextPart_001_01CC88F5.5E98CBE8-- From mehmet.ersue@nsn.com Wed Oct 12 08:43:19 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DCC21F8BF4 for ; Wed, 12 Oct 2011 08:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxM3WT5MP9YX for ; Wed, 12 Oct 2011 08:43:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2E61D21F8BA0 for ; Wed, 12 Oct 2011 08:43:19 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9CFhDQN023646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 17:43:13 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9CFhB7w031719; Wed, 12 Oct 2011 17:43:13 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 17:43:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2011 17:43:09 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402C8EA2D@DEMUEXC006.nsn-intra.net> In-Reply-To: <02de01cc8821$fb680ba0$4001a8c0@gateway.2wire.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 Thread-Index: AcyIKwtRDVFzd4RJQQCk3DnLVL4YaQAxBT6Q References: <4E919213.2080401@cisco.com><4E919435.4010200@cisco.com><20111009161019.GC99820@elstar.local><4E935671.7060503@cisco.com><20111011043920.GA9033@elstar.local><4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> <02de01cc8821$fb680ba0$4001a8c0@gateway.2wire.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext t.petch" X-OriginalArrivalTime: 12 Oct 2011 15:43:11.0544 (UTC) FILETIME=[A5B61380:01CC88F5] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 15:43:20 -0000 Hi Tom, > My concern is with all the other sections as well:-) I do not believe that we > have the resources to do the subject justice, which is similar to a view that > Juergen expressed some time ago. We actually do have sufficient experts involved in the work described in the document. The document contributors are well-known names and active WG chairs at the IETF. =20 > If we stay with the all encompassing approach, then I do think that FCAPS is > needed, since it is how other organizations approach the topic, even though we > do not. This exactly is the issue we have and need to address. A document for IETF guys=20 is actually not needed. There are different web sites providing a complete list=20 of MIBs with different sort criteria. What we essentially need is a document=20 for people outside of IETF, giving an overview from their application pov. =20 > And by including the MPLS/ITU-T definition of OAM, but excluding any of the > protocols which would be understood by those to come under that name, given the > current fiery debate about which way OAM for MPLS-TP should go, on the IETF and > MPLS lists, seems like tossing a hand grenade into a petrol tanker. I have a different opinion on this. RFC 5586 uses this abbreviation the same way. Also draft-ietf-opsawg-mpls-tp-oam-def-10 states in section 3 that IETF recommended=20 the expansion of the OAM acronym as we did. We actually did not discuss anything related to MPLS-TP OAM and the debate with ITU-T.=20 Can you please elaborate what exactly should be changed or you think looks like a=20 hand grenade ;) ? Mehmet From mehmet.ersue@nsn.com Wed Oct 12 08:54:35 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8138821F8BC4 for ; Wed, 12 Oct 2011 08:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYWyb2L1WCiU for ; Wed, 12 Oct 2011 08:54:34 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3D84B21F8B5A for ; Wed, 12 Oct 2011 08:54:34 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9CFsWe4002519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 17:54:33 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9CFsWXl007287; Wed, 12 Oct 2011 17:54:32 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 17:54:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2011 17:54:31 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402C8EA48@DEMUEXC006.nsn-intra.net> In-Reply-To: <006301cc8840$6260d760$6b01a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 Thread-Index: AcyIQC0wucPlE1KeRDK5HVpOyKYcCgAsnG+g References: <4E919213.2080401@cisco.com><4E919435.4010200@cisco.com><20111009161019.GC99820@elstar.local><4E935671.7060503@cisco.com><20111011043920.GA9033@elstar.local><4E9403F9.6080800@cisco.com><20111011093519.GA9661@elstar.local><80A0822C5E9A4440A5117C2F4CD36A6402C42A39@DEMUEXC006.nsn-intra.net><20111011111240.GB10251@elstar.local> <006301cc8840$6260d760$6b01a8c0@oemcomputer> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Randy Presuhn" , X-OriginalArrivalTime: 12 Oct 2011 15:54:32.0959 (UTC) FILETIME=[3BDDC0F0:01CC88F7] Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 15:54:36 -0000 Hi Randy, > Experience shows that FCAPS is pretty useless for purposes of > *structuring* models. FCAPS can be helpful for sorting out application > requirements, but at the level of the models it might be better to consider > FCAPS as "aspects" - but that'd be a research topic, since the tools > we've given ourselves provide woefully inadequate support for aspect- > oriented model building. >=20 > If we mention FCAPS, we need to immediately note that this is a theory > that has had little effect on IETF model-building practice, and is not used > as an organizing priciple in our models. We actually do not aim to build models or give them any structure. The attempt is rather to give guidance to people outside of IETF, who=20 try to match and use data models for their management applications. You are right we should note explicitly that FCAPS is not used at IETF=20 internally as an organizing principle in our models. Mehmet From biermana@Brocade.com Wed Oct 12 10:33:45 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309FC21F8BA2 for ; Wed, 12 Oct 2011 10:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koCowyR8x298 for ; Wed, 12 Oct 2011 10:33:44 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 67A3E21F8B3F for ; Wed, 12 Oct 2011 10:33:44 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p9CHXXmV003194; Wed, 12 Oct 2011 10:33:33 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id 10deya80gs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 12 Oct 2011 10:33:33 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 12 Oct 2011 10:41:05 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 12 Oct 2011 10:33:32 -0700 From: Andy Bierman To: Juergen Schoenwaelder , Mark Ellison Date: Wed, 12 Oct 2011 10:33:31 -0700 Thread-Topic: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt Thread-Index: AcyI7SMya6MaoYSRSSebf33Nbl/qWAAFvbmA Message-ID: References: <20111007143330.6945.7834.idtracker@ietfa.amsl.com> <20111007150136.GA60009@elstar.local> <20111012144138.GA18898@elstar.local> In-Reply-To: <20111012144138.GA18898@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-10-12_06:2011-10-12, 2011-10-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1110120186 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:33:45 -0000 We went through the overlap discussion about a year ago I think. Choice of tools is subjective. I prefer to use YANG, not XSD, so I can't say this draft is useful of not, because XSD itself is not useful to me. Since we have no official YANG to XSD mapping, there is no chance that there can be conflicts between different XSDs (generated vs. static). So there is no chance that any YANG definition could ever be affected because it doesn't 'match the XSD version' in this draft. As long as that is true (ADs?) then I have no strong objections to this dra= ft. Andy -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Juergen Schoenwaelder Sent: Wednesday, October 12, 2011 7:42 AM To: Mark Ellison Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventi= ons-xsd-00.txt On Wed, Oct 12, 2011 at 10:22:50AM -0400, Mark Ellison wrote: =20 > The mapping in draft-ellison-opsawg-smi-textual-conventions-xsd, as compa= red > to the SMIv2-->YANG-->XSD production is more faithful to and better refle= cts > the semantics and base data types of SMIv2 textual conventions. I believ= e > you will see that the proposed mapping > in draft-ellison-opsawg-smi-textual-conventions-xsd is simpler, more dire= ct > and lends itself to a less complex tool set. My concern is that multiple mappings to XSD likely are more costly than having a single one. > The mapping described in draft-ellison-opsawg-smi-textual-conventions-xsd > has no dependencies on YANG and the resulting XSD has no dependencies upo= n > YANG namespaces. Rather, there is a dependency upon the namespace > established within RFC 5935. Putting all TCs into a single namespace won't work if you have TCs in different SMIv2 modules that happen to have the same name. =20 > In other words, when TCs are mapped from SMIv2 to XSD using the algorithm= s > described in draft-ellison-opsawg-smi-textual-conventions-xsd, the result= ing > XSD is built upon the XSD simple types, as defined in RFC 5935, represent= ing > the mapped SMIv2 base type. Thus the relationship between TC refinement = and > base type as established within the SMIv2 is maintained within the XSD. = I > believe this essential relationship is lost in the SMIv2-->YANG-->XSD > mapping currently produced by smidump and pyang. Not sure what is lost. Perhaps an example helps me to understand. > My hope is that participants of the OPSAWG see the value of such an > algorithmic, direct mapping from SMIv2 to XSD for textual conventions, th= at > is faithful to the original SMIv2, that deterministically extends from th= e > mapped SMIv2 base types and, that has no dependencies on YANG intermediat= e > forms or YANG namespaces in the resulting XSD. I am concerned about having multiple mappings that lead not just to different namespaces but also different XSD data types. I am also kind of missing the description of the actual algorithm in the document (OK its a first draft so probably too much to ask for). What I see are a collection of examples and it is not always clear how the algorithm would actually work (e.g. how does the pattern you have for DateAndTime work faithfully with base=3D"smi:OctetString")? It is not really clear from the document whether you want to standardize an algorithm or the outcome of executing an algorithm on a certain collection of TCs (in that case a single namespace might work but then extending the collection will be painful). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From Tina.Tsou.Zouting@huawei.com Wed Oct 12 10:59:57 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFEC21F8C58 for ; Wed, 12 Oct 2011 10:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqlXYmJiA25X for ; Wed, 12 Oct 2011 10:59:55 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4C521F8BDE for ; Wed, 12 Oct 2011 10:59:54 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00MCPSNQYR@szxga05-in.huawei.com> for opsawg@ietf.org; Thu, 13 Oct 2011 01:59:50 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00JKESNPF3@szxga05-in.huawei.com> for opsawg@ietf.org; Thu, 13 Oct 2011 01:59:50 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ90899; Thu, 13 Oct 2011 01:59:49 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 01:59:44 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.58]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 01:59:41 +0800 Date: Wed, 12 Oct 2011 17:59:41 +0000 From: Tina TSOU In-reply-to: <80A0822C5E9A4440A5117C2F4CD36A6402C8EA29@DEMUEXC006.nsn-intra.net> X-Originating-IP: [10.193.34.158] To: "Ersue, Mehmet (NSN - DE/Munich)" , Benoit Claise Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y93PBi0XF/L0UenjO+PLZQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Thread-index: AQHMhn+cjZFsyMMxgUyN0mRKWci+jJV2MI8ggAFuuGCAAWTKsA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110916195501.6D4E9F6AE22@newdev.eecs.harvard.edu> <4E919478.4010107@cisco.com> A <80A0822C5E9A4440A5117C2F4CD36A6402C8EA29@DEMUEXC006.nsn-intra.net> Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:59:57 -0000 --Boundary_(ID_y93PBi0XF/L0UenjO+PLZQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Mehmet, In line... Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] Sent: Wednesday, October 12, 2011 8:41 AM To: Tina TSOU; Benoit Claise Cc: opsawg@ietf.org Subject: RE: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Hi Tina, thank you for your comments. > Some quick comments: > 1. It would be useful if a figure can be given describing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages. [Me]: Appendix A has been prepared with the intention to show the relation between the protocols and data models and provides also a dispatcher for quick access of the appropriate section. Please let me know if there is something missing. [TT] COPS and COPS PR support both Push and Pull Mechanism, which are missing from A.4. > 2. Should network automation be included? [Me]: The draft aims to give an overview on IETF management standards. References to Internet-Drafts are not allowed, as they are short-living. All drafts I have in the document right now will be cleaned up before publishing. I will check where it could fit and mention as ongoing work. > 3. There are more work going on about 3.2. IPv6 Network Operations, would this document only include the RFCs or that ongoing work even for the transition technologies? [Me]: We can mention transition technologies as "ongoing work" in section 3.2. > 4. Some texts for how these protocols and data models be used for data center applications may be needed, if you are aware of the discussion in configuration and management group in ONF. [Me]: Unfortunately I am not aware of the discussion in configuration and management group in ONF. I am afraid the documents related to data center applications we discussed in Quebec are not stable enough for this kind of standard overview. Cheers, Mehmet From: ext Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Sent: Tuesday, October 11, 2011 1:08 AM To: Benoit Claise Cc: Ersue, Mehmet (NSN - DE/Munich); opsawg@ietf.org Subject: RE: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Hi all, It's a good intention of having such a document to guide people who use them. Some quick comments: 1. It would be useful if a figure can be given describing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages. 2. Should network automation be included? 3. There are more work going on about 3.2. IPv6 Network Operations, would this document only include the RFCs or that ongoing work even for the transition technologies? 4. Some texts for how these protocols and data models be used for data center applications may be needed, if you are aware of the discussion in configuration and management group in ONF. That's about it, so far. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -------- Original Message -------- Subject: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Date: Fri, 16 Sep 2011 15:55:01 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) To: opsawg@ietf.org this starts a WGLC on draft-ietf-opsawg-management-stds-01 comments to the list by the end of Sept please Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --Boundary_(ID_y93PBi0XF/L0UenjO+PLZQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Mehmet,

In line…

 

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

 

From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]
Sent: Wednesday, October 12, 2011 8:41 AM
To: Tina TSOU; Benoit Claise
Cc: opsawg@ietf.org
Subject: RE: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01

 

Hi Tina,

 

thank you for your comments.

 

> Some quick comments:

> 1. It would be useful if a figure can be given describing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages.

[Me]: Appendix A has been prepared with the intention to show the relation between the protocols and data models and provides also a dispatcher for quick access of the appropriate section. Please let me know if there is something missing.

[TT] COPS and COPS PR support both Push and Pull Mechanism, which are missing from A.4.

 

> 2. Should network automation be included?

[Me]: The draft aims to give an overview on IETF management standards. References to Internet-Drafts are not allowed, as they are short-living. All drafts I have in the document right now will be cleaned up before publishing. I will check where it could fit and mention as ongoing work.

 

> 3. There are more work going on about 3.2.  IPv6 Network Operations, would this document only include the RFCs or that ongoing work even for the transition technologies?

[Me]: We can mention transition technologies as “ongoing work” in section 3.2.

 

> 4. Some texts for how these protocols and data models be used for data center applications may be needed, if you are aware of the discussion in configuration and management group in ONF.

[Me]: Unfortunately I am not aware of the discussion in configuration and management group in ONF. I am afraid the documents related to data center applications we discussed in Quebec are not stable enough for this kind of standard overview.

 

Cheers,
Mehmet

 

From: ext Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]
Sent: Tuesday, October 11, 2011 1:08 AM
To: Benoit Claise
Cc: Ersue, Mehmet (NSN - DE/Munich); opsawg@ietf.org
Subject: RE: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01

 

Hi all,

It’s a good intention of having such a document to guide people who use them.

 

Some quick comments:

1. It would be useful if a figure can be given describing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages.

2. Should network automation be included?

3. There are more work going on about 3.2.  IPv6 Network Operations, would this document only include the RFCs or that ongoing work even for the transition technologies?

4. Some texts for how these protocols and data models be used for data center applications may be needed, if you are aware of the discussion in configuration and management group in ONF.

 

That’s about it, so far.

 

 

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 


-------- Original Message --------

Subject:

[OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01

Date:

Fri, 16 Sep 2011 15:55:01 -0400 (EDT)

From:

sob@harvard.edu (Scott O. Bradner)

To:

opsawg@ietf.org

 

this starts a WGLC on draft-ietf-opsawg-management-stds-01 
 
comments to the list by the end of Sept please
 
Scott
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
 
--Boundary_(ID_y93PBi0XF/L0UenjO+PLZQ)-- From mehmet.ersue@nsn.com Wed Oct 12 11:49:20 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1829C21F8B86 for ; Wed, 12 Oct 2011 11:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIYGAFUC-RI7 for ; Wed, 12 Oct 2011 11:49:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9DF21F8B81 for ; Wed, 12 Oct 2011 11:49:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9CIItY7019106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 20:18:56 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9CIItCl004557; Wed, 12 Oct 2011 20:18:55 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 20:18:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC890B.6675965F" Date: Wed, 12 Oct 2011 20:18:54 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402C8EAB8@DEMUEXC006.nsn-intra.net> In-Reply-To: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 Thread-Index: AQHMhn+cjZFsyMMxgUyN0mRKWci+jJV2MI8ggAFuuGCAAWTKsIAABD3Q References: <20110916195501.6D4E9F6AE22@newdev.eecs.harvard.edu> <4E919478.4010107@cisco.com> A <80A0822C5E9A4440A5117C2F4CD36A6402C8EA29@DEMUEXC006.nsn-intra.net> A From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Tina TSOU" , "Benoit Claise" X-OriginalArrivalTime: 12 Oct 2011 18:18:55.0425 (UTC) FILETIME=[67192B10:01CC890B] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:49:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC890B.6675965F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tina, =20 > 1. It would be useful if a figure can be given describing the relationship among some of the protocols and data models. There are many other papers in IEEE explorers and other web pages. [Me]: Appendix A has been prepared with the intention to show the relation between the protocols and data models and provides also a dispatcher for quick access of the appropriate section. Please let me know if there is something missing. [TT] COPS and COPS PR support both Push and Pull Mechanism, which are missing from A.4. =20 [Me-2]: There is an explicit statement in section 3.3.2. that "the use of COPS-PR is not recommended." However, we should probably add COPS to the table in A.3. =20 Cheers,=20 Mehmet=20 =20 =20 ------_=_NextPart_001_01CC890B.6675965F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Tina,

=  

> 1. It would be useful if a figure can be given describing the = relationship among some of the protocols and data models. There are many = other papers in IEEE explorers and other web = pages.

= [Me]: Appendix A has been prepared with the intention to show the = relation between the protocols and data models and provides also a = dispatcher for quick access of the appropriate section. Please let me = know if there is something missing.

[TT] COPS and COPS PR support both Push and Pull Mechanism, which are = missing from A.4.

 =

[Me-2]: There is =
an explicit statement in section 3.3.2. that “the use of COPS-PR is not =
recommended.” However, we =
should probably add COPS to the table in =
A.3.

=  

= Cheers,=
= Mehmet=

=  

 =
------_=_NextPart_001_01CC890B.6675965F-- From ietfc@btconnect.com Thu Oct 13 04:15:09 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8A21F8BA9 for ; Thu, 13 Oct 2011 04:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id licHHz3jSQ6l for ; Thu, 13 Oct 2011 04:15:08 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4211121F8BA8 for ; Thu, 13 Oct 2011 04:15:07 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr06.btconnect.com with SMTP id EYD64821; Thu, 13 Oct 2011 12:15:03 +0100 (BST) Message-ID: <01c101cc8990$50bd9740$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <4E919213.2080401@cisco.com><4E919435.4010200@cisco.com><20111009161019.GC99820@elstar.local><4E935671.7060503@cisco.com><20111011043920.GA9033@elstar.local><4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> <02de01cc8821$fb680ba0$4001a8c0@gateway.2wire.net> <80A0822C5E9A4440A5117C2F4CD36A6402C8EA2D@DEMUEXC006.nsn-intra.net> Date: Thu, 13 Oct 2011 12:10:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E96C836.00AB, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.13.95114:17:7.944, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_1900_1999, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E96C838.0140,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 11:15:09 -0000 ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext t.petch" Cc: ; "Benoit Claise" Sent: Wednesday, October 12, 2011 5:43 PM Hi Tom, > And by including the MPLS/ITU-T definition of OAM, but excluding any of the > protocols which would be understood by those to come under that name, given the > current fiery debate about which way OAM for MPLS-TP should go, on the IETF and > MPLS lists, seems like tossing a hand grenade into a petrol tanker. I have a different opinion on this. RFC 5586 uses this abbreviation the same way. Also draft-ietf-opsawg-mpls-tp-oam-def-10 states in section 3 that IETF recommended the expansion of the OAM acronym as we did. We actually did not discuss anything related to MPLS-TP OAM and the debate with ITU-T. Can you please elaborate what exactly should be changed or you think looks like a hand grenade ;) ? There is currently a lively debate on the main ietf list over draft-sprecher-mpls-tp-oam-considerations-01.txt which reviews the current position whereby the IETF have recommended one approach to OAM for MPLS-TP while the ITU-T are ratifying an incompatible one. Proponents of the ITU-T approach, who have been involved in the discussions all along, question the IETF processes by which the IETF arrived at its conclusions, and have been doing so for some years, implying, to me, that they do not think that their views got proper consideration. Were this to go into IETF LC now, with its claim to cover 'existing and ongoing development of IETF standards-track network management protocols and data models' without any mention of the MPLS-TP work with its contributions by ITU-T participants over the years, would seem to me likely to aggravate the situation; as a hand grenade would in a petrol tanker:-) Tom Petch Mehmet From mehmet.ersue@nsn.com Thu Oct 13 05:12:30 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55C21F8B9E for ; Thu, 13 Oct 2011 05:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZyWpwawACZY for ; Thu, 13 Oct 2011 05:12:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A487121F8B86 for ; Thu, 13 Oct 2011 05:12:29 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9DCCNDE001670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2011 14:12:24 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9DCCMoW016490; Thu, 13 Oct 2011 14:12:23 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 14:12:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Oct 2011 14:12:20 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402CCC5AF@DEMUEXC006.nsn-intra.net> In-Reply-To: <01c101cc8990$50bd9740$4001a8c0@gateway.2wire.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 Thread-Index: AcyJmV7MDqojIN7QQmaBiYMeY4+DkwABG0tA References: <4E919213.2080401@cisco.com><4E919435.4010200@cisco.com><20111009161019.GC99820@elstar.local><4E935671.7060503@cisco.com><20111011043920.GA9033@elstar.local><4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> <02de01cc8821$fb680ba0$4001a8c0@gateway.2wire.net> <80A0822C5E9A4440A5117C2F4CD36A6402C8EA2D@DEMUEXC006.nsn-intra.net> <01c101cc8990$50bd9740$4001a8c0@gateway.2wire.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext t.petch" X-OriginalArrivalTime: 13 Oct 2011 12:12:21.0130 (UTC) FILETIME=[5BE3D6A0:01CC89A1] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 12:12:30 -0000 Hi Tom, after some discussion we decided to not include MPLS-TP OAM into this document. There is a note in the draft stating that the document does not cover OAM=20 technologies on the data-path, e.g. OAM of tunnels, MPLS-TP OAM, Pseudowire, etc. =20 and points to two active WG drafts (draft.ietf-opsawg-oam-overview and=20 draft.ietf-mpls-tp-oam-framework), which cover it appropriately. I think it is sufficient if we point to this work and by this avoid carrying=20 the ongoing difficult debate to our draft and its LC. So, I would suggest to let the grenades where they are (ietf@ietf.org) right now ;) Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext t.petch [mailto:ietfc@btconnect.com] > Sent: Thursday, October 13, 2011 12:10 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: opsawg@ietf.org; Benoit Claise > Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 >=20 > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > To: "ext t.petch" > Cc: ; "Benoit Claise" > Sent: Wednesday, October 12, 2011 5:43 PM >=20 > Hi Tom, >=20 > > And by including the MPLS/ITU-T definition of OAM, but excluding any > of the > > protocols which would be understood by those to come under that name, > given the > > current fiery debate about which way OAM for MPLS-TP should go, on the > IETF and > > MPLS lists, seems like tossing a hand grenade into a petrol tanker. >=20 > I have a different opinion on this. RFC 5586 uses this abbreviation the > same way. > Also draft-ietf-opsawg-mpls-tp-oam-def-10 states in section 3 that IETF > recommended > the expansion of the OAM acronym as we did. > We actually did not discuss anything related to MPLS-TP OAM and the > debate with ITU-T. > Can you please elaborate what exactly should be changed or you think > looks like a > hand grenade ;) ? >=20 > >=20 > There is currently a lively debate on the main ietf list over > draft-sprecher-mpls-tp-oam-considerations-01.txt > which reviews the current position whereby the IETF have > recommended one approach to OAM for MPLS-TP while the > ITU-T are ratifying an incompatible one. >=20 > Proponents of the ITU-T approach, who have been involved in > the discussions all along, question the IETF processes by which > the IETF arrived at its conclusions, and have been doing so > for some years, implying, to me, that they do not think that > their views got proper consideration. >=20 > Were this to go into IETF LC now, with its claim to cover > 'existing and ongoing development of IETF standards-track > network management protocols and data models' > without any mention of the MPLS-TP work with its > contributions by ITU-T participants over the years, > would seem to me likely to aggravate > the situation; as a hand grenade would in a petrol > tanker:-) >=20 > Tom Petch > >=20 > Mehmet From bclaise@cisco.com Fri Oct 14 04:10:13 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5663621F8BF9 for ; Fri, 14 Oct 2011 04:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1MMrKBsE3rU for ; Fri, 14 Oct 2011 04:10:12 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7E821F8BB6 for ; Fri, 14 Oct 2011 04:10:12 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9EB9eYt013208; Fri, 14 Oct 2011 13:09:40 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9EB9dMV004700; Fri, 14 Oct 2011 13:09:39 +0200 (CEST) Message-ID: <4E981873.40406@cisco.com> Date: Fri, 14 Oct 2011 13:09:39 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Randy Presuhn References: <4E919213.2080401@cisco.com> <4E919435.4010200@cisco.com><20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com><20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com><20111011093519.GA9661@elstar.local><80A0822C5E9A4440A5117C2F4CD36A6402C42A39@DEMUEXC006.nsn-intra.net> <20111011111240.GB10251@elstar.local> <006301cc8840$6260d760$6b01a8c0@oemcomputer> In-Reply-To: <006301cc8840$6260d760$6b01a8c0@oemcomputer> Content-Type: multipart/alternative; boundary="------------080709070905070600060007" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 11:10:13 -0000 This is a multi-part message in MIME format. --------------080709070905070600060007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Randy, > Hi - > >> From: "Juergen Schoenwaelder" >> To: "Ersue, Mehmet (NSN - DE/Munich)" >> Cc: >> Sent: Tuesday, October 11, 2011 4:12 AM >> Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 > ... >> I do not agree - we simply waste time and energy if we do not manage >> to convey how things are done in the IETF. We have 20+ years of data >> models history and experience in the IETF. I have been involved for >> about 15 years. There simply is no FCAPS structure in what is being >> done in the IETF. ... > Experience shows that FCAPS is pretty useless for purposes of > *structuring* models. FCAPS can be helpful for sorting out application > requirements, but at the level of the models it might be better to consider > FCAPS as "aspects" - but that'd be a research topic, since the tools > we've given ourselves provide woefully inadequate support for aspect- > oriented model building. > > If we mention FCAPS, we need to immediately note that this is a theory > that has had little effect on IETF model-building practice, and is not used > as an organizing priciple in our models. This was exactly my intention with this proposal, made some days ago to the mailing list. OLD: 4. Network Management Data Models This section lists management data models standardized at IETF, which can be reused and applied to different management solutions. The subsections below are structured following the management application view and focus mainly on the management data models for the network management tasks fault, configuration, accounting, performance, and security management. NEW: 4. Network Management Data Models This section lists management data models standardized at IETF, which can be reused and applied to different management solutions. The subsections below are structured following the management application view and focus mainly on the management data models for the network management tasks fault, configuration, accounting, performance, and security (FCAPS) management. While the IETF does not logically organize data models around FCAPS, this classification was presented in this document to help the audience to review and select the appropriate data models based on his management needs. Regards, Benoit. > > Randy > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > --------------080709070905070600060007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Randy,
Hi -


From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
Cc: <opsawg@ietf.org>
Sent: Tuesday, October 11, 2011 4:12 AM
Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01

...

I do not agree - we simply waste time and energy if we do not manage
to convey how things are done in the IETF. We have 20+ years of data
models history and experience in the IETF. I have been involved for
about 15 years. There simply is no FCAPS structure in what is being
done in the IETF.  ...

Experience shows that FCAPS is pretty useless for purposes of
*structuring* models.  FCAPS can be helpful for sorting out application
requirements, but at the level of the models it might be better to consider
FCAPS as "aspects" - but that'd be a research topic, since the tools
we've given ourselves provide woefully inadequate support for aspect-
oriented model building.

If we mention FCAPS, we need to immediately note that this is a theory
that has had little effect on IETF model-building practice, and is not used
as an organizing priciple in our models.
This was exactly my intention with this proposal, made some days ago to the mailing list.

OLD:
4.  Network Management Data Models
   This section lists management data models standardized at IETF, which
   can be reused and applied to different management solutions.  The
   subsections below are structured following the management application
   view and focus mainly on the management data models for the network
   management tasks fault, configuration, accounting, performance, and
   security management.

NEW:

 
4.  Network Management Data Models

   This section lists management data models standardized at IETF, which
   can be reused and applied to different management solutions.  The
   subsections below are structured following the management application
   view and focus mainly on the management data models for the network
   management tasks fault, configuration, accounting, performance, and
   security (FCAPS) management. While the IETF does not logically organize 
   data models around FCAPS, this classification was presented in this 
   document to help the audience to review and select the appropriate data 
   models based on his management needs.

Regards, Benoit.



Randy

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------080709070905070600060007-- From mark@ellisonsoftware.com Mon Oct 17 07:20:37 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1A121F8B98 for ; Mon, 17 Oct 2011 07:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE77RANm-XLd for ; Mon, 17 Oct 2011 07:20:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D593621F8B83 for ; Mon, 17 Oct 2011 07:20:35 -0700 (PDT) Received: by iabn5 with SMTP id n5so6752237iab.31 for ; Mon, 17 Oct 2011 07:20:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.49.131 with SMTP id va3mr38345120icb.51.1318861234961; Mon, 17 Oct 2011 07:20:34 -0700 (PDT) Sender: mark@ellisonsoftware.com Received: by 10.231.206.7 with HTTP; Mon, 17 Oct 2011 07:20:34 -0700 (PDT) In-Reply-To: <20111012144138.GA18898@elstar.local> References: <20111007143330.6945.7834.idtracker@ietfa.amsl.com> <20111007150136.GA60009@elstar.local> <20111012144138.GA18898@elstar.local> Date: Mon, 17 Oct 2011 10:20:34 -0400 X-Google-Sender-Auth: LS9v2dljDKho5Sz9M91BX3XCse4 Message-ID: From: Mark Ellison To: Juergen Schoenwaelder , Mark Ellison , opsawg@ietf.org, "Natale, Bob" Content-Type: multipart/alternative; boundary=bcaec529a0396afca204af7f4fd9 Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:20:37 -0000 --bcaec529a0396afca204af7f4fd9 Content-Type: text/plain; charset=ISO-8859-1 Hello Jeurgen... On Wed, Oct 12, 2011 at 10:41 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Oct 12, 2011 at 10:22:50AM -0400, Mark Ellison wrote: > > > The mapping in draft-ellison-opsawg-smi-textual-conventions-xsd, as > compared > > to the SMIv2-->YANG-->XSD production is more faithful to and better > reflects > > the semantics and base data types of SMIv2 textual conventions. I > believe > > you will see that the proposed mapping > > in draft-ellison-opsawg-smi-textual-conventions-xsd is simpler, more > direct > > and lends itself to a less complex tool set. > > My concern is that multiple mappings to XSD likely are more costly > than having a single one. I understand this concern. However, the XSD mappings provided in RFC 5935 ought form the base of any mappings from SMIv2 to XSD, not a YANG data type. The purpose of RFC 5935 is to provide a mapping from SMIv2 base data types into XSD. The ID under discussion extends the mapping of TCs (which rely upon refinements of SMIv2 base data types) directly to XSD. The resulting XSD is based upon, and refines the set of XSD definintions of the SMIv2 base data types found in RFC 5935. No YANG stuff here! > The mapping described in draft-ellison-opsawg-smi-textual-conventions-xsd > > has no dependencies on YANG and the resulting XSD has no dependencies > upon > > YANG namespaces. Rather, there is a dependency upon the namespace > > established within RFC 5935. > > Putting all TCs into a single namespace won't work if you have TCs in > different SMIv2 modules that happen to have the same name. > > I agree with your statement. Putting all TCs mapped into XSD into a single XML namespace is not the intention of the draft under discussion. I have made a note to add text to the next revision to clarify and relieve this concern. > In other words, when TCs are mapped from SMIv2 to XSD using the algorithms > > described in draft-ellison-opsawg-smi-textual-conventions-xsd, the > resulting > > XSD is built upon the XSD simple types, as defined in RFC 5935, > representing > > the mapped SMIv2 base type. Thus the relationship between TC refinement > and > > base type as established within the SMIv2 is maintained within the XSD. > I > > believe this essential relationship is lost in the SMIv2-->YANG-->XSD > > mapping currently produced by smidump and pyang. > > Not sure what is lost. Perhaps an example helps me to understand. > >From my perspective, what is lost is the use of the base data type XSD definitions contained in RFC 5935. There is also a reliance upon YANG namespace definitions, which adds complexity that is not necessary. > > > My hope is that participants of the OPSAWG see the value of such an > > algorithmic, direct mapping from SMIv2 to XSD for textual conventions, > that > > is faithful to the original SMIv2, that deterministically extends from > the > > mapped SMIv2 base types and, that has no dependencies on YANG > intermediate > > forms or YANG namespaces in the resulting XSD. > > I am concerned about having multiple mappings that lead not just to > different namespaces but also different XSD data types. I am also kind > of missing the description of the actual algorithm in the document (OK > its a first draft so probably too much to ask for). What I see are a > collection of examples and it is not always clear how the algorithm > would actually work (e.g. how does the pattern you have for > DateAndTime work faithfully with base="smi:OctetString")? It is not > really clear from the document whether you want to standardize an > algorithm or the outcome of executing an algorithm on a certain > collection of TCs (in that case a single namespace might work but > then extending the collection will be painful). > We already have a mapping for the base data types. It is the belief of the authors of the draft under discussion that TCs should be based upon these base data types. The SMIv2-->YANG-->XSD does not use the definitions found in RFC 5935...maybe it should? re- the DateAndTime...its still a work-in-progress. I have made a note on this issue. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > Mark -- Mark Ellison Ellison Software Consulting, Inc. http://EllisonSoftware.com/ --bcaec529a0396afca204af7f4fd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Jeurgen...

On Wed, Oct 12, 2011 at = 10:41 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Wed, Oct 12, 2011 at 1= 0:22:50AM -0400, Mark Ellison wrote:

> The mapping in draft-ellison-opsawg-smi-textual-conventions-xsd, as co= mpared
> to the SMIv2-->YANG-->XSD production is more faithful to and bet= ter reflects
> the semantics and base data types of SMIv2 textual conventions. =A0I b= elieve
> you will see that the proposed mapping
> in draft-ellison-opsawg-smi-textual-conventions-xsd is simpler, more d= irect
> and lends itself to a less complex tool set.

My concern is that multiple mappings to XSD likely are more costly than having a single one.
=A0
I understand this = concern. =A0 However, the XSD mappings provided in RFC 5935 ought form the = base of any mappings from SMIv2 to XSD, not a YANG data type. =A0The purpos= e of RFC 5935 is to provide a mapping from SMIv2 base data types into XSD. = =A0The ID under discussion extends the mapping of TCs (which rely upon refi= nements of SMIv2 base data types) directly to XSD. =A0The resulting XSD is = based upon, and refines the set of XSD definintions of the SMIv2 base data = types found in RFC 5935. =A0No YANG stuff here!


> The mapping described in draft-ellison-opsawg-smi-textual-conventions-= xsd
> has no dependencies on YANG and the resulting XSD has no dependencies = upon
> YANG namespaces. =A0Rather, there is a dependency upon the namespace > established within RFC 5935.

Putting all TCs into a single namespace won't work if you have TC= s in
different SMIv2 modules that happen to have the same name.


I agree with y= our statement. =A0Putting all TCs mapped into XSD into a single XML namespa= ce is not the intention of the draft under discussion. =A0I have made a not= e to add text to the next revision to clarify and relieve this concern.

> In other words, when TCs are mapped from SMIv2 to XSD using the algori= thms
> described in draft-ellison-opsawg-smi-textual-conventions-xsd, the res= ulting
> XSD is built upon the XSD simple types, as defined in RFC 5935, repres= enting
> the mapped SMIv2 base type. =A0Thus the relationship between TC refine= ment and
> base type as established within the SMIv2 is maintained within the XSD= . =A0I
> believe this essential relationship is lost in the SMIv2-->YANG--&g= t;XSD
> mapping currently produced by smidump and pyang.

Not sure what is lost. Perhaps an example helps me to understand.
=

From my perspective, what is lost is the u= se of the base data type XSD definitions contained in RFC 5935. =A0There is= also a reliance upon YANG namespace definitions, which adds complexity tha= t is not necessary.

=A0

> My hope is that participants of the OPSAWG see the value of such an > algorithmic, direct mapping from SMIv2 to XSD for textual conventions,= that
> is faithful to the original SMIv2, that deterministically extends from= the
> mapped SMIv2 base types and, that has no dependencies on YANG intermed= iate
> forms or YANG namespaces in the resulting XSD.

I am concerned about having multiple mappings that lead not just to different namespaces but also different XSD data types. I am also kind
of missing the description of the actual algorithm in the document (OK
its a first draft so probably too much to ask for). What I see are a
collection of examples and it is not always clear how the algorithm
would actually work (e.g. how does the pattern you have for
DateAndTime work faithfully with base=3D"smi:OctetString")? It is= not
really clear from the document whether you want to standardize an
algorithm or the outcome of executing an algorithm on a certain
collection of TCs (in that case a single namespace might work but
then extending the collection will be painful).

We already have a mapping for the base data types. =A0It is the be= lief of the authors of the draft under discussion that TCs should be based = upon these base data types. =A0The SMIv2-->YANG-->XSD does not use th= e definitions found in RFC 5935...maybe it should?

re- the DateAndTime...its still a work-in-progress. =A0= I have made a note on this issue.
=A0

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49= 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, Germany
Fax: =A0 += 49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>


Mark
--
= Mark Ellison
Ellison Software Consulting, Inc.
http://EllisonSoftware.com/
--bcaec529a0396afca204af7f4fd9-- From j.schoenwaelder@jacobs-university.de Mon Oct 17 07:24:30 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB2A21F8BB8 for ; Mon, 17 Oct 2011 07:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.035 X-Spam-Level: X-Spam-Status: No, score=-103.035 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Yh3RrY7s-On for ; Mon, 17 Oct 2011 07:24:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEAD21F8BB1 for ; Mon, 17 Oct 2011 07:24:29 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C684520D24; Mon, 17 Oct 2011 16:24:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n0aa7RakJVnh; Mon, 17 Oct 2011 16:24:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A0C420D61; Mon, 17 Oct 2011 16:24:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 91C241B29737; Mon, 17 Oct 2011 16:24:09 +0200 (CEST) Date: Mon, 17 Oct 2011 16:24:08 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20111017142407.GA263@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Randy Presuhn , opsawg@ietf.org References: <4E919435.4010200@cisco.com> <20111009161019.GC99820@elstar.local> <4E935671.7060503@cisco.com> <20111011043920.GA9033@elstar.local> <4E9403F9.6080800@cisco.com> <20111011093519.GA9661@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402C42A39@DEMUEXC006.nsn-intra.net> <20111011111240.GB10251@elstar.local> <006301cc8840$6260d760$6b01a8c0@oemcomputer> <80A0822C5E9A4440A5117C2F4CD36A6402C8EA48@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6402C8EA48@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: WGLC on draft-ietf-opsawg-management-stds-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:24:30 -0000 On Wed, Oct 12, 2011 at 05:54:31PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Randy, > > > Experience shows that FCAPS is pretty useless for purposes of > > *structuring* models. FCAPS can be helpful for sorting out > application > > requirements, but at the level of the models it might be better to > consider > > FCAPS as "aspects" - but that'd be a research topic, since the tools > > we've given ourselves provide woefully inadequate support for aspect- > > oriented model building. > > > > If we mention FCAPS, we need to immediately note that this is a theory > > that has had little effect on IETF model-building practice, and is not > used > > as an organizing priciple in our models. > > We actually do not aim to build models or give them any structure. > The attempt is rather to give guidance to people outside of IETF, who > try to match and use data models for their management applications. > > You are right we should note explicitly that FCAPS is not used at IETF > internally as an organizing principle in our models. Then you should also remove the sections that try to list data models under FCAPS section titles. An example why this does not work well: The perhaps most widely used MIB module is the IF-MIB. It currently pops up under "4.2. Configuration Management" (and only there). I suggest to count the number of non-deprecated writable objects in there. ;-) As far as I can tell, the IF-MIB is used heavily for _monitoring_ - and interface _monitoring_ is used for fault mgmt, accounting mgmt, performance mgmt, and perhaps even security mgmt. With your structure, you would have to mention the IF-MIB in several sections. This is an example, similiar arguments apply to other data models listed in the current I-D. /js PS: Some interesting historic background can be found in this paper published 1989: -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From vumip1@gmail.com Mon Oct 17 14:11:05 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465A721F84C9 for ; Mon, 17 Oct 2011 14:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q6eMPnVyRkZ for ; Mon, 17 Oct 2011 14:11:04 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id A22F621F84BC for ; Mon, 17 Oct 2011 14:11:04 -0700 (PDT) Received: by qyk31 with SMTP id 31so1445913qyk.10 for ; Mon, 17 Oct 2011 14:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=KAFWLg/UXL4J0697DgGxcdPSjLlVzjCtKVqtO6CfgFg=; b=d5fmlwy3AWPRdF3VXkdsTyJyBVrb7O/JzYLIYXshy5D0GmDfF6L3Rsl4GyYn9tQQoc kc6tIrgQcOEop71GK3Kc5dFK/AgUkUo8T//UNTOX8RzcKLSyXHxAGIsAjGeLrdq6PUz1 2yqVxMqQTwYIDynrlP4ztnAHqK+QXQwo4dG48= MIME-Version: 1.0 Received: by 10.182.108.100 with SMTP id hj4mr12386467obb.34.1318885864057; Mon, 17 Oct 2011 14:11:04 -0700 (PDT) Received: by 10.182.37.69 with HTTP; Mon, 17 Oct 2011 14:11:04 -0700 (PDT) Date: Mon, 17 Oct 2011 17:11:04 -0400 Message-ID: From: Bhumip Khasnabish To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=f46d044789156d2b0004af850b9f Subject: [OPSAWG] Fwd: update on Network Portability Requirements and Models for Cloud Environment X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 21:11:05 -0000 --f46d044789156d2b0004af850b9f Content-Type: text/plain; charset=ISO-8859-1 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Portability Requirements and Models for Cloud Environment Author(s) : Keiichi Shima Yuji Sekiya Katsuhiro Horiba Filename : draft-shima-clouds-net-portability-reqs-and-models-01.txt Pages : 10 Date : 2011-10-17 Recent progress of virtual machine technology made it possible to host various Internet service nodes in a so called cloud environment. The virtual machine hosting technology provides a method to migrate a virtual machine from one hypervisor to another. However, such a technology is mainly focusing on a migration between hypervisors attached to the same link, and tend not to consider migration over the Internet. This document mentions the purpose of that type of operation and describe several possible operation methods to provide network portability in cloud systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shima-clouds-net-portability-reqs-and-models-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-shima-clouds-net-portability-reqs-and-models-01.txt --f46d044789156d2b0004af850b9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A New Internet-Draft is available from the on-line Intern= et-Drafts directories.

Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Network= Portability Requirements and Models for Cloud Environment
Author(s)=A0= =A0=A0=A0=A0=A0 : Keiichi Shima
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Yuji Sekiya
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Katsuhiro Horiba
Filename=A0=A0=A0=A0=A0=A0=A0 : draf= t-shima-clouds-net-portability-reqs-and-models-01.txt
Pages=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 : 10
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-= 17

=A0=A0 Recent progress of virtual machine technology made it possible t= o
=A0=A0 host various Internet service nodes in a so called cloud enviro= nment.
=A0=A0 The virtual machine hosting technology provides a method t= o migrate a
=A0=A0 virtual machine from one hypervisor to another.=A0 However, such a=A0=A0 technology is mainly focusing on a migration between hypervisors=A0=A0 attached to the same link, and tend not to consider migration over=
=A0=A0 the Internet.=A0 This document mentions the purpose of that type= of
=A0=A0 operation and describe several possible operation methods to provide=
=A0=A0 network portability in cloud systems.


A URL for this = Internet-Draft is:
http:= //www.ietf.org/internet-drafts/draft-shima-clouds-net-portability-reqs-and-= models-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/int= ernet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts= /draft-shima-clouds-net-portability-reqs-and-models-01.txt
--f46d044789156d2b0004af850b9f-- From dromasca@avaya.com Mon Oct 24 04:18:45 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A8021F8CFB for ; Mon, 24 Oct 2011 04:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7fVJvKMfZUP for ; Mon, 24 Oct 2011 04:18:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6D93121F8CFA for ; Mon, 24 Oct 2011 04:18:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAALVIpU7GmAcF/2dsb2JhbABAA5lQj0GBBYFuAQEBAQMBAQEPFQkKNAQHDAICAgEIDQMBBAEBAQoGDAsBBgEaDB8JCAEBBAESCBqHZpgdmwAChSmCNGEEmVSMEg X-IronPort-AV: E=Sophos;i="4.69,397,1315195200"; d="scan'208";a="274132437" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Oct 2011 07:18:42 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Oct 2011 07:16:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2011 13:18:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt thread-index: AcyI7SMya6MaoYSRSSebf33Nbl/qWAAFvbmAAk5ZLWA= References: <20111007143330.6945.7834.idtracker@ietfa.amsl.com><20111007150136.GA60009@elstar.local><20111012144138.GA18898@elstar.local> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Juergen Schoenwaelder" , "Mark Ellison" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 11:18:45 -0000 Hi, Sorry for the late intervention, I was on vacation for the last 12 days. In answer to Andy's AD-directed question, I think that this is true and that this document is a 'natural' extension of RFC 5935 and in line with the plans we had in mind when we started the work on XML-based configuration in the area. I do not think it will harm or impact in anyway the usage of YANG or definition of YANG modules. The question is to what extent it will be used, but then this is a more general question about the usage and usefulness of XSD for this purpose.=20 Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Andy Bierman > Sent: Wednesday, October 12, 2011 7:34 PM > To: Juergen Schoenwaelder; Mark Ellison > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual- > conventions-xsd-00.txt >=20 > We went through the overlap discussion about a year ago I think. > Choice of tools is subjective. I prefer to use YANG, not XSD, > so I can't say this draft is useful of not, because XSD itself > is not useful to me. >=20 > Since we have no official YANG to XSD mapping, there is no chance > that there can be conflicts between different XSDs (generated vs. > static). > So there is no chance that any YANG definition could ever be affected > because it doesn't 'match the XSD version' in this draft. >=20 > As long as that is true (ADs?) then I have no strong objections to this > draft. >=20 >=20 > Andy >=20 >=20 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, October 12, 2011 7:42 AM > To: Mark Ellison > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] I-D Action: draft-ellison-opsawg-smi-textual- > conventions-xsd-00.txt >=20 > On Wed, Oct 12, 2011 at 10:22:50AM -0400, Mark Ellison wrote: >=20 > > The mapping in draft-ellison-opsawg-smi-textual-conventions-xsd, as > compared > > to the SMIv2-->YANG-->XSD production is more faithful to and better > reflects > > the semantics and base data types of SMIv2 textual conventions. I > believe > > you will see that the proposed mapping > > in draft-ellison-opsawg-smi-textual-conventions-xsd is simpler, more > direct > > and lends itself to a less complex tool set. >=20 > My concern is that multiple mappings to XSD likely are more costly > than having a single one. >=20 > > The mapping described in draft-ellison-opsawg-smi-textual- > conventions-xsd > > has no dependencies on YANG and the resulting XSD has no dependencies > upon > > YANG namespaces. Rather, there is a dependency upon the namespace > > established within RFC 5935. >=20 > Putting all TCs into a single namespace won't work if you have TCs in > different SMIv2 modules that happen to have the same name. >=20 > > In other words, when TCs are mapped from SMIv2 to XSD using the > algorithms > > described in draft-ellison-opsawg-smi-textual-conventions-xsd, the > resulting > > XSD is built upon the XSD simple types, as defined in RFC 5935, > representing > > the mapped SMIv2 base type. Thus the relationship between TC > refinement and > > base type as established within the SMIv2 is maintained within the > XSD. I > > believe this essential relationship is lost in the SMIv2-->YANG-->XSD > > mapping currently produced by smidump and pyang. >=20 > Not sure what is lost. Perhaps an example helps me to understand. >=20 > > My hope is that participants of the OPSAWG see the value of such an > > algorithmic, direct mapping from SMIv2 to XSD for textual > conventions, that > > is faithful to the original SMIv2, that deterministically extends > from the > > mapped SMIv2 base types and, that has no dependencies on YANG > intermediate > > forms or YANG namespaces in the resulting XSD. >=20 > I am concerned about having multiple mappings that lead not just to > different namespaces but also different XSD data types. I am also kind > of missing the description of the actual algorithm in the document (OK > its a first draft so probably too much to ask for). What I see are a > collection of examples and it is not always clear how the algorithm > would actually work (e.g. how does the pattern you have for > DateAndTime work faithfully with base=3D"smi:OctetString")? It is not > really clear from the document whether you want to standardize an > algorithm or the outcome of executing an algorithm on a certain > collection of TCs (in that case a single namespace might work but > then extending the collection will be painful). >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From vumip1@gmail.com Mon Oct 24 15:51:41 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF76421F8B47; Mon, 24 Oct 2011 15:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyg0IIDAs-e2; Mon, 24 Oct 2011 15:51:40 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4F421F8B46; Mon, 24 Oct 2011 15:51:38 -0700 (PDT) Received: by gyh20 with SMTP id 20so7545127gyh.31 for ; Mon, 24 Oct 2011 15:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=0SCoGwv8JROI9x+nhOVkuvRFAw3W01fTvjLN/C+Su5k=; b=OqbYQydvtRgc9InejVqmmLqJjeon6BIdUJ9M/kOBVPNLh4fsZZ6fTelu2boqQT3kcu 7P4hB+HX/uwIvgAtadJ39UVZ92+m+jS1SA9Lca3RadkUwAOu2NYJgvFQEDfq4fpnhg6G kZIEvaDARiCQNrSaWTdtmH9lABXSkgt68oXWI= MIME-Version: 1.0 Received: by 10.182.13.1 with SMTP id d1mr3768025obc.74.1319496698001; Mon, 24 Oct 2011 15:51:38 -0700 (PDT) Received: by 10.182.37.69 with HTTP; Mon, 24 Oct 2011 15:51:37 -0700 (PDT) Date: Mon, 24 Oct 2011 18:51:37 -0400 Message-ID: From: Bhumip Khasnabish To: opsawg@ietf.org, l3vpn@ietf.org Content-Type: multipart/alternative; boundary=f46d044402f0f777ad04b0134311 Subject: [OPSAWG] Fwd: L3VPN automatical interconnection for VPN4DC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 22:51:41 -0000 --f46d044402f0f777ad04b0134311 Content-Type: text/plain; charset=ISO-8859-1 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : L3VPN automatical interconnection for VPN4DC Author(s) : Lizhong Jin Ning So Bhumip Khasnabish Bo Wu Filename : draft-jin-l3vpn-vpn4dc-interconnect-00.txt Pages : 7 Date : 2011-10-24 VPN4DC provides VPN oriented datacenter service to customer through L3VPN which is consisted of (private) L3VPN in datacenter and network provider's L3VPN over wide geographical area. If we considering the two L3VPN in two different AS, [RFC4364] providers three options to achieve L3VPN inter-AS connection. Both option A and B could be used to connect L3VPN in VPN4DC. This draft discusses a novel method for implementing option A, to automatically configure the VRF interface in order to interconnect the two segments of the end-to-end L3VPN. This L3VPN interconnection automation mechanism is expected to significantly reduce the VPN oriented inter-connection/service provisioning time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt --f46d044402f0f777ad04b0134311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : L3VPN automatical interco= nnection for VPN4DC
Author(s)=A0=A0=A0=A0=A0=A0 : Lizhong Jin
=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Ning = So
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Bhumip Khasnabish
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Bo Wu
Filename=A0=A0=A0=A0=A0=A0=A0 : draft-jin= -l3vpn-vpn4dc-interconnect-00.txt
Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = 7
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-24

=A0=A0 VPN4D= C provides VPN oriented datacenter service to customer through
=A0=A0 L3VPN which is consisted of (private) L3VPN in datacenter and networ= k
=A0=A0 provider&#39;s L3VPN over wide geographical area.=A0 If we = considering the
=A0=A0 two L3VPN in two different AS, [RFC4364] provider= s three options to
=A0=A0 achieve L3VPN inter-AS connection.=A0 Both option A and B could be u= sed
=A0=A0 to connect L3VPN in VPN4DC.=A0 This draft discusses a novel m= ethod for
=A0=A0 implementing option A, to automatically configure the V= RF interface
=A0=A0 in order to interconnect the two segments of the end-to-end L3VPN.=A0=A0 This L3VPN interconnection automation mechanism is expected to
= =A0=A0 significantly reduce the VPN oriented inter-connection/service
= =A0=A0 provisioning time.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-= 00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/int= ernet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-jin-l3vp= n-vpn4dc-interconnect-00.txt

--f46d044402f0f777ad04b0134311-- From peng.yonglin@zte.com.cn Mon Oct 24 19:24:03 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCA911E80B8; Mon, 24 Oct 2011 19:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.176 X-Spam-Level: X-Spam-Status: No, score=-95.176 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLSaYyKgN4dL; Mon, 24 Oct 2011 19:24:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 549C01F0C52; Mon, 24 Oct 2011 19:23:56 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466213465113155; Tue, 25 Oct 2011 10:15:48 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 96241.4995755854; Tue, 25 Oct 2011 10:23:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9P2NhB2076847; Tue, 25 Oct 2011 10:23:43 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) To: , opsawg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Tue, 25 Oct 2011 10:23:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-25 10:23:44, Serialize complete at 2011-10-25 10:23:44 Content-Type: multipart/alternative; boundary="=_alternative 000D1EBE48257934_=" X-MAIL: mse02.zte.com.cn p9P2NhB2076847 Cc: hao.zhenwu@zte.com.cn Subject: Re: [OPSAWG] An SNMP Usage for RELOAD X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 02:24:04 -0000 This is a multipart message in MIME format. --=_alternative 000D1EBE48257934_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCldlIGhhdmUgZG9uZSBtb3JlIHJlc2VhcmNoIG9uIHNlY3VyaXR5IGFuZCBvdGhlciBp c3N1ZXMgYmFzZWQgb24gRGF2aWQncyANCmNvbW1lbnRzLCBhbmQgdXBkYXRlZCBvdXIgZHJhZnQu DQoNClRoaXMgaXMgdGhlIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0OiANCmh0dHA6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtcGVuZy1wMnBzaXAtc25tcC0wMy50eHQNCg0KV2Ugd2VsY29tZSBhbnkgY29t bWVudHMhIFRoYW5rcyENCg0KDQpPdXIgYW5hbHlzaXMgb2YgRGF2aWQncyBjb21tZW50cyBhcyBm b2xsb3dzKGJsdWUgdGV4dCk6DQoNCjEpIFVzZSBTTk1QdjMgdGVybWlub2xvZ3kNCkFwcGFyZW50 bHksIHlvdSBjb21lIGZyb20gdGhlIFJFTE9BRCBzaWRlIG9mIHRoaW5ncywgbm90IHRoZSBTTk1Q DQpzaWRlLg0KWW91ciB0ZXh0IGRvZXNuJ3QgdXNlIHRoZSBjb21tb24gU05NUCB0ZXJtaW5vbG9n eSBmb3IgdmFyaW91cw0KU05NUC1yZWxhdGVkIHRoaW5ncy4NCllvdSB3aWxsIGhhdmUgYSBiZXR0 ZXIgY2hhbmNlIG9mIHN1Y2Nlc3MgaWYgeW91IGRlc2NyaWJlIFNOTVAtcmVsYXRlZA0KdGhpbmdz IHVzaW5nIHRoZSBub3JtYWwgU05NUHYzIHRlcm1pbm9sb2d5Lg0KVGhpcyBpc24ndCBjcml0aWNh bDsgeW91ciBpZGVhcyBzZWVtIHJlYXNvbmFibGUsIGJ1dCBzaW5jZSB5b3UgZG9uJ3QNCnVzZSB0 aGUgc3RhbmRhcmQgdGVybWlub2xvZ3ksIHlvdSBtaWdodCBtZWFuIHNsaWdodGx5IGRpZmZlcmVu dCB0aGluZ3MNCnRoYW4gd2hhdCBpdCB3b3VsZCBtZWFuIGlmIHlvdSB1c2VkIHRoZSBzdGFuZGFy ZCB0ZXJtaW5vbG9neS4NCg0KKEkgZG9uJ3QgaGF2ZSBhIFJFTE9BRCBiYWNrZ3JvdW5kLCBzbyBz b21lIG9mIG15IGNvbW1lbnRzIG1pZ2h0IHNlZW0NCndyb25nIGJlY2F1c2UgSSBkb24ndCBrbm93 IHRoZSBSRUxPQUQgY29uY2VwdHMgYW5kIHRlcm1pbm9sb2d5LiBOb3cNCnlvdSdsbCB1bmRlcnN0 YW5kIG15IHBvaW50IDstKQ0KDQpQWUw6IFdlIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdXNpbmcg U05NUCB0ZXJtaW5vbG9neS4gQXMgd2UgYXJlIG5vdCBTTk1QDQpleHBlcnRzLCBzb21lIHRlcm1p bm9sb2d5IG1heSBub3QgYmUgYWNjdXJhdGUuIFdlIHdpbGwgdHJ5IHRvIGltcHJvdmUgdGhpcw0K b3ZlciB0aW1lLg0KDQoyKSBVc2UgU05NUHYzDQpJdCBpcyBpbXBvcnRhbnQgdG8gbWFrZSBzdXJl IHlvdSBhcmUgdGFsa2luZyBhYm91dCBTTk1QdjMuIFNOTVB2MSBhbmQNClNOTVB2MiBoYXZlIGJl ZW4gZGVjbGFyZWQgSGlzdG9yaWMsIGFuZCBubyBuZXcgd29yayBzaG91bGQgYmUgZG9uZQ0KdXNp bmcgdGhvc2UgcHJvdG9jb2xzLiBIb3dldmVyLCBhbnkgTUlCIG1vZHVsZSBzaG91bGQgYmUgYWJs ZSB0byBiZQ0KdXNlZCB3aXRoIGFueSB2ZXJzaW9uIG9mIFNOTVAuDQpNeSBjb25jZXJuIGlzIHRo YXQgU05NUHYzIGhhcyBhc3N1bXB0aW9ucyBhYm91dCBzZWN1cml0eSBhc3NvY2lhdGlvbnMsDQph bmQgeW91IG5lZWQgdG8gbWFrZSBzdXJlIHRob3NlIGFyZSBjb25zaWRlcmVkLg0KDQpQWUw6IFdl IGRldGFpbGVkIHRoZSBzZWN1cml0eSBhbmQgTkFUIHRyYXZlcnNhbCBhbmQgb3RoZXIgY29udGVu dCANCmNvbnNpZGVyYXRpb25zIG9mIHRoZSBkb2N1bWVudCBiYXNlZCBvbiB0aGUgYXJjaGl0ZWN0 dXJlIGFuZCBkZXNjcmlwdGlvbiANCm1vZGUgb2YgU05NUHYzLiANCg0KMykgVXNlIE1JQiBtb2R1 bGVzDQpZb3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIG1hbmFnZXIgZ2V0dGluZyBpbmZvcm1hdGlv biBmcm9tIGEgbWFuYWdlZA0Kbm9kZS4gVGhlIHJpZ2h0IHdheSB0byBhcHByb2FjaCAiaW5mb3Jt YXRpb24gZnJvbSBhIG5vZGUiIGlzIHRvIGRlZmluZQ0KYSBNSUIgbW9kdWxlIHRoYXQgY29udGFp bnMgdGhlIGluZm9ybWF0aW9uIGZvciB0aGUgbWFuYWdlZCBub2RlLiBTTk1QDQoodHlwaWNhbGx5 KSBvbmx5IGNhcnJpZXMgaW5mb3JtYXRpb24gZnJvbSBNSUIgbW9kdWxlcy4gU28gd2hlbiB5b3UN CnRhbGsgYWJvdXQgdGhlIGluZm9ybWF0aW9uIGFib3V0IGEgbm9kZSwgeW91IHByb2JhYmx5IHNo b3VsZCB0YWxrDQphYm91dCBhIE1JQiBtb2R1bGUgYXQgdGhlIG1hbmFnZWQgbm9kZS4gSWYgdGhl IGZ1bmN0aW9uYWxpdHkgaXMNCmRpZmZlcmVudCBhdCB0aGUgTy1ub2RlIGFuZCBSLW5vZGUsIHlv dSBtaWdodCBuZWVkIGRpZmZlcmVudCBNSUINCm1vZHVsZXMsIG9yIGhhdmUgb25lIE1JQiBtb2R1 bGUgdGhhdCBzdXBwb3J0cyBib3RoIHJvbGVzLg0KDQpQWUw6IE5vIE1JQiBjb25jZXJuaW5nIGlt cGxlbWVudGF0aW9uIG1lY2hhbmlzbSBuZWVkIGJlIGRlZmluZWQsIGFuZCB3ZSANCm1heSBkZWZp bmUgdGhlIE1JQiBhYm91dCB0aGUgbWFuYWdlZCBvYmplY3RzIG9mIFJFTE9BRCBOb2RlIGluIHRo ZSBmdXR1cmUuDQoNCjQpIFVzZSBTTk1QIEVuZ2luZUlEDQpZb3UgdGFsayBhYm91dCBhIE5vZGUg SUQgaW4gdGhlIFJFTE9BRCBuZXR3b3JrLiBUaGVyZSBpcyBhbHNvIGFuDQppZGVudGlmaWVyIGlu IHRoZSBTTk1QIG5ldHdvcmssIGNhbGxlZCB0aGUgU25tcEVuZ2luZUlELiBJdCBtaWdodCBiZQ0K cG9zc2libGUgdG8gdXNlIHRoZSBTbm1wRW5naW5lSUQgYXMgYSBSRUxPQUQgTm9kZSBJRCwgYnV0 IFNubXBFbmdpbmVJRA0KaXMgbm90IHVzZXItZnJpZW5kbHkuIFNubXBFbmdpbmVJRCBpcyBuZWVk ZWQgZm9yIHR3byBTTk1QIGVuZHBvaW50cyB0bw0KdGFsayB0byBlYWNoIG90aGVyLiBTbyB5b3Ug bWlnaHQgd2FudCB0byBoYXZlIHRoZSBTbm1wRW5naW5lSUQNCmluY2x1ZGVkIGluIHRoZSBSZWdp c3RyYXRpb24gaW5mb3JtYXRpb24uIA0KDQpUeXBpY2FsbHksIHR3byBTTk1QIG5vZGVzIG5lZWQg dG8gYmUgcHJlLWNvbmZpZ3VyZWQgdG8gdGFsayBiZWNhdXNlDQpTTk1QIGhhcyBhY2Nlc3MgY29u dHJvbCBmb3IgdGhlIE1JQiBkYXRhYmFzZSwgYW5kIHRoZSB1c2VyIG5lZWRzIHRvIGJlDQpjb25m aWd1cmVkIHRvIGhhdmUgYWNjZXNzIHRvIHRoZSBkYXRhYmFzZS4gU28gYSBkaXNjb3ZlcnkgbWVj aGFuaXNtIHRvDQpkZXRlcm1pbmUgd2hlcmUgdG8gZmluZCBhIG1hbmFnZXIgbWlnaHQgYmUgc3Vw ZXJmbHVvdXMsIHNpbmNlIGENCnNlY3VyaXR5IGFzc29jaWF0aW9uIGJldHdlZW4gdGhlIG1hbmFn ZXIgYW5kIG1hbmFnZWQgbm9kZSBtaWdodCBuZWVkDQp0byBiZSBwcmUtZXN0YWJsaXNoZWQgYW55 d2F5LiANCg0KSSBhbSBub3QgdHJ5aW5nIHRvIGNvbnZpbmNlIHlvdSBub3QgdG8gZG8gdGhpcyBk aXNjb3Zlcnkgd29yaywgYnV0IHRvDQpiZSBhd2FyZSBpdCBtaWdodCBub3QgbWFrZSBzZW5zZS4g T1RPSCwgYSBtZWNoYW5pc20gdGhhdCB3b3VsZCBhbGxvdw0KYW4gYWdlbnQgdG8gZmluZCBpdHMg bWFuYWdlciwgZXNwZWNpYWxseSBpbiBhIE5BVCBlbnZpcm9ubWVudCwgY291bGQNCmJlIHZlcnkg dXNlZnVsIGZvciBTTk1QLiBTZWUgYWxzbyBSRkM1MzQzLg0KDQpQWUw6IFJFTE9BRCBOb2RlSUQg aXNuJ3QgdXNlci1mcmllbmRseSB0b28sIHdlIHByb3Bvc2UgdG8gZGVyaXZlIHRoZSANClNubXBF bmdpbmVJRCBiYXNlZCBvbiBSRUxPQUQgTm9kZUlELiBUaGVyZWZvcmUsDQplYWNoIFJFTE9BRCBO b2RlIGlzIGFzc29jaWF0ZWQgd2l0aCBhbiBTTk1QIEVuZ2luZS4gV2UgaGF2ZW4ndCBkZWZpbmVk IHRoZSANCmRldGFpbGVkIHdheXMgdG8gY29uc3RydWN0IHRoZSBTbm1wRW5naW5lSUQgaW4gdGhl IGRyYWZ0LiBXZSBtYXkgY29uc3RydWN0IA0KdGhlIFNubXBFbmdpbmVJRCBieSBSRUxPQUQgTm9k ZUlEIGFuZCBwcml2YXRlIGVudGVycHJpc2UgbnVtYmVyLCBhbHNvIG1heSANCnVzZSBSRUxPQUQg Tm9kZUlEIGFzIFNubXBFbmdpbmVJRC4gDQpQcmUtY29uZmlndXJhdGlvbiBpcyBhcHByb3ByaWF0 ZSBmb3IgdGhlIG1hbmFnZXIgZGVwbG95ZWQgc3RhdGljbHksIGFuZCANCmRpc2NvdmVyeSBpcyBh cHByb3ByaWF0ZSBmb3IgdGhlIG1hbmFnZXIgZGVwbG95ZWQgZHluYW1pY2FsbHkuIFdlIGludGVu ZCANCnRvIGRlcGxveSBkeW5hbWljYWxseSBtYW5hZ2VyIGluIFJFTE9BRCBuZXR3b3JrLiANCg0K DQo1KSBDb25zaWRlciB1c2luZyBQUk9YWS1NSUINClNOTVB2MyB1c2VzIGhvcC10by1ob3Agc2Vj dXJpdHksIGJ1dCB0aGUgbWFuYWdlbWVudCBpcyBlbmQtdG8tZW5kLg0KU25tcEVuZ2VpbklEIGlz IHVzZWQgYm90aCBkdXJpbmcgYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBhdCBhDQpob3At YnktaG9wIGxldmVsLCBhbmQgaXMgY29udGFpbmVkIGluIHRoZSBTTk1QIG1lc3NhZ2UgdG8gaWRl bnRpZnkgdGhlDQpzb3VyY2Ugbm9kZSBmb3IgdGhlIGluZm9ybWF0aW9uLiAoc28sIGZvciBleGFt cGxlLCBhIHRyYXAgbWVzc2FnZSB0bw0KbWFuYWdlciBBIGZyb20gbm9kZSBDIGlzIGlkZW50aWZp ZWQgYXMgYmVpbmcgZnJvbSBub2RlIEMsIGV2ZW4gaWYgdGhlDQpTTk1QIG1lc3NhZ2UgZ2V0cyBy ZWxheWVkIHZpYSBub2RlIEIsIGFuZCBTTk1QIG1lc3NhZ2Ugc2VjdXJpdHkgaXMNCmRvbmUgQy10 by1CLCBhbmQgdGhlbiBCLXRvLUEuIFRoZSBjb250ZW50cyBvZiB0aGUgdmFyYmluZHMgYXJlIHN0 aWxsDQppZGVudGlmaWVkIGFzIGJlaW5nIGZyb20gbm9kZSBDLg0KDQpUaGVyZSBpcyBhIFBST1hZ LU1JQiBpbiBSRkMzNDEzKD8pIHRvIHNwZWNpZnkgaG93IHRvIHJlbGF5IFNOTVANCm1lc3NhZ2Vz LiBUaGlzIGFsbG93cyBub2RlIEEgdG8gaGF2ZSBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIHdpdGgg QiwNCmFuZCBCIHRvIGhhdmUgYSBzZWN1cml0eSBhc3NvY2lhdGlvbiB3aXRoIEMsIHdpdGhvdXQg cmVxdWlyaW5nIEEgdG8NCmhhdmUgYSBzZWN1cml0eSBhc3NvY2lhdGlvbiBkaXJlY3RseSB3aXRo IEMuDQpJIGRvIG5vdCBiZWxpZXZlIHRoaXMgaXMgaW4gd2lkZS1zcHJlYWQgdXNlLCBidXQgaXQg d2FzIGRlc2lnbmVkIGludG8NClNOTVAgZXhwbGljaXRseSB0byBoZWxwIGdldCB0aHJvdWdoIGlu dGVybWVkaWFyaWVzLCBzdWNoIGFzIGZpcmV3YWxscy4NCihOQVRzIGFuZCBJQ0Ugd2VyZSBub3Qg d2lkZWx5IGRlcGxveWVkIGF0IHRoYXQgdGltZSwgYnV0IGl0IGNhbiBhbHNvDQpiZSBhcHBsaWVk IHRvIGdldHRpbmcgYXJvdW5kIE5BVHMuKQ0KDQo2KSBDb25zaWRlciB1c2luZyBNSURDT00tTUlC DQpUaGlzIHdhcyB3cml0dGVuIGFmdGVyIFNOTVB2MyBjb21wbGV0ZWQsIGFuZCBiZWZvcmUgSUNF LiBJdCB3YXMNCmRlc2lnbmVkIHRvIGRlYWwgd2l0aCBOQVRzIGFuZCBmaXJld2FsbHMsIGFuZCBv dGhlciBtaWRkbGUgYm94ZXMuIEkNCmJlbGlldmUgaXQgaXMgbm90IHdpZGVseSBkZXBsb3llZC4g SSB0aGluayB0aGUgSUVURiBjb21tdW5pdHkgcHJlZmVycw0KSUNFIGZvciBnZXR0aW5nIGFyb3Vu ZCBOQVRzLCBidXQgZm9yIGRvaW5nIFNOTVAgbWFuYWdlbWVudCB0aHJvdWdoIGENClJFTE9BRC1t YW5hZ2VkIG1pZGRsZWJveCwgaXQgbWlnaHQgYmUgaGVscGZ1bC4gbWF5YmUgbm90Lg0KDQpQWUw6 IEFzIG91ciBzb2x1dGlvbiBzZXRzIHVwIGEgZGlyZWN0aW9uIGNvbm5lY3Rpb24gYmV0d2VlbiBT Tk1QIGFnZW50cywNClBST1hZLU1JQiBvciBNSURDT00tTUlCIG1heSBub3QgYmUgdXNlZCBpbiBv dXIgZHJhZnQuDQoNCg0KNykgVXNlIGV4aXN0aW5nIFNOTVB2My1zdXBwb3J0ZWQgc2VjdXJpdHkg cHJvdG9jb2xzDQpVU00gaXMgdGhlIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgc2VjdXJpdHkgZm9y IFNOTVB2MywgYmVjYXVzZSBTTk1QdjMNCm5lZWRzIHRvIHdvcmsgd2hlbiBhIG5ldHdvcmsgaXMg bm90IHdvcmtpbmcgd2VsbCwgYW5kIFVTTSBpcw0Kc2VsZi1jb250YWluZWQgaW4gU05NUHYzLiBI b3dldmVyLCBmb3Igbm9ybWFsIG1hbmFnZW1lbnQgdGFza3MsIGFuZA0KbXVjaCBlYXNpZXIga2V5 IGRpc3RyaWJ1dGlvbiwgb3BlcmF0b3JzIGdyZWF0bHkgcHJlZmVyIHVzaW5nIHRoZXJpcg0KYWxy ZWFkeS13aWRlbHktZGVwbG95ZWQgc2VjdXJpdHkgc29sdXRpb25zLCBzdWNoIGFzIFNTSCwgVExT LCBhbmQNCkRUTFMuIE9wZXJhdG9ycyBwYXJ0aWN1bGFyeSBkaXNsaWtlZCBoYXZpbmcgdG8gbWFp bnRhaW4gYSB3aG9sZQ0KZGlmZmVyZW50IHNlY3VyaXR5IGluZnJhc3RydWN0dXJlIGp1c3QgZm9y IGNhcnJ5aW5nIFNOTVAuDQoNClJGQzU1OTAsIDU1OTEsIDU1OTIsIGFuZCA1OTUzIGFkZCBzdXBw b3J0IGZvciB1c2luZyBleGlzdGluZyBzZWN1cml0eQ0KaW5mcmFzdHJ1Y3R1cmUgZm9yIFNOTVB2 MysgbWVzc2FnZXMuIFRoaXMgbWlnaHQgYmUgYSBiZXR0ZXIgYXBwcm9hY2gNCnRoYW4gZGVzaWdu aW5nIGEgUkVMT0FELXNwZWNpZmljIHNvbHV0aW9uIGZvciBjYXJyeWluZyBTTk1QIHNlY3VyZWx5 Lg0KDQpQWUw6IFdlIHRoaW5rIHRoZSBUTFMgc2VjdXJpdHkgbW9kZWwgaXMgYSBnb29kIGZpdCBm b3IgUkVMT0FELiBSRUxPQUQgYWxzbw0KdXNlcyBUTFMgZm9yIGNvbm5lY3Rpbmcgbm9kZXMgYW5k IHByb3ZpZGVzIGNlcnRpZmljYXRpb25zIHRoYXQgY2FuIGJlIA0KcmV1c2VkDQpieSBTTk1QIFRM Uy4NCg0KOCkgQmUgYXdhcmUgb2YgYWRkcmVzcyB0cmFuc2xhdGlvbiBpc3N1ZXMgZm9yIFNOTVAN Ckl0IGlzIGltcG9ydGFudCBmb3IgdGhlIGluZm9ybWF0aW9uIGNvbnZleWVkIHVzaW5nIFNOTVAg dG8gYmUNCmFjY3VyYXRlLiBhbmQgdGhhdCBtZWFucyBpZiB0aGUgbWFuYWdlZCBub2RlIHB1dHMg aXRzIElQIGFkZHJlc3MgaW50bw0KYSBNSUIsIGFuZCB0aGF0IE1JQiBpcyB0cmFuc2xhdGVkIGlu dG8gU05NUCB2YXJiaW5kcywgYW5kIHRob3NlDQp2YXJiaW5kcyBnbyB0aHJvdWdoIGEgTkFUIChv ciBoZXJlIGEgUkVMT0FEIHByb3h5KSwgdGhhdCB0aGUgSVANCmFkZHJlc3MgaW5zaWRlIHRoZSB2 YXJiaW5kIGlzIG5vdCBtb2RpZmllZC4gUkZDIDI5NjIgZGlzY3Vzc2VzIEFMRw0KY29uc2lkZXJh dGlvbnMgZm9yIFNOTVAuIEkgdGhpbmsgeW91ciBwcm9wb3NhbCBpcywgdG8gYSBkZWdyZWUsIGFu IEFMRw0KZm9yIFNOTVAgKGJ1dCB5b3VyIHByb3Bvc2FsIGxhY2tzIGVub3VnaCBkZXRhaWwgZm9y IG1lIHRvIGJlIHN1cmUpLg0KUGxlYXNlIGJlIHN1cmUgdG8gcmVhZCBSRkMyOTYyLg0KDQpUaGlz IGV2ZW4gaGFzIGFuIElFU0cgTm90ZSBhdHRhY2hlZDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGFuIFNOTVAgYXBwbGljYXRpb24gbGF5ZXIgZ2F0ZXdheSAoQUxHKSwNCiAgIHdoaWNoIG1h eSBiZSB1c2VmdWwgaW4gY2VydGFpbiBlbnZpcm9ubWVudHMuICBUaGUgZG9jdW1lbnQgZG9lcw0K YWxzbw0KICAgbGlzdCB0aGUgaXNzdWVzIGFuZCBwcm9ibGVtcyB0aGF0IGNhbiBhcmlzZSB3aGVu IHVzZWQgYXMgYSBnZW5lcmljDQogICBTTk1QIEFMRy4gIFNwZWNpZmljYWxseSwgd2hlbiB1c2lu ZyBTTk1QdjMncyBhdXRoZW50aWNhdGlvbiBhbmQNCiAgIHByaXZhY3kgbWVjaGFuaXNtcyB0aGlz IGFwcHJvYWNoIG1heSBiZSB2ZXJ5IHByb2JsZW1hdGljIGFuZA0KICAgamVvcGFyZGl6ZSB0aGUg U05NUCBzZWN1cml0eS4gIFRoZSByZWFkZXIgaXMgdXJnZWQgdG8gY2FyZWZ1bGx5DQogICBjb25z aWRlciB0aGVzZSBpc3N1ZXMgYmVmb3JlIGRlY2lkaW5nIHRvIGRlcGxveSB0aGlzIHR5cGUgb2Yg U05NUA0KICAgQUxHLg0KDQpQWUw6IFdlIHVzZSB0aGUgUkVMT0FEIG1lY2hhbmlzbXMgdG8gdHJh dmVyc2UgTkFULiBBcyB3ZSB1c2UgVExTIGZvciANCnNlY3VyaXR5LCB0aGUNClNOTVAgQUxHIHBy b2JsZW0gbWF5IG5vdCBhcmlzZSBpbiBvdXIgc29sdXRpb24uDQoNCjkpIFVzaW5nIFNOTVAgdG8g ZG8gY29uZmlndXJhdGlvbiBjYW4gYmUgcHJvYmxlbWF0aWMNCkJlY2F1c2UgU05NUHYxIHdhcyBu b3Qgc2VjdXJlLCBhbmQgQ0xJIGNhbiBiZSB1c2VkIHRvIGRvDQpjb25maWd1cmF0aW9uLCBtYW55 IFNOTVAgYWdlbnRzIGRvIG5vdCByZWFsbHkgc3VwcG9ydCBTRVRzLiBpZiB0aGV5IGRvDQpzdXBw b3J0IFNFVHMsIHRob3NlIFNFVHMgb2Z0ZW4gbmV2ZXIgZ2V0IHNhdmVkIHRvIE5WUkFNLiBTbw0K cmVjb21tZW5kaW5nIFNOTVAgdG8gY29uZmlndXJlIG5vZGVzIGNvdWxkIGJlIGEgcHJvYmxlbSBp biBtYW55DQppbXBsZW1lbnRhdGlvbnMuIEknbSBub3QgdGVsbGluZyB5b3Ugbm90IHRvIGRvIHRo aXMsIGJ1dCBiZSBhd2FyZSBvZg0KdGhlIHByb2JsZW1zIChtYXliZSB3cml0ZSB0aGlzIGludG8g YW4gIk9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQNCkNvbnNpZGVyYXRpb25zIiBzZWN0aW9uKS4N Cg0KUFlMOiBSRUxPQUQgaGFzIHByb3ZpZGVkIHNvbWUgbWVjaGFuaXNtcyBmb3IgYmFzaWMgY29u ZmlndXJhdGlvbi4gV2Ugd2lsbCANCnRyeQ0KdG8gZmlndXJlIG91dCB3aGljaCB3YXkgaXMgYmV0 dGVyIGZvciBzZXR0aW5nIHRoZSBSRUxPQUQgbm9kZXMuDQoNCg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K08ogvP6junBlbmcueW9uZ2xpbkB6dGUu Y29tLmNuDQrE2iDP36O6ODE1NDMNCs3iIM/fo7owMjUtNTI4NzE1NDMNCsrWILv6o7oxMzc3NjYz NzI3NA0KtKsg1eajujAyNS01Mjg3MjE4Nw0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 000D1EBE48257934_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPkhpLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+V2Ug aGF2ZSBkb25lIG1vcmUgcmVzZWFyY2ggb24gc2VjdXJpdHkgYW5kIG90aGVyIGlzc3Vlcw0KYmFz ZWQgb24gRGF2aWQncyBjb21tZW50cywgYW5kIHVwZGF0ZWQgb3VyIGRyYWZ0LjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTI+VGhpcyBpcyB0aGUgbmV3IHZlcnNpb24gb2YgZHJhZnQ6IDwv Zm9udD48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXBlbmctcDJwc2lwLXNu bXAtMDMudHh0Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5odHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LXBlbmctcDJwc2lwLXNubXAtMDMudHh0PC9mb250PjwvYT4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KV2Ugd2VsY29tZSBhbnkgY29tbWVudHMhIFRoYW5r cyE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pk91ciBhbmFseXNpcyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPm9mDQpEYXZpZCdzIGNvbW1lbnRzPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4gYXMgZm9sbG93cyhibHVlDQp0ZXh0 KTo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEpIFVz ZSBTTk1QdjMgdGVybWlub2xvZ3k8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkFwcGFyZW50bHksIHlvdSBjb21lIGZyb20gdGhlIFJFTE9BRA0Kc2lkZSBvZiB0aGlu Z3MsIG5vdCB0aGUgU05NUDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+c2lkZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllvdXIg dGV4dCBkb2Vzbid0IHVzZSB0aGUgY29tbW9uIFNOTVANCnRlcm1pbm9sb2d5IGZvciB2YXJpb3Vz PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TTk1QLXJlbGF0ZWQg dGhpbmdzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WW91IHdp bGwgaGF2ZSBhIGJldHRlciBjaGFuY2Ugb2Ygc3VjY2Vzcw0KaWYgeW91IGRlc2NyaWJlIFNOTVAt cmVsYXRlZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhpbmdz IHVzaW5nIHRoZSBub3JtYWwgU05NUHYzIHRlcm1pbm9sb2d5LjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhpcyBpc24ndCBjcml0aWNhbDsgeW91ciBpZGVhcyBz ZWVtDQpyZWFzb25hYmxlLCBidXQgc2luY2UgeW91IGRvbid0PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj51c2UgdGhlIHN0YW5kYXJkIHRlcm1pbm9sb2d5LCB5b3Ug bWlnaHQNCm1lYW4gc2xpZ2h0bHkgZGlmZmVyZW50IHRoaW5nczwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhhbiB3aGF0IGl0IHdvdWxkIG1lYW4gaWYgeW91IHVz ZWQNCnRoZSBzdGFuZGFyZCB0ZXJtaW5vbG9neS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPihJIGRvbid0IGhhdmUgYSBSRUxPQUQgYmFja2dyb3VuZCwg c28NCnNvbWUgb2YgbXkgY29tbWVudHMgbWlnaHQgc2VlbTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+d3JvbmcgYmVjYXVzZSBJIGRvbid0IGtub3cgdGhlIFJFTE9B RA0KY29uY2VwdHMgYW5kIHRlcm1pbm9sb2d5LiBOb3c8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPnlvdSdsbCB1bmRlcnN0YW5kIG15IHBvaW50IDstKTwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5QWUw6 IFdlIGhhdmUgdXBkYXRlZCB0aGUNCmRyYWZ0IHVzaW5nIFNOTVAgdGVybWlub2xvZ3kuIEFzIHdl IGFyZSBub3QgU05NUDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj5leHBlcnRzLCBzb21lIHRlcm1pbm9sb2d5DQptYXkgbm90IGJlIGFjY3VyYXRl LiBXZSB3aWxsIHRyeSB0byBpbXByb3ZlIHRoaXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+b3ZlciB0aW1lLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MikgVXNlIFNOTVB2MzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SXQgaXMgaW1wb3J0YW50IHRvIG1ha2Ugc3Vy ZSB5b3UgYXJlDQp0YWxraW5nIGFib3V0IFNOTVB2My4gU05NUHYxIGFuZDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U05NUHYyIGhhdmUgYmVlbiBkZWNsYXJlZCBI aXN0b3JpYywNCmFuZCBubyBuZXcgd29yayBzaG91bGQgYmUgZG9uZTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dXNpbmcgdGhvc2UgcHJvdG9jb2xzLiBIb3dldmVy LCBhbnkNCk1JQiBtb2R1bGUgc2hvdWxkIGJlIGFibGUgdG8gYmU8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnVzZWQgd2l0aCBhbnkgdmVyc2lvbiBvZiBTTk1QLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TXkgY29uY2VybiBpcyB0 aGF0IFNOTVB2MyBoYXMgYXNzdW1wdGlvbnMNCmFib3V0IHNlY3VyaXR5IGFzc29jaWF0aW9ucyw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZCB5b3UgbmVlZCB0 byBtYWtlIHN1cmUgdGhvc2UgYXJlDQpjb25zaWRlcmVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5QWUw6IFdlIGRldGFpbGVkIHRo ZSBzZWN1cml0eQ0KYW5kIE5BVCB0cmF2ZXJzYWwgYW5kIG90aGVyIGNvbnRlbnQgY29uc2lkZXJh dGlvbnMgb2YgdGhlIGRvY3VtZW50IGJhc2VkDQpvbiB0aGUgYXJjaGl0ZWN0dXJlIGFuZCBkZXNj cmlwdGlvbiBtb2RlIG9mIFNOTVB2My4gJm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4zKSBVc2UgTUlCIG1vZHVsZXM8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllvdSBhcmUgdGFsa2luZyBhYm91dCB0aGUgbWFu YWdlciBnZXR0aW5nDQppbmZvcm1hdGlvbiBmcm9tIGEgbWFuYWdlZDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bm9kZS4gVGhlIHJpZ2h0IHdheSB0byBhcHByb2Fj aCAmcXVvdDtpbmZvcm1hdGlvbg0KZnJvbSBhIG5vZGUmcXVvdDsgaXMgdG8gZGVmaW5lPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hIE1JQiBtb2R1bGUgdGhhdCBj b250YWlucyB0aGUgaW5mb3JtYXRpb24NCmZvciB0aGUgbWFuYWdlZCBub2RlLiBTTk1QPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4odHlwaWNhbGx5KSBvbmx5IGNh cnJpZXMgaW5mb3JtYXRpb24NCmZyb20gTUlCIG1vZHVsZXMuIFNvIHdoZW4geW91PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50YWxrIGFib3V0IHRoZSBpbmZvcm1h dGlvbiBhYm91dCBhIG5vZGUsDQp5b3UgcHJvYmFibHkgc2hvdWxkIHRhbGs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFib3V0IGEgTUlCIG1vZHVsZSBhdCB0aGUg bWFuYWdlZCBub2RlLg0KSWYgdGhlIGZ1bmN0aW9uYWxpdHkgaXM8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRpZmZlcmVudCBhdCB0aGUgTy1ub2RlIGFuZCBSLW5v ZGUsDQp5b3UgbWlnaHQgbmVlZCBkaWZmZXJlbnQgTUlCPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5tb2R1bGVzLCBvciBoYXZlIG9uZSBNSUIgbW9kdWxlIHRoYXQN CnN1cHBvcnRzIGJvdGggcm9sZXMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlBZTDogTm8gTUlCIGNvbmNlcm5pbmcgaW1wbGVtZW50 YXRpb24NCm1lY2hhbmlzbSBuZWVkIGJlIGRlZmluZWQsIGFuZCB3ZSBtYXkgZGVmaW5lIHRoZSBN SUIgYWJvdXQgdGhlIG1hbmFnZWQNCm9iamVjdHMgb2YgUkVMT0FEIE5vZGUgaW4gdGhlIGZ1dHVy ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjQpIFVz ZSBTTk1QIEVuZ2luZUlEPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5Zb3UgdGFsayBhYm91dCBhIE5vZGUgSUQgaW4gdGhlIFJFTE9BRA0KbmV0d29yay4gVGhlcmUg aXMgYWxzbyBhbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aWRl bnRpZmllciBpbiB0aGUgU05NUCBuZXR3b3JrLCBjYWxsZWQNCnRoZSBTbm1wRW5naW5lSUQuIEl0 IG1pZ2h0IGJlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5wb3Nz aWJsZSB0byB1c2UgdGhlIFNubXBFbmdpbmVJRCBhcw0KYSBSRUxPQUQgTm9kZSBJRCwgYnV0IFNu bXBFbmdpbmVJRDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aXMg bm90IHVzZXItZnJpZW5kbHkuIFNubXBFbmdpbmVJRCBpcw0KbmVlZGVkIGZvciB0d28gU05NUCBl bmRwb2ludHMgdG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRh bGsgdG8gZWFjaCBvdGhlci4gU28geW91IG1pZ2h0IHdhbnQNCnRvIGhhdmUgdGhlIFNubXBFbmdp bmVJRDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aW5jbHVkZWQg aW4gdGhlIFJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbi4NCiZuYnNwOzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VHlwaWNhbGx5LCB0d28gU05NUCBub2Rl cyBuZWVkIHRvIGJlDQpwcmUtY29uZmlndXJlZCB0byB0YWxrIGJlY2F1c2U8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNOTVAgaGFzIGFjY2VzcyBjb250cm9sIGZv ciB0aGUgTUlCDQpkYXRhYmFzZSwgYW5kIHRoZSB1c2VyIG5lZWRzIHRvIGJlPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5jb25maWd1cmVkIHRvIGhhdmUgYWNjZXNz IHRvIHRoZSBkYXRhYmFzZS4NClNvIGEgZGlzY292ZXJ5IG1lY2hhbmlzbSB0bzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ZGV0ZXJtaW5lIHdoZXJlIHRvIGZpbmQg YSBtYW5hZ2VyIG1pZ2h0DQpiZSBzdXBlcmZsdW91cywgc2luY2UgYTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+c2VjdXJpdHkgYXNzb2NpYXRpb24gYmV0d2VlbiB0 aGUgbWFuYWdlcg0KYW5kIG1hbmFnZWQgbm9kZSBtaWdodCBuZWVkPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50byBiZSBwcmUtZXN0YWJsaXNoZWQgYW55d2F5LiA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gbm90 IHRyeWluZyB0byBjb252aW5jZSB5b3Ugbm90DQp0byBkbyB0aGlzIGRpc2NvdmVyeSB3b3JrLCBi dXQgdG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJlIGF3YXJl IGl0IG1pZ2h0IG5vdCBtYWtlIHNlbnNlLiBPVE9ILA0KYSBtZWNoYW5pc20gdGhhdCB3b3VsZCBh bGxvdzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YW4gYWdlbnQg dG8gZmluZCBpdHMgbWFuYWdlciwgZXNwZWNpYWxseQ0KaW4gYSBOQVQgZW52aXJvbm1lbnQsIGNv dWxkPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iZSB2ZXJ5IHVz ZWZ1bCBmb3IgU05NUC4gU2VlIGFsc28gUkZDNTM0My48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+UFlMOiBSRUxPQUQgTm9kZUlEIGlz bid0DQp1c2VyLWZyaWVuZGx5IHRvbywgd2UgcHJvcG9zZSB0byBkZXJpdmUgdGhlIFNubXBFbmdp bmVJRCBiYXNlZCBvbiBSRUxPQUQNCk5vZGVJRC4gVGhlcmVmb3JlLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5lYWNoIFJFTE9BRCBOb2RlIGlz IGFzc29jaWF0ZWQNCndpdGggYW4gU05NUCBFbmdpbmUuIFdlIGhhdmVuJ3QgZGVmaW5lZCB0aGUg ZGV0YWlsZWQgd2F5cyB0byBjb25zdHJ1Y3QNCnRoZSBTbm1wRW5naW5lSUQgaW4gdGhlIGRyYWZ0 LiBXZSBtYXkgY29uc3RydWN0IHRoZSBTbm1wRW5naW5lSUQgYnkgUkVMT0FEDQpOb2RlSUQgYW5k IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+cHJpdmF0 ZSBlbnRlcnByaXNlDQpudW1iZXIsIGFsc28gbWF5IHVzZSA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+UkVMT0FEDQpOb2RlSUQ8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPiBhcyA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+U25tcEVuZ2luZUlEPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij4uPC9mb250Pjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlByZS1jb25maWd1cmF0aW9uIGlzIGFwcHJvcHJp YXRlDQpmb3IgdGhlIG1hbmFnZXIgZGVwbG95ZWQgc3RhdGljbHksIGFuZCBkaXNjb3ZlcnkgaXMg YXBwcm9wcmlhdGUgZm9yIHRoZQ0KbWFuYWdlciBkZXBsb3llZCBkeW5hbWljYWxseS4gV2UgaW50 ZW5kIHRvIGRlcGxveSBkeW5hbWljYWxseSBtYW5hZ2VyIGluDQpSRUxPQUQgbmV0d29yay4gPC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj41KSBD b25zaWRlciB1c2luZyBQUk9YWS1NSUI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPlNOTVB2MyB1c2VzIGhvcC10by1ob3Agc2VjdXJpdHksIGJ1dA0KdGhlIG1hbmFn ZW1lbnQgaXMgZW5kLXRvLWVuZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlNubXBFbmdlaW5JRCBpcyB1c2VkIGJvdGggZHVyaW5nIGF1dGhlbnRpY2F0aW9uL2F1 dGhvcml6YXRpb24NCmF0IGE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPmhvcC1ieS1ob3AgbGV2ZWwsIGFuZCBpcyBjb250YWluZWQgaW4NCnRoZSBTTk1QIG1lc3Nh Z2UgdG8gaWRlbnRpZnkgdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5zb3VyY2Ugbm9kZSBmb3IgdGhlIGluZm9ybWF0aW9uLiAoc28sDQpmb3IgZXhhbXBsZSwg YSB0cmFwIG1lc3NhZ2UgdG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPm1hbmFnZXIgQSBmcm9tIG5vZGUgQyBpcyBpZGVudGlmaWVkDQphcyBiZWluZyBmcm9tIG5v ZGUgQywgZXZlbiBpZiB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlNOTVAgbWVzc2FnZSBnZXRzIHJlbGF5ZWQgdmlhIG5vZGUgQiwNCmFuZCBTTk1QIG1lc3Nh Z2Ugc2VjdXJpdHkgaXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PmRvbmUgQy10by1CLCBhbmQgdGhlbiBCLXRvLUEuIFRoZSBjb250ZW50cw0Kb2YgdGhlIHZhcmJp bmRzIGFyZSBzdGlsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ aWRlbnRpZmllZCBhcyBiZWluZyBmcm9tIG5vZGUgQy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZXJlIGlzIGEgUFJPWFktTUlCIGluIFJGQzM0MTMo PykgdG8NCnNwZWNpZnkgaG93IHRvIHJlbGF5IFNOTVA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPm1lc3NhZ2VzLiBUaGlzIGFsbG93cyBub2RlIEEgdG8gaGF2ZQ0K YSBzZWN1cml0eSBhc3NvY2lhdGlvbiB3aXRoIEIsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5hbmQgQiB0byBoYXZlIGEgc2VjdXJpdHkgYXNzb2NpYXRpb24NCndp dGggQywgd2l0aG91dCByZXF1aXJpbmcgQSB0bzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+aGF2ZSBhIHNlY3VyaXR5IGFzc29jaWF0aW9uIGRpcmVjdGx5DQp3aXRo IEMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGRvIG5vdCBi ZWxpZXZlIHRoaXMgaXMgaW4gd2lkZS1zcHJlYWQNCnVzZSwgYnV0IGl0IHdhcyBkZXNpZ25lZCBp bnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TTk1QIGV4cGxp Y2l0bHkgdG8gaGVscCBnZXQgdGhyb3VnaA0KaW50ZXJtZWRpYXJpZXMsIHN1Y2ggYXMgZmlyZXdh bGxzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KE5BVHMgYW5k IElDRSB3ZXJlIG5vdCB3aWRlbHkgZGVwbG95ZWQNCmF0IHRoYXQgdGltZSwgYnV0IGl0IGNhbiBh bHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iZSBhcHBsaWVk IHRvIGdldHRpbmcgYXJvdW5kIE5BVHMuKTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+NikgQ29uc2lkZXIgdXNpbmcgTUlEQ09NLU1JQjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhpcyB3YXMgd3JpdHRlbiBhZnRlciBT Tk1QdjMgY29tcGxldGVkLA0KYW5kIGJlZm9yZSBJQ0UuIEl0IHdhczwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ZGVzaWduZWQgdG8gZGVhbCB3aXRoIE5BVHMgYW5k IGZpcmV3YWxscywNCmFuZCBvdGhlciBtaWRkbGUgYm94ZXMuIEk8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJlbGlldmUgaXQgaXMgbm90IHdpZGVseSBkZXBsb3ll ZC4gSQ0KdGhpbmsgdGhlIElFVEYgY29tbXVuaXR5IHByZWZlcnM8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklDRSBmb3IgZ2V0dGluZyBhcm91bmQgTkFUcywgYnV0 IGZvcg0KZG9pbmcgU05NUCBtYW5hZ2VtZW50IHRocm91Z2ggYTwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UkVMT0FELW1hbmFnZWQgbWlkZGxlYm94LCBpdCBtaWdo dCBiZQ0KaGVscGZ1bC4gbWF5YmUgbm90LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj5QWUw6IEFzIG91ciBzb2x1dGlvbiBzZXRzDQp1 cCBhIGRpcmVjdGlvbiBjb25uZWN0aW9uIGJldHdlZW4gU05NUCBhZ2VudHMsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlBST1hZLU1JQiBvciBN SURDT00tTUlCIG1heQ0Kbm90IGJlIHVzZWQgaW4gb3VyIGRyYWZ0LjwvZm9udD4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+NykgVXNlIGV4aXN0aW5nIFNO TVB2My1zdXBwb3J0ZWQgc2VjdXJpdHkNCnByb3RvY29sczwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+VVNNIGlzIHRoZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IHNl Y3VyaXR5DQpmb3IgU05NUHYzLCBiZWNhdXNlIFNOTVB2MzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+bmVlZHMgdG8gd29yayB3aGVuIGEgbmV0d29yayBpcyBub3QN Cndvcmtpbmcgd2VsbCwgYW5kIFVTTSBpczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+c2VsZi1jb250YWluZWQgaW4gU05NUHYzLiBIb3dldmVyLCBmb3INCm5vcm1h bCBtYW5hZ2VtZW50IHRhc2tzLCBhbmQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPm11Y2ggZWFzaWVyIGtleSBkaXN0cmlidXRpb24sIG9wZXJhdG9ycw0KZ3JlYXRs eSBwcmVmZXIgdXNpbmcgdGhlcmlyPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5hbHJlYWR5LXdpZGVseS1kZXBsb3llZCBzZWN1cml0eSBzb2x1dGlvbnMsDQpzdWNo IGFzIFNTSCwgVExTLCBhbmQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkRUTFMuIE9wZXJhdG9ycyBwYXJ0aWN1bGFyeSBkaXNsaWtlZA0KaGF2aW5nIHRvIG1haW50 YWluIGEgd2hvbGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRp ZmZlcmVudCBzZWN1cml0eSBpbmZyYXN0cnVjdHVyZSBqdXN0DQpmb3IgY2FycnlpbmcgU05NUC48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJGQzU1OTAs IDU1OTEsIDU1OTIsIGFuZCA1OTUzIGFkZCBzdXBwb3J0DQpmb3IgdXNpbmcgZXhpc3Rpbmcgc2Vj dXJpdHk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmluZnJhc3Ry dWN0dXJlIGZvciBTTk1QdjMrIG1lc3NhZ2VzLg0KVGhpcyBtaWdodCBiZSBhIGJldHRlciBhcHBy b2FjaDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhhbiBkZXNp Z25pbmcgYSBSRUxPQUQtc3BlY2lmaWMgc29sdXRpb24NCmZvciBjYXJyeWluZyBTTk1QIHNlY3Vy ZWx5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj5QWUw6IFdlIHRoaW5rIHRoZSBUTFMgc2VjdXJpdHkNCm1vZGVsIGlzIGEgZ29vZCBm aXQgZm9yIFJFTE9BRC4gUkVMT0FEIGFsc288L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+dXNlcyBUTFMgZm9yIGNvbm5lY3Rpbmcgbm9kZXMNCmFu ZCBwcm92aWRlcyBjZXJ0aWZpY2F0aW9ucyB0aGF0IGNhbiBiZSByZXVzZWQ8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+YnkgU05NUCBUTFMuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj44KSBCZSBhd2Fy ZSBvZiBhZGRyZXNzIHRyYW5zbGF0aW9uIGlzc3Vlcw0KZm9yIFNOTVA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0IGlzIGltcG9ydGFudCBmb3IgdGhlIGluZm9y bWF0aW9uDQpjb252ZXllZCB1c2luZyBTTk1QIHRvIGJlPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5hY2N1cmF0ZS4gYW5kIHRoYXQgbWVhbnMgaWYgdGhlIG1hbmFn ZWQNCm5vZGUgcHV0cyBpdHMgSVAgYWRkcmVzcyBpbnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5hIE1JQiwgYW5kIHRoYXQgTUlCIGlzIHRyYW5zbGF0ZWQgaW50 bw0KU05NUCB2YXJiaW5kcywgYW5kIHRob3NlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj52YXJiaW5kcyBnbyB0aHJvdWdoIGEgTkFUIChvciBoZXJlIGENClJFTE9B RCBwcm94eSksIHRoYXQgdGhlIElQPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5hZGRyZXNzIGluc2lkZSB0aGUgdmFyYmluZCBpcyBub3QgbW9kaWZpZWQuDQpSRkMg Mjk2MiBkaXNjdXNzZXMgQUxHPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5jb25zaWRlcmF0aW9ucyBmb3IgU05NUC4gSSB0aGluayB5b3VyDQpwcm9wb3NhbCBpcywg dG8gYSBkZWdyZWUsIGFuIEFMRzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Zm9yIFNOTVAgKGJ1dCB5b3VyIHByb3Bvc2FsIGxhY2tzIGVub3VnaA0KZGV0YWlsIGZv ciBtZSB0byBiZSBzdXJlKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlBsZWFzZSBiZSBzdXJlIHRvIHJlYWQgUkZDMjk2Mi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoaXMgZXZlbiBoYXMgYW4gSUVTRyBOb3RlIGF0 dGFjaGVkOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzDQphbiBTTk1QIGFwcGxpY2F0aW9uIGxheWVy IGdhdGV3YXkgKEFMRyksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7d2hpY2ggbWF5IGJlIHVzZWZ1bCBpbg0KY2VydGFpbiBlbnZpcm9ubWVu dHMuICZuYnNwO1RoZSBkb2N1bWVudCBkb2VzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5hbHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7bGlzdCB0aGUgaXNzdWVzIGFuZCBwcm9ibGVtcw0KdGhhdCBjYW4g YXJpc2Ugd2hlbiB1c2VkIGFzIGEgZ2VuZXJpYzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1NOTVAgQUxHLiAmbmJzcDtTcGVjaWZpY2FsbHks DQp3aGVuIHVzaW5nIFNOTVB2MydzIGF1dGhlbnRpY2F0aW9uIGFuZDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3ByaXZhY3kgbWVjaGFuaXNt cyB0aGlzDQphcHByb2FjaCBtYXkgYmUgdmVyeSBwcm9ibGVtYXRpYyBhbmQ8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtqZW9wYXJkaXplIHRo ZSBTTk1QIHNlY3VyaXR5Lg0KJm5ic3A7VGhlIHJlYWRlciBpcyB1cmdlZCB0byBjYXJlZnVsbHk8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtj b25zaWRlciB0aGVzZSBpc3N1ZXMgYmVmb3JlDQpkZWNpZGluZyB0byBkZXBsb3kgdGhpcyB0eXBl IG9mIFNOTVA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDtBTEcuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPlBZTDogV2UgdXNlIHRoZSBSRUxPQUQgbWVjaGFuaXNtcw0KdG8gdHJh dmVyc2UgTkFULiBBcyB3ZSB1c2UgVExTIGZvciBzZWN1cml0eSwgdGhlPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlNOTVAgQUxHIHByb2JsZW0g bWF5IG5vdA0KYXJpc2UgaW4gb3VyIHNvbHV0aW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+OSkgVXNpbmcgU05NUCB0byBkbyBjb25maWd1cmF0aW9u IGNhbg0KYmUgcHJvYmxlbWF0aWM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkJlY2F1c2UgU05NUHYxIHdhcyBub3Qgc2VjdXJlLCBhbmQgQ0xJDQpjYW4gYmUgdXNl ZCB0byBkbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Y29uZmln dXJhdGlvbiwgbWFueSBTTk1QIGFnZW50cyBkbyBub3QNCnJlYWxseSBzdXBwb3J0IFNFVHMuIGlm IHRoZXkgZG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnN1cHBv cnQgU0VUcywgdGhvc2UgU0VUcyBvZnRlbiBuZXZlcg0KZ2V0IHNhdmVkIHRvIE5WUkFNLiBTbzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cmVjb21tZW5kaW5nIFNO TVAgdG8gY29uZmlndXJlIG5vZGVzDQpjb3VsZCBiZSBhIHByb2JsZW0gaW4gbWFueTwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aW1wbGVtZW50YXRpb25zLiBJJ20g bm90IHRlbGxpbmcgeW91DQpub3QgdG8gZG8gdGhpcywgYnV0IGJlIGF3YXJlIG9mPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGUgcHJvYmxlbXMgKG1heWJlIHdy aXRlIHRoaXMgaW50bw0KYW4gJnF1b3Q7T3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q29uc2lkZXJhdGlvbnMmcXVvdDsg c2VjdGlvbikuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPlBZTDogUkVMT0FEIGhhcyBwcm92aWRlZA0Kc29tZSBtZWNoYW5pc21zIGZv ciBiYXNpYyBjb25maWd1cmF0aW9uLiBXZSB3aWxsIHRyeTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj50byBmaWd1cmUgb3V0IHdoaWNoIHdheSBp cw0KYmV0dGVyIGZvciBzZXR0aW5nIHRoZSBSRUxPQUQgbm9kZXMuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0K08ogvP6junBlbmcueW9uZ2xpbkB6 dGUuY29tLmNuPGJyPg0KxNogz9+jujgxNTQzPGJyPg0KzeIgz9+jujAyNS01Mjg3MTU0Mzxicj4N CsrWILv6o7oxMzc3NjYzNzI3NDxicj4NCrSrINXmo7owMjUtNTI4NzIxODc8YnI+DQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9mb250Pg0KPGJyPjxw cmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJz cDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZu YnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGll bnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3Rv Jm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5i c3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRz Jm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJz Lg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFu c21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNw O2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJz cDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lm Jm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5i c3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29y aWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmll d3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJl Jm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIu DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7 Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNw O0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000D1EBE48257934_=-- From ietfc@btconnect.com Tue Oct 25 08:20:53 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DEC21F83EF; Tue, 25 Oct 2011 08:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSrnxI5TJIaw; Tue, 25 Oct 2011 08:20:52 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2E64021F8BBF; Tue, 25 Oct 2011 08:20:51 -0700 (PDT) Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2bthomr09.btconnect.com with SMTP id EYR01884; Tue, 25 Oct 2011 16:20:46 +0100 (BST) Message-ID: <048b01cc9320$97727900$4001a8c0@gateway.2wire.net> From: "t.petch" To: , , References: Date: Tue, 25 Oct 2011 16:15:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4EA6D3CE.0008, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.10.25.143623:17:9.535, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CHAR_CHINESE_CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, CN_TLD, __CP_URI_IN_BODY, __LINES_OF_YELLING, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, LOCALE_CHINESE, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4EA6D3D2.0191,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: hao.zhenwu@zte.com.cn Subject: Re: [OPSAWG] An SNMP Usage for RELOAD X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 15:20:53 -0000 ----- Original Message ----- From: ; To: ; ; ; Cc: ; Sent: Tuesday, October 25, 2011 4:23 AM > We have done more research on security and other issues based on David's > comments, and updated our draft. > > This is the new version of draft: > http://www.ietf.org/id/draft-peng-p2psip-snmp-03.txt > > We welcome any comments! Thanks! > > Our analysis of David's comments as follows(blue text): > > 1) Use SNMPv3 terminology > Apparently, you come from the RELOAD side of things, not the SNMP > side. > Your text doesn't use the common SNMP terminology for various > SNMP-related things. > You will have a better chance of success if you describe SNMP-related > things using the normal SNMPv3 terminology. > This isn't critical; your ideas seem reasonable, but since you don't > use the standard terminology, you might mean slightly different things > than what it would mean if you used the standard terminology. > > (I don't have a RELOAD background, so some of my comments might seem > wrong because I don't know the RELOAD concepts and terminology. Now > you'll understand my point ;-) > > PYL: We have updated the draft using SNMP terminology. As we are not SNMP > experts, some terminology may not be accurate. We will try to improve this > over time. You are indeed using SNMP terminology, but I struggle to see how its usage is the same as in RFC3411. RELOAD defines a messaging network, on top of which run applications, which RELOAD calls Usages, so when you define an SNMP Usage, you would appear to be discarding most of an Architecture for SNMP as defined in RFC3411, perhaps providing instead a gateway for functionality such as that specified in RFC3414; or perhaps not, I do not find the I-D clear on this. Thus you have Application +-------+ +-------+ +-------+ | SIP | | XMPP | | SNMP | ... | Usage | | Usage | | Usage | +-------+ +-------+ +-------+ ------------------------------------------- Messaging API RELOAD but elsewhere you say ' SNMP entities talk to each other using SNMP protocol on dedicated connections' which is rather different. The I-D reads more like a wish list of requirements, than an overview, architecture or framework. Or perhaps it is all beyond me:-( Tom Petch From peng.yonglin@zte.com.cn Tue Oct 25 20:03:29 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E1E21F8BDE; Tue, 25 Oct 2011 20:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.801 X-Spam-Level: X-Spam-Status: No, score=-91.801 tagged_above=-999 required=5 tests=[AWL=-3.375, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, DC_GIF_UNO_LARGO=2.275, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu9uG4SGVqtw; Tue, 25 Oct 2011 20:03:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 92F8621F8BD5; Tue, 25 Oct 2011 20:03:21 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466213465113155; Wed, 26 Oct 2011 10:55:33 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 75161.4569552579; Wed, 26 Oct 2011 11:02:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9Q32xt0059465; Wed, 26 Oct 2011 11:02:59 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: <048b01cc9320$97727900$4001a8c0@gateway.2wire.net> To: "t.petch" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Wed, 26 Oct 2011 11:02:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-26 11:03:00, Serialize complete at 2011-10-26 11:03:00 Content-Type: multipart/related; boundary="=_related 0010B7F748257935_=" X-MAIL: mse02.zte.com.cn p9Q32xt0059465 Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: [OPSAWG] =?gb2312?b?tPC4tDogUmU6ICBBbiBTTk1QIFVzYWdlIGZvciBSRUxP?= =?gb2312?b?QUQ=?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 03:03:29 -0000 This is a multipart message in MIME format. --=_related 0010B7F748257935_= Content-Type: multipart/alternative; boundary="=_alternative 0010B7F948257935_=" --=_alternative 0010B7F948257935_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SW4gc2hvcnQsIHRoZSByZWxhdGlvbiBiZXR3ZWVuIFNOTVAgVXNhZ2UgYW5kIFJFTE9BRCBhcyBm b2xsb3dzOg0KU05NUCBVc2FnZSBnZXQgYSBhdmFpbGFibGUgSVAgYWRkcmVzcywgd2hpY2ggaXMg dXNlZCBmb3IgU05NUCANCmNvbW11bmljYXRpb24sIGZvciBzbm1lRW5naW5lSUQgb3IgTm9kZUlE IG9yIFJlc291cmNlSUQgb3IgTWFuYWdlciBuYW1lIGJ5IA0KUkVMT0FEIG1lY2hhbmlzbSwgc3Vj aCBhcyBBcHBBdHRhY2gsIFN0b3JlLCBGZXRjaC4NClRoZW4gU05NUCBVc2FnZSB1c2VzIHRoaXMg SVAgYWRkcmVzcyBmb3IgU05NUCBjb21tdW5pY2F0aW9uIGJldHdlZW4gU05NUCANCmVudGl0aWVz IGJ5IHRoZSBTTk1QIG1lY2hhbmlzbSBhbmQgYXJjaGl0ZWN0dXJlIHdoaWNoIGRlZmluZWQgaW4g UkZDMzQxMSANCmFuZCBSRkM1OTUzIGFuZCBvdGhlciBTTk1QIFJGQ3MgKGFzIGRlcGljdGVkIGlu IHRoZSBkaWFncmFtIGJlbG93KS4gQW5kIA0Kbm93IHRoZXJlIGlzIGxpdHRsZSByZWxhdGlvbiBi ZXR3ZWVuIFNOTVAgVXNhZ2UgYW5kIFJFTE9BRCBiZXNpZGVzIHVzaW5nIA0KUkVMT0FEIGNlcnRp ZmljYXRlLiBTbyB3ZSBzYXkgIlNOTVAgZW50aXRpZXMgdGFsayB0byBlYWNoIG90aGVyIHVzaW5n IFNOTVAgDQpwcm90b2NvbCBvbiBkZWRpY2F0ZWQgY29ubmVjdGlvbnMiDQoNCg0KSWYgeW91IHRp bGwgaGF2ZSBxdWVzdGlvbnMsIHBsZWFzZSB0ZWxsIHVzLiBUaGFua3MhDQoNCg0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K08ogvP6junBlbmcueW9u Z2xpbkB6dGUuY29tLmNuDQrE2iDP36O6ODE1NDMNCs3iIM/fo7owMjUtNTI4NzE1NDMNCsrWILv6 o7oxMzc3NjYzNzI3NA0KtKsg1eajujAyNS01Mjg3MjE4Nw0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNCg0KInQucGV0Y2giIDxpZXRmY0BidGNv bm5lY3QuY29tPiANCjIwMTEtMTAtMjUgMjI6MTUNCg0KytW8/sjLDQo8cDJwc2lwQGlldGYub3Jn PiwgPG9wc2F3Z0BpZXRmLm9yZz4sIDxwZW5nLnlvbmdsaW5AenRlLmNvbS5jbj4NCrOty80NCjxo YW8uemhlbnd1QHp0ZS5jb20uY24+DQrW98ziDQpSZTogW09QU0FXR10gQW4gU05NUCBVc2FnZSBm b3IgUkVMT0FEDQoNCg0KDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9t OiA8cGVuZy55b25nbGluQHp0ZS5jb20uY24+OyA8cGVuZy55b25nbGluQHp0ZS5jb20uY24+DQpU bzogPHAycHNpcEBpZXRmLm9yZz47IDxvcHNhd2dAaWV0Zi5vcmc+OyA8cDJwc2lwQGlldGYub3Jn PjsgDQo8b3BzYXdnQGlldGYub3JnPg0KQ2M6IDxoYW8uemhlbnd1QHp0ZS5jb20uY24+OyA8aGFv LnpoZW53dUB6dGUuY29tLmNuPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyNSwgMjAxMSA0OjIz IEFNDQoNCj4gV2UgaGF2ZSBkb25lIG1vcmUgcmVzZWFyY2ggb24gc2VjdXJpdHkgYW5kIG90aGVy IGlzc3VlcyBiYXNlZCBvbiBEYXZpZCdzDQo+IGNvbW1lbnRzLCBhbmQgdXBkYXRlZCBvdXIgZHJh ZnQuDQo+DQo+IFRoaXMgaXMgdGhlIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0Og0KPiBodHRwOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LXBlbmctcDJwc2lwLXNubXAtMDMudHh0DQo+DQo+IFdlIHdlbGNv bWUgYW55IGNvbW1lbnRzISBUaGFua3MhDQo+DQo+IE91ciBhbmFseXNpcyBvZiBEYXZpZCdzIGNv bW1lbnRzIGFzIGZvbGxvd3MoYmx1ZSB0ZXh0KToNCj4NCj4gMSkgVXNlIFNOTVB2MyB0ZXJtaW5v bG9neQ0KPiBBcHBhcmVudGx5LCB5b3UgY29tZSBmcm9tIHRoZSBSRUxPQUQgc2lkZSBvZiB0aGlu Z3MsIG5vdCB0aGUgU05NUA0KPiBzaWRlLg0KPiBZb3VyIHRleHQgZG9lc24ndCB1c2UgdGhlIGNv bW1vbiBTTk1QIHRlcm1pbm9sb2d5IGZvciB2YXJpb3VzDQo+IFNOTVAtcmVsYXRlZCB0aGluZ3Mu DQo+IFlvdSB3aWxsIGhhdmUgYSBiZXR0ZXIgY2hhbmNlIG9mIHN1Y2Nlc3MgaWYgeW91IGRlc2Ny aWJlIFNOTVAtcmVsYXRlZA0KPiB0aGluZ3MgdXNpbmcgdGhlIG5vcm1hbCBTTk1QdjMgdGVybWlu b2xvZ3kuDQo+IFRoaXMgaXNuJ3QgY3JpdGljYWw7IHlvdXIgaWRlYXMgc2VlbSByZWFzb25hYmxl LCBidXQgc2luY2UgeW91IGRvbid0DQo+IHVzZSB0aGUgc3RhbmRhcmQgdGVybWlub2xvZ3ksIHlv dSBtaWdodCBtZWFuIHNsaWdodGx5IGRpZmZlcmVudCB0aGluZ3MNCj4gdGhhbiB3aGF0IGl0IHdv dWxkIG1lYW4gaWYgeW91IHVzZWQgdGhlIHN0YW5kYXJkIHRlcm1pbm9sb2d5Lg0KPg0KPiAoSSBk b24ndCBoYXZlIGEgUkVMT0FEIGJhY2tncm91bmQsIHNvIHNvbWUgb2YgbXkgY29tbWVudHMgbWln aHQgc2VlbQ0KPiB3cm9uZyBiZWNhdXNlIEkgZG9uJ3Qga25vdyB0aGUgUkVMT0FEIGNvbmNlcHRz IGFuZCB0ZXJtaW5vbG9neS4gTm93DQo+IHlvdSdsbCB1bmRlcnN0YW5kIG15IHBvaW50IDstKQ0K Pg0KPiBQWUw6IFdlIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdXNpbmcgU05NUCB0ZXJtaW5vbG9n eS4gQXMgd2UgYXJlIG5vdCANClNOTVANCj4gZXhwZXJ0cywgc29tZSB0ZXJtaW5vbG9neSBtYXkg bm90IGJlIGFjY3VyYXRlLiBXZSB3aWxsIHRyeSB0byBpbXByb3ZlIA0KdGhpcw0KPiBvdmVyIHRp bWUuDQoNCllvdSBhcmUgaW5kZWVkIHVzaW5nIFNOTVAgdGVybWlub2xvZ3ksIGJ1dCBJIHN0cnVn Z2xlIHRvIHNlZSBob3cgaXRzIHVzYWdlIA0KaXMNCnRoZSBzYW1lIGFzIGluIFJGQzM0MTEuDQoN ClJFTE9BRCBkZWZpbmVzIGEgbWVzc2FnaW5nIG5ldHdvcmssIG9uIHRvcCBvZiB3aGljaCBydW4g YXBwbGljYXRpb25zLCANCndoaWNoDQpSRUxPQUQgY2FsbHMgVXNhZ2VzLCBzbyB3aGVuIHlvdSBk ZWZpbmUgYW4gU05NUCBVc2FnZSwgeW91IHdvdWxkIGFwcGVhciB0byANCmJlDQpkaXNjYXJkaW5n IG1vc3Qgb2YgYW4gQXJjaGl0ZWN0dXJlIGZvciBTTk1QIGFzIGRlZmluZWQgaW4gUkZDMzQxMSwg cGVyaGFwcw0KcHJvdmlkaW5nIGluc3RlYWQgYSBnYXRld2F5IGZvciBmdW5jdGlvbmFsaXR5IHN1 Y2ggYXMgdGhhdCBzcGVjaWZpZWQgaW4gDQpSRkMzNDE0Ow0Kb3IgcGVyaGFwcyBub3QsIEkgZG8g bm90IGZpbmQgdGhlIEktRCBjbGVhciBvbiB0aGlzLiAgVGh1cyB5b3UgaGF2ZQ0KDQogICAgICAg ICAgICAgICAgICBBcHBsaWNhdGlvbg0KDQogICAgICAgICAgICArLS0tLS0tLSsgICstLS0tLS0t KyAgKy0tLS0tLS0rDQogICAgICAgICAgICB8IFNJUCAgIHwgIHwgWE1QUCAgfCAgfCBTTk1QICB8 ICAuLi4NCiAgICAgICAgICAgIHwgVXNhZ2UgfCAgfCBVc2FnZSB8ICB8IFVzYWdlIHwNCiAgICAg ICAgICAgICstLS0tLS0tKyAgKy0tLS0tLS0rICArLS0tLS0tLSsNCiAgICAgICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gTWVzc2FnaW5nIEFQSQ0KDQogICAg ICAgICAgICAgICAgICAgICAgUkVMT0FEDQoNCmJ1dCBlbHNld2hlcmUgeW91IHNheQ0KJyBTTk1Q IGVudGl0aWVzIHRhbGsgdG8gZWFjaCBvdGhlciB1c2luZyBTTk1QIHByb3RvY29sIG9uIGRlZGlj YXRlZCANCmNvbm5lY3Rpb25zJw0Kd2hpY2ggaXMgcmF0aGVyIGRpZmZlcmVudC4NCg0KVGhlIEkt RCByZWFkcyBtb3JlIGxpa2UgYSB3aXNoIGxpc3Qgb2YgcmVxdWlyZW1lbnRzLCB0aGFuIGFuIG92 ZXJ2aWV3LA0KYXJjaGl0ZWN0dXJlIG9yIGZyYW1ld29yay4gIE9yIHBlcmhhcHMgaXQgaXMgYWxs IGJleW9uZCBtZTotKA0KDQpUb20gUGV0Y2gNCg0KPHNuaXA+DQoNCg0KDQoNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24u IFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1l ZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVy bWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g b3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJl IGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNj YW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0010B7F948257935_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIHNob3J0LCB0aGUgcmVsYXRp b24gYmV0d2VlbiBTTk1QDQpVc2FnZSBhbmQgUkVMT0FEIGFzIGZvbGxvd3M6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TTk1QIFVzYWdlIGdldCBhIGF2YWlsYWJs ZSBJUCBhZGRyZXNzLA0Kd2hpY2ggaXMgdXNlZCBmb3IgU05NUCBjb21tdW5pY2F0aW9uLCBmb3Ig PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+c25tZUVuZ2luZUlEPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCm9yIE5vZGVJRCBvciBSZXNvdXJjZUlE IG9yIE1hbmFnZXIgbmFtZSBieSBSRUxPQUQgbWVjaGFuaXNtLCBzdWNoIGFzIEFwcEF0dGFjaCwN ClN0b3JlLCBGZXRjaC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlRoZW4gU05NUCBVc2FnZSB1c2VzIHRoaXMgSVAgYWRkcmVzcw0KZm9yIFNOTVAgY29tbXVuaWNh dGlvbiBiZXR3ZWVuIFNOTVAgZW50aXRpZXMgYnkgdGhlIFNOTVAgbWVjaGFuaXNtIGFuZA0KYXJj aGl0ZWN0dXJlIHdoaWNoPC9mb250Pjxmb250IHNpemU9Mj48dHQ+IGRlZmluZWQgaW4gUkZDMzQx MTwvdHQ+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCmFuZCA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yPjx0dD5SRkM8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+NTk1Mw0KYW5kIG90aGVyIFNOTVAgUkZDcyAoYXMgZGVwaWN0ZWQgaW4gdGhlIGRpYWdy YW0gYmVsb3cpLiBBbmQgbm93IHRoZXJlIGlzDQpsaXR0bGUgcmVsYXRpb24gYmV0d2VlbiBTTk1Q IFVzYWdlIGFuZCBSRUxPQUQgYmVzaWRlcyB1c2luZyBSRUxPQUQgY2VydGlmaWNhdGUuDQpTbyB3 ZSA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5zYXkgJnF1b3Q7U05NUCBlbnRpdGllcyB0YWxrIHRv IGVhY2ggb3RoZXINCnVzaW5nIFNOTVAgcHJvdG9jb2wgb24gZGVkaWNhdGVkIGNvbm5lY3Rpb25z JnF1b3Q7PC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGltZyBzcmM9Y2lkOl8xXzA3N0Q0MTQwMDc3 RDJCQzgwMDEwQjdGNzQ4MjU3OTM1Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5JZiB5b3UgdGlsbCBoYXZlIHF1ZXN0aW9ucywgcGxlYXNlIHRlbGwNCnVzLiBUaGFua3MhPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0K08ogvP6j unBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPGJyPg0KxNogz9+jujgxNTQzPGJyPg0KzeIgz9+jujAy NS01Mjg3MTU0Mzxicj4NCsrWILv6o7oxMzc3NjYzNzI3NDxicj4NCrSrINXmo7owMjUtNTI4NzIx ODc8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZx dW90O3QucGV0Y2gmcXVvdDsgJmx0O2lldGZjQGJ0Y29ubmVjdC5jb20mZ3Q7PC9iPg0KPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMTAtMjUgMjI6MTU8L2Zv bnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0 O3AycHNpcEBpZXRmLm9yZyZndDssICZsdDtvcHNhd2dAaWV0Zi5vcmcmZ3Q7LA0KJmx0O3Blbmcu eW9uZ2xpbkB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2hhby56aGVud3VA enRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbT1BTQVdHXSBBbiBTTk1QIFVz YWdlIGZvciBSRUxPQUQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTI+PHR0Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+DQpGcm9tOiAm bHQ7cGVuZy55b25nbGluQHp0ZS5jb20uY24mZ3Q7OyAmbHQ7cGVuZy55b25nbGluQHp0ZS5jb20u Y24mZ3Q7PGJyPg0KVG86ICZsdDtwMnBzaXBAaWV0Zi5vcmcmZ3Q7OyAmbHQ7b3BzYXdnQGlldGYu b3JnJmd0OzsgJmx0O3AycHNpcEBpZXRmLm9yZyZndDs7DQombHQ7b3BzYXdnQGlldGYub3JnJmd0 Ozxicj4NCkNjOiAmbHQ7aGFvLnpoZW53dUB6dGUuY29tLmNuJmd0OzsgJmx0O2hhby56aGVud3VA enRlLmNvbS5jbiZndDs8YnI+DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI1LCAyMDExIDQ6MjMg QU08YnI+DQo8YnI+DQomZ3Q7IFdlIGhhdmUgZG9uZSBtb3JlIHJlc2VhcmNoIG9uIHNlY3VyaXR5 IGFuZCBvdGhlciBpc3N1ZXMgYmFzZWQgb24gRGF2aWQnczxicj4NCiZndDsgY29tbWVudHMsIGFu ZCB1cGRhdGVkIG91ciBkcmFmdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGlzIHRoZSBuZXcg dmVyc2lvbiBvZiBkcmFmdDo8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt cGVuZy1wMnBzaXAtc25tcC0wMy50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZSB3ZWxjb21lIGFu eSBjb21tZW50cyEgVGhhbmtzITxicj4NCiZndDs8YnI+DQomZ3Q7IE91ciBhbmFseXNpcyBvZiBE YXZpZCdzIGNvbW1lbnRzIGFzIGZvbGxvd3MoYmx1ZSB0ZXh0KTo8YnI+DQomZ3Q7PGJyPg0KJmd0 OyAxKSBVc2UgU05NUHYzIHRlcm1pbm9sb2d5PGJyPg0KJmd0OyBBcHBhcmVudGx5LCB5b3UgY29t ZSBmcm9tIHRoZSBSRUxPQUQgc2lkZSBvZiB0aGluZ3MsIG5vdCB0aGUgU05NUDxicj4NCiZndDsg c2lkZS48YnI+DQomZ3Q7IFlvdXIgdGV4dCBkb2Vzbid0IHVzZSB0aGUgY29tbW9uIFNOTVAgdGVy bWlub2xvZ3kgZm9yIHZhcmlvdXM8YnI+DQomZ3Q7IFNOTVAtcmVsYXRlZCB0aGluZ3MuPGJyPg0K Jmd0OyBZb3Ugd2lsbCBoYXZlIGEgYmV0dGVyIGNoYW5jZSBvZiBzdWNjZXNzIGlmIHlvdSBkZXNj cmliZSBTTk1QLXJlbGF0ZWQ8YnI+DQomZ3Q7IHRoaW5ncyB1c2luZyB0aGUgbm9ybWFsIFNOTVB2 MyB0ZXJtaW5vbG9neS48YnI+DQomZ3Q7IFRoaXMgaXNuJ3QgY3JpdGljYWw7IHlvdXIgaWRlYXMg c2VlbSByZWFzb25hYmxlLCBidXQgc2luY2UgeW91IGRvbid0PGJyPg0KJmd0OyB1c2UgdGhlIHN0 YW5kYXJkIHRlcm1pbm9sb2d5LCB5b3UgbWlnaHQgbWVhbiBzbGlnaHRseSBkaWZmZXJlbnQgdGhp bmdzPGJyPg0KJmd0OyB0aGFuIHdoYXQgaXQgd291bGQgbWVhbiBpZiB5b3UgdXNlZCB0aGUgc3Rh bmRhcmQgdGVybWlub2xvZ3kuPGJyPg0KJmd0Ozxicj4NCiZndDsgKEkgZG9uJ3QgaGF2ZSBhIFJF TE9BRCBiYWNrZ3JvdW5kLCBzbyBzb21lIG9mIG15IGNvbW1lbnRzIG1pZ2h0IHNlZW08YnI+DQom Z3Q7IHdyb25nIGJlY2F1c2UgSSBkb24ndCBrbm93IHRoZSBSRUxPQUQgY29uY2VwdHMgYW5kIHRl cm1pbm9sb2d5LiBOb3c8YnI+DQomZ3Q7IHlvdSdsbCB1bmRlcnN0YW5kIG15IHBvaW50IDstKTxi cj4NCiZndDs8YnI+DQomZ3Q7IFBZTDogV2UgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB1c2luZyBT Tk1QIHRlcm1pbm9sb2d5LiBBcyB3ZSBhcmUgbm90DQpTTk1QPGJyPg0KJmd0OyBleHBlcnRzLCBz b21lIHRlcm1pbm9sb2d5IG1heSBub3QgYmUgYWNjdXJhdGUuIFdlIHdpbGwgdHJ5IHRvIGltcHJv dmUNCnRoaXM8YnI+DQomZ3Q7IG92ZXIgdGltZS48YnI+DQo8YnI+DQpZb3UgYXJlIGluZGVlZCB1 c2luZyBTTk1QIHRlcm1pbm9sb2d5LCBidXQgSSBzdHJ1Z2dsZSB0byBzZWUgaG93IGl0cyB1c2Fn ZQ0KaXM8YnI+DQp0aGUgc2FtZSBhcyBpbiBSRkMzNDExLjxicj4NCjxicj4NClJFTE9BRCBkZWZp bmVzIGEgbWVzc2FnaW5nIG5ldHdvcmssIG9uIHRvcCBvZiB3aGljaCBydW4gYXBwbGljYXRpb25z LCB3aGljaDxicj4NClJFTE9BRCBjYWxscyBVc2FnZXMsIHNvIHdoZW4geW91IGRlZmluZSBhbiBT Tk1QIFVzYWdlLCB5b3Ugd291bGQgYXBwZWFyDQp0byBiZTxicj4NCmRpc2NhcmRpbmcgbW9zdCBv ZiBhbiBBcmNoaXRlY3R1cmUgZm9yIFNOTVAgYXMgZGVmaW5lZCBpbiBSRkMzNDExLCBwZXJoYXBz PGJyPg0KcHJvdmlkaW5nIGluc3RlYWQgYSBnYXRld2F5IGZvciBmdW5jdGlvbmFsaXR5IHN1Y2gg YXMgdGhhdCBzcGVjaWZpZWQgaW4NClJGQzM0MTQ7PGJyPg0Kb3IgcGVyaGFwcyBub3QsIEkgZG8g bm90IGZpbmQgdGhlIEktRCBjbGVhciBvbiB0aGlzLiAmbmJzcDtUaHVzIHlvdSBoYXZlPGJyPg0K PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7QXBwbGljYXRpb248YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLS0tLSsgJm5ic3A7Ky0tLS0tLS0rICZuYnNwOystLS0t LS0tKzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgU0lQ ICZuYnNwOyB8ICZuYnNwO3wgWE1QUCAmbmJzcDt8DQombmJzcDt8IFNOTVAgJm5ic3A7fCAmbmJz cDsuLi48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IFVz YWdlIHwgJm5ic3A7fCBVc2FnZSB8ICZuYnNwO3wNClVzYWdlIHw8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLS0tLSsgJm5ic3A7Ky0tLS0tLS0rICZu YnNwOystLS0tLS0tKzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTWVzc2FnaW5nIEFQSTxicj4NCjxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO1JFTE9BRDxicj4NCjxicj4NCmJ1dCBlbHNld2hlcmUg eW91IHNheTxicj4NCicgU05NUCBlbnRpdGllcyB0YWxrIHRvIGVhY2ggb3RoZXIgdXNpbmcgU05N UCBwcm90b2NvbCBvbiBkZWRpY2F0ZWQgY29ubmVjdGlvbnMnPGJyPg0Kd2hpY2ggaXMgcmF0aGVy IGRpZmZlcmVudC48YnI+DQo8YnI+DQpUaGUgSS1EIHJlYWRzIG1vcmUgbGlrZSBhIHdpc2ggbGlz dCBvZiByZXF1aXJlbWVudHMsIHRoYW4gYW4gb3ZlcnZpZXcsPGJyPg0KYXJjaGl0ZWN0dXJlIG9y IGZyYW1ld29yay4gJm5ic3A7T3IgcGVyaGFwcyBpdCBpcyBhbGwgYmV5b25kIG1lOi0oPGJyPg0K PGJyPg0KVG9tIFBldGNoPGJyPg0KPGJyPg0KJmx0O3NuaXAmZ3Q7PGJyPg0KPGJyPg0KPGJyPg0K PC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNw O1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29u dGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5i c3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0 aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7 Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7 YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJz cDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Ns b3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJz cDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7 YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkm bmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDth cmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2 ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5i c3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5i c3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7 U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0010B7F948257935_=-- --=_related 0010B7F748257935_= Content-Type: image/gif Content-ID: <_1_077D4140077D2BC80010B7F748257935> Content-Transfer-Encoding: base64 R0lGODlhxAH2AecAAP///8jg0AAAAPgAADAYKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAxAH2AUAI/wADCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaNDACAPCigooKTJkQJPmhyosiTLli9Vxjw5c2VK mDdl5qS502aAlih/4hSqkyhPoz6B1nTZkylSp0qbBo36dOpQqlivai2alevWo13Bfk06FmrZoATR HgQJwKPbt3Djyp1Lt67du3gvshUJ0WpatCidCk1LmKFatXkTK17MuLHjuYgL7jUYOeFIn0RfZo7Z MyLmoTsHcz589LHp06hTqya5cPLq17Bjy55NG6/rwrVz697Nu/fdygNvLxzguzhG4saTK4ctPOVB 5JaXvwauELr0t9SvK86OMHvzn8+1i/9HaH28+fMSvYd0WB799fbu48uH+D0yfNx1ATsHz58p4NKp cRfefBdlp19/+/n3F1lFIcUafw9GWNiB+7HU10TqtcUege9x6OGHa60n4UD3WZgfXQKeuBBiJRIo YIoZwWiRjHLRWCFC9Q0YHUkrQbWZhZhVtdR/n/VImmBUGbVgTk11Z5hBLc73ImVGAikYeEGGVeSW lx1JZGlg+nflihi2JiJDUYI4W5pqtqldjlCS6WaNE7E55413emQjhDieOVyeu9kJ6KC1wVlQlHsS KmdEgs6ZqKI7emamhiMK1Cikil2K6aYoTvqQppzaBWqopNrmJ56WlqraqKq2OqOnG7r/ahqrsta6 kaEE0WrXo+PpaitcvPaW4ae0Baudr7+6Zax435GXLGPIPittQ83qGNuy0kU7bYyQVhvntnhpC+64 wZ2akLjAEoouuel1a66zs2G73LrsXqiot4fWSxe9+iaLb66yBTYov/3uKO9y/5JYcFwEL+xqwqkq dLCaEzd83cSKYhwAxAFY3K/HDpPKMcj1khyydgRoNPKiKibosmhfamzvRiYbJ/OCVwpMGV8780kh qnoSlHJGK5/cUc1GKzc0RkVHWmCl51XcaqL//cUzbiki2a5Dj2rctJMYARWYmET6jJNNXN6MX0ZI +0Y1Z3AbOGZ3ZuFMZZc4H1aR1+9a/5v0cX8HLtDXV/c8IaqRVfazxJUm3hBi1Emtqtp38k0pmoKz nfnfhBv+rOSlUu6oW51vzqjpRrOl+uqsD8D667DHLvvstNdu++2456776q7v7vvvwAcv/PDEF2/8 8cgnr/zyzDfv/PPQRy/99NRXr3rvAGA/wPbYW+/99+CHL/745Jdfe/fmp6/++uy37/776L8v//z0 12///a/Hj//+/Pfv///J2x4AB0jAAhrwgCDRHwIXyMAGOrB6CnygBCdIwQpa8IIYzKAGYYe+DiaQ LREEIe8+eD0SijB/I8xeCj3YuhOqcHbdi6EJScjCGq7whjN04QtzmMPesVCHQPRhCv93qD0cnvCH JezhBiUYwiU68YlQ9J3+hBi7Kc7Qg/FzXRZ3iDwrtpCLXxyiF104RjAWr4liNJ4XtbjCKVJxiEk0 IgrDGEXbbZGHcCRiEekYxzz2UYBg3GP2ymjCJiJRkESMo/YQ+cc3FhKEChQkIyUJRD4ycpBXTCIa K3nJPCJyk3UMpShHSUrocY+GcjRjAk/5SFRacpXcA6QnISnLWLISiWT0YyCVqMog8jKScpThIG35 y1Ia85jITKYyl8nMZs6vcKiLpjSBRhCOTfOa2Bxc37LJTW7iSlIm0tnYbtQgxmENQFeJkNi6yc4y KcSa7Yxn6swlOnna00PD8tw99/n/OVg1pG3bAig/lfPNiDlNSFIZkkITylCEOlRLZvFKOan5p8nx SKJiwSiDMsrRjXo0oh0FaZAoas6ElO6eAh2ocQraMZZhRzMwTVDVTERSxuwppbqBXExFI1Or0ZRP TvMRfoAzFSp5jkZ7yifUEAWZH/3IJVvqDGxuOrWdRfUmTkUbgCyDpC6dLUlP7apXR/qkrZl0m/lS qUHV2iqWMvWin1Fn4w4auXIaaK7kzBvYdoqzAYj0r1bRKGAX+tCzcFWfT1lbUdcGVMVKzK4u1Wle Z0bZEF2uomrFKVt341aX1ouqFl1YUv3J2JaWtF+gDZ3DRvtOtAKMrZrdbG46e9rC/wo2sCHF7Ud1 O9iGQtRxEoltseC6W8L+1riG9W1yHVrasp71stXZrHBlOxvaXquxbZrutC6DT9L+VGGwpW6elIq5 8IpXZPTkkV+Lq9zbElaxyz1ue3OLXIyut770nS97bZtf/u5Xvv6dm5f+G98CuxexknEteDN7XvRC 91zDHViDv5unkwZIXROuKYgsLE/tZhg1HD5NPWvjYWmNeLYKXutAS/zhx4S4nSxucWNe7Ji5ZTfD NnYTjbsZYxkvJsQD7m2AeUtk/BL4wFCzSI8vnDchA/jJBu4vgJurlxSblsE+HhSQm4rVnY7Ty1Tu FEeWjBrRzRSoi8OaUSVUT7Qsrf/KD4bXQZWV1bpddaJ5AR2pKFekqowNNGEtG6DTNZA3W2TH3CRz lu+yZW41lkJ6QyykwUrnMVfVrD1FM4LHGlcEPRpPRI40pm9lZUVjytSLpkuj9/o0aHJNzRVarOFy 5tmLoLrGqyVdqWtNYVkzV0lMcirdtnrboo70rpYObcEsRyzzpnpOq9avk6N8ZCkvN8x1urSRp41k KHeb2gLWNe5A6czlkbvc6E63utfN7vmdu93wjjf+cCnvetubgO++t773nb588/vfAIdgwAdO8PL5 u+AITzjxDq7whjv8dgx/uMQdTm+BBxCG4Is4/9CocQ5O/He4dGQffbnLkr+y5BX/76QqhenKI6ZS 5DDH4wtZvvKX69KGisylJm0exop//OdADzotYznyosuOknPkIwcBifNKDpPoTpd5FckITKW3juk8 n2Uid87189VS52+koi1leXViRr2XZxe62teOTKir0O2w7CXUib5HK7LyemTX+tN5l/dh1vyDcC/7 yIV4d76zkZaCJ7kWmZ73wi+e8X1n+/rozsu4R/Lup6w7Cgsf9ypmfuiGF/wYfe53vAtQ5Pk7vekT D3pH0tzxbUS95GdP+9rb/vZRfLbuK5ze3fs+OeSl8O+HX5vgE//45oEn8peP4gefmPnQB+dzXV1b wiyWu1ga6uMedGafnVP70Ret/3c1DP5Ye7r8DxG1XGFN0+eHf3StdX7G3P/+8Y6//vivbu/zz//f 3J/+/Yd/xoddAViAHTGAAGiA0TeAcqZSt6aA8Ud9DyhhEHhdEYhgb7Vs2aZsqOVO04eBvDYuqbVn uTZqBmFdDliBFviB/yRdKlgcKEh95DKCoZKAUuKBfSJ/3zJnQeMk14cgP2ODIRhdHEhR2AeEzhGE 2wdrwAU1P+hY6YeDliWBQ6gRSpiEiINtpkGDnCJZk5V9nyZ8LLM4V6hpX2iGr2aCCaaDacWDM7iB qiV+alhNu+ZsL8hZ+/dabniAOXZifgiHJAgZfbgrhDiH5cKGeshqZyhUXYZdRP91VL6mfq4WhLLW fWJIgFdWOdVHiT/FiFTmhTxFhp7FieSnhTJ4iFRYW+onapKIia34Xa8IhezniqcIHBMYF5EzIqII agjGi4oYi7A4a6Y4jEmGiiBYfchYit0VXNq2hKfoJqzFguWFZXeIh4i4YIr4WYBYgyUofTmYinsI Lly4KUIYH9H4jccYjtsyjphSju5xjlOYjtnILuwIKe6IHvB4gnVIjdXYfOCYgv1YZv/nN70ogtvY hd1YWfp4jSpWkOJ4kOSYkFF4gUvlggEpYvfXgCt2kf4oj1OFYTj2IQhIkAJJjOhxi/ZYjOIxkjsI kByJaxRZWih5JzMpgBlJkij/9ZK0gWg2BZITdo8glofY+JEU+JMiOZAtSZSAUpMpuYzSiFkrmCdM mTHuEmc4aU9TWYE8uRhA+RhZOShdaRpbuR0+2WBh6WL7GJU0+WFn6RhjmRhtuRhfCShxyRhvKU1z aYB3iRd1mRh5qYn3kpZKKZVsWZXNFjBleV59qRh76X9FaZaGGSv8qJOv0Zim85cBaJl0cokegpkg kmY6JpiqoTOECZmYqCaamTmeyX+pKTirmX+tGTiviX/Rlix6xo1y2BG1+Su3iZC5yRGx+TezWX/B mTTDSV2GVhG7aSu9GZG/mZwUsZwHGB0/KDBlCJdH04wvxYTU14Sk6Yu4KDQq/yOaKmmF5Yd9oNiV zdmOXHaG3td+6+eeZiaeREOeJumcNKOd2lho42mVSclPxxl+0omRagk4RaiQzsiVWfMqHjGg4AQ5 kchXiBOhnLkR69mU3giGRxiMDomF5teJYNZrFMFskjmPUkihaMhYkIadyRaHGZqev+iM6NkzrOhc Gdqfh2miebaY6siMBzqR78igummfWEmZsuGgp/mMPIKYVeijLtqBDUqkRuiEVCoSvqaKHwohijOE F0qVv0lq/tmGOqpT3AWKYgia0GSmX5hmudiigaiBURqmiaikPLqZyVgRAWqeX4qjJbqRRsocUhpP eQp9SPqjSqaf9ChuOaqkhv+Kp4j6hnG6qAD6p4A6brgndZfKbh2HcJuaqZ76qaBqTJ0aqqSqQY83 qqWaqg9Ec6raqqN0R64aq20nq7R6TKhaq7gKQLeaq7y6cb36q6YKrMJ6Qbs6rMaqPpF3rMqKb8va rAdUrM4ardYDrdJarc9Drdaardq6rdzarT+HRZhnesDEeXsHeGO3dF8XeJ/3RXNHrubqQ43Xd7Cn ruHqdjFUr5B3dPi6SIakeojXeiJEr1nkr2kUeBIXclfkriZ3S5WXeDFncjkHeknHRfBqdlVHdWIX TOGqQ5eXseLqrjV0rq2EciKbciT3cQhLsQr7eIZ3eB0UeZQHsesqRpB3sRT/u3qhd7Ix23TlerNR t7Op16+H13k6J7PySrARm3beurTLOnb3KrJDN7A2a3RoJzxuZHawhLVZ+7Jwx3lQW3oXB3FKuzta u0ZT93QKi7Zk57Rcm6zKZLYeZ0ep9LNHp0kst0gT63Jx63mwZ7crW7dHdLeQtLeSJLiFFEIR5HqA N0KyR0gtZ3V/NKuRu7dyy7aQm7g8Z7KTm7e0M7V0e3I8+3d6i3KUa3UxF3ZbR26HdLZyy7SuSz7Y +rqyq3CqO0eOGz6xOzy5a7WzC7ij+7iim7SNm3WDh0ehO3o3l7m+C7wPy7PCdLyYOrvQC7Fxi3SE 9LB613XMm3Sa+7szt7zf/6u94fu7z6u8vXu+6Ju+6ru+7Nu+7rs+lBq/EsFS8luNLFm/HKlUYlOn +CtN+xuP5dm/Bni/Amy/N1nA9at8CHyRCrzA/djADnyHEBzBKki/XHWEH7UkiWUYEUXBe7qGjIp+ GOyhG4qmujgTaHZsUPUlHvyZSJl+WfIyM3qddKWMV3qlSdrC2kHA3mhsmWbCNXw1NTqLOnyUMVmh S7qI3+meaail8clTWrqLRWyOLwyWUwyYT0koW3XFmDLBXAybVvbFCujFYvx+FlzGx8fDaMx8arzG yNfGbkx8cBzHvzfHdLx7DPgcbLvHfNzHfvzHgBzIgjzIhFzIdwycgQpjh/8MppK6T4PKfMVpNI+8 fDHYodsFkez5wTYKwDLZpCaGyRgKpTcKwh4pFTlWK//bp/NHaba5Tk2MjhV5pw/ppG8qyghKhwyZ iSHcT7SMm3A6yrj8j366yJu8kI2ck8TMNInMTpOMfJF8Ms18fM8cMtFMfJUcwDECVXCzwcE2aAR6 Oj/aI9sMGlq1xXeTNuVsY2lDXDaSj6Qcyz0aNtpXnR7KxFsIyl4qwk6soe9JfkMMoml6OLKYoEAK y50syxYaw542w+hXkuD8pCgs0NZZz/18Wiy8aUIMnsqYw0p6zfcpz/ApTt/Jv/WYz6zmw/0x0mYl iVcIXOSMzUjc0ULZkDD/PSMoCjNHFWEPXcuNSIow+qIcuojw+cRIJYXGXMo1zZv4rMUS+cqcDJXD nMzKucw8JtVwdsxFatVTLadDOR2FCBvVXBx/uFIzrcuWbKFi9hglzdQtE573bIjalMsZaDea0Wdk 5YgCJs4R3VDBBldWkyV6rZJzE9ZJzINhUmfCJnxkRRMXzdeJDWxYddcIraNxLcwdKsWt+IjECIwa naX7XGunTNhWStkV/dlZGKNOjWwias+TLdNyHVls9sRhGNCoXaGZDdDdOdoQBpZbOtD/fNq0Hdw1 ddusHc8d6tFBDcWe6ImXaKYjvYqSps+dTVKDPV6qTU5nlt21qE/PHdt4/yXUt1yFyL3Rmm3SWG3e Ici/fGnU7zyNYZPX6i0boo0d8J000+ww8617970w+f1s+10w/Z1q483RvLzTvmzLBf3UQDPX+rLW VqzJ4l3WDL6fBu6bvxzelY3UHy0rDk6XTU3QRw3PpH3JvWzhCO7UIX7Qxm2bS/3gF57gKQ7Vk6rV 0UnViUbjNc7VNI3MOB4R//0xPT6/Eu7JBQ4RAV7MiQrXGzPkrV3k583WL47i7S188JHK6+jKLdiF WL5dWx7hr93kLF7i+HniID7lC07kYV7hY97g7B3MGp7VQV6hP64vR55lc14ycU4fNp5Nde5jd84u fS5jA/7WS1mYTmnQVP/OpAQeH4HOGziMj1Xc1Y6c53LO5JMZ5G3c6PJN6TU16MzM6Un65+Si6Rkm 6uNC6hNm6uCC6g2m6gEF6gzh6TBZ6CF56AqOXagW33PB6rmh647Gglae64kpXr4+ol2e4SI+mGtZ 6xyS6TpdmkZp6zFOhIoO7aZJKK4+LbwuXtkuLdtOXd3+LN8uW+GeLOO+WeUu5TfG7Fq251w57NRV 7HKR7mW+7tGO7e5Olo+pmJGZ5dW+7Pfe7jpu1qsh729x7gV6J/ReKwivVgsvKw2vUg/vKhE/UBPf KhXPTxc/4hyS8UyG7wMv7PtO7P3u3so+Jx7v0AL/5IRu7fwemCH/7AD/f+0rr8oFD++yZfBwsfGl kvL2xPOk4vPyBPShIvTxRPScYvTthPSbovTsRPTl7PJsFfWAgvRA3PE0r/ORavMlqfVuGu8bLR9M D8UzT+xev/X+7pKwjujUrvZrP+27felvb4xpH9Vz7+Z1P+N3b+Zxz/E8baAQTeGIHPNgbuKa06iz PKSEz86S3Y7H3uLQ+Pi8KfkTUaiBb2uPapBob/Jn/feYj/jrqKhcD+d7T/ecP+mlj/enz+Opv+SL 7/ZrDJ2Vn+/T5PTjIvtC/vq7XCDa3NfkTDaNn9Ya8e181iCujGd1Btjm3IMCgfs+HqjzCaL0DIbF LfyHf/nTScRoCt0p/7roe0Ofyqz7nc/7tLbQSIjbLJqfoP/rZhNuGP0yyb2dzc+neZ/U7I/SX3b1 jqn+2M8RNwwQAQQKFDAwQMGBCBEaPEhQwMOHBhcSZFjR4kWMDQcSyNiRIQCQHgcO6DhR5EmGESkm lKiw4kSTKGWijDmzIkmbOXXu5HmxZs+XKVlKJDp0pUakRmECFTmRI1OQAFDixPiT6VWsWYVmparV 61eZVsGOJbvT6dWoU8uuZdtWrVu4ceXObfsUaNqTXenu5ctTb1/AgQXvtdsTr8i/gxUrTrzY8WPI fA97bBw5qGWvlTFv7imWM+DJHTUnNQvR9Gegnm2ORl1Wtc+EKh3GrP8J8aTt2TNfH7W5e2bojKN9 l9waEXfLgrIPKl++nPZx11pZtx47vChFl7QvG82YnPvplMbDMycd9itwjMKvgr+O1GTt7e7jg7VO mTrd+qS9N3w/nzdsjVwqbqvy+sspP4/Qu0g9pgxMaiEH2+MNwrkQTO++Cg8sTsD/Oixvu/200487 AHs7L6S8iGuQwKWUgo/AB2GkTzoM5UKwxevEorCplr7LEccJzTpRqhS7G8xCvpC0aLoas7rxtiY9 hNIrBZe0jL0or2IySy67jKvKm7wU074xyzTTLTAZ2vJMDNdk8004E0QRsbiUjJPOO/PUE6U0DWKw xM4Avc00mAi1jVD/iw6V0b+e3Nxz0Uejo3JOMqsyMrceMY0NUZagU3GoHeVLVELP7FQzUp1MRXVK rfoc6dP5Qo2QRB95lPBDq7Ck9dZGVzXR17VU/YhS0WBd1Lv9eP0JyEtpfVFKEQUFytFVhQXW0kmJ xBNbQZEtcFSleAXXw2fdC1XKXf26lqZ1ybJ2IFcF+nNcYEulsV2P3sU3XcOIDW5f1KgFeODF4g1A YILhQjhhhvcyeOGGy4I4YorZerhixybGeONs3+KWY0bVxVhfgEm+uFmQIRW5YpL3NdnfC18ylLyI Z6Z5tZptTrkqndGCeUFjd/5wZYpbxvdlbSuVdud3Nb7T6HaR9lho/7qcpvrqk07GWi6rt/baoqjC FnvsAcY2+2y001Z7bbbbdvttuOMWu2y567b7brzz1ntvvvv2O2+6/xZ8cMIJD7xwxBNXfHHGG+f7 cMcjl1xwyCe3/HLMM9d87gE69/xz0EMXfXTSSzf9dNRTV3111knf/HXYY5d9dtprt/123HPXfXfe e/f9d+CDF3544os3/vjcK0d+eeabd5525Z+Xfnrqq9878LI7t3577rv3PuzDK/f8e/LLN/93yKM/ f332239dfPfjl3/+yOGn/3788y9cff379///s/EPgAMkoP4EWEAEJnB9B1RgAx1oPQY+UIITPF4E KXhBDPrOghnkYP8HoedBEIYweSIkYQllt0ETplCFj1thC12IOBS+UIYzRFsMaXjDG9oQhzt0oQ55 +EMT+hCIQwyhEIl4xAsaEYlLfKD2mPjEFSoRilMEoBSpeMX8WRGLW+RiF734RTCGUYxj7J/roqdF tqERfGbDHuasqEYYpjF7LCTbE9OnOTiCRIB5fBsfb3fAPPpRhOkLnx6jUkiytfGQawSAEw0ZQEY6 spGL1KPyFDlJSnLukJe8JCY9KclO0g2Uj/QkJh15SkhSUpKfrOEmM4nIT8IylK6sYyUZmcO55ZKV arsj50Spy7SNr5SmBOYtO5lKUhIzkshMZiV/ucxmJhOWAXRiLzP/ectHWpOTuuylNY1ZzBl6U5m1 BOczVQnOa44zm+jcJTmxicgzMlOd8zQnN9/JRntis5XQxCcpuylPS6ZTkAQUpzmnSct2NrKew7xm NYGJvYD6U5/S/CZFJcpPhTbToBg9qDQXmtCHbvOVAh3pKyM6zIHSMKVkZKnwVtpSmMZUpjOlaU0n Zz+GlrOi4LNkTw3Xz50CdKIXjSZR/bbBYwIupLVcpS0ZGs+H8pKd/4uo+pCay39ilI3CnOTnfJnT qu5TrDrNqTsTiUqv8nSO1ISo9rLHVWeuEa5FXeQ/7/hRsPbTqmtLqwHJKbp0sjWfZg0sSVGqUaCa FHSFvSdiS0nI/71qdaEnXadjsxrMpop0o/MsK04BS1fG4u+gkXXbWukKVcHS07HFFOdQg6nWzspz k8+8bFEv283QgXaf8KysIi042rGy9aXD8yb/wjpR1E71sMtt7XJ1e9xzSna1+pzsdA17zOqW1baI 3ahvS8va1xJWu+6Dbg37OlvZnhazbp3u+Cgb3fVmdpXnjetXzcte5yrUtGeFbXFHycvzlpe3bSuv cCHbUZsmWHrDVXCDHfxgCAPvtyV9Lx4TmzkG1y3DEQ5vGvV6YQv/EXcbbik8ZYnQxmp2qw1lbG1F 6s+T/vev1zUuQmdpVFNCtKSx1CqH9SbM2uZ1xpUla3ODbFl2Ymv3wtmtsXRjy1EnH9nHcgtydsOr YrPiNcsfXjJQjTxYIneZuUJ9bI+RPGW8hc/KOnbnZjmbUYs+2aknjnNTQYraUGrZpDtup5rj3Ofr olnQgyZ0oQ19aEQnWtGLZnSjHf1oSEda0pOmtEwDAgA7 --=_related 0010B7F748257935_=-- From ietfc@btconnect.com Thu Oct 27 04:17:54 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6340221F886A; Thu, 27 Oct 2011 04:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.459 X-Spam-Level: X-Spam-Status: No, score=0.459 tagged_above=-999 required=5 tests=[AWL=-2.592, BAYES_50=0.001, J_CHICKENPOX_74=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diAa5kQyYL-Y; Thu, 27 Oct 2011 04:17:53 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5C321F8677; Thu, 27 Oct 2011 04:17:51 -0700 (PDT) Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2bthomr07.btconnect.com with SMTP id FBI68612; Thu, 27 Oct 2011 12:17:41 +0100 (BST) Message-ID: <00ea01cc9490$f50eefa0$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: Date: Thu, 27 Oct 2011 12:09:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4EA93DD1.00B8, actions=TAG X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.7.19.51514:17:9.535, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CHAR_CHINESE_CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, CN_TLD, __HIGHBITS, __CP_URI_IN_BODY, __C230066_P5, __GB2312_MAINLAND_CELL_NUMBER, __LINES_OF_YELLING, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, LOCALE_CHINESE, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4EA93DD6.018E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: Re: [OPSAWG] An SNMP Usage for RELOAD X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 11:17:54 -0000 ----- Original Message ----- From: To: "t.petch" Cc: ; ; ; ; Sent: Wednesday, October 26, 2011 5:02 AM > In short, the relation between SNMP Usage and RELOAD as follows: > SNMP Usage get a available IP address, which is used for SNMP > communication, for snmeEngineID or NodeID or ResourceID or Manager name by > RELOAD mechanism, such as AppAttach, Store, Fetch. > Then SNMP Usage uses this IP address for SNMP communication between SNMP > entities by the SNMP mechanism and architecture which defined in RFC3411 > and RFC5953 and other SNMP RFCs (as depicted in the diagram below). And > now there is little relation between SNMP Usage and RELOAD besides using > RELOAD certificate. So we say "SNMP entities talk to each other using SNMP > protocol on dedicated connections" No, it still does not make sense. You understand that an SNMP engine can do nothing until it has been customised - snmpEngineID, snmpTargetAddrTable, etc - and you use RELOAD to obtain that information; I assume you are familiar with the MIB modules into which that information must then be placed before an engine can communicate. Two engines can then communicate but cannot do anything useful without suitable MIB modules; the I-D says " SNMP usage for RELOAD SHOULD provide the management functions ... ... monitoring the number of the messages initiated, forwarded or processed by nodes, reporting program failure , message forwarding failure or other error on nodes." This is a typical usage for SNMP but is quite impossible unless and until a suitable MIB module is defined, which is what everyone using SNMP for management then does. Your earlier response to David rejected the idea of creating a MIB module, which leaves me with two SNMP engines able to talk to each other but having nothing useful to say. The I-D also says "As traditional network management protocols (e.g., SNMP) cannot be directly applied to RELOAD network management, it is necessary to introduce new RELOAD usage of SNMP." which is only true in the sense that SNMP cannot be directly applied to any network management, unless and until there is a suitable MIB module. Once there is, and you have two communicating engines (which you say you will have), then of course SNMP can be used to manage anything, including RELOAD. Tom Petch > > If you till have questions, please tell us. Thanks! > > > ************************************************* > ÓÊ ¼þ£ºpeng.yonglin@zte.com.cn > ÄÚ Ïߣº81543 > Íâ Ïߣº025-52871543 > ÊÖ »ú£º13776637274 > ´« Õ棺025-52872187 > ************************************************* > > > > > > > ----- Original Message ----- > From: ; > To: ; ; ; > > Cc: ; > Sent: Tuesday, October 25, 2011 4:23 AM > > > We have done more research on security and other issues based on David's > > comments, and updated our draft. > > > > This is the new version of draft: > > http://www.ietf.org/id/draft-peng-p2psip-snmp-03.txt > > > > We welcome any comments! Thanks! > > > > Our analysis of David's comments as follows(blue text): > > > > 1) Use SNMPv3 terminology > > Apparently, you come from the RELOAD side of things, not the SNMP > > side. > > Your text doesn't use the common SNMP terminology for various > > SNMP-related things. > > You will have a better chance of success if you describe SNMP-related > > things using the normal SNMPv3 terminology. > > This isn't critical; your ideas seem reasonable, but since you don't > > use the standard terminology, you might mean slightly different things > > than what it would mean if you used the standard terminology. > > > > (I don't have a RELOAD background, so some of my comments might seem > > wrong because I don't know the RELOAD concepts and terminology. Now > > you'll understand my point ;-) > > > > PYL: We have updated the draft using SNMP terminology. As we are not > SNMP > > experts, some terminology may not be accurate. We will try to improve > this > > over time. > > You are indeed using SNMP terminology, but I struggle to see how its usage > is > the same as in RFC3411. > > RELOAD defines a messaging network, on top of which run applications, > which > RELOAD calls Usages, so when you define an SNMP Usage, you would appear to > be > discarding most of an Architecture for SNMP as defined in RFC3411, perhaps > providing instead a gateway for functionality such as that specified in > RFC3414; > or perhaps not, I do not find the I-D clear on this. Thus you have > > Application > > +-------+ +-------+ +-------+ > | SIP | | XMPP | | SNMP | ... > | Usage | | Usage | | Usage | > +-------+ +-------+ +-------+ > ------------------------------------------- Messaging API > > RELOAD > > but elsewhere you say > ' SNMP entities talk to each other using SNMP protocol on dedicated > connections' > which is rather different. > > The I-D reads more like a wish list of requirements, than an overview, > architecture or framework. Or perhaps it is all beyond me:-( > > Tom Petch > > From dromasca@avaya.com Thu Oct 27 04:48:57 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C8721F8663; Thu, 27 Oct 2011 04:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.841 X-Spam-Level: X-Spam-Status: No, score=-99.841 tagged_above=-999 required=5 tests=[AWL=-3.306, BAYES_40=-0.185, J_CHICKENPOX_15=0.6, J_CHICKENPOX_74=0.6, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN9wvlB00XIV; Thu, 27 Oct 2011 04:48:57 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C23F021F85A4; Thu, 27 Oct 2011 04:48:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8BALRDqU6HCzI1/2dsb2JhbABChHeVFY9RgQWBcgEBAQEDAQEBDx47AwQHDAQCAQYCDQQBAwEBBQYGDAsBBAIBJh8DBggBAQQBEggBGYdomRiJWQiSDYEshjo3YQSZWYwV X-IronPort-AV: E=Sophos;i="4.69,413,1315195200"; d="scan'208";a="214949370" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Oct 2011 07:48:52 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Oct 2011 07:38:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Oct 2011 13:48:43 +0200 Message-ID: In-Reply-To: <00ea01cc9490$f50eefa0$4001a8c0@gateway.2wire.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [OPSAWG] An SNMP Usage for RELOAD thread-index: AcyUmh9ppjV7Slo1SnCWRRnwN2xWKgAA6J8w References: <00ea01cc9490$f50eefa0$4001a8c0@gateway.2wire.net> From: "Romascanu, Dan (Dan)" To: "t.petch" , Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: Re: [OPSAWG] An SNMP Usage for RELOAD X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 11:48:58 -0000 Just to make sharper the statements made by Tom. In the SNMP = architecture in order for two entities to exchange management = information we have a protocol (basic primitives to fetch pieces of = information, set values of pieces of information or send notifications = related to the pieces of information) and a data model (e.g. MIB model) = expressed in a Data Modeling Language (e.g. SMI). The proposed text = talks about the protocol (SNMP) but not about the information exchanged = (data model). This is of little help.=20 Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of t.petch > Sent: Thursday, October 27, 2011 12:09 PM > To: peng.yonglin@zte.com.cn > Cc: hao.zhenwu@zte.com.cn; opsawg@ietf.org; p2psip@ietf.org > Subject: Re: [OPSAWG] An SNMP Usage for RELOAD >=20 > ----- Original Message ----- > From: > To: "t.petch" > Cc: ; ; ; > ; > Sent: Wednesday, October 26, 2011 5:02 AM >=20 > > In short, the relation between SNMP Usage and RELOAD as follows: > > SNMP Usage get a available IP address, which is used for SNMP > > communication, for snmeEngineID or NodeID or ResourceID or Manager > name by > > RELOAD mechanism, such as AppAttach, Store, Fetch. > > Then SNMP Usage uses this IP address for SNMP communication between > SNMP > > entities by the SNMP mechanism and architecture which defined in > RFC3411 > > and RFC5953 and other SNMP RFCs (as depicted in the diagram below). > And > > now there is little relation between SNMP Usage and RELOAD besides > using > > RELOAD certificate. So we say "SNMP entities talk to each other = using > SNMP > > protocol on dedicated connections" >=20 > No, it still does not make sense. You understand that an SNMP engine > can do > nothing until it has been customised - snmpEngineID, > snmpTargetAddrTable, etc - > and you use RELOAD to obtain that information; I assume you are > familiar with > the MIB modules into which that information must then be placed before > an engine > can communicate. >=20 > Two engines can then communicate but cannot do anything useful without > suitable > MIB modules; the I-D says > " SNMP usage for RELOAD SHOULD provide the management functions ... > ... monitoring the number of the messages > initiated, forwarded or processed by nodes, reporting program > failure > , message forwarding failure or other error on nodes." >=20 > This is a typical usage for SNMP but is quite impossible unless and > until a > suitable > MIB module is defined, which is what everyone using SNMP for = management > then does. Your earlier response to David rejected the idea of > creating a MIB > module, which leaves me with two SNMP engines able to talk to each > other but > having nothing useful to say. >=20 > The I-D also says > "As traditional network > management protocols (e.g., SNMP) cannot be directly applied to > RELOAD network management, it is necessary to introduce new RELOAD > usage of SNMP." > which is only true in the sense that SNMP cannot be directly applied = to > any > network > management, unless and until there is a suitable MIB module. Once > there is, > and you have two communicating engines (which you say you will have), > then > of course SNMP can be used to manage anything, including RELOAD. >=20 > Tom Petch >=20 > > > > If you till have questions, please tell us. Thanks! > > > > > > ************************************************* > > =D3=CA =BC=FE=A3=BApeng.yonglin@zte.com.cn > > =C4=DA =CF=DF=A3=BA81543 > > =CD=E2 =CF=DF=A3=BA025-52871543 > > =CA=D6 =BB=FA=A3=BA13776637274 > > =B4=AB =D5=E6=A3=BA025-52872187 > > ************************************************* > > > > > > > > > > > > ----- Original Message ----- > > From: ; > > To: ; ; ; > > > > Cc: ; > > Sent: Tuesday, October 25, 2011 4:23 AM > > > > > We have done more research on security and other issues based on > David's > > > comments, and updated our draft. > > > > > > This is the new version of draft: > > > http://www.ietf.org/id/draft-peng-p2psip-snmp-03.txt > > > > > > We welcome any comments! Thanks! > > > > > > Our analysis of David's comments as follows(blue text): > > > > > > 1) Use SNMPv3 terminology > > > Apparently, you come from the RELOAD side of things, not the SNMP > > > side. > > > Your text doesn't use the common SNMP terminology for various > > > SNMP-related things. > > > You will have a better chance of success if you describe SNMP- > related > > > things using the normal SNMPv3 terminology. > > > This isn't critical; your ideas seem reasonable, but since you > don't > > > use the standard terminology, you might mean slightly different > things > > > than what it would mean if you used the standard terminology. > > > > > > (I don't have a RELOAD background, so some of my comments might > seem > > > wrong because I don't know the RELOAD concepts and terminology. = Now > > > you'll understand my point ;-) > > > > > > PYL: We have updated the draft using SNMP terminology. As we are > not > > SNMP > > > experts, some terminology may not be accurate. We will try to > improve > > this > > > over time. > > > > You are indeed using SNMP terminology, but I struggle to see how its > usage > > is > > the same as in RFC3411. > > > > RELOAD defines a messaging network, on top of which run = applications, > > which > > RELOAD calls Usages, so when you define an SNMP Usage, you would > appear to > > be > > discarding most of an Architecture for SNMP as defined in RFC3411, > perhaps > > providing instead a gateway for functionality such as that specified > in > > RFC3414; > > or perhaps not, I do not find the I-D clear on this. Thus you have > > > > Application > > > > +-------+ +-------+ +-------+ > > | SIP | | XMPP | | SNMP | ... > > | Usage | | Usage | | Usage | > > +-------+ +-------+ +-------+ > > ------------------------------------------- Messaging API > > > > RELOAD > > > > but elsewhere you say > > ' SNMP entities talk to each other using SNMP protocol on dedicated > > connections' > > which is rather different. > > > > The I-D reads more like a wish list of requirements, than an > overview, > > architecture or framework. Or perhaps it is all beyond me:-( > > > > Tom Petch > > > > >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From j.schoenwaelder@jacobs-university.de Thu Oct 27 08:15:51 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036EB21F8B23; Thu, 27 Oct 2011 08:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-t5j+jeqXH6; Thu, 27 Oct 2011 08:15:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F25BB21F8B21; Thu, 27 Oct 2011 08:15:49 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56F8820E54; Thu, 27 Oct 2011 17:15:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 73czeMLz3K0S; Thu, 27 Oct 2011 17:15:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6274D20E50; Thu, 27 Oct 2011 17:15:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 783DA1B3DB52; Thu, 27 Oct 2011 17:15:31 +0200 (CEST) Date: Thu, 27 Oct 2011 17:15:31 +0200 From: Juergen Schoenwaelder To: peng.yonglin@zte.com.cn Message-ID: <20111027151531.GD40631@elstar.local> Mail-Followup-To: peng.yonglin@zte.com.cn, hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org References: <00ea01cc9490$f50eefa0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: Re: [OPSAWG] An SNMP Usage for RELOAD X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:15:51 -0000 On Thu, Oct 27, 2011 at 01:48:43PM +0200, Romascanu, Dan (Dan) wrote: > Just to make sharper the statements made by Tom. In the SNMP architecture in order for two entities to exchange management information we have a protocol (basic primitives to fetch pieces of information, set values of pieces of information or send notifications related to the pieces of information) and a data model (e.g. MIB model) expressed in a Data Modeling Language (e.g. SMI). The proposed text talks about the protocol (SNMP) but not about the information exchanged (data model). This is of little help. > And it might help to notice that the set of SNMP's protocol operations has been static for almost 20 years and any attempts to add additional protocol operations during this period failed to get sufficient support. So if your idea is to add new operations, you likely will have a hard time getting this anywhere. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From peng.yonglin@zte.com.cn Thu Oct 27 20:56:49 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE741F0C54; Thu, 27 Oct 2011 20:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.695 X-Spam-Level: X-Spam-Status: No, score=-90.695 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7a2zrBRHt0p; Thu, 27 Oct 2011 20:56:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 40B751F0C5E; Thu, 27 Oct 2011 20:56:47 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466213465113155; Fri, 28 Oct 2011 11:47:09 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 60802.5026350496; Fri, 28 Oct 2011 11:56:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9S3uX4q088250; Fri, 28 Oct 2011 11:56:33 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: <00ea01cc9490$f50eefa0$4001a8c0@gateway.2wire.net> To: "t.petch" , "Romascanu, Dan (Dan)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Fri, 28 Oct 2011 11:56:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-28 11:56:34, Serialize complete at 2011-10-28 11:56:34 Content-Type: multipart/alternative; boundary="=_alternative 0015A02C48257937_=" X-MAIL: mse02.zte.com.cn p9S3uX4q088250 Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: [OPSAWG] =?gb2312?b?tPC4tDogUmU6IFJlOiAgQW4gU05NUCBVc2FnZSBmb3Ig?= =?gb2312?b?UkVMT0FE?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 03:56:49 -0000 This is a multipart message in MIME format. --=_alternative 0015A02C48257937_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBUb20ncyByZXNwb25zZSBhbmQgRGFuJ3MgZXhwbGFuYXRpb24uIFBsZWFzZSBz ZWUgaW5saW5lIChibHVlIA0KdGV4dCkuDQoNCg0KDQoNCg0KInQucGV0Y2giIDxpZXRmY0BidGNv bm5lY3QuY29tPiANCjIwMTEtMTAtMjcgMTg6MDkNCg0KytW8/sjLDQo8cGVuZy55b25nbGluQHp0 ZS5jb20uY24+DQqzrcvNDQo8aGFvLnpoZW53dUB6dGUuY29tLmNuPiwgPG9wc2F3Z0BpZXRmLm9y Zz4sIDxwMnBzaXBAaWV0Zi5vcmc+LCANCjx3YW5nLndlaTEwOEB6dGUuY29tLmNuPiwgPG1lbmcu eXVAenRlLmNvbS5jbj4NCtb3zOINClJlOiBSZTogW09QU0FXR10gQW4gU05NUCBVc2FnZSBmb3Ig UkVMT0FEDQoNCg0KDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiA8 cGVuZy55b25nbGluQHp0ZS5jb20uY24+DQpUbzogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3Qu Y29tPg0KQ2M6IDxoYW8uemhlbnd1QHp0ZS5jb20uY24+OyA8b3BzYXdnQGlldGYub3JnPjsgPHAy cHNpcEBpZXRmLm9yZz47DQo8d2FuZy53ZWkxMDhAenRlLmNvbS5jbj47IDxtZW5nLnl1QHp0ZS5j b20uY24+DQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjYsIDIwMTEgNTowMiBBTQ0KDQo+IElu IHNob3J0LCB0aGUgcmVsYXRpb24gYmV0d2VlbiBTTk1QIFVzYWdlIGFuZCBSRUxPQUQgYXMgZm9s bG93czoNCj4gU05NUCBVc2FnZSBnZXQgYSBhdmFpbGFibGUgSVAgYWRkcmVzcywgd2hpY2ggaXMg dXNlZCBmb3IgU05NUA0KPiBjb21tdW5pY2F0aW9uLCBmb3Igc25tZUVuZ2luZUlEIG9yIE5vZGVJ RCBvciBSZXNvdXJjZUlEIG9yIE1hbmFnZXIgbmFtZSANCmJ5DQo+IFJFTE9BRCBtZWNoYW5pc20s IHN1Y2ggYXMgQXBwQXR0YWNoLCBTdG9yZSwgRmV0Y2guDQo+IFRoZW4gU05NUCBVc2FnZSB1c2Vz IHRoaXMgSVAgYWRkcmVzcyBmb3IgU05NUCBjb21tdW5pY2F0aW9uIGJldHdlZW4gU05NUA0KPiBl bnRpdGllcyBieSB0aGUgU05NUCBtZWNoYW5pc20gYW5kIGFyY2hpdGVjdHVyZSB3aGljaCBkZWZp bmVkIGluIFJGQzM0MTENCj4gYW5kIFJGQzU5NTMgYW5kIG90aGVyIFNOTVAgUkZDcyAoYXMgZGVw aWN0ZWQgaW4gdGhlIGRpYWdyYW0gYmVsb3cpLiBBbmQNCj4gbm93IHRoZXJlIGlzIGxpdHRsZSBy ZWxhdGlvbiBiZXR3ZWVuIFNOTVAgVXNhZ2UgYW5kIFJFTE9BRCBiZXNpZGVzIHVzaW5nDQo+IFJF TE9BRCBjZXJ0aWZpY2F0ZS4gU28gd2Ugc2F5ICJTTk1QIGVudGl0aWVzIHRhbGsgdG8gZWFjaCBv dGhlciB1c2luZyANClNOTVANCj4gcHJvdG9jb2wgb24gZGVkaWNhdGVkIGNvbm5lY3Rpb25zIg0K DQpObywgaXQgc3RpbGwgZG9lcyBub3QgbWFrZSBzZW5zZS4gIFlvdSB1bmRlcnN0YW5kIHRoYXQg YW4gU05NUCBlbmdpbmUgY2FuIA0KZG8NCm5vdGhpbmcgdW50aWwgaXQgaGFzIGJlZW4gY3VzdG9t aXNlZCAtIHNubXBFbmdpbmVJRCwgc25tcFRhcmdldEFkZHJUYWJsZSwgDQpldGMgLQ0KYW5kIHlv dSB1c2UgUkVMT0FEIHRvIG9idGFpbiB0aGF0IGluZm9ybWF0aW9uOyBJIGFzc3VtZSB5b3UgYXJl IGZhbWlsaWFyIA0Kd2l0aA0KdGhlIE1JQiBtb2R1bGVzIGludG8gd2hpY2ggdGhhdCBpbmZvcm1h dGlvbiBtdXN0IHRoZW4gYmUgcGxhY2VkIGJlZm9yZSBhbiANCmVuZ2luZQ0KY2FuIGNvbW11bmlj YXRlLg0KWWVzLCB0aGVzZSBpbmZvcm1hdGlvbiB3aWxsIGJlIHBsYWNlZCBpbnRvIE1JQi4gRm9y IGV4YW1wbGUsIHdlIHNheSB3aGVuIA0KQWdlbnQgDQpnZXQgdGhlIGFkZHJlc3Mgb2YgTWFuYWdl ciwgaXQgd2lsbCBzdG9yZSB0aGUgYWRkcmVzcyBpbnRvIA0KTUlCKHNubXBUYXJnZXRBZGRyVGFi bGUpIGluIHRoZSBkaWFncmFtIGluIGNoYXB0ZXIgOS4NCg0KDQpUd28gZW5naW5lcyBjYW4gdGhl biBjb21tdW5pY2F0ZSBidXQgY2Fubm90IGRvIGFueXRoaW5nIHVzZWZ1bCB3aXRob3V0IA0Kc3Vp dGFibGUNCk1JQiBtb2R1bGVzOyB0aGUgSS1EIHNheXMNCiIgU05NUCB1c2FnZSBmb3IgUkVMT0FE IFNIT1VMRCBwcm92aWRlIHRoZSBtYW5hZ2VtZW50IGZ1bmN0aW9ucyAuLi4NCiAgICAgLi4uIG1v bml0b3JpbmcgdGhlIG51bWJlciBvZiB0aGUgbWVzc2FnZXMNCiAgIGluaXRpYXRlZCwgZm9yd2Fy ZGVkIG9yIHByb2Nlc3NlZCBieSBub2RlcywgcmVwb3J0aW5nIHByb2dyYW0gZmFpbHVyZQ0KICAg LCBtZXNzYWdlIGZvcndhcmRpbmcgZmFpbHVyZSBvciBvdGhlciBlcnJvciBvbiBub2Rlcy4iDQoN ClRoaXMgaXMgYSB0eXBpY2FsIHVzYWdlIGZvciBTTk1QIGJ1dCBpcyBxdWl0ZSBpbXBvc3NpYmxl IHVubGVzcyBhbmQgdW50aWwgDQphDQpzdWl0YWJsZQ0KTUlCIG1vZHVsZSBpcyBkZWZpbmVkLCB3 aGljaCBpcyB3aGF0IGV2ZXJ5b25lIHVzaW5nIFNOTVAgZm9yIG1hbmFnZW1lbnQNCnRoZW4gZG9l cy4gIFlvdXIgZWFybGllciByZXNwb25zZSB0byBEYXZpZCByZWplY3RlZCB0aGUgaWRlYSBvZiBj cmVhdGluZyBhIA0KTUlCDQptb2R1bGUsIHdoaWNoIGxlYXZlcyBtZSB3aXRoIHR3byBTTk1QIGVu Z2luZXMgYWJsZSB0byB0YWxrIHRvIGVhY2ggb3RoZXIgDQpidXQNCmhhdmluZyBub3RoaW5nIHVz ZWZ1bCB0byBzYXkuDQpTb3JyeaOsb3VyIGxhc3QgcmVzcG9uc2UgbWF5YmUgY29uZnVzaW5nLiBX ZSBhbHNvIHRoaW5rIHdlIG5lZWQgTUlCIG1vZHVsZSANCndoaWNoIHJlbGF0ZXMgdG8gbWFuYWdl ZCBvYmplY3RzIG9mIFJFTE9BRC4gDQpPbmx5IGJlY2F1c2UgaXQgZG9lc24ndCBhZmZlY3QgdGhl IGltcGxlbWVudGF0aW9uIG1lY2hhbmlzbSBvZiBtYW5hZ2VtZW50LCANCnNvIHdlIHBsYW4gdG8g c3R1ZHkgYW5kIGRlZmluZSBpdCBsYXRlci4gDQpGb3Igbm93LCB3ZSB0cnkgdG8gcmVzb2x2ZSB0 aGUgZGlzY292ZXJ5IGFuZCBjb21tdW5pY2F0aW9uIHByb2JsZW1zIGZvciANCnNubXBFbmdpbmVz LiANCkFzIG91ciBjdXJyZW50IGRlc2lnbiBkb2VzIG5vdCByZXF1aXJlIGEgcHJlZGVmaW5lZCBN SUIgKG1heWJlIHdlIG1pc3MgDQpzb21lIHBhdHMpLCB3ZSBsZWF2ZSB0aGUgTUlCIGRlZmluaXRp b24gZm9yIGZ1dHVyZSBzdHVkeS4gDQoNClRoZSBJLUQgYWxzbyBzYXlzDQoiQXMgdHJhZGl0aW9u YWwgbmV0d29yaw0KICAgbWFuYWdlbWVudCBwcm90b2NvbHMgKGUuZy4sIFNOTVApIGNhbm5vdCBi ZSBkaXJlY3RseSBhcHBsaWVkIHRvDQogICBSRUxPQUQgbmV0d29yayBtYW5hZ2VtZW50LCBpdCBp cyBuZWNlc3NhcnkgdG8gaW50cm9kdWNlIG5ldyBSRUxPQUQNCiAgIHVzYWdlIG9mIFNOTVAuIg0K d2hpY2ggaXMgb25seSB0cnVlIGluIHRoZSBzZW5zZSB0aGF0IFNOTVAgY2Fubm90IGJlIGRpcmVj dGx5IGFwcGxpZWQgdG8gDQphbnkNCm5ldHdvcmsNCm1hbmFnZW1lbnQsIHVubGVzcyBhbmQgdW50 aWwgdGhlcmUgaXMgYSBzdWl0YWJsZSBNSUIgbW9kdWxlLiAgT25jZSB0aGVyZSANCmlzLA0KYW5k IHlvdSBoYXZlIHR3byBjb21tdW5pY2F0aW5nIGVuZ2luZXMgKHdoaWNoIHlvdSBzYXkgeW91IHdp bGwgaGF2ZSksIHRoZW4NCm9mIGNvdXJzZSBTTk1QIGNhbiBiZSB1c2VkIHRvIG1hbmFnZSBhbnl0 aGluZywgaW5jbHVkaW5nIFJFTE9BRC4NCg0KVG9tIFBldGNoDQoNCj4NCj4gSWYgeW91IHRpbGwg aGF2ZSBxdWVzdGlvbnMsIHBsZWFzZSB0ZWxsIHVzLiBUaGFua3MhDQo+DQo+DQo+ICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4g08ogvP6junBlbmcu eW9uZ2xpbkB6dGUuY29tLmNuDQo+IMTaIM/fo7o4MTU0Mw0KPiDN4iDP36O6MDI1LTUyODcxNTQz DQo+IMrWILv6o7oxMzc3NjYzNzI3NA0KPiC0qyDV5qO6MDI1LTUyODcyMTg3DQo+ICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4NCj4gPg0KPg0KPg0K PiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogPHBlbmcueW9uZ2xpbkB6 dGUuY29tLmNuPjsgPHBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPg0KPiBUbzogPHAycHNpcEBpZXRm Lm9yZz47IDxvcHNhd2dAaWV0Zi5vcmc+OyA8cDJwc2lwQGlldGYub3JnPjsNCj4gPG9wc2F3Z0Bp ZXRmLm9yZz4NCj4gQ2M6IDxoYW8uemhlbnd1QHp0ZS5jb20uY24+OyA8aGFvLnpoZW53dUB6dGUu Y29tLmNuPg0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDI1LCAyMDExIDQ6MjMgQU0NCj4NCj4g PiBXZSBoYXZlIGRvbmUgbW9yZSByZXNlYXJjaCBvbiBzZWN1cml0eSBhbmQgb3RoZXIgaXNzdWVz IGJhc2VkIG9uIA0KRGF2aWQncw0KPiA+IGNvbW1lbnRzLCBhbmQgdXBkYXRlZCBvdXIgZHJhZnQu DQo+ID4NCj4gPiBUaGlzIGlzIHRoZSBuZXcgdmVyc2lvbiBvZiBkcmFmdDoNCj4gPiBodHRwOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LXBlbmctcDJwc2lwLXNubXAtMDMudHh0DQo+ID4NCj4gPiBX ZSB3ZWxjb21lIGFueSBjb21tZW50cyEgVGhhbmtzIQ0KPiA+DQo+ID4gT3VyIGFuYWx5c2lzIG9m IERhdmlkJ3MgY29tbWVudHMgYXMgZm9sbG93cyhibHVlIHRleHQpOg0KPiA+DQo+ID4gMSkgVXNl IFNOTVB2MyB0ZXJtaW5vbG9neQ0KPiA+IEFwcGFyZW50bHksIHlvdSBjb21lIGZyb20gdGhlIFJF TE9BRCBzaWRlIG9mIHRoaW5ncywgbm90IHRoZSBTTk1QDQo+ID4gc2lkZS4NCj4gPiBZb3VyIHRl eHQgZG9lc24ndCB1c2UgdGhlIGNvbW1vbiBTTk1QIHRlcm1pbm9sb2d5IGZvciB2YXJpb3VzDQo+ ID4gU05NUC1yZWxhdGVkIHRoaW5ncy4NCj4gPiBZb3Ugd2lsbCBoYXZlIGEgYmV0dGVyIGNoYW5j ZSBvZiBzdWNjZXNzIGlmIHlvdSBkZXNjcmliZSBTTk1QLXJlbGF0ZWQNCj4gPiB0aGluZ3MgdXNp bmcgdGhlIG5vcm1hbCBTTk1QdjMgdGVybWlub2xvZ3kuDQo+ID4gVGhpcyBpc24ndCBjcml0aWNh bDsgeW91ciBpZGVhcyBzZWVtIHJlYXNvbmFibGUsIGJ1dCBzaW5jZSB5b3UgZG9uJ3QNCj4gPiB1 c2UgdGhlIHN0YW5kYXJkIHRlcm1pbm9sb2d5LCB5b3UgbWlnaHQgbWVhbiBzbGlnaHRseSBkaWZm ZXJlbnQgdGhpbmdzDQo+ID4gdGhhbiB3aGF0IGl0IHdvdWxkIG1lYW4gaWYgeW91IHVzZWQgdGhl IHN0YW5kYXJkIHRlcm1pbm9sb2d5Lg0KPiA+DQo+ID4gKEkgZG9uJ3QgaGF2ZSBhIFJFTE9BRCBi YWNrZ3JvdW5kLCBzbyBzb21lIG9mIG15IGNvbW1lbnRzIG1pZ2h0IHNlZW0NCj4gPiB3cm9uZyBi ZWNhdXNlIEkgZG9uJ3Qga25vdyB0aGUgUkVMT0FEIGNvbmNlcHRzIGFuZCB0ZXJtaW5vbG9neS4g Tm93DQo+ID4geW91J2xsIHVuZGVyc3RhbmQgbXkgcG9pbnQgOy0pDQo+ID4NCj4gPiBQWUw6IFdl IGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdXNpbmcgU05NUCB0ZXJtaW5vbG9neS4gQXMgd2UgYXJl IG5vdA0KPiBTTk1QDQo+ID4gZXhwZXJ0cywgc29tZSB0ZXJtaW5vbG9neSBtYXkgbm90IGJlIGFj Y3VyYXRlLiBXZSB3aWxsIHRyeSB0byBpbXByb3ZlDQo+IHRoaXMNCj4gPiBvdmVyIHRpbWUuDQo+ DQo+IFlvdSBhcmUgaW5kZWVkIHVzaW5nIFNOTVAgdGVybWlub2xvZ3ksIGJ1dCBJIHN0cnVnZ2xl IHRvIHNlZSBob3cgaXRzIA0KdXNhZ2UNCj4gaXMNCj4gdGhlIHNhbWUgYXMgaW4gUkZDMzQxMS4N Cj4NCj4gUkVMT0FEIGRlZmluZXMgYSBtZXNzYWdpbmcgbmV0d29yaywgb24gdG9wIG9mIHdoaWNo IHJ1biBhcHBsaWNhdGlvbnMsDQo+IHdoaWNoDQo+IFJFTE9BRCBjYWxscyBVc2FnZXMsIHNvIHdo ZW4geW91IGRlZmluZSBhbiBTTk1QIFVzYWdlLCB5b3Ugd291bGQgYXBwZWFyIA0KdG8NCj4gYmUN Cj4gZGlzY2FyZGluZyBtb3N0IG9mIGFuIEFyY2hpdGVjdHVyZSBmb3IgU05NUCBhcyBkZWZpbmVk IGluIFJGQzM0MTEsIA0KcGVyaGFwcw0KPiBwcm92aWRpbmcgaW5zdGVhZCBhIGdhdGV3YXkgZm9y IGZ1bmN0aW9uYWxpdHkgc3VjaCBhcyB0aGF0IHNwZWNpZmllZCBpbg0KPiBSRkMzNDE0Ow0KPiBv ciBwZXJoYXBzIG5vdCwgSSBkbyBub3QgZmluZCB0aGUgSS1EIGNsZWFyIG9uIHRoaXMuICBUaHVz IHlvdSBoYXZlDQo+DQo+ICAgICAgICAgICAgICAgICAgIEFwcGxpY2F0aW9uDQo+DQo+ICAgICAg ICAgICAgICstLS0tLS0tKyAgKy0tLS0tLS0rICArLS0tLS0tLSsNCj4gICAgICAgICAgICAgfCBT SVAgICB8ICB8IFhNUFAgIHwgIHwgU05NUCAgfCAgLi4uDQo+ICAgICAgICAgICAgIHwgVXNhZ2Ug fCAgfCBVc2FnZSB8ICB8IFVzYWdlIHwNCj4gICAgICAgICAgICAgKy0tLS0tLS0rICArLS0tLS0t LSsgICstLS0tLS0tKw0KPiAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIE1lc3NhZ2luZyBBUEkNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgIFJF TE9BRA0KPg0KPiBidXQgZWxzZXdoZXJlIHlvdSBzYXkNCj4gJyBTTk1QIGVudGl0aWVzIHRhbGsg dG8gZWFjaCBvdGhlciB1c2luZyBTTk1QIHByb3RvY29sIG9uIGRlZGljYXRlZA0KPiBjb25uZWN0 aW9ucycNCj4gd2hpY2ggaXMgcmF0aGVyIGRpZmZlcmVudC4NCj4NCj4gVGhlIEktRCByZWFkcyBt b3JlIGxpa2UgYSB3aXNoIGxpc3Qgb2YgcmVxdWlyZW1lbnRzLCB0aGFuIGFuIG92ZXJ2aWV3LA0K PiBhcmNoaXRlY3R1cmUgb3IgZnJhbWV3b3JrLiAgT3IgcGVyaGFwcyBpdCBpcyBhbGwgYmV5b25k IG1lOi0oDQo+DQo+IFRvbSBQZXRjaA0KPg0KPiA8c25pcD4NCg0KDQoNCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0015A02C48257937_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgVG9tJ3MgcmVz cG9uc2UgYW5kIERhbidzDQpleHBsYW5hdGlvbi4gUGxlYXNlIHNlZSBpbmxpbmUgKGJsdWUgdGV4 dCkuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjxiPiZxdW90O3QucGV0Y2gmcXVvdDsgJmx0O2lldGZjQGJ0Y29ubmVjdC5jb20m Z3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEt MTAtMjcgMTg6MDk8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+Jmx0O3BlbmcueW9uZ2xpbkB6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+Jmx0O2hhby56aGVud3VAenRlLmNvbS5jbiZndDssICZsdDtvcHNhd2dAaWV0Zi5vcmcm Z3Q7LA0KJmx0O3AycHNpcEBpZXRmLm9yZyZndDssICZsdDt3YW5nLndlaTEwOEB6dGUuY29tLmNu Jmd0OywgJmx0O21lbmcueXVAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3 zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBS ZTogW09QU0FXR10gQW4gU05NUCBVc2FnZSBmb3IgUkVMT0FEPC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tPGJyPg0KRnJvbTogJmx0O3BlbmcueW9uZ2xpbkB6dGUuY29tLmNuJmd0Ozxicj4N ClRvOiAmcXVvdDt0LnBldGNoJnF1b3Q7ICZsdDtpZXRmY0BidGNvbm5lY3QuY29tJmd0Ozxicj4N CkNjOiAmbHQ7aGFvLnpoZW53dUB6dGUuY29tLmNuJmd0OzsgJmx0O29wc2F3Z0BpZXRmLm9yZyZn dDs7ICZsdDtwMnBzaXBAaWV0Zi5vcmcmZ3Q7Ozxicj4NCiZsdDt3YW5nLndlaTEwOEB6dGUuY29t LmNuJmd0OzsgJmx0O21lbmcueXVAenRlLmNvbS5jbiZndDs8YnI+DQpTZW50OiBXZWRuZXNkYXks IE9jdG9iZXIgMjYsIDIwMTEgNTowMiBBTTxicj4NCjxicj4NCiZndDsgSW4gc2hvcnQsIHRoZSBy ZWxhdGlvbiBiZXR3ZWVuIFNOTVAgVXNhZ2UgYW5kIFJFTE9BRCBhcyBmb2xsb3dzOjxicj4NCiZn dDsgU05NUCBVc2FnZSBnZXQgYSBhdmFpbGFibGUgSVAgYWRkcmVzcywgd2hpY2ggaXMgdXNlZCBm b3IgU05NUDxicj4NCiZndDsgY29tbXVuaWNhdGlvbiwgZm9yIHNubWVFbmdpbmVJRCBvciBOb2Rl SUQgb3IgUmVzb3VyY2VJRCBvciBNYW5hZ2VyDQpuYW1lIGJ5PGJyPg0KJmd0OyBSRUxPQUQgbWVj aGFuaXNtLCBzdWNoIGFzIEFwcEF0dGFjaCwgU3RvcmUsIEZldGNoLjxicj4NCiZndDsgVGhlbiBT Tk1QIFVzYWdlIHVzZXMgdGhpcyBJUCBhZGRyZXNzIGZvciBTTk1QIGNvbW11bmljYXRpb24gYmV0 d2Vlbg0KU05NUDxicj4NCiZndDsgZW50aXRpZXMgYnkgdGhlIFNOTVAgbWVjaGFuaXNtIGFuZCBh cmNoaXRlY3R1cmUgd2hpY2ggZGVmaW5lZCBpbiBSRkMzNDExPGJyPg0KJmd0OyBhbmQgUkZDNTk1 MyBhbmQgb3RoZXIgU05NUCBSRkNzIChhcyBkZXBpY3RlZCBpbiB0aGUgZGlhZ3JhbSBiZWxvdyku DQpBbmQ8YnI+DQomZ3Q7IG5vdyB0aGVyZSBpcyBsaXR0bGUgcmVsYXRpb24gYmV0d2VlbiBTTk1Q IFVzYWdlIGFuZCBSRUxPQUQgYmVzaWRlcw0KdXNpbmc8YnI+DQomZ3Q7IFJFTE9BRCBjZXJ0aWZp Y2F0ZS4gU28gd2Ugc2F5ICZxdW90O1NOTVAgZW50aXRpZXMgdGFsayB0byBlYWNoIG90aGVyDQp1 c2luZyBTTk1QPGJyPg0KJmd0OyBwcm90b2NvbCBvbiBkZWRpY2F0ZWQgY29ubmVjdGlvbnMmcXVv dDs8YnI+DQo8YnI+DQpObywgaXQgc3RpbGwgZG9lcyBub3QgbWFrZSBzZW5zZS4gJm5ic3A7WW91 IHVuZGVyc3RhbmQgdGhhdCBhbiBTTk1QIGVuZ2luZQ0KY2FuIGRvPGJyPg0Kbm90aGluZyB1bnRp bCBpdCBoYXMgYmVlbiBjdXN0b21pc2VkIC0gc25tcEVuZ2luZUlELCBzbm1wVGFyZ2V0QWRkclRh YmxlLA0KZXRjIC08YnI+DQphbmQgeW91IHVzZSBSRUxPQUQgdG8gb2J0YWluIHRoYXQgaW5mb3Jt YXRpb247IEkgYXNzdW1lIHlvdSBhcmUgZmFtaWxpYXINCndpdGg8YnI+DQp0aGUgTUlCIG1vZHVs ZXMgaW50byB3aGljaCB0aGF0IGluZm9ybWF0aW9uIG11c3QgdGhlbiBiZSBwbGFjZWQgYmVmb3Jl DQphbiBlbmdpbmU8YnI+DQpjYW4gY29tbXVuaWNhdGUuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWU+PHR0PlllcywgdGhlc2UgaW5mb3JtYXRpb24gd2lsbCBiZSBwbGFj ZWQgaW50bw0KTUlCLiBGb3IgZXhhbXBsZSwgd2Ugc2F5IHdoZW4gQWdlbnQgJm5ic3A7PGJyPg0K Z2V0IHRoZSBhZGRyZXNzIG9mIE1hbmFnZXIsIGl0IHdpbGwgc3RvcmUgdGhlIGFkZHJlc3MgaW50 byBNSUIoc25tcFRhcmdldEFkZHJUYWJsZSkNCmluIHRoZSBkaWFncmFtIGluIGNoYXB0ZXIgOS48 L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NClR3byBlbmdpbmVz IGNhbiB0aGVuIGNvbW11bmljYXRlIGJ1dCBjYW5ub3QgZG8gYW55dGhpbmcgdXNlZnVsIHdpdGhv dXQNCnN1aXRhYmxlPGJyPg0KTUlCIG1vZHVsZXM7IHRoZSBJLUQgc2F5czxicj4NCiZxdW90OyBT Tk1QIHVzYWdlIGZvciBSRUxPQUQgU0hPVUxEIHByb3ZpZGUgdGhlIG1hbmFnZW1lbnQgZnVuY3Rp b25zIC4uLjxicj4NCiAmbmJzcDsgJm5ic3A7IC4uLiBtb25pdG9yaW5nIHRoZSBudW1iZXIgb2Yg dGhlIG1lc3NhZ2VzPGJyPg0KICZuYnNwOyBpbml0aWF0ZWQsIGZvcndhcmRlZCBvciBwcm9jZXNz ZWQgYnkgbm9kZXMsIHJlcG9ydGluZyBwcm9ncmFtIGZhaWx1cmU8YnI+DQogJm5ic3A7ICwgbWVz c2FnZSBmb3J3YXJkaW5nIGZhaWx1cmUgb3Igb3RoZXIgZXJyb3Igb24gbm9kZXMuJnF1b3Q7PGJy Pg0KPGJyPg0KVGhpcyBpcyBhIHR5cGljYWwgdXNhZ2UgZm9yIFNOTVAgYnV0IGlzIHF1aXRlIGlt cG9zc2libGUgdW5sZXNzIGFuZCB1bnRpbA0KYTxicj4NCnN1aXRhYmxlPGJyPg0KTUlCIG1vZHVs ZSBpcyBkZWZpbmVkLCB3aGljaCBpcyB3aGF0IGV2ZXJ5b25lIHVzaW5nIFNOTVAgZm9yIG1hbmFn ZW1lbnQ8YnI+DQp0aGVuIGRvZXMuICZuYnNwO1lvdXIgZWFybGllciByZXNwb25zZSB0byBEYXZp ZCByZWplY3RlZCB0aGUgaWRlYSBvZiBjcmVhdGluZw0KYSBNSUI8YnI+DQptb2R1bGUsIHdoaWNo IGxlYXZlcyBtZSB3aXRoIHR3byBTTk1QIGVuZ2luZXMgYWJsZSB0byB0YWxrIHRvIGVhY2ggb3Ro ZXINCmJ1dDxicj4NCmhhdmluZyBub3RoaW5nIHVzZWZ1bCB0byBzYXkuPGJyPg0KPC90dD48L2Zv bnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0PlNvcnJ5o6xvdXIgbGFzdCByZXNwb25zZSBt YXliZQ0KY29uZnVzaW5nLiBXZSBhbHNvIHRoaW5rIHdlIG5lZWQgTUlCIG1vZHVsZTwvdHQ+PC9m b250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPg0Kd2hpY2ggcmVsYXRlcyB0byBtYW5hZ2VkIG9i amVjdHMgb2YgUkVMT0FEPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx0dD4uDQo8L3R0 PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+T25seSBiZWNhdXNlIGl0 IGRvZXNuJ3QgYWZmZWN0IHRoZSBpbXBsZW1lbnRhdGlvbg0KbWVjaGFuaXNtIG9mIG1hbmFnZW1l bnQsIHNvIHdlIHBsYW4gdG8gc3R1ZHkgYW5kIGRlZmluZSBpdCBsYXRlci4gJm5ic3A7DQo8L3R0 PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5Gb3Igbm93LCB3ZSB0cnkgdG8g cmVzb2x2ZSB0aGUgZGlzY292ZXJ5IGFuZA0KY29tbXVuaWNhdGlvbiBwcm9ibGVtcyBmb3Igc25t cEVuZ2luZXMuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5BcyBvdXIgY3Vy cmVudCBkZXNpZ24gZG9lcyBub3QgcmVxdWlyZSBhIHByZWRlZmluZWQNCk1JQiAobWF5YmUgd2Ug bWlzcyBzb21lIHBhdHMpLCB3ZSBsZWF2ZSB0aGUgTUlCIGRlZmluaXRpb24gZm9yIGZ1dHVyZSBz dHVkeS48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0Pg0KJm5ic3A7PC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpUaGUgSS1EIGFsc28gc2F5czxicj4NCiZx dW90O0FzIHRyYWRpdGlvbmFsIG5ldHdvcms8YnI+DQogJm5ic3A7IG1hbmFnZW1lbnQgcHJvdG9j b2xzIChlLmcuLCBTTk1QKSBjYW5ub3QgYmUgZGlyZWN0bHkgYXBwbGllZCB0bzxicj4NCiAmbmJz cDsgUkVMT0FEIG5ldHdvcmsgbWFuYWdlbWVudCwgaXQgaXMgbmVjZXNzYXJ5IHRvIGludHJvZHVj ZSBuZXcgUkVMT0FEPGJyPg0KICZuYnNwOyB1c2FnZSBvZiBTTk1QLiZxdW90Ozxicj4NCndoaWNo IGlzIG9ubHkgdHJ1ZSBpbiB0aGUgc2Vuc2UgdGhhdCBTTk1QIGNhbm5vdCBiZSBkaXJlY3RseSBh cHBsaWVkIHRvDQphbnk8YnI+DQpuZXR3b3JrPGJyPg0KbWFuYWdlbWVudCwgdW5sZXNzIGFuZCB1 bnRpbCB0aGVyZSBpcyBhIHN1aXRhYmxlIE1JQiBtb2R1bGUuICZuYnNwO09uY2UNCnRoZXJlIGlz LDxicj4NCmFuZCB5b3UgaGF2ZSB0d28gY29tbXVuaWNhdGluZyBlbmdpbmVzICh3aGljaCB5b3Ug c2F5IHlvdSB3aWxsIGhhdmUpLCB0aGVuPGJyPg0Kb2YgY291cnNlIFNOTVAgY2FuIGJlIHVzZWQg dG8gbWFuYWdlIGFueXRoaW5nLCBpbmNsdWRpbmcgUkVMT0FELjxicj4NCjxicj4NClRvbSBQZXRj aDxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHlvdSB0aWxsIGhhdmUgcXVlc3Rpb25zLCBw bGVhc2UgdGVsbCB1cy4gVGhhbmtzITxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KJmd0OyDT yiC8/qO6cGVuZy55b25nbGluQHp0ZS5jb20uY248YnI+DQomZ3Q7IMTaIM/fo7o4MTU0Mzxicj4N CiZndDsgzeIgz9+jujAyNS01Mjg3MTU0Mzxicj4NCiZndDsgytYgu/qjujEzNzc2NjM3Mjc0PGJy Pg0KJmd0OyC0qyDV5qO6MDI1LTUyODcyMTg3PGJyPg0KJmd0OyAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS08YnI+DQomZ3Q7IEZyb206ICZsdDtwZW5nLnlvbmdsaW5AenRlLmNvbS5jbiZndDs7ICZs dDtwZW5nLnlvbmdsaW5AenRlLmNvbS5jbiZndDs8YnI+DQomZ3Q7IFRvOiAmbHQ7cDJwc2lwQGll dGYub3JnJmd0OzsgJmx0O29wc2F3Z0BpZXRmLm9yZyZndDs7ICZsdDtwMnBzaXBAaWV0Zi5vcmcm Z3Q7Ozxicj4NCiZndDsgJmx0O29wc2F3Z0BpZXRmLm9yZyZndDs8YnI+DQomZ3Q7IENjOiAmbHQ7 aGFvLnpoZW53dUB6dGUuY29tLmNuJmd0OzsgJmx0O2hhby56aGVud3VAenRlLmNvbS5jbiZndDs8 YnI+DQomZ3Q7IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjUsIDIwMTEgNDoyMyBBTTxicj4NCiZn dDs8YnI+DQomZ3Q7ICZndDsgV2UgaGF2ZSBkb25lIG1vcmUgcmVzZWFyY2ggb24gc2VjdXJpdHkg YW5kIG90aGVyIGlzc3VlcyBiYXNlZA0Kb24gRGF2aWQnczxicj4NCiZndDsgJmd0OyBjb21tZW50 cywgYW5kIHVwZGF0ZWQgb3VyIGRyYWZ0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBU aGlzIGlzIHRoZSBuZXcgdmVyc2lvbiBvZiBkcmFmdDo8YnI+DQomZ3Q7ICZndDsgaHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1wZW5nLXAycHNpcC1zbm1wLTAzLnR4dDxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBXZSB3ZWxjb21lIGFueSBjb21tZW50cyEgVGhhbmtzITxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPdXIgYW5hbHlzaXMgb2YgRGF2aWQncyBjb21tZW50cyBh cyBmb2xsb3dzKGJsdWUgdGV4dCk6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDEpIFVz ZSBTTk1QdjMgdGVybWlub2xvZ3k8YnI+DQomZ3Q7ICZndDsgQXBwYXJlbnRseSwgeW91IGNvbWUg ZnJvbSB0aGUgUkVMT0FEIHNpZGUgb2YgdGhpbmdzLCBub3QgdGhlDQpTTk1QPGJyPg0KJmd0OyAm Z3Q7IHNpZGUuPGJyPg0KJmd0OyAmZ3Q7IFlvdXIgdGV4dCBkb2Vzbid0IHVzZSB0aGUgY29tbW9u IFNOTVAgdGVybWlub2xvZ3kgZm9yIHZhcmlvdXM8YnI+DQomZ3Q7ICZndDsgU05NUC1yZWxhdGVk IHRoaW5ncy48YnI+DQomZ3Q7ICZndDsgWW91IHdpbGwgaGF2ZSBhIGJldHRlciBjaGFuY2Ugb2Yg c3VjY2VzcyBpZiB5b3UgZGVzY3JpYmUgU05NUC1yZWxhdGVkPGJyPg0KJmd0OyAmZ3Q7IHRoaW5n cyB1c2luZyB0aGUgbm9ybWFsIFNOTVB2MyB0ZXJtaW5vbG9neS48YnI+DQomZ3Q7ICZndDsgVGhp cyBpc24ndCBjcml0aWNhbDsgeW91ciBpZGVhcyBzZWVtIHJlYXNvbmFibGUsIGJ1dCBzaW5jZSB5 b3UNCmRvbid0PGJyPg0KJmd0OyAmZ3Q7IHVzZSB0aGUgc3RhbmRhcmQgdGVybWlub2xvZ3ksIHlv dSBtaWdodCBtZWFuIHNsaWdodGx5IGRpZmZlcmVudA0KdGhpbmdzPGJyPg0KJmd0OyAmZ3Q7IHRo YW4gd2hhdCBpdCB3b3VsZCBtZWFuIGlmIHlvdSB1c2VkIHRoZSBzdGFuZGFyZCB0ZXJtaW5vbG9n eS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgKEkgZG9uJ3QgaGF2ZSBhIFJFTE9BRCBi YWNrZ3JvdW5kLCBzbyBzb21lIG9mIG15IGNvbW1lbnRzIG1pZ2h0DQpzZWVtPGJyPg0KJmd0OyAm Z3Q7IHdyb25nIGJlY2F1c2UgSSBkb24ndCBrbm93IHRoZSBSRUxPQUQgY29uY2VwdHMgYW5kIHRl cm1pbm9sb2d5Lg0KTm93PGJyPg0KJmd0OyAmZ3Q7IHlvdSdsbCB1bmRlcnN0YW5kIG15IHBvaW50 IDstKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBQWUw6IFdlIGhhdmUgdXBkYXRlZCB0 aGUgZHJhZnQgdXNpbmcgU05NUCB0ZXJtaW5vbG9neS4gQXMgd2UNCmFyZSBub3Q8YnI+DQomZ3Q7 IFNOTVA8YnI+DQomZ3Q7ICZndDsgZXhwZXJ0cywgc29tZSB0ZXJtaW5vbG9neSBtYXkgbm90IGJl IGFjY3VyYXRlLiBXZSB3aWxsIHRyeSB0bw0KaW1wcm92ZTxicj4NCiZndDsgdGhpczxicj4NCiZn dDsgJmd0OyBvdmVyIHRpbWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgWW91IGFyZSBpbmRlZWQgdXNp bmcgU05NUCB0ZXJtaW5vbG9neSwgYnV0IEkgc3RydWdnbGUgdG8gc2VlIGhvdyBpdHMNCnVzYWdl PGJyPg0KJmd0OyBpczxicj4NCiZndDsgdGhlIHNhbWUgYXMgaW4gUkZDMzQxMS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBSRUxPQUQgZGVmaW5lcyBhIG1lc3NhZ2luZyBuZXR3b3JrLCBvbiB0b3Agb2Yg d2hpY2ggcnVuIGFwcGxpY2F0aW9ucyw8YnI+DQomZ3Q7IHdoaWNoPGJyPg0KJmd0OyBSRUxPQUQg Y2FsbHMgVXNhZ2VzLCBzbyB3aGVuIHlvdSBkZWZpbmUgYW4gU05NUCBVc2FnZSwgeW91IHdvdWxk IGFwcGVhcg0KdG88YnI+DQomZ3Q7IGJlPGJyPg0KJmd0OyBkaXNjYXJkaW5nIG1vc3Qgb2YgYW4g QXJjaGl0ZWN0dXJlIGZvciBTTk1QIGFzIGRlZmluZWQgaW4gUkZDMzQxMSwNCnBlcmhhcHM8YnI+ DQomZ3Q7IHByb3ZpZGluZyBpbnN0ZWFkIGEgZ2F0ZXdheSBmb3IgZnVuY3Rpb25hbGl0eSBzdWNo IGFzIHRoYXQgc3BlY2lmaWVkDQppbjxicj4NCiZndDsgUkZDMzQxNDs8YnI+DQomZ3Q7IG9yIHBl cmhhcHMgbm90LCBJIGRvIG5vdCBmaW5kIHRoZSBJLUQgY2xlYXIgb24gdGhpcy4gJm5ic3A7VGh1 cyB5b3UNCmhhdmU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBcHBsaWNhdGlvbjxicj4NCiZn dDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICst LS0tLS0tKyAmbmJzcDsrLS0tLS0tLSsNCiZuYnNwOystLS0tLS0tKzxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBTSVAgJm5ic3A7IHwgJm5ic3A7 fCBYTVBQDQombmJzcDt8ICZuYnNwO3wgU05NUCAmbmJzcDt8ICZuYnNwOy4uLjxicj4NCiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBVc2FnZSB8ICZuYnNw O3wgVXNhZ2UNCnwgJm5ic3A7fCBVc2FnZSB8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArLS0tLS0tLSsgJm5ic3A7Ky0tLS0tLS0rDQombmJzcDsr LS0tLS0tLSs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNZXNzYWdpbmcgQVBJPGJy Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgUkVMT0FEPGJyPg0KJmd0Ozxi cj4NCiZndDsgYnV0IGVsc2V3aGVyZSB5b3Ugc2F5PGJyPg0KJmd0OyAnIFNOTVAgZW50aXRpZXMg dGFsayB0byBlYWNoIG90aGVyIHVzaW5nIFNOTVAgcHJvdG9jb2wgb24gZGVkaWNhdGVkPGJyPg0K Jmd0OyBjb25uZWN0aW9ucyc8YnI+DQomZ3Q7IHdoaWNoIGlzIHJhdGhlciBkaWZmZXJlbnQuPGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhlIEktRCByZWFkcyBtb3JlIGxpa2UgYSB3aXNoIGxpc3Qgb2Yg cmVxdWlyZW1lbnRzLCB0aGFuIGFuIG92ZXJ2aWV3LDxicj4NCiZndDsgYXJjaGl0ZWN0dXJlIG9y IGZyYW1ld29yay4gJm5ic3A7T3IgcGVyaGFwcyBpdCBpcyBhbGwgYmV5b25kIG1lOi0oPGJyPg0K Jmd0Ozxicj4NCiZndDsgVG9tIFBldGNoPGJyPg0KJmd0Ozxicj4NCiZndDsgJmx0O3NuaXAmZ3Q7 PGJyPg0KPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1 c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5i c3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0015A02C48257937_=-- From peng.yonglin@zte.com.cn Thu Oct 27 22:49:34 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A2E21F861E; Thu, 27 Oct 2011 22:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.72 X-Spam-Level: X-Spam-Status: No, score=-90.72 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOoIqFjI56Pi; Thu, 27 Oct 2011 22:49:33 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6290621F8610; Thu, 27 Oct 2011 22:49:32 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466213465113155; Fri, 28 Oct 2011 13:40:13 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 60802.5408727031; Fri, 28 Oct 2011 13:49:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9S5nJFZ066401; Fri, 28 Oct 2011 13:49:19 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) In-Reply-To: <20111027151531.GD40631@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Fri, 28 Oct 2011 13:49:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-28 13:49:20, Serialize complete at 2011-10-28 13:49:20 Content-Type: multipart/alternative; boundary="=_alternative 001FF30A48257937_=" X-MAIL: mse01.zte.com.cn p9S5nJFZ066401 Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org Subject: [OPSAWG] =?gb2312?b?tPC4tDogUmU6ICBBbiBTTk1QIFVzYWdlIGZvciBSRUxP?= =?gb2312?b?QUQ=?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 05:49:34 -0000 This is a multipart message in MIME format. --=_alternative 001FF30A48257937_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHJlbWluZGVyIHZlcnkgbXVjaC4NCkl0IGlzbid0IG5lZWRlZCB0byBh ZGQgbmV3IHByb3RvY29sIG9wZXJhdGlvbnMgb3IgbW9kaWZ5IHRoZW0gaW4gb3VyIA0KZHJhZnQs IGFuZCB3ZSB1c2Ugb25seSBjdXJyZW50IHByb3RvY29sIG9wZXJhdGlvbnMuIA0KVGhlIGRyYXQg aW50cm9kdWNlcyBtYWlubHkgdGhlIHByZXBhcmF0aW9uIHdvcmsgYmVmb3JlIHNlbmRpbmcgcHJv dG9jb2wgDQpvcGVyYXRpb25zLg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KRW1haWyjuiAgICAgICAgcGVuZy55b25nbGluQHp0ZS5jb20uY24NClRFTKO6ICAg ICAgICAgIDAyNS01Mjg3MTU0Mw0KTW9iaWxlo7ogICAgICAgMTM3NzY2MzcyNzQNCkZheKO6ICAg ICAgICAgIDAyNS01Mjg3MjE4Nw0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqDQoNCg0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZT4gDQoyMDExLTEwLTI3IDIzOjE1DQrH67TwuLQguPgNCkp1ZXJnZW4gU2No b2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KDQoNCsrV vP7Iyw0KcGVuZy55b25nbGluQHp0ZS5jb20uY24NCrOty80NCmhhby56aGVud3VAenRlLmNvbS5j biwgb3BzYXdnQGlldGYub3JnLCBwMnBzaXBAaWV0Zi5vcmcNCtb3zOINClJlOiBbT1BTQVdHXSBB biBTTk1QIFVzYWdlIGZvciBSRUxPQUQNCg0KDQoNCg0KDQoNCk9uIFRodSwgT2N0IDI3LCAyMDEx IGF0IDAxOjQ4OjQzUE0gKzAyMDAsIFJvbWFzY2FudSwgRGFuIChEYW4pIHdyb3RlOg0KPiBKdXN0 IHRvIG1ha2Ugc2hhcnBlciB0aGUgc3RhdGVtZW50cyBtYWRlIGJ5IFRvbS4gSW4gdGhlIFNOTVAg DQphcmNoaXRlY3R1cmUgaW4gb3JkZXIgZm9yIHR3byBlbnRpdGllcyB0byBleGNoYW5nZSBtYW5h Z2VtZW50IGluZm9ybWF0aW9uIA0Kd2UgaGF2ZSBhIHByb3RvY29sIChiYXNpYyBwcmltaXRpdmVz IHRvIGZldGNoIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiwgc2V0IA0KdmFsdWVzIG9mIHBpZWNlcyBv ZiBpbmZvcm1hdGlvbiBvciBzZW5kIG5vdGlmaWNhdGlvbnMgcmVsYXRlZCB0byB0aGUgDQpwaWVj ZXMgb2YgaW5mb3JtYXRpb24pIGFuZCBhIGRhdGEgbW9kZWwgKGUuZy4gTUlCIG1vZGVsKSBleHBy ZXNzZWQgaW4gYSANCkRhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UgKGUuZy4gU01JKS4gVGhlIHByb3Bv c2VkIHRleHQgdGFsa3MgYWJvdXQgdGhlIA0KcHJvdG9jb2wgKFNOTVApIGJ1dCBub3QgYWJvdXQg dGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCAoZGF0YSBtb2RlbCkuIFRoaXMgDQppcyBvZiBsaXR0 bGUgaGVscC4gDQo+IA0KDQpBbmQgaXQgbWlnaHQgaGVscCB0byBub3RpY2UgdGhhdCB0aGUgc2V0 IG9mIFNOTVAncyBwcm90b2NvbCBvcGVyYXRpb25zDQpoYXMgYmVlbiBzdGF0aWMgZm9yIGFsbW9z dCAyMCB5ZWFycyBhbmQgYW55IGF0dGVtcHRzIHRvIGFkZCBhZGRpdGlvbmFsDQpwcm90b2NvbCBv cGVyYXRpb25zIGR1cmluZyB0aGlzIHBlcmlvZCBmYWlsZWQgdG8gZ2V0IHN1ZmZpY2llbnQgc3Vw cG9ydC4NClNvIGlmIHlvdXIgaWRlYSBpcyB0byBhZGQgbmV3IG9wZXJhdGlvbnMsIHlvdSBsaWtl bHkgd2lsbCBoYXZlIGEgaGFyZA0KdGltZSBnZXR0aW5nIHRoaXMgYW55d2hlcmUuDQoNCi9qcw0K DQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkg QnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5n IDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAg ICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCg0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90 aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBj b25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBv ZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2Fu bmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 001FF30A48257937_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciByZW1p bmRlciB2ZXJ5IG11Y2guPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5JdCBpc24ndCBuZWVkZWQgdG8gYWRkIG5ldyBwcm90b2NvbA0Kb3BlcmF0aW9ucyBvciBtb2Rp ZnkgdGhlbSBpbiBvdXIgZHJhZnQsIGFuZCB3ZSB1c2Ugb25seSBjdXJyZW50IHByb3RvY29sDQpv cGVyYXRpb25zLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRo ZSBkcmF0IGludHJvZHVjZXMgbWFpbmx5IHRoZSBwcmVwYXJhdGlvbg0Kd29yayBiZWZvcmUgc2Vu ZGluZyBwcm90b2NvbCBvcGVyYXRpb25zLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqPGJyPg0KRW1haWyjuiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwZW5nLnlvbmds aW5AenRlLmNvbS5jbjxicj4NClRFTKO6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDswMjUtNTI4NzE1NDM8YnI+DQpNb2JpbGWjuiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxMzc3NjYz NzI3NDxicj4NCkZheKO6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMjUtNTI4 NzIxODc8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SnVlcmdlbiBT Y2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7 PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMTAt MjcgMjM6MTU8L2ZvbnQ+DQo8dGFibGUgYm9yZGVyPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgYmdj b2xvcj13aGl0ZT4NCjxkaXYgYWxpZ249Y2VudGVyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7H67TwuLQguPg8YnI+DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8L2ZvbnQ+PC9kaXY+PC90YWJsZT4NCjxicj4N Cjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5wZW5nLnlv bmdsaW5AenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aGFvLnpoZW53dUB6dGUuY29tLmNu LCBvcHNhd2dAaWV0Zi5vcmcsDQpwMnBzaXBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBbT1BTQVdHXSBBbiBTTk1QIFVzYWdlIGZvciBSRUxPQUQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pk9uIFRodSwgT2N0IDI3LCAyMDEx IGF0IDAxOjQ4OjQzUE0gKzAyMDAsIFJvbWFzY2FudSwNCkRhbiAoRGFuKSB3cm90ZTo8YnI+DQom Z3Q7IEp1c3QgdG8gbWFrZSBzaGFycGVyIHRoZSBzdGF0ZW1lbnRzIG1hZGUgYnkgVG9tLiBJbiB0 aGUgU05NUCBhcmNoaXRlY3R1cmUNCmluIG9yZGVyIGZvciB0d28gZW50aXRpZXMgdG8gZXhjaGFu Z2UgbWFuYWdlbWVudCBpbmZvcm1hdGlvbiB3ZSBoYXZlIGENCnByb3RvY29sIChiYXNpYyBwcmlt aXRpdmVzIHRvIGZldGNoIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiwgc2V0IHZhbHVlcyBvZg0KcGll Y2VzIG9mIGluZm9ybWF0aW9uIG9yIHNlbmQgbm90aWZpY2F0aW9ucyByZWxhdGVkIHRvIHRoZSBw aWVjZXMgb2YgaW5mb3JtYXRpb24pDQphbmQgYSBkYXRhIG1vZGVsIChlLmcuIE1JQiBtb2RlbCkg ZXhwcmVzc2VkIGluIGEgRGF0YSBNb2RlbGluZyBMYW5ndWFnZQ0KKGUuZy4gU01JKS4gVGhlIHBy b3Bvc2VkIHRleHQgdGFsa3MgYWJvdXQgdGhlIHByb3RvY29sIChTTk1QKSBidXQgbm90IGFib3V0 DQp0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIChkYXRhIG1vZGVsKS4gVGhpcyBpcyBvZiBsaXR0 bGUgaGVscC4gPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQpBbmQgaXQgbWlnaHQgaGVscCB0byBub3Rp Y2UgdGhhdCB0aGUgc2V0IG9mIFNOTVAncyBwcm90b2NvbCBvcGVyYXRpb25zPGJyPg0KaGFzIGJl ZW4gc3RhdGljIGZvciBhbG1vc3QgMjAgeWVhcnMgYW5kIGFueSBhdHRlbXB0cyB0byBhZGQgYWRk aXRpb25hbDxicj4NCnByb3RvY29sIG9wZXJhdGlvbnMgZHVyaW5nIHRoaXMgcGVyaW9kIGZhaWxl ZCB0byBnZXQgc3VmZmljaWVudCBzdXBwb3J0Ljxicj4NClNvIGlmIHlvdXIgaWRlYSBpcyB0byBh ZGQgbmV3IG9wZXJhdGlvbnMsIHlvdSBsaWtlbHkgd2lsbCBoYXZlIGEgaGFyZDxicj4NCnRpbWUg Z2V0dGluZyB0aGlzIGFueXdoZXJlLjxicj4NCjxicj4NCi9qczxicj4NCjxicj4NCi0tIDxicj4N Ckp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEphY29icyBVbml2ZXJzaXR5DQpCcmVtZW4gZ0dtYkg8YnI+DQpQaG9uZTogKzQ5IDQyMSAyMDAg MzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2FtcHVzIFJpbmcgMSwgMjg3NTkNCkJy ZW1lbiwgR2VybWFueTxicj4NCkZheDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyZn dDs8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0lu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3Jt YXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMm bmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3Mm bmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5i c3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5i c3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNw O3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhp cyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFp bCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRo Jm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRl ZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5i c3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hh dmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3Im bmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2Vk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMm bmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtz eXN0ZW0uDQo8L3ByZT4= --=_alternative 001FF30A48257937_=-- From lizhong.jin@zte.com.cn Fri Oct 28 00:16:48 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDD021F84D4; Fri, 28 Oct 2011 00:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbLtDqjhMnZq; Fri, 28 Oct 2011 00:16:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1960221F89BA; Fri, 28 Oct 2011 00:16:46 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466212260588612; Fri, 28 Oct 2011 15:08:00 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 60802.3864543671; Fri, 28 Oct 2011 15:16:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p9S7GUh5084576; Fri, 28 Oct 2011 15:16:30 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: l3vpn@ietf.org, opsawg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Fri, 28 Oct 2011 15:15:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-28 15:16:32, Serialize complete at 2011-10-28 15:16:32 Content-Type: multipart/alternative; boundary="=_alternative 0027F6C148257937_=" X-MAIL: mse01.zte.com.cn p9S7GUh5084576 X-Mailman-Approved-At: Fri, 28 Oct 2011 09:07:06 -0700 Subject: Re: [OPSAWG] Fwd: L3VPN automatic interconnection for VPN4DC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 07:16:48 -0000 This is a multipart message in MIME format. --=_alternative 0027F6C148257937_= Content-Type: text/plain; charset="US-ASCII" Hi All, This draft enables L3VPN VRF-to-VRF interconnection to be automatically provided by one PE, and is expect to reduce the VPN4DC provisioning time. Would appreciate if you could review. And any comments are welcome! Thanks Lizhong > ------------------------------ > > Message: 2 > Date: Mon, 24 Oct 2011 18:51:37 -0400 > From: Bhumip Khasnabish > To: opsawg@ietf.org, l3vpn@ietf.org > Subject: Fwd: L3VPN automatical interconnection for VPN4DC > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : L3VPN automatical interconnection for VPN4DC > Author(s) : Lizhong Jin > Ning So > Bhumip Khasnabish > Bo Wu > Filename : draft-jin-l3vpn-vpn4dc-interconnect-00.txt > Pages : 7 > Date : 2011-10-24 > > VPN4DC provides VPN oriented datacenter service to customer through > L3VPN which is consisted of (private) L3VPN in datacenter and network > provider's L3VPN over wide geographical area. If we considering the > two L3VPN in two different AS, [RFC4364] providers three options to > achieve L3VPN inter-AS connection. Both option A and B could be used > to connect L3VPN in VPN4DC. This draft discusses a novel method for > implementing option A, to automatically configure the VRF interface > in order to interconnect the two segments of the end-to-end L3VPN. > This L3VPN interconnection automation mechanism is expected to > significantly reduce the VPN oriented inter-connection/service > provisioning time. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/l3vpn/attachments/20111024/e2f1cb0d/attachment.htm> > > ------------------------------ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0027F6C148257937_= Content-Type: text/html; charset="US-ASCII"
Hi All,
This draft enables L3VPN VRF-to-VRF interconnection to be automatically provided by one PE, and is expect to reduce the VPN4DC provisioning time. Would appreciate if you could review. And any comments are welcome!

Thanks
Lizhong


> ------------------------------
>
> Message: 2
> Date: Mon, 24 Oct 2011 18:51:37 -0400
> From: Bhumip Khasnabish <vumip1@gmail.com>
> To: opsawg@ietf.org, l3vpn@ietf.org
> Subject: Fwd: L3VPN automatical interconnection for VPN4DC
> Message-ID:
>    <CANtnpwgH9y3QZ2e1N84H62QpnHB3GcXhsTJEqVvU9JzmQjhy+w@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title           : L3VPN automatical interconnection for VPN4DC
> Author(s)       : Lizhong Jin
>                           Ning So
>                           Bhumip Khasnabish
>                           Bo Wu
> Filename        : draft-jin-l3vpn-vpn4dc-interconnect-00.txt
> Pages           : 7
> Date            : 2011-10-24
>
>    VPN4DC provides VPN oriented datacenter service to customer through
>    L3VPN which is consisted of (private) L3VPN in datacenter and network
>    provider&#39;s L3VPN over wide geographical area.  If we considering the
>    two L3VPN in two different AS, [RFC4364] providers three options to
>    achieve L3VPN inter-AS connection.  Both option A and B could be used
>    to connect L3VPN in VPN4DC.  This draft discusses a novel method for
>    implementing option A, to automatically configure the VRF interface
>    in order to interconnect the two segments of the end-to-end L3VPN.
>    This L3VPN interconnection automation mechanism is expected to
>    significantly reduce the VPN oriented inter-connection/service
>    provisioning time.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-jin-l3vpn-vpn4dc-interconnect-00.txt
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/l3vpn/attachments/20111024/e2f1cb0d/attachment.htm>
>
> ------------------------------
> 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0027F6C148257937_=-- From internet-drafts@ietf.org Mon Oct 31 10:19:51 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D412521F87C9; Mon, 31 Oct 2011 10:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmIO2U3zJ13b; Mon, 31 Oct 2011 10:19:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A0D21F8562; Mon, 31 Oct 2011 10:19:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031171936.24412.86765.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 10:19:36 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-management-stds-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:19:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Workin= g Group Working Group of the IETF. Title : An Overview of the IETF Network Management Standards Author(s) : Mehmet Ersue Benoit Claise Filename : draft-ietf-opsawg-management-stds-02.txt Pages : 74 Date : 2011-10-31 This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-management-stds-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsawg-management-stds-02.txt From internet-drafts@ietf.org Mon Oct 31 13:41:43 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCBB11E8253; Mon, 31 Oct 2011 13:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e0qNWaIfwLS; Mon, 31 Oct 2011 13:41:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A7811E8192; Mon, 31 Oct 2011 13:41:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031204142.8319.24518.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 13:41:42 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-automated-network-configuration-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:41:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Workin= g Group Working Group of the IETF. Title : Problem Statement for the Automated Configuration of Lar= ge IP Networks Author(s) : Tina Tsou Juergen Schoenwaelder Yang Shi Tom Taylor Guoliang Yang Filename : draft-ietf-opsawg-automated-network-configuration-02.txt Pages : 23 Date : 2011-10-31 This memo discusses the steps required to bring a large number of devices into service in IP networks in an automated fashion. The goal of this document is to list known solutions where they exist and to identify gaps that require further specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-automated-network-con= figuration-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsawg-automated-network-conf= iguration-02.txt