From nobody Sun May 3 23:46:20 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F4D1ACD87 for ; Sun, 3 May 2015 23:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxLab-Ro2bQn for ; Sun, 3 May 2015 23:46:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F211ACD77 for ; Sun, 3 May 2015 23:46:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVP58876; Mon, 04 May 2015 06:46:15 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 May 2015 07:46:14 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.68]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Mon, 4 May 2015 14:46:04 +0800 From: "Yemin (Amy)" To: Lou Berger , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Solicit comments on availability WG drafts Thread-Index: AdB9kkrQFJT/TuIfQGC5W8y27F5XTgFac7+AAMfOkPA= Date: Mon, 4 May 2015 06:46:03 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F8F405B80@szxema506-mbs.china.huawei.com> References: <9C5FD3EFA72E1740A3D41BADDE0B461F8F404DA3@szxema506-mbs.china.huawei.com> <55421C8F.6020104@labn.net> In-Reply-To: <55421C8F.6020104@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.33.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Longhao Subject: Re: [CCAMP] Solicit comments on availability WG drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 06:46:19 -0000 Hi Lou, Thanks for your comments. Please see my reply below. For OSPF draft, how about text like this: "When the Switching Capability field is PSC-1/LSC (other Switching Capabili= ty could also be possible), the Switching Capability specific information f= ield MAY include one or more ISCD Availability sub-TLV(s)." The PSC-2/3/4 are removed to align with RFC7074. For RSVP draft, the technology specific part in the section 1 will be moved= to the appendix. The rest part is generic without the technology specific = information, I think. =20 And we need input on optical usage. Once we got it, it may goes to the appe= ndix section. Or a separated draft including all the use case might be bett= er? BR, Amy -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, April 30, 2015 8:14 PM To: Yemin (Amy); CCAMP (ccamp@ietf.org) Cc: Longhao; Giovanni Martinelli (giomarti) Subject: Re: [CCAMP] Solicit comments on availability WG drafts Hi Amy, If memory serves this dates back to IETF 90. It would seem to me that = the authors could take a pass at suggesting how to generalize or ask the pe= rson who proposed it make a proposal. It doesn't look too hard: For the OSPF draft: I think you just need to change the 1st line of 3.2 and drop restrictio= n on types. (BTW I don't think you want to reference deprecated types in ge= neral, see RFC7074.) For the RSVP draft: I think separating out the generic definition of the function and requi= red information from the technology specifics and allowing form multiple te= chnologies , will go a long (if not all the) way to making the solution gen= eric. Having a second use technology, e.g., optical, defined would be help= ful to ensure that the split is right. Lou On 4/23/2015 2:54 AM, Yemin (Amy) wrote: > > Dear CCAMPers, > > =20 > > We would like to solicit comments on the two availability WG drafts: > > http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-ava > ilability/ > > http://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-ext > ension/ > > =20 > > There were some comments to generalize the draft to optical area. > However, how to generalize is still missing. > > We are looking forward to get more comments on the possible=20 > generalization. > > Do you think it's worthy to apply the drafts to other area, e.g.,=20 > optical? If so, how to generalize? > > =20 > > BR, > > Amy (on behalf of the co-authors) > > =20 > > ********************************************************************** > ***************** This e-mail and its attachments contain confidential=20 > information from HUAWEI, which is intended only for the person or=20 > entity whose address is listed above. Any use of the information=20 > contained herein in any way (including, but not limited to, total or=20 > partial disclosure, reproduction, or dissemination) by persons other=20 > than the intended > recipient(s) is prohibited. If you receive this e-mail in error,=20 > please notify the sender by phone or email immediately and delete it! > ********************************************************************** > ***************** > > =20 > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From nobody Tue May 5 11:58:07 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008C01ACCEC for ; Tue, 5 May 2015 11:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.633 X-Spam-Level: X-Spam-Status: No, score=0.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_WM0t2MMjiB for ; Tue, 5 May 2015 11:58:04 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id A484C1A873D for ; Tue, 5 May 2015 11:58:04 -0700 (PDT) Received: (qmail 7364 invoked by uid 0); 5 May 2015 18:58:04 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 5 May 2015 18:58:04 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id QQxz1q00N2SSUrH01Qy2cP; Tue, 05 May 2015 18:58:02 -0600 X-Authority-Analysis: v=2.1 cv=boDfWiqi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=SY9aFQKHIdAA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=xedkMAyscRro3ChjWI0A:9 a=eSnav06PsxSjaq06:21 a=Zj0s1s7hnjS-_CjV:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=1d5OXrS+6JF+6/2vk3YBtrd/TLYnO62QuhLSfBQU1ls=; b=U65v+7cEX0vU8CgIw8BEnLmxzF1Fj40+AyliVmS5yMTRAHped0V5YL0tbEyX99x9ugMgq5wdyGYuCTgpqu1Mfk/2rnWirSkMXe0AT9Lj6zRN/+U/VWH4ugESMrgPOjn5; Received: from box313.bluehost.com ([69.89.31.113]:50483 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Ypi2a-0004iJ-VV; Tue, 05 May 2015 12:58:01 -0600 Message-ID: <554912AE.3090402@labn.net> Date: Tue, 05 May 2015 14:57:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Yemin (Amy)" , "CCAMP (ccamp@ietf.org)" References: <9C5FD3EFA72E1740A3D41BADDE0B461F8F404DA3@szxema506-mbs.china.huawei.com> <55421C8F.6020104@labn.net> <9C5FD3EFA72E1740A3D41BADDE0B461F8F405B80@szxema506-mbs.china.huawei.com> In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461F8F405B80@szxema506-mbs.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Longhao Subject: Re: [CCAMP] Solicit comments on availability WG drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:58:06 -0000 Amy, On 5/4/2015 2:46 AM, Yemin (Amy) wrote: > Hi Lou, > > Thanks for your comments. Please see my reply below. > > For OSPF draft, how about text like this: > "When the Switching Capability field is PSC-1/LSC (other Switching Capability could also be possible), the Switching Capability specific information field MAY include one or more ISCD Availability sub-TLV(s)." > The PSC-2/3/4 are removed to align with RFC7074. Why not just start with "The Switching Capability specific information field MAY ... > For RSVP draft, the technology specific part in the section 1 will be moved to the appendix. The rest part is generic without the technology specific information, I think. > And we need input on optical usage. Once we got it, it may goes to the appendix section. Or a separated draft including all the use case might be better? I think separate generic and technology specific sections make sense. I'm not so sure about putting the latter part in appendices, but this can be revisited once the text is there. Thanks, Lou > > BR, > Amy > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, April 30, 2015 8:14 PM > To: Yemin (Amy); CCAMP (ccamp@ietf.org) > Cc: Longhao; Giovanni Martinelli (giomarti) > Subject: Re: [CCAMP] Solicit comments on availability WG drafts > > Hi Amy, > If memory serves this dates back to IETF 90. It would seem to me that the authors could take a pass at suggesting how to generalize or ask the person who proposed it make a proposal. It doesn't look too hard: > For the OSPF draft: > I think you just need to change the 1st line of 3.2 and drop restriction on types. (BTW I don't think you want to reference deprecated types in general, see RFC7074.) > > For the RSVP draft: > I think separating out the generic definition of the function and required information from the technology specifics and allowing form multiple technologies , will go a long (if not all the) way to making the solution generic. Having a second use technology, e.g., optical, defined would be helpful to ensure that the split is right. > > Lou > > On 4/23/2015 2:54 AM, Yemin (Amy) wrote: >> Dear CCAMPers, >> >> >> >> We would like to solicit comments on the two availability WG drafts: >> >> http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-ava >> ilability/ >> >> http://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-ext >> ension/ >> >> >> >> There were some comments to generalize the draft to optical area. >> However, how to generalize is still missing. >> >> We are looking forward to get more comments on the possible >> generalization. >> >> Do you think it's worthy to apply the drafts to other area, e.g., >> optical? If so, how to generalize? >> >> >> >> BR, >> >> Amy (on behalf of the co-authors) >> >> >> >> ********************************************************************** >> ***************** This e-mail and its attachments contain confidential >> information from HUAWEI, which is intended only for the person or >> entity whose address is listed above. Any use of the information >> contained herein in any way (including, but not limited to, total or >> partial disclosure, reproduction, or dissemination) by persons other >> than the intended >> recipient(s) is prohibited. If you receive this e-mail in error, >> please notify the sender by phone or email immediately and delete it! >> ********************************************************************** >> ***************** >> >> >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > From nobody Tue May 5 14:52:57 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA601A7009; Tue, 5 May 2015 14:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlNZyidqLTCW; Tue, 5 May 2015 14:52:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B69D1A1C04; Tue, 5 May 2015 14:52:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150505215253.10316.35866.idtracker@ietfa.amsl.com> Date: Tue, 05 May 2015 14:52:53 -0700 Archived-At: Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:52:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Signaling Extensions for Wavelength Switched Optical Networks Authors : Greg M. Bernstein Sugang Xu Young Lee Giovanni Martinelli Hiroaki Harai Filename : draft-ietf-ccamp-wson-signaling-11.txt Pages : 16 Date : 2015-05-05 Abstract: This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSON). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with choice in distributed wavelength assignment algorithms. This draft updates RFC 6205. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-wson-signaling-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 5 19:58:55 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D341ACDE6 for ; Tue, 5 May 2015 19:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZaT7DRFU7N3 for ; Tue, 5 May 2015 19:58:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F281ACE45 for ; Tue, 5 May 2015 19:58:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSE46730; Wed, 06 May 2015 02:58:50 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 May 2015 03:58:49 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.68]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 6 May 2015 10:58:38 +0800 From: "Yemin (Amy)" To: Lou Berger , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] Solicit comments on availability WG drafts Thread-Index: AdB9kkrQFJT/TuIfQGC5W8y27F5XTgFac7+AAMfOkPAAQb/2AAAhHt4w Date: Wed, 6 May 2015 02:58:37 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F8F4060BC@szxema506-mbs.china.huawei.com> References: <9C5FD3EFA72E1740A3D41BADDE0B461F8F404DA3@szxema506-mbs.china.huawei.com> <55421C8F.6020104@labn.net> <9C5FD3EFA72E1740A3D41BADDE0B461F8F405B80@szxema506-mbs.china.huawei.com> <554912AE.3090402@labn.net> In-Reply-To: <554912AE.3090402@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.33.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Longhao Subject: Re: [CCAMP] Solicit comments on availability WG drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 02:58:54 -0000 Hi Lou, Please see reply inline.=20 BR, Amy -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, May 06, 2015 2:58 AM To: Yemin (Amy); CCAMP (ccamp@ietf.org) Cc: Longhao; Giovanni Martinelli (giomarti) Subject: Re: [CCAMP] Solicit comments on availability WG drafts Amy, =20 On 5/4/2015 2:46 AM, Yemin (Amy) wrote: > Hi Lou, > > Thanks for your comments. Please see my reply below. > > For OSPF draft, how about text like this: > "When the Switching Capability field is PSC-1/LSC (other Switching Capabi= lity could also be possible), the Switching Capability specific information= field MAY include one or more ISCD Availability sub-TLV(s)." > The PSC-2/3/4 are removed to align with RFC7074. Why not just start with "The Switching Capability specific information fiel= d MAY ... [Amy] Good idea. Will update the text. > For RSVP draft, the technology specific part in the section 1 will be mov= ed to the appendix. The rest part is generic without the technology specifi= c information, I think. =20 > And we need input on optical usage. Once we got it, it may goes to the ap= pendix section. Or a separated draft including all the use case might be be= tter? I think separate generic and technology specific sections make sense.=20 I'm not so sure about putting the latter part in appendices, but this can b= e revisited once the text is there. [Amy]OK. We will wait the text and make the decision.=20 Thanks, Lou=20 > > BR, > Amy > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, April 30, 2015 8:14 PM > To: Yemin (Amy); CCAMP (ccamp@ietf.org) > Cc: Longhao; Giovanni Martinelli (giomarti) > Subject: Re: [CCAMP] Solicit comments on availability WG drafts > > Hi Amy, > If memory serves this dates back to IETF 90. It would seem to me tha= t the authors could take a pass at suggesting how to generalize or ask the = person who proposed it make a proposal. It doesn't look too hard: > For the OSPF draft: > I think you just need to change the 1st line of 3.2 and drop=20 > restriction on types. (BTW I don't think you want to reference=20 > deprecated types in general, see RFC7074.) > > For the RSVP draft: > I think separating out the generic definition of the function and req= uired information from the technology specifics and allowing form multiple = technologies , will go a long (if not all the) way to making the solution g= eneric. Having a second use technology, e.g., optical, defined would be he= lpful to ensure that the split is right. > > Lou > > On 4/23/2015 2:54 AM, Yemin (Amy) wrote: >> Dear CCAMPers, >> >> =20 >> >> We would like to solicit comments on the two availability WG drafts: >> >> http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-av >> a >> ilability/ >> >> http://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-ex >> t >> ension/ >> >> =20 >> >> There were some comments to generalize the draft to optical area. >> However, how to generalize is still missing. >> >> We are looking forward to get more comments on the possible=20 >> generalization. >> >> Do you think it's worthy to apply the drafts to other area, e.g.,=20 >> optical? If so, how to generalize? >> >> =20 >> >> BR, >> >> Amy (on behalf of the co-authors) >> >> =20 >> >> ********************************************************************* >> * >> ***************** This e-mail and its attachments contain=20 >> confidential information from HUAWEI, which is intended only for the=20 >> person or entity whose address is listed above. Any use of the=20 >> information contained herein in any way (including, but not limited=20 >> to, total or partial disclosure, reproduction, or dissemination) by=20 >> persons other than the intended >> recipient(s) is prohibited. If you receive this e-mail in error,=20 >> please notify the sender by phone or email immediately and delete it! >> ********************************************************************* >> * >> ***************** >> >> =20 >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > From nobody Mon May 11 06:04:16 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC991A6ED9 for ; Mon, 11 May 2015 06:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi6xcS3zC183 for ; Mon, 11 May 2015 06:04:12 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 690D71A1B44 for ; Mon, 11 May 2015 06:04:12 -0700 (PDT) Received: (qmail 3175 invoked by uid 0); 11 May 2015 13:04:05 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 11 May 2015 13:04:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id Sd3y1q0132SSUrH01d42tg; Mon, 11 May 2015 07:04:03 -0600 X-Authority-Analysis: v=2.1 cv=FPmImYYs c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=SY9aFQKHIdAA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=h1PgugrvaO0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=gZbpxnkM3yUA:10 a=48vgC7mUAAAA:8 a=kB7jUPQ1TG9bV7MhZkAA:9 a=pILNOxqGKmIA:10 a=nTHCoUExaRkA:10 a=t9MFvKAEumoA:10 a=at5CUUSg4DeaiKhg3NwA:9 a=_qn7nlDPDaC11pYC:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=10gK9RwAGSBj2+cwRF1yafWm3/6mXWEsdoyYdAk3zSg=; b=xRyqEtnq717Rgpe+BgqdkfghPdw2ou+iY07Wg0mu1r+qA5WxEpVWeZfcvhntHu5wJMhVCDcjwobwwyF8QR84leTwRvQZAEG3xcKrfrg+xXu6faqpzMNfZ7AjKREw4j/8; Received: from box313.bluehost.com ([69.89.31.113]:40996 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YrnNI-0000uG-Oi; Mon, 11 May 2015 07:04:00 -0600 Message-ID: <5550A8BC.4090005@labn.net> Date: Mon, 11 May 2015 09:03:56 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "CCAMP (ccamp@ietf.org)" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------000201040701020807040607" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 13:04:14 -0000 This is a multi-part message in MIME format. --------------000201040701020807040607 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit All, Per below, I've been asked to call consensus on this, but there haven't yet been any comments received during the LC period -- which ends today. So it's not too late to voice your opinion. If you can, please review the latest rev of the document and comment. Positive comments, e.g., "I've reviewed the latest version of this document and believe it is ready for publication", are welcome! This would be helpful, even from authors. (Just saying "support" without review doesn't really serve the purpose.) Thanks, Lou -- as consensus caller "stuckee" PS I have reviewed this rev of the document and believe it is ready for publication. On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote: > > Working group, > > > > this starts a two weeks working group last call on > draft-ietf-ccamp-flexi-grid-fwk-03. > > The last call end on Monday May 11^th . Please send you comments to > the CCAMP mailing list. > > > > All the IPR declarations from authors and contributors have been > collected and can be found in the history of the document: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/ > > Please note that no IPR was disclosed against this draft. > > > > *_PLEASE NOTE_* > > 1. Since both the chairs and the secretary are involved in the > draft as co-authors, the consensus will be called by Lou. > > 2. This is a good opportunity to have the WG involved also in > the Post-WG Last call process nominating a document shepherd which is > not one of the chairs or the secretary. The document shepherd: > > a. MUST NOT be one of the authors/contributors of the draft > > b. SHOULD be an expert of the ID subject > > c. Will receive all the needed support from the chairs. > > > > Further details on the shepherd duties can be found in RFC4858 and at > https://www.ietf.org/iesg/statement/document-shepherds.html: > > Please volunteer if interested > > > > Thanks > > Daniele & Fatai > --------------000201040701020807040607 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit All,
    Per below, I've been asked to call consensus on this, but there haven't yet been any comments received during the LC period -- which ends today.  So it's not too late to voice your opinion.

If you can, please review the latest rev of the document and comment.  Positive comments, e.g., "I've reviewed the latest version of this document and believe it is ready for publication", are welcome! This would be helpful, even from authors.  (Just saying "support" without review doesn't really serve the purpose.)

Thanks,
Lou -- as consensus caller "stuckee"

PS  I have reviewed this rev of the document and believe it is ready for publication.

On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote:

Working group,

 

this starts a two weeks working group last call on draft-ietf-ccamp-flexi-grid-fwk-03.

The last call end on Monday May 11th. Please send you comments to the CCAMP mailing list.

 

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/

Please note that no IPR was disclosed against this draft.

 

PLEASE NOTE

1.       Since both the chairs and the secretary are involved in the draft as co-authors, the consensus will be called by Lou.

2.       This is a good opportunity to have the WG involved also in the Post-WG Last call process nominating a document shepherd which is not one of the chairs or the secretary. The document shepherd:

a.       MUST NOT be one of the authors/contributors of the draft

b.      SHOULD be an expert of the ID subject

c.       Will receive all the needed support from the chairs.

 

Further details on the shepherd duties can be found in RFC4858 and at https://www.ietf.org/iesg/statement/document-shepherds.html:

Please volunteer if interested

 

Thanks

Daniele & Fatai


--------------000201040701020807040607-- From nobody Mon May 11 10:50:24 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3591ACE7E for ; Mon, 11 May 2015 10:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7mcCw3xZpMP for ; Mon, 11 May 2015 10:50:20 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D5F1ACE7F for ; Mon, 11 May 2015 10:50:20 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so33996435wic.1 for ; Mon, 11 May 2015 10:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N4mQyOAisWiiQ1Cad51khdmFEPVBfcuXVxCH6gQCl58=; b=j/gzvV1aIgfcn57Cnabai8bjZMTVNT2tGH2N/DqpGmgbjxkxaR2Ja0AKu2+G28I7lU 9PlV0aq0cbiS+tH69xF/wsjuHb5ozGRTJ6YehCXNJMvCIZRX8B2spXONEYGxv9KRVFft geTQy42dHN/acGdhnJRaPzsDs5L1PHqijs/7uFJzTBmqIBMnw1FOOtUSfQ0rKhAbt0qz FC65j+1pFWZ7okMjVN0NAXz4EHVmCVBxF4zUjus4cKTi8E0VnjN/uirLT4RJ2f/L30LB V04o5Oj8vE+6NdIsoMJZDym6MX7UtX5L1W3s+D82VSugmk6RwklrH3dFY94tlsOypCAK qY8A== X-Received: by 10.194.11.73 with SMTP id o9mr22915622wjb.116.1431366618970; Mon, 11 May 2015 10:50:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.182.215 with HTTP; Mon, 11 May 2015 10:49:58 -0700 (PDT) In-Reply-To: <5550A8BC.4090005@labn.net> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> From: "Andrew G. Malis" Date: Mon, 11 May 2015 13:49:58 -0400 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=047d7b4507e0de01850515d2023c Archived-At: Cc: "CCAMP \(ccamp@ietf.org\)" Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 17:50:22 -0000 --047d7b4507e0de01850515d2023c Content-Type: text/plain; charset=UTF-8 Lou, As one of the hundred or so :-) contributors to this draft, I've reviewed the latest version and believe it is ready for publication. Cheers, Andy On Mon, May 11, 2015 at 9:03 AM, Lou Berger wrote: > All, > Per below, I've been asked to call consensus on this, but there > haven't yet been any comments received during the LC period -- which ends > today. So it's not too late to voice your opinion. > > If you can, please review the latest rev of the document and comment. > Positive comments, e.g., "I've reviewed the latest version of this document > and believe it is ready for publication", are welcome! This would be > helpful, even from authors. (Just saying "support" without review doesn't > really serve the purpose.) > > Thanks, > Lou -- as consensus caller "stuckee" > > PS I have reviewed this rev of the document and believe it is ready for > publication. > > > On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote: > > Working group, > > > > this starts a two weeks working group last call on > draft-ietf-ccamp-flexi-grid-fwk-03. > > The last call end on Monday May 11th. Please send you comments to the > CCAMP mailing list. > > > > All the IPR declarations from authors and contributors have been collected > and can be found in the history of the document: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/ > > Please note that no IPR was disclosed against this draft. > > > > *PLEASE NOTE* > > 1. Since both the chairs and the secretary are involved in the > draft as co-authors, the consensus will be called by Lou. > > 2. This is a good opportunity to have the WG involved also in the > Post-WG Last call process nominating a document shepherd which is not one > of the chairs or the secretary. The document shepherd: > > a. MUST NOT be one of the authors/contributors of the draft > > b. SHOULD be an expert of the ID subject > > c. Will receive all the needed support from the chairs. > > > > Further details on the shepherd duties can be found in RFC4858 and at > https://www.ietf.org/iesg/statement/document-shepherds.html: > > Please volunteer if interested > > > > Thanks > > Daniele & Fatai > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > --047d7b4507e0de01850515d2023c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lou,

As one of the hundred or so :-) co= ntributors to this draft,=C2=A0I've revi= ewed the latest version and believe it is ready for publication.

Cheers,
And= y


On Mon, May 11, 201= 5 at 9:03 AM, Lou Berger <lberger@labn.net> wrote:
=20 =20 =20
All,
=C2=A0=C2=A0=C2=A0 Per below, I've been asked to call consensus on = this, but there haven't yet been any comments received during the LC period -- whic= h ends today.=C2=A0 So it's not too late to voice your opinion.

If you can, please review the latest rev of the document and comment.=C2=A0 Positive comments, e.g., "I've reviewed the lat= est version of this document and believe it is ready for publication", are welcome! This would be helpful, even from authors.=C2=A0 (Just saying "support" without review doesn't really serve the purpose= .)

Thanks,
Lou -- as consensus caller "stuckee"

PS=C2=A0 I have reviewed this rev of the document and believe it is rea= dy for publication.


On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote:
=20 =20 =20

Working group,

=C2=A0

this starts a two weeks working group last call on draft-ietf-ccamp-flexi-grid-fwk-03.

The last call end on Monday May 11th. Please send you comments to the CCAMP mailing list.=

=C2=A0

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document: https://datatracker.ietf.org/doc/dra= ft-ietf-ccamp-flexi-grid-fwk/history/

Please note that no IPR was disclosed against this draft.

=C2=A0

PLEASE NOTE

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Since both the chairs and the secretary are involved in the draft as co-authors, the consensus will be called by Lou.

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is a good opportunity to have the WG involved also in the Post-WG Last call process nominating a document shepherd which is not one of the chairs or the secretary. The document shepherd:

a.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST NOT be one of the authors/contributors of the draft

b.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD be an expert of the ID subject

c.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Will receive all the needed support from the chairs.

=C2=A0

Further details on the shepherd duties can be found in RFC4858 and at https://www.ietf.org/iesg/statement/document-sheph= erds.html:

Please volunteer if interested

=C2=A0

Thanks

Daniele & Fatai



_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp


--047d7b4507e0de01850515d2023c-- From nobody Mon May 11 14:04:19 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB1F1A916B for ; Mon, 11 May 2015 14:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEA22AM0FT-T for ; Mon, 11 May 2015 14:04:15 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284A71A9168 for ; Mon, 11 May 2015 14:04:15 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4BL4CAC026859; Mon, 11 May 2015 22:04:12 +0100 Received: from 950129200 (93-63-166-178.ip28.fastwebnet.it [93.63.166.178]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4BL45ud026805 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 May 2015 22:04:08 +0100 From: "Adrian Farrel" To: "'Lou Berger'" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> In-Reply-To: Date: Mon, 11 May 2015 22:04:03 +0100 Message-ID: <001301d08c2e$05556090$100021b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01D08C36.671B4F30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJ8z7OtFL3qSQ0EA1ynidDf4RrAgLpivoBAY1Cg6Ke4L42MA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21538.002 X-TM-AS-Result: No--25.521-10.0-31-10 X-imss-scan-details: No--25.521-10.0-31-10 X-TMASE-MatchedRID: Xxz90/Ib/ZhbJCKOm3VRCThgoAzehG32zcwTglIp/qPeSIPhEcRS6/pB UeIPGIgB92W+zZRwnRgG7bNEJKsuNuAe2rni5lNAdq4OCozQy1XS7l9oY/zO1JzmLUG30eeXyoB dc+vJDnm9XBcmqjeTJ/VFR4sC8dPy9r9tEcSw8jcifM7JMNHW658NuGexHVnGGb3g9jikqYEYJh HqyvEVqMArNhnG9OGVma6DzXaohvOsvgu4NQN9u7EjpKAYMHdxq1hc1vJPxq1xftOfjiZOmB5fJ nUc9r1PJO0KFVwm0TipuD25aEtgt7OA0SKY3oCF4pddx2NHo55Ai7jQeJMVL2esCeL5dc/6Bhxw l3hRruzaRs0xILLwurU+IyHhkXf1dZPoD9V2prR0PA/ki2kI7EtU4/pKr/obDsbtrO33TVeLFgn z+hpr+XW0oJLOugKBj1RGQOB2Vvn9GaYSzB/sh6Jd7mc2dRi3oEozraubH2nx6gF+AN4QjuBe5Q RmIfivPwbcb/CNUOlwvDydhBUuyCAXLFyLhL5W5GdZsk1yqBcqoeXFMnt4lSJunynLhcivKEdCt wyfJsLWV8MKb34RlRZU/yoIC8o9JVsoL7U3JcDimKcLRvsB1UauzWhZogiAzkH/0tV77RA9ihzf HXEWBFN5kIZnYeEYY4guKfvwCBYzH3zWWApNw/ufvd3T2+v3GRCKVx5QswnzbeV2VN8Li3ZBE86 uj+Htoi8K/V7jzhlNVr4vdmCpztFpembubBCcuRjdZTD8Hxe7yLIkLI23qXb4Bm7FqQnLeKdvzr QKtCjA+jwY/tNg2xlLm7Fc/E3pyiBjGmb09NubKItl61J/yZUdXE/WGn0FSlnU38LCY8v3vguvm Elg+pF3mJo8ap5Qqq9OGss1bHi22TrDxDzTIfRaVrTJDlJtb+lqXVjCVl4= Archived-At: Cc: 'CCAMP' Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 21:04:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0014_01D08C36.671B4F30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, I too reviewed this document before the authors requested last = call. My review resulted in some updates in the current version which I = now think is ready for publication. =20 Adrian (contributor) =20 From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: 11 May 2015 18:50 To: Lou Berger Cc: CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 = and call for sheperd =20 Lou, =20 As one of the hundred or so :-) contributors to this draft, I've = reviewed the latest version and believe it is ready for publication. =20 Cheers, Andy =20 =20 On Mon, May 11, 2015 at 9:03 AM, Lou Berger wrote: All, Per below, I've been asked to call consensus on this, but there = haven't yet been any comments received during the LC period -- which = ends today. So it's not too late to voice your opinion. If you can, please review the latest rev of the document and comment. = Positive comments, e.g., "I've reviewed the latest version of this = document and believe it is ready for publication", are welcome! This = would be helpful, even from authors. (Just saying "support" without = review doesn't really serve the purpose.) Thanks, Lou -- as consensus caller "stuckee" PS I have reviewed this rev of the document and believe it is ready for = publication. =20 On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote: Working group, =20 this starts a two weeks working group last call on = draft-ietf-ccamp-flexi-grid-fwk-03. The last call end on Monday May 11th. Please send you comments to the = CCAMP mailing list. =20 All the IPR declarations from authors and contributors have been = collected and can be found in the history of the document: = https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/= Please note that no IPR was disclosed against this draft. =20 PLEASE NOTE 1. Since both the chairs and the secretary are involved in the = draft as co-authors, the consensus will be called by Lou.=20 2. This is a good opportunity to have the WG involved also in the = Post-WG Last call process nominating a document shepherd which is not = one of the chairs or the secretary. The document shepherd: a. MUST NOT be one of the authors/contributors of the draft b. SHOULD be an expert of the ID subject c. Will receive all the needed support from the chairs. =20 Further details on the shepherd duties can be found in RFC4858 and at = https://www.ietf.org/iesg/statement/document-shepherds.html: Please volunteer if interested =20 Thanks Daniele & Fatai =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 ------=_NextPart_000_0014_01D08C36.671B4F30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Yes, I too reviewed this = document before the authors requested last call. My review resulted in = some updates in the current version which I now think is ready for = publication.

 

Adrian = (contributor)

 

From: CCAMP = [mailto:ccamp-bounces@ietf.org] On Behalf Of Andrew G. = Malis
Sent: 11 May 2015 18:50
To: Lou = Berger
Cc: CCAMP (ccamp@ietf.org)
Subject: Re: = [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for = sheperd

 

Lou,

 

As one of the hundred or so :-) contributors to this = draft, I've reviewed the latest = version and believe it is ready for = publication.

 

Cheers,

Andy

 

 

On Mon, = May 11, 2015 at 9:03 AM, Lou Berger <lberger@labn.net> wrote:

All,
    Per below, I've been asked = to call consensus on this, but there haven't yet been any comments = received during the LC period -- which ends today.  So it's not too = late to voice your opinion.

If you can, please review the latest = rev of the document and comment.  Positive comments, e.g., = "I've reviewed the latest version of this document and believe it = is ready for publication", are welcome! This would be helpful, even = from authors.  (Just saying "support" without review = doesn't really serve the purpose.)

Thanks,
Lou -- as consensus = caller "stuckee"

PS  I have reviewed this rev of = the document and believe it is ready for = publication.

 

On 4/27/2015 6:04 AM, Daniele Ceccarelli = wrote:

Working = group,

 <= /o:p>

this starts = a two weeks working group last call on = draft-ietf-ccamp-flexi-grid-fwk-03.

The last = call end on Monday May 11th. Please send you comments to the = CCAMP mailing list.

 <= /o:p>

All the IPR = declarations from authors and contributors have been collected and can = be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi= -grid-fwk/history/

Please note = that no IPR was disclosed against this draft.

 <= /o:p>

PLEASE= NOTE

1.       = Since both the chairs and the secretary are involved in the draft = as co-authors, the consensus will be called by Lou. =

2.       = This is a good opportunity to have the WG involved also in the = Post-WG Last call process nominating a document shepherd which is not = one of the chairs or the secretary. The document = shepherd:

a.       = MUST NOT be one of the authors/contributors of the = draft

b.      SHOULD = be an expert of the ID subject

c.       = Will receive all the needed support from the = chairs.

 

Further details on the = shepherd duties can be found in RFC4858 and at https://www.ietf.org/iesg/statement/document-shepherds.= html:

Please volunteer if = interested

 

Thanks

=

Daniele & Fatai

 


______________________________________= _________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

 

------=_NextPart_000_0014_01D08C36.671B4F30-- From nobody Mon May 11 15:02:48 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAC21A88D1 for ; Mon, 11 May 2015 15:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N2qXffjuYVl for ; Mon, 11 May 2015 15:02:43 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867B91A90A8 for ; Mon, 11 May 2015 15:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20508; q=dns/txt; s=iport; t=1431381763; x=1432591363; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UZIaCp4KTweXDK4yTSEhciIP2GA6e/97rLgTcIgeVGc=; b=BeMlkGEVulFiKQLUy5ARTDRqzM6HlpA1/I0pJ12EgewoVgdo3MuKHf+/ m6TL0rA43pN2dOG/M41kEy4oMqW+Qd0Z4p64YIP//e0kLodfd/UnGK+/R NdBpGHZG0NDs7wZ6dXp0vk7YaxwY0vyjYk8dIdXSx00EmTrEw2euSg197 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBACaJVFV/4YNJK1GFoJFSlReBsR1CYFahgMCgTs4FAEBAQEBAQGBCoQgAQEBBB0QOgQDCxACAQgOAwQBAQsJFAcyFAkIAgQBDQUIiCQNyQUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs5hBo6LQQGAYMXgRYFkj2EHodpg1qOBINVI2GBBSMcFYE9bwGBRIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,410,1427760000"; d="scan'208,217";a="149176561" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 11 May 2015 22:02:42 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4BM2gPP003359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 May 2015 22:02:42 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.22]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Mon, 11 May 2015 17:02:41 -0500 From: "Matt Hartley (mhartley)" To: Lou Berger , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AQHQi+sCRbr+LifYa0qF5OmSNlKil513Qq8g Date: Mon, 11 May 2015 22:02:41 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> In-Reply-To: <5550A8BC.4090005@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.94] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC29C85B6Bxmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 22:02:47 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC29C85B6Bxmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I've reviewed this revision of the document, and I think it's almost ready = for publication. I have a few comments (below) but I don't think there's an= y major issues. 3.1: definition of OTN could be moved up to section 2.2, if you want. 3.2.1: you state that the Nominal Central Frequency Granularity is 6.25GHz,= but there's no reference for this. I assume it's in an ITU doc somewhere? = If so, it'd be good to say so (and where) The document refers to "OTSi signals" in several places, but the definition= of "OTSi" includes "signal" :) I don't know whether or not this is normal = usage or whether it's worth fixing... but it looks technically wrong to me = (like people talking about "PIN numbers" whenever they get cash out of the = bank). 3.2.5, first bullet: "This group of OTSi should be carried over a single fi= bre." Is that a normal English should, or a 2219 SHOULD? If the former, it = might be worth rephrasing to avoid ambiguity. 4.2: "The association of the three components a filter, a fiber, and a filt= er, is a media channel in its most basic form.". It'd be nice to clarify th= at this is a fiber with a filter at each end - that's not immediately obvio= us on first reading, especially with the diagram that makes it clear on the= next page. The paragraph below figure 8 is... unclear. Is it just trying to say that m= edia channels can be joined together to make a new media channel? Or is the= re more to it than that? Fig 12: OTSi trail? Did you mean OCh trail? Fig 14: MLN/MRN needs explaining. Or removing. 4.3, towards the end: "there must be enough guard band between adjacent OTS= is in any media channel to compensate filter concatenation effect and other= effects caused by signal layer switching elements". Maybe "...to compensat= e for the filter concatenation effect and..." or "...to compensate for filt= er concatenation effects and..."? 4.8.4: bear in mind that 0 is not a positive integer, and it looks like the= definitions involving (2^n) and (2^m) are intended to include the case whe= re n/m is 0. Cheers Matt From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, May 11, 2015 9:04 AM To: CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and= call for sheperd All, Per below, I've been asked to call consensus on this, but there haven't= yet been any comments received during the LC period -- which ends today. = So it's not too late to voice your opinion. If you can, please review the latest rev of the document and comment. Posi= tive comments, e.g., "I've reviewed the latest version of this document and= believe it is ready for publication", are welcome! This would be helpful, = even from authors. (Just saying "support" without review doesn't really se= rve the purpose.) Thanks, Lou -- as consensus caller "stuckee" PS I have reviewed this rev of the document and believe it is ready for pu= blication. On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote: Working group, this starts a two weeks working group last call on draft-ietf-ccamp-flexi-g= rid-fwk-03. The last call end on Monday May 11th. Please send you comments to the CCAMP= mailing list. All the IPR declarations from authors and contributors have been collected = and can be found in the history of the document: https://datatracker.ietf.o= rg/doc/draft-ietf-ccamp-flexi-grid-fwk/history/ Please note that no IPR was disclosed against this draft. PLEASE NOTE 1. Since both the chairs and the secretary are involved in the draft = as co-authors, the consensus will be called by Lou. 2. This is a good opportunity to have the WG involved also in the Pos= t-WG Last call process nominating a document shepherd which is not one of t= he chairs or the secretary. The document shepherd: a. MUST NOT be one of the authors/contributors of the draft b. SHOULD be an expert of the ID subject c. Will receive all the needed support from the chairs. Further details on the shepherd duties can be found in RFC4858 and at https= ://www.ietf.org/iesg/statement/document-shepherds.html: Please volunteer if interested Thanks Daniele & Fatai --_000_9D50FCE7413E3D4EA5E42331115FB5BC29C85B6Bxmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I’ve reviewed = this revision of the document, and I think it’s almost ready for publ= ication. I have a few comments (below) but I don’t think there’= s any major issues.

 

3.1: definition of O= TN could be moved up to section 2.2, if you want.

 

3.2.1: you state tha= t the Nominal Central Frequency Granularity is 6.25GHz, but there’s n= o reference for this. I assume it’s in an ITU doc somewhere? If so, it’d be good to say so (and where)

 

The document refers = to “OTSi signals” in several places, but the definition of R= 20;OTSi” includes “signal” :) I don’t know whether = or not this is normal usage or whether it’s worth fixing… but it looks technically wrong t= o me (like people talking about “PIN numbers” whenever they get= cash out of the bank).

 

3.2.5, first bullet:= “This group of OTSi should be carried over a single fibre.” Is= that a normal English should, or a 2219 SHOULD? If the former, it might be worth rephrasing to avoid ambiguity.

 

4.2: “The asso= ciation of the three components a filter, a fiber, and a filter, is a media= channel in its most basic form.”. It’d be nice to clarify that this is a fiber with a filter at each end – that’s not immedia= tely obvious on first reading, especially with the diagram that makes it cl= ear on the next page.

 

The paragraph below = figure 8 is... unclear. Is it just trying to say that media channels can be= joined together to make a new media channel? Or is there more to it than that?

 

Fig 12: OTSi trail? = Did you mean OCh trail?

 

Fig 14: MLN/MRN need= s explaining. Or removing.

 

4.3, towards the end= : “there must be enough guard band between adjacent OTSis in any medi= a channel to compensate filter concatenation effect and other effects caused by signal layer switching elements”. Maybe “= 230;to compensate for the filter concatenation effect and…” or = “…to compensate for filter concatenation effects and…R= 21;?

 

4.8.4: bear in mind = that 0 is not a positive integer, and it looks like the definitions involvi= ng (2^n) and (2^m) are intended to include the case where n/m is 0.

 

Cheers

 

Matt

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Monday, May 11, 2015 9:04 AM
To: CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk= -03 and call for sheperd

 

All,
    Per below, I've been asked to call consensus on this, bu= t there haven't yet been any comments received during the LC period -- whic= h ends today.  So it's not too late to voice your opinion.

If you can, please review the latest rev of the document and comment. = Positive comments, e.g., "I've reviewed the latest version of this do= cument and believe it is ready for publication", are welcome! This wou= ld be helpful, even from authors.  (Just saying "support" without review doesn't really serve the purpose.)

Thanks,
Lou -- as consensus caller "stuckee"

PS  I have reviewed this rev of the document and believe it is ready f= or publication.

On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote:=

Working group,

 

this starts a two weeks working group last call on d= raft-ietf-ccamp-flexi-grid-fwk-03.

The last call end on Monday May 11th. Ple= ase send you comments to the CCAMP mailing list.

 

All the IPR declarations from authors and contributo= rs have been collected and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/

Please note that no IPR was disclosed against this d= raft.

 

PLEASE NOTE

1.     &= nbsp; Since both the chairs and the secretary are involve= d in the draft as co-authors, the consensus will be called by Lou.

2.     &= nbsp; This is a good opportunity to have the WG involved = also in the Post-WG Last call process nominating a document shepherd which = is not one of the chairs or the secretary. The document shepherd:

a.       MUST NOT be one of the authors/contributors of the = draft

b.      SHOULD be an expert of the ID subject

c.       Will receive all the needed support from the chairs= .

 

Further details on the shepherd duties can be= found in RFC4858 and at htt= ps://www.ietf.org/iesg/statement/document-shepherds.html:

Please volunteer if interested

 

Thanks

Daniele & Fatai

 

--_000_9D50FCE7413E3D4EA5E42331115FB5BC29C85B6Bxmbrcdx03ciscoc_-- From nobody Mon May 11 18:12:14 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60F01A8035 for ; Mon, 11 May 2015 18:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gLHuywoeb9j for ; Mon, 11 May 2015 18:12:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06621A1A8D for ; Mon, 11 May 2015 18:12:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVX70470; Tue, 12 May 2015 01:12:08 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 May 2015 02:12:07 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.171]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Tue, 12 May 2015 09:12:03 +0800 From: "Zhangxian (Xian)" To: Lou Berger , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgK4QKUAACoepwA= Date: Tue, 12 May 2015 01:12:03 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> In-Reply-To: <5550A8BC.4090005@labn.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B471BBD7ASZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 01:12:13 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471BBD7ASZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIExvdSwgYWxsLA0KDQpJJ3ZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGlz IGRvY3VtZW50IGFuZCBjb21tZW50cyAobm8gbWFqb3Igb25lcykgaGF2ZSBhbHJlYWR5IHNlbnQg dG8gUmFtb24uIFRodXMsIEkgdGhpbmsgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9ucy4NCg0K QlRXLCBpZiBpdCBtaWdodCBiZSBoZWxwZnVsLCBJIGNhbiBkaWcgb3V0IHRoZSBlbWFpbCBhbmQg cmVzZW5kIHRoZSBjb21tZW50cyB0byB0aGUgbGlzdC4NCg0KUmVnYXJkcywNClhpYW4NCg0KRnJv bTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG91 IEJlcmdlcg0KU2VudDogMjAxNcTqNdTCMTHI1SAyMTowNA0KVG86IENDQU1QIChjY2FtcEBpZXRm Lm9yZykNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWNj YW1wLWZsZXhpLWdyaWQtZndrLTAzIGFuZCBjYWxsIGZvciBzaGVwZXJkDQoNCkFsbCwNCiAgICBQ ZXIgYmVsb3csIEkndmUgYmVlbiBhc2tlZCB0byBjYWxsIGNvbnNlbnN1cyBvbiB0aGlzLCBidXQg dGhlcmUgaGF2ZW4ndCB5ZXQgYmVlbiBhbnkgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBM QyBwZXJpb2QgLS0gd2hpY2ggZW5kcyB0b2RheS4gIFNvIGl0J3Mgbm90IHRvbyBsYXRlIHRvIHZv aWNlIHlvdXIgb3Bpbmlvbi4NCg0KSWYgeW91IGNhbiwgcGxlYXNlIHJldmlldyB0aGUgbGF0ZXN0 IHJldiBvZiB0aGUgZG9jdW1lbnQgYW5kIGNvbW1lbnQuICBQb3NpdGl2ZSBjb21tZW50cywgZS5n LiwgIkkndmUgcmV2aWV3ZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1lbnQgYW5k IGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNvbWUhIFRoaXMg d291bGQgYmUgaGVscGZ1bCwgZXZlbiBmcm9tIGF1dGhvcnMuICAoSnVzdCBzYXlpbmcgInN1cHBv cnQiIHdpdGhvdXQgcmV2aWV3IGRvZXNuJ3QgcmVhbGx5IHNlcnZlIHRoZSBwdXJwb3NlLikNCg0K VGhhbmtzLA0KTG91IC0tIGFzIGNvbnNlbnN1cyBjYWxsZXIgInN0dWNrZWUiDQoNClBTICBJIGhh dmUgcmV2aWV3ZWQgdGhpcyByZXYgb2YgdGhlIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJl YWR5IGZvciBwdWJsaWNhdGlvbi4NCk9uIDQvMjcvMjAxNSA2OjA0IEFNLCBEYW5pZWxlIENlY2Nh cmVsbGkgd3JvdGU6DQpXb3JraW5nIGdyb3VwLA0KDQp0aGlzIHN0YXJ0cyBhIHR3byB3ZWVrcyB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLWNjYW1wLWZsZXhpLWdyaWQtZndr LTAzLg0KVGhlIGxhc3QgY2FsbCBlbmQgb24gTW9uZGF5IE1heSAxMXRoLiBQbGVhc2Ugc2VuZCB5 b3UgY29tbWVudHMgdG8gdGhlIENDQU1QIG1haWxpbmcgbGlzdC4NCg0KQWxsIHRoZSBJUFIgZGVj bGFyYXRpb25zIGZyb20gYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzIGhhdmUgYmVlbiBjb2xsZWN0 ZWQgYW5kIGNhbiBiZSBmb3VuZCBpbiB0aGUgaGlzdG9yeSBvZiB0aGUgZG9jdW1lbnQ6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2NhbXAtZmxleGktZ3JpZC1m d2svaGlzdG9yeS8NClBsZWFzZSBub3RlIHRoYXQgbm8gSVBSIHdhcyBkaXNjbG9zZWQgYWdhaW5z dCB0aGlzIGRyYWZ0Lg0KDQpQTEVBU0UgTk9URQ0KDQoxLiAgICAgIFNpbmNlIGJvdGggdGhlIGNo YWlycyBhbmQgdGhlIHNlY3JldGFyeSBhcmUgaW52b2x2ZWQgaW4gdGhlIGRyYWZ0IGFzIGNvLWF1 dGhvcnMsIHRoZSBjb25zZW5zdXMgd2lsbCBiZSBjYWxsZWQgYnkgTG91Lg0KDQoyLiAgICAgIFRo aXMgaXMgYSBnb29kIG9wcG9ydHVuaXR5IHRvIGhhdmUgdGhlIFdHIGludm9sdmVkIGFsc28gaW4g dGhlIFBvc3QtV0cgTGFzdCBjYWxsIHByb2Nlc3Mgbm9taW5hdGluZyBhIGRvY3VtZW50IHNoZXBo ZXJkIHdoaWNoIGlzIG5vdCBvbmUgb2YgdGhlIGNoYWlycyBvciB0aGUgc2VjcmV0YXJ5LiBUaGUg ZG9jdW1lbnQgc2hlcGhlcmQ6DQoNCmEuICAgICAgTVVTVCBOT1QgYmUgb25lIG9mIHRoZSBhdXRo b3JzL2NvbnRyaWJ1dG9ycyBvZiB0aGUgZHJhZnQNCg0KYi4gICAgICBTSE9VTEQgYmUgYW4gZXhw ZXJ0IG9mIHRoZSBJRCBzdWJqZWN0DQoNCmMuICAgICAgV2lsbCByZWNlaXZlIGFsbCB0aGUgbmVl ZGVkIHN1cHBvcnQgZnJvbSB0aGUgY2hhaXJzLg0KDQoNCg0KRnVydGhlciBkZXRhaWxzIG9uIHRo ZSBzaGVwaGVyZCBkdXRpZXMgY2FuIGJlIGZvdW5kIGluIFJGQzQ4NTggYW5kIGF0IGh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2RvY3VtZW50LXNoZXBoZXJkcy5odG1sOg0KDQpQ bGVhc2Ugdm9sdW50ZWVyIGlmIGludGVyZXN0ZWQNCg0KDQoNClRoYW5rcw0KDQpEYW5pZWxlICYg RmF0YWkNCg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471BBD7ASZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Lou, all,

 

I'= ve reviewed the latest version of this document and comments (no major ones) have already sent to R= amon. Thus, I think it is ready for publications.

 

BT= W, if it might be helpful, I can dig out the email and resend the comments = to the list.

Regards,
Xian

 

From:= CCAMP [mailto:ccamp= -bounces@ietf.org] On Behalf Of Lou Berger
Sent: 2015=C4=EA= 5=D4=C211=C8=D5= 21:04
To: CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk= -03 and call for sheperd

 

= All,
    Per below, I've been asked to call consensus on this, bu= t there haven't yet been any comments received during the LC period -- whic= h ends today.  So it's not too late to voice your opinion.

If you can, please review the latest rev of the document and comment. = Positive comments, e.g., "I've reviewed the latest version of this do= cument and believe it is ready for publication", are welcome! This wou= ld be helpful, even from authors.  (Just saying "support" without review doesn't really serve the purpose.)

Thanks,
Lou -- as consensus caller "stuckee"

PS  I have reviewed this rev of the document and believe it is ready f= or publication.

On 4/27/2015 6:04 AM, Daniele C= eccarelli wrote:

Working group,

 

this starts a two weeks working= group last call on draft-ietf-ccamp-flexi-grid-fwk-03.

The last call end on Monday May= 11th. Please send you comments to the CCAMP mailing list.<= /o:p>

 

All the IPR declarations from a= uthors and contributors have been collected and can be found in the history= of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/

Please note that no IPR was dis= closed against this draft.

 

PLEASE NOTE

1. &nbs= p;    Since both the chairs a= nd the secretary are involved in the draft as co-authors, the consensus wil= l be called by Lou.

2. &nbs= p;    This is a good opportun= ity to have the WG involved also in the Post-WG Last call process nominatin= g a document shepherd which is not one of the chairs or the secretary. The = document shepherd:

a= .   &= nbsp;  MUST NOT be one of the = authors/contributors of the draft

b= .   &= nbsp;  SHOULD be an expert of = the ID subject

c= .   &= nbsp;  Will receive all the ne= eded support from the chairs.

 =

Further details on the s= hepherd duties can be found in RFC4858 and at htt= ps://www.ietf.org/iesg/statement/document-shepherds.html:

Please volunteer if inte= rested

 =

Thanks=

Daniele & Fatai=

 

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B471BBD7ASZXEMA512MBSchi_-- From nobody Tue May 12 00:58:00 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA09E1A1BD2 for ; Tue, 12 May 2015 00:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.7 X-Spam-Level: X-Spam-Status: No, score=-100.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j227TXSR10mu for ; Tue, 12 May 2015 00:57:56 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FA81A1BF8 for ; Tue, 12 May 2015 00:57:55 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4C7vntQ025164; Tue, 12 May 2015 08:57:49 +0100 Received: from 950129200 (93-63-166-178.ip28.fastwebnet.it [93.63.166.178]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4C7v1mO023788 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 08:57:47 +0100 From: "Adrian Farrel" To: "'Matt Hartley \(mhartley\)'" , "'Lou Berger'" , "'CCAMP'" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> Date: Tue, 12 May 2015 08:56:38 +0100 Message-ID: <00b801d08c89$54506ef0$fcf14cd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01D08C91.B61991E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJ8z7OtFL3qSQ0EA1ynidDf4RrAgLpivoBAXM7VdKe4j/QIA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21538.005 X-TM-AS-Result: No--9.347-10.0-31-10 X-imss-scan-details: No--9.347-10.0-31-10 X-TMASE-MatchedRID: DuKherWvI/uMM/e2w9VkiQPZZctd3P4BC/ExpXrHizxF+YXPIqAdvuEm 2AuUTve3dMPtA2mlYMoqtR5dpDoB4zHoq5wq7Ry6HcQQBuf4ZFtcSMp/1+Epp/0TP/kikeqnQhy MInWMJgrTgz5+vw91E7jlO5fRQYn9Qp3R14HljTiMVQb49Y23I56KYa03LCO2dDwP5ItpCOwcSR F9JP5Ozi4jb1n1eNA3RHaihp8THGAxoJNALx/f4Z3bt4XlQMWj/5QRvrl2CZDrKAwxOgrz3aeFn JsqgWxcQt2470g7veffrLmAIPWViTMbwODjywn+8hUvf4pI2DCRPMCAcbl40qAkf3vialurqBOQ uBO1OCBeqXaEhzCXaxMfL/qOWmMdPiAaQSjAgpk2zdLf3NqhdhTbB6yIhfK7Fb73eKpG9ftUPgh fcaHOS5xNkaIFR3x9rBBSnn/GVMan+dP7GcjVHbiMC5wdwKqddwX/SSKrKHh40NDah2ISIWji04 EzOjY4789pseECvAFuxytUTKTafadwsJe6fN2L5HDr20Bhc0aXYX34rFl3xwv/nTOPQovsFj7vn T2w9fs2PdZ3b67nCSKINqHfol/n3szvVnpBZzhIOSHptb5txy9wqaqMRxje47ndse0z1bcWP8We rtUXzJtmx62Nt/M+LWN7JnJVmAmCIg7tJ//usdjDJsU1r62bm/y00tE9StZdJqXcElZhZuRqQAx bWD9+4vM1YF6AJbbVZ0g740lL+SIQ5mZ5SqHPknr+LSwdt5wNB4N1wVn6pE32YjE1Bg7KMj8K3H srRdI4NIY68I5Hn8s16NCQbfYU+MKnCjDvq5M6sZrmxygSUvGdKTMSiSNwVuGAHHweLts= Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 07:57:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B9_01D08C91.B61991E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Matt, =20 Leaving the bulk of the editorials to the, erm, editors... =20 > 3.2.5, first bullet: =E2=80=9CThis group of OTSi should be carried = over a single fibre.=E2=80=9D Is that > a normal English should, or a 2219 SHOULD? If the former, it might be = worth=20 > rephrasing to avoid ambiguity. =20 It is certainly not 2119 because we do not define data plane behaviour. =20 I would favour s/should be/are/ =20 > 4.2: =E2=80=9CThe association of the three components a filter, a = fiber, and a filter, is a=20 > media channel in its most basic form.=E2=80=9D. It=E2=80=99d be nice = to clarify that this is a fiber=20 > with a filter at each end =E2=80=93 that=E2=80=99s not immediately = obvious on first reading,=20 > especially with the diagram that makes it clear on the next page. =20 s/association/association sequence/ =20 > 4.8.4: bear in mind that 0 is not a positive integer, and it looks = like the definitions=20 > involving (2^n) and (2^m) are intended to include the case where n/m = is 0. =20 Yeah, we should probably say "non-negative integer" to be consistent = with the usage in computer science. It would be OK to write =E2=84=950 if only we supported unicode and = superscript in I-Ds :-) Or perhaps being more explicit "the set of zero and all positive = integers". =20 Thanks for the review, Adrian ------=_NextPart_000_00B9_01D08C91.B61991E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello = Matt,

 

Leaving the bulk of the editorials to the, erm, = editors...

 

> 3.2.5, first bullet: =E2=80=9CThis group of = OTSi should be carried over a single fibre.=E2=80=9D Is = that

> a normal English should, = or a 2219 SHOULD? If the former, it might be worth

> rephrasing to avoid = ambiguity.

 

It is certainly not 2119 because we do not define = data plane behaviour.

 

I = would favour s/should be/are/

 

> = 4.2: =E2=80=9CThe association of the three components a filter, a fiber, = and a filter, is a

> media = channel in its most basic form.=E2=80=9D. It=E2=80=99d be nice to = clarify that this is a fiber

> = with a filter at each end =E2=80=93 that=E2=80=99s not immediately = obvious on first reading,

> = especially with the diagram that makes it clear on the next = page.

 

s/association/association = sequence/

 

> 4.8.4: bear in mind that 0 is not a positive = integer, and it looks like the definitions

> involving (2^n) and (2^m) are intended to = include the case where n/m is 0.

 

Yeah, = we should probably say "non-negative integer" to be consistent = with the usage in computer science.

It would be OK to write =E2=84=950 = if only we supported unicode and superscript in I-Ds = :-)

Or perhaps being more = explicit "the set of zero and all positive = integers".

 

Thanks = for the review,

Adrian

------=_NextPart_000_00B9_01D08C91.B61991E0-- From nobody Tue May 12 10:13:01 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7971ACD5B for ; Tue, 12 May 2015 10:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNWZ89wgh7Jc for ; Tue, 12 May 2015 10:12:58 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C53B1ACD58 for ; Tue, 12 May 2015 10:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12304; q=dns/txt; s=iport; t=1431450778; x=1432660378; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JqRfSEv+gRFUB1Yfz8TQAH9QbExBiOqDSsfKNMTTJAw=; b=Yxk3qPZRAS02TZNMbnXceHvszzW1lJYW+QUPgH6p1nHU2On3VVtv6o0Y q08zVjQaQLqJxJCTmiFH9VDAY8F2UZVQzHjDY3xWYHRz8WNE07LUjVGtY THFIFuZCp9HQDWlRg6kOp0TypZfWVvsp24Xf5dJs0XbKEyARS3OAdR7cg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQC0M1JV/5BdJa1cgkVKVGSDGMlvAhyBHzsRAQEBAQEBAYEKhCABAQEDAR0GCjoSBQsCAQgiIAICAjAlAgQBDQ2IHAi2CJNpAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s5hFQxB4JoL4EWBZJNoVUjYYEFIxwVgT2CNIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,416,1427760000"; d="scan'208,217";a="149293100" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP; 12 May 2015 17:12:57 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4CHCvmv009047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 17:12:57 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.22]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 12 May 2015 12:12:56 -0500 From: "Matt Hartley (mhartley)" To: "adrian@olddog.co.uk" , "'Lou Berger'" , "'CCAMP'" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AQHQi+sCRbr+LifYa0qF5OmSNlKil513Qq8ggAELpQCAAEd90A== Date: Tue, 12 May 2015 17:12:56 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29C8720F@xmb-rcd-x03.cisco.com> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <00b801d08c89$54506ef0$fcf14cd0$@olddog.co.uk> In-Reply-To: <00b801d08c89$54506ef0$fcf14cd0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.78] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC29C8720Fxmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:13:00 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC29C8720Fxmbrcdx03ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRyaWFuLA0KDQpUaGUgYWx0ZXJuYXRpdmVzIHlvdeKAmXZlIHByb3Bvc2VkIGFsbCBzb3VuZCBn b29kIHRvIG1lLg0KDQpDaGVlcnMNCg0KTWF0dA0KDQoNCkhlbGxvIE1hdHQsDQoNCg0KDQpMZWF2 aW5nIHRoZSBidWxrIG9mIHRoZSBlZGl0b3JpYWxzIHRvIHRoZSwgZXJtLCBlZGl0b3JzLi4uDQoN Cg0KDQo+IDMuMi41LCBmaXJzdCBidWxsZXQ6IOKAnFRoaXMgZ3JvdXAgb2YgT1RTaSBzaG91bGQg YmUgY2FycmllZCBvdmVyIGEgc2luZ2xlIGZpYnJlLuKAnSBJcyB0aGF0DQoNCj4gYSBub3JtYWwg RW5nbGlzaCBzaG91bGQsIG9yIGEgMjIxOSBTSE9VTEQ/IElmIHRoZSBmb3JtZXIsIGl0IG1pZ2h0 IGJlIHdvcnRoDQoNCj4gcmVwaHJhc2luZyB0byBhdm9pZCBhbWJpZ3VpdHkuDQoNCg0KDQpJdCBp cyBjZXJ0YWlubHkgbm90IDIxMTkgYmVjYXVzZSB3ZSBkbyBub3QgZGVmaW5lIGRhdGEgcGxhbmUg YmVoYXZpb3VyLg0KDQoNCg0KSSB3b3VsZCBmYXZvdXIgcy9zaG91bGQgYmUvYXJlLw0KDQoNCg0K PiA0LjI6IOKAnFRoZSBhc3NvY2lhdGlvbiBvZiB0aGUgdGhyZWUgY29tcG9uZW50cyBhIGZpbHRl ciwgYSBmaWJlciwgYW5kIGEgZmlsdGVyLCBpcyBhDQoNCj4gbWVkaWEgY2hhbm5lbCBpbiBpdHMg bW9zdCBiYXNpYyBmb3JtLuKAnS4gSXTigJlkIGJlIG5pY2UgdG8gY2xhcmlmeSB0aGF0IHRoaXMg aXMgYSBmaWJlcg0KDQo+IHdpdGggYSBmaWx0ZXIgYXQgZWFjaCBlbmQg4oCTIHRoYXTigJlzIG5v dCBpbW1lZGlhdGVseSBvYnZpb3VzIG9uIGZpcnN0IHJlYWRpbmcsDQoNCj4gZXNwZWNpYWxseSB3 aXRoIHRoZSBkaWFncmFtIHRoYXQgbWFrZXMgaXQgY2xlYXIgb24gdGhlIG5leHQgcGFnZS4NCg0K DQoNCnMvYXNzb2NpYXRpb24vYXNzb2NpYXRpb24gc2VxdWVuY2UvDQoNCg0KDQo+IDQuOC40OiBi ZWFyIGluIG1pbmQgdGhhdCAwIGlzIG5vdCBhIHBvc2l0aXZlIGludGVnZXIsIGFuZCBpdCBsb29r cyBsaWtlIHRoZSBkZWZpbml0aW9ucw0KDQo+IGludm9sdmluZyAoMl5uKSBhbmQgKDJebSkgYXJl IGludGVuZGVkIHRvIGluY2x1ZGUgdGhlIGNhc2Ugd2hlcmUgbi9tIGlzIDAuDQoNCg0KDQpZZWFo LCB3ZSBzaG91bGQgcHJvYmFibHkgc2F5ICJub24tbmVnYXRpdmUgaW50ZWdlciIgdG8gYmUgY29u c2lzdGVudCB3aXRoIHRoZSB1c2FnZSBpbiBjb21wdXRlciBzY2llbmNlLg0KDQpJdCB3b3VsZCBi ZSBPSyB0byB3cml0ZSDihJUwIGlmIG9ubHkgd2Ugc3VwcG9ydGVkIHVuaWNvZGUgYW5kIHN1cGVy c2NyaXB0IGluIEktRHMgOi0pDQoNCk9yIHBlcmhhcHMgYmVpbmcgbW9yZSBleHBsaWNpdCAidGhl IHNldCBvZiB6ZXJvIGFuZCBhbGwgcG9zaXRpdmUgaW50ZWdlcnMiLg0KDQoNCg0KVGhhbmtzIGZv ciB0aGUgcmV2aWV3LA0KDQpBZHJpYW4NCg== --_000_9D50FCE7413E3D4EA5E42331115FB5BC29C8720Fxmbrcdx03ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQm9va21hbiBPbGQgU3R5bGUiOw0KCXBh bm9zZS0xOjIgNSA2IDQgNSA1IDUgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5N c29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ bGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlBsYWluVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQm9va21hbiBP bGQgU3R5bGUiLCJzZXJpZiI7DQoJY29sb3I6IzYzMjQyMzt9DQpzcGFuLkVtYWlsU3R5bGUyMg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwi c2VyaWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPkFkcmlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojNjMyNDIzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtC b29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojNjMyNDIzIj5U aGUgYWx0ZXJuYXRpdmVzIHlvdeKAmXZlIHByb3Bvc2VkIGFsbCBzb3VuZCBnb29kIHRvIG1lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOiM2MzI0MjMiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0 MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xk IFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPk1hdHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjojNjMyNDIzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tR0IiPkhlbGxvIE1hdHQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5MZWF2aW5n IHRoZSBidWxrIG9mIHRoZSBlZGl0b3JpYWxzIHRvIHRoZSwgZXJtLCBlZGl0b3JzLi4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDMuMi41LCBmaXJzdCBidWxsZXQ6IOKAnFRoaXMgZ3Jv dXAgb2YgT1RTaSBzaG91bGQgYmUgY2FycmllZCBvdmVyIGEgc2luZ2xlIGZpYnJlLuKAnSBJcyB0 aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tR0IiPiZndDsgYSBub3JtYWwgRW5nbGlzaCBzaG91bGQsIG9yIGEgMjIxOSBTSE9V TEQ/IElmIHRoZSBmb3JtZXIsIGl0IG1pZ2h0IGJlIHdvcnRoDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyByZXBo cmFzaW5nIHRvIGF2b2lkIGFtYmlndWl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPkl0IGlz IGNlcnRhaW5seSBub3QgMjExOSBiZWNhdXNlIHdlIGRvIG5vdCBkZWZpbmUgZGF0YSBwbGFuZSBi ZWhhdmlvdXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5JIHdvdWxkIGZhdm91ciBzL3Nob3Vs ZCBiZS9hcmUvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IDQuMjog4oCcVGhlIGFzc29j aWF0aW9uIG9mIHRoZSB0aHJlZSBjb21wb25lbnRzIGEgZmlsdGVyLCBhIGZpYmVyLCBhbmQgYSBm aWx0ZXIsIGlzIGENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLUdCIj4mZ3Q7IG1lZGlhIGNoYW5uZWwgaW4gaXRzIG1vc3QgYmFz aWMgZm9ybS7igJ0uIEl04oCZZCBiZSBuaWNlIHRvIGNsYXJpZnkgdGhhdCB0aGlzIGlzIGEgZmli ZXINCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLUdCIj4mZ3Q7IHdpdGggYSBmaWx0ZXIgYXQgZWFjaCBlbmQg4oCTIHRoYXTigJlz IG5vdCBpbW1lZGlhdGVseSBvYnZpb3VzIG9uIGZpcnN0IHJlYWRpbmcsDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0 OyBlc3BlY2lhbGx5IHdpdGggdGhlIGRpYWdyYW0gdGhhdCBtYWtlcyBpdCBjbGVhciBvbiB0aGUg bmV4dCBwYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+cy9hc3NvY2lhdGlvbi9hc3NvY2lh dGlvbiBzZXF1ZW5jZS88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZndDsgNC44LjQ6IGJlYXIg aW4gbWluZCB0aGF0IDAgaXMgbm90IGEgcG9zaXRpdmUgaW50ZWdlciwgYW5kIGl0IGxvb2tzIGxp a2UgdGhlIGRlZmluaXRpb25zDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBpbnZvbHZpbmcgKDJebikgYW5kICgy Xm0pIGFyZSBpbnRlbmRlZCB0byBpbmNsdWRlIHRoZSBjYXNlIHdoZXJlIG4vbSBpcyAwLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1HQiI+WWVhaCwgd2Ugc2hvdWxkIHByb2JhYmx5IHNheSAmcXVvdDtu b24tbmVnYXRpdmUgaW50ZWdlciZxdW90OyB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIHVzYWdl IGluIGNvbXB1dGVyIHNjaWVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPkl0IHdvdWxkIGJlIE9LIHRvIHdyaXRlIDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEg TWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+4oSVPHN1cD4wPC9zdXA+IGlmIG9ubHkgd2Ug c3VwcG9ydGVkIHVuaWNvZGUgYW5kIHN1cGVyc2NyaXB0IGluIEktRHMgOi0pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPk9y IHBlcmhhcHMgYmVpbmcgbW9yZSBleHBsaWNpdCAmcXVvdDt0aGUgc2V0IG9mIHplcm8gYW5kIGFs bCBwb3NpdGl2ZSBpbnRlZ2VycyZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoYW5r cyBmb3IgdGhlIHJldmlldyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+QWRyaWFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9D50FCE7413E3D4EA5E42331115FB5BC29C8720Fxmbrcdx03ciscoc_-- From nobody Wed May 13 22:59:29 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035561B33B6 for ; Wed, 13 May 2015 22:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.598 X-Spam-Level: ** X-Spam-Status: No, score=2.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYJpnPs-C8yr for ; Wed, 13 May 2015 22:59:25 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5B1B33B5 for ; Wed, 13 May 2015 22:59:24 -0700 (PDT) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t4E5xOtY024143; Thu, 14 May 2015 14:59:24 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 56E9A5F63F; Thu, 14 May 2015 14:59:24 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1.m.ecl.ntt.co.jp [129.60.5.246]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 47BC35F631; Thu, 14 May 2015 14:59:24 +0900 (JST) Received: from [129.60.21.195] (neba-hp-shiomoto.silab.ecl.ntt.co.jp [129.60.21.195]) by imail1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t4E5xO8i017854; Thu, 14 May 2015 14:59:24 +0900 Message-ID: <55543A19.3040201@lab.ntt.co.jp> Date: Thu, 14 May 2015 15:00:57 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "ccamp@ietf.org" Content-Type: multipart/alternative; boundary="------------030307000005060504040001" X-TM-AS-MML: disable Archived-At: Subject: [CCAMP] SDN/MPLS 2015 CFP Announcement X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 05:59:27 -0000 This is a multi-part message in MIME format. --------------030307000005060504040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear CCAMP WG [Apologies, if you receive multiple copies of this CFP] --------------------------------------- Call for Presentation Abstract Proposals Now up at http://www.isocore.com/2015/cfp.htm Submissions Deadline: *May 18* Isocore's 2015 International Conference, the 18th Annual event on new networking technologies will be held November 15-18, 2015, in Washington, DC. This year, the overarching themes of the conference will be on *Softwarization (Integration of SDN and NFV), Programmatic Control, Security and Operational Experience of the Network **and Services in Cloud, Data Centers and DevOps environments*. The conference Program Committee is soliciting presentation proposals seeking original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. In particular, submission in at least the following topics areas are of interest * Cybersecurity, Security of the Cloud and Data Governance * Softwarization (Integration of SDN and NFV) of the Network and Services * Service Function Chaining * Mobile and Wireless Packet Infrastructure Please submit your abstracts to cfp2015@isocore.com Regards, -- Kohei Shiomoto, Ph.D Senior Manager, Communication Traffic & Service Quality Project NTT Network Technology Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION TEL +81-422-59-4402 FAX +81-422-59-6364 --------------030307000005060504040001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear CCAMP WG

[Apologies, if you receive multiple copies of this CFP]
---------------------------------------
Call for Presentation Abstract Proposals Now up at http://www.isocore.com/2015/cfp.htm

Submissions Deadline: May 18

Isocore's 2015 International Conference, the 18th Annual event on new networking technologies will be held November 15-18, 2015, in Washington, DC. This year, the overarching themes of the conference will be on Softwarization (Integration of SDN and NFV), Programmatic Control, Security and Operational Experience of the Network and Services in Cloud, Data Centers and DevOps environments.

The conference Program Committee is soliciting presentation proposals seeking original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise  users. In particular, submission in at least the following topics areas are of interest

* Cybersecurity, Security of the Cloud and Data Governance
* Softwarization (Integration of SDN and NFV) of the Network and Services
* Service Function Chaining
* Mobile and Wireless Packet Infrastructure

Please submit your abstracts to cfp2015@isocore.com

Regards,

--
Kohei Shiomoto, Ph.D
Senior Manager, Communication Traffic & Service Quality Project
NTT Network Technology Laboratories
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
TEL +81-422-59-4402   FAX +81-422-59-6364
--------------030307000005060504040001-- From nobody Thu May 14 02:22:25 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AD41AC41B for ; Thu, 14 May 2015 02:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.559 X-Spam-Level: *** X-Spam-Status: No, score=3.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_12=0.6, MANGLED_FORM=2.3, T_HTML_ATTACH=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssiSYFkv8xBb for ; Thu, 14 May 2015 02:22:12 -0700 (PDT) Received: from navarro.puc.rediris.es (navarro.puc.rediris.es [IPv6:2001:720:418:ca01::131]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E4F1ACEDE for ; Thu, 14 May 2015 02:22:10 -0700 (PDT) Received: from [2001:40b0:7c22:6020:78f1:9a85:af1c:f412] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YspLB-0006CF-K3 for ccamp@ietf.org; Thu, 14 May 2015 11:22:06 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id E54471FD05 for ; Thu, 14 May 2015 11:21:53 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <55546934.8070806@cttc.es> Date: Thu, 14 May 2015 11:21:56 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ccamp@ietf.org References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> Content-Type: multipart/mixed; boundary="------------060803020706090102050806" X-Spamina-Bogosity: Unsure Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:22:22 -0000 This is a multi-part message in MIME format. --------------060803020706090102050806 Content-Type: multipart/alternative; boundary="------------000200020501050002080907" --------------000200020501050002080907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear Matt, all Thank you very much for the review and comments, please see inline (aligned with Adrian's reply). For what is worth, there were some comments that I received post LC, that will also be in next updated version. El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribió: > > All, > > I’ve reviewed this revision of the document, and I think it’s almost > ready for publication. I have a few comments (below) but I don’t think > there’s any major issues. > > 3.1: definition of OTN could be moved up to section 2.2, if you want. > Ramon> Added as acronym, and removed the expansion, thank you > > 3.2.1: you state that the Nominal Central Frequency Granularity is > 6.25GHz, but there’s no reference for this. I assume it’s in an ITU > doc somewhere? If so, it’d be good to say so (and where) > Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1] > > The document refers to “OTSi signals” in several places, but the > definition of “OTSi” includes “signal” :) I don’t know whether or not > this is normal usage or whether it’s worth fixing… but it looks > technically wrong to me (like people talking about “PIN numbers” > whenever they get cash out of the bank). > Ramon> changed OTSi signals to OTSi > 3.2.5, first bullet: “This group of OTSi should be carried over a > single fibre.” Is that a normal English should, or a 2219 SHOULD? If > the former, it might be worth rephrasing to avoid ambiguity. > Ramon> changed to "are" as per Adrian's suggestion > > 4.2: “The association of the three components a filter, a fiber, and a > filter, is a media channel in its most basic form.”. It’d be nice to > clarify that this is a fiber with a filter at each end – that’s not > immediately obvious on first reading, especially with the diagram that > makes it clear on the next page. > Ramon> Likewise, changed to "association sequence" > The paragraph below figure 8 is... unclear. Is it just trying to say > that media channels can be joined together to make a new media > channel? Or is there more to it than that? > Ramon> Basically the intent is that one, although it should reflect more to the join of "basic" media channels (defined as an association sequence of filter-fiber-filter as above). This, and the architectural construct being an LSP. Changed to also use the term "association sequence" OLD Additionally, when a cross-connect for a specific frequency slot is considered, the underlying media support is still a media channel, augmented, so to speak, with a bigger association of media elements and a resulting effective slot. When this media channel is the result of the association of basic media channels and media layer matrix cross-connects, this architectural construct can be represented as (i.e., corresponds to) a Label Switched Path (LSP) from a control plane perspective. In other words, It is possible to "concatenate" several media channels (e.g., Patch on intermediate nodes) to create a single media channel. NEW Additionally, when a cross-connect for a specific frequency slot is considered, the resulting media support of joining basic media channels is still a media channel, i.e., a longer association sequence of media elements and its effective frequency slot. In other words, It is possible to "concatenate" several media channels (e.g., patch on intermediate nodes) to create a single media channel. The architectural construct resulting of the association sequence of basic media channels and media layer matrix cross-connects can be represented as (i.e., corresponds to) a Label Switched Path (LSP) from a control plane perspective. > Fig 12: OTSi trail? Did you mean OCh trail? > Ramon> The error comes from the text, since the correct term is OTSi. OLD In Figure 12 a Network Media Channel is represented as terminated at the DWDM side of the transponder. This is commonly named as OCh- trail connection. NEW In Figure 12 a Network Media Channel is represented as terminated at the network side of the transponders. This is commonly named as OTSi- trail connection. > Fig 14: MLN/MRN needs explaining. Or removing. > Ramon> Removed. > > 4.3, towards the end: “there must be enough guard band between > adjacent OTSis in any media channel to compensate filter concatenation > effect and other effects caused by signal layer switching elements”. > Maybe “…to compensate for the filter concatenation effect and…” or > “…to compensate for filter concatenation effects and…”? > Ramon> new text "there must be enough guard band between adjacent OTSis in any media channel to compensate for the filter concatenation effects and other effects caused by signal layer switching elements" > 4.8.4: bear in mind that 0 is not a positive integer, and it looks > like the definitions involving (2^n) and (2^m) are intended to include > the case where n/m is 0. > Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving it as positive integer, since m=0 would imply an empty frequency slot. If no further comments, I will proceed to upload these changes for -04 (with other backlogged changes such as affiliation changes, CCAMP WG, Informational, nits, editorial changes , typos, etc. ). Please see the attached diff Thanks Ramon --------------000200020501050002080907 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear Matt, all

Thank you very much for the review and comments, please see inline (aligned with Adrian's reply).

For what is worth, there were some comments that I received post LC, that will also be in next updated version.


El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribió:

All,

 

I’ve reviewed this revision of the document, and I think it’s almost ready for publication. I have a few comments (below) but I don’t think there’s any major issues.

 

3.1: definition of OTN could be moved up to section 2.2, if you want.

Ramon> Added as acronym, and removed the expansion, thank you

 

3.2.1: you state that the Nominal Central Frequency Granularity is 6.25GHz, but there’s no reference for this. I assume it’s in an ITU doc somewhere? If so, it’d be good to say so (and where)

Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1]

 

The document refers to “OTSi signals” in several places, but the definition of “OTSi” includes “signal” :) I don’t know whether or not this is normal usage or whether it’s worth fixing… but it looks technically wrong to me (like people talking about “PIN numbers” whenever they get cash out of the bank).

 

Ramon> changed OTSi signals to OTSi

3.2.5, first bullet: “This group of OTSi should be carried over a single fibre.” Is that a normal English should, or a 2219 SHOULD? If the former, it might be worth rephrasing to avoid ambiguity.

Ramon> changed to "are" as per Adrian's suggestion

 

4.2: “The association of the three components a filter, a fiber, and a filter, is a media channel in its most basic form.”. It’d be nice to clarify that this is a fiber with a filter at each end – that’s not immediately obvious on first reading, especially with the diagram that makes it clear on the next page.

 

Ramon> Likewise, changed to "association sequence"

The paragraph below figure 8 is... unclear. Is it just trying to say that media channels can be joined together to make a new media channel? Or is there more to it than that?

 

Ramon> Basically the intent is that one, although it should reflect more to the join of "basic" media channels (defined as an association sequence of filter-fiber-filter as above). This, and the architectural construct being an LSP.  Changed to also use the term "association sequence"

OLD
   Additionally, when a cross-connect for a specific frequency slot is
   considered, the underlying media support is still a media channel,
   augmented, so to speak, with a bigger association of media elements
   and a resulting effective slot.  When this media channel is the
   result of the association of basic media channels and media layer
   matrix cross-connects, this architectural construct can be
   represented as (i.e., corresponds to) a Label Switched Path (LSP)
   from a control plane perspective.  In other words, It is possible to
   "concatenate" several media channels (e.g., Patch on intermediate
   nodes) to create a single media channel.

NEW
   Additionally, when a cross-connect for a specific frequency slot is
   considered, the resulting media support of joining basic media channels
   is still a media channel, i.e., a longer association sequence of media 
   elements and its effective frequency slot. In other words, It is possible to
   "concatenate" several media channels (e.g., patch on intermediate
   nodes) to create a single media channel.

   The architectural construct resulting of the association sequence 
   of basic media channels and media layer matrix cross-connects can be
   represented as (i.e., corresponds to) a Label Switched Path (LSP)
   from a control plane perspective.


Fig 12: OTSi trail? Did you mean OCh trail?

Ramon> The error comes from the text, since the correct term is OTSi.

OLD 
   In Figure 12 a Network Media Channel is represented as terminated at
   the DWDM side of the transponder.  This is commonly named as OCh-
   trail connection.
NEW
   In Figure 12 a Network Media Channel is represented as terminated at
   the network side of the transponders.  This is commonly named as OTSi-
   trail connection.

 

Fig 14: MLN/MRN needs explaining. Or removing.

Ramon> Removed.

 

4.3, towards the end: “there must be enough guard band between adjacent OTSis in any media channel to compensate filter concatenation effect and other effects caused by signal layer switching elements”. Maybe “…to compensate for the filter concatenation effect and…” or “…to compensate for filter concatenation effects and…”?

 

Ramon> new text
"there must be  enough guard band between adjacent OTSis in any media channel to  compensate for the filter concatenation effects and other effects caused by signal layer switching elements"

4.8.4: bear in mind that 0 is not a positive integer, and it looks like the definitions involving (2^n) and (2^m) are intended to include the case where n/m is 0.

Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving it as positive integer, since m=0 would imply an empty frequency slot.


If no further comments, I will proceed to upload these changes for -04 (with other backlogged changes such as affiliation changes, CCAMP WG, Informational, nits, editorial changes , typos, etc. ). Please see the attached diff


Thanks
Ramon

--------------000200020501050002080907-- --------------060803020706090102050806 Content-Type: text/html; charset=UTF-8; name="Diff_ draft-ietf-ccamp-flexi-grid-fwk-03.txt - draft-ietf-ccamp-flexi-grid-fwk-04.txt.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-ccamp-flexi-grid-fwk-03.txt - draft-ietf-cc"; filename*1="amp-flexi-grid-fwk-04.txt.html" Diff: draft-ietf-ccamp-flexi-grid-fwk-03.txt - draft-ietf-ccamp-flexi-grid-fwk-04.txt
< draft-ietf-ccamp-flexi-grid-fwk-03.txt   draft-ietf-ccamp-flexi-grid-fwk-04.txt >
Network Working Group O. Gonzalez de Dios, Ed. CCAMP Working Group O. Gonzalez de Dios, Ed.
Internet-Draft Telefonica I+D Internet-Draft Telefonica I+D
Intended status: Standards Track R. Casellas, Ed. Intended status: Informational R. Casellas, Ed.
Expires: August 27, 2015 CTTC Expires: November 15, 2015 CTTC
F. Zhang F. Zhang
Huawei Huawei
X. Fu X. Fu
ZTE ZTE
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
I. Hussain I. Hussain
Infinera Infinera
February 23, 2015 May 14, 2015
Framework and Requirements for GMPLS-based control of Flexi-grid DWDM Framework and Requirements for GMPLS-based control of Flexi-grid DWDM
networks networks
draft-ietf-ccamp-flexi-grid-fwk-03 draft-ietf-ccamp-flexi-grid-fwk-04
Abstract Abstract
To allow efficient allocation of optical spectral bandwidth for high To allow efficient allocation of optical spectral bandwidth for high
bit-rate systems, the International Telecommunication Union bit-rate systems, the International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) has extended its Telecommunication Standardization Sector (ITU-T) has extended its
Recommendations G.694.1 and G.872 to include a new dense wavelength Recommendations G.694.1 and G.872 to include a new dense wavelength
division multiplexing (DWDM) grid by defining a set of nominal division multiplexing (DWDM) grid by defining a set of nominal
central frequencies, channel spacings and the concept of "frequency central frequencies, channel spacings and the concept of "frequency
slot". In such an environment, a data plane connection is switched slot". In such an environment, a data plane connection is switched
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2015. This Internet-Draft will expire on November 15, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Flexi-grid Networks . . . . . . . . . . . . . . . 5 3. Overview of Flexi-grid Networks . . . . . . . . . . . . . . . 5
3.1. Flexi-grid in the Context of OTN . . . . . . . . . . . . 5 3.1. Flexi-grid in the Context of OTN . . . . . . . . . . . . 5
3.2. Flexi-grid Terminology . . . . . . . . . . . . . . . . . 6 3.2. Flexi-grid Terminology . . . . . . . . . . . . . . . . . 6
3.2.1. Frequency Slots . . . . . . . . . . . . . . . . . . . 6 3.2.1. Frequency Slots . . . . . . . . . . . . . . . . . . . 6
3.2.2. Media Channels . . . . . . . . . . . . . . . . . . . 8 3.2.2. Media Layer Elements . . . . . . . . . . . . . . . . 8
3.2.3. Media Layer Elements . . . . . . . . . . . . . . . . 8 3.2.3. Media Channels . . . . . . . . . . . . . . . . . . . 8
3.2.4. Optical Tributary Signals . . . . . . . . . . . . . . 9 3.2.4. Optical Tributary Signals . . . . . . . . . . . . . . 9
3.2.5. Composite Media Channels . . . . . . . . . . . . . . 9 3.2.5. Composite Media Channels . . . . . . . . . . . . . . 9
3.3. Hierarchy in the Media Layer . . . . . . . . . . . . . . 10 3.3. Hierarchy in the Media Layer . . . . . . . . . . . . . . 10
3.4. Flexi-grid Layered Network Model . . . . . . . . . . . . 10 3.4. Flexi-grid Layered Network Model . . . . . . . . . . . . 10
3.4.1. DWDM Flexi-grid Enabled Network Element Models . . . 12 3.4.1. DWDM Flexi-grid Enabled Network Element Models . . . 12
4. GMPLS Applicability . . . . . . . . . . . . . . . . . . . . . 12 4. GMPLS Applicability . . . . . . . . . . . . . . . . . . . . . 12
4.1. General Considerations . . . . . . . . . . . . . . . . . 12 4.1. General Considerations . . . . . . . . . . . . . . . . . 12
4.2. Consideration of TE Links . . . . . . . . . . . . . . . . 13 4.2. Consideration of TE Links . . . . . . . . . . . . . . . . 13
4.3. Consideration of LSPs in Flexi-grid . . . . . . . . . . . 16 4.3. Consideration of LSPs in Flexi-grid . . . . . . . . . . . 15
4.4. Control Plane Modeling of Network Elements . . . . . . . 21 4.4. Control Plane Modeling of Network Elements . . . . . . . 20
4.5. Media Layer Resource Allocation Considerations . . . . . 21 4.5. Media Layer Resource Allocation Considerations . . . . . 20
4.6. Neighbor Discovery and Link Property Correlation . . . . 25 4.6. Neighbor Discovery and Link Property Correlation . . . . 24
4.7. Path Computation / Routing and Spectrum Assignment (RSA) 26 4.7. Path Computation / Routing and Spectrum Assignment (RSA) 25
4.7.1. Architectural Approaches to RSA . . . . . . . . . . . 26 4.7.1. Architectural Approaches to RSA . . . . . . . . . . . 25
4.8. Routing and Topology Dissemination . . . . . . . . . . . 27 4.8. Routing and Topology Dissemination . . . . . . . . . . . 26
4.8.1. Available Frequency Ranges/Slots of DWDM Links . . . 28 4.8.1. Available Frequency Ranges/Slots of DWDM Links . . . 27
4.8.2. Available Slot Width Ranges of DWDM Links . . . . . . 28 4.8.2. Available Slot Width Ranges of DWDM Links . . . . . . 27
4.8.3. Spectrum Management . . . . . . . . . . . . . . . . . 28 4.8.3. Spectrum Management . . . . . . . . . . . . . . . . . 27
4.8.4. Information Model . . . . . . . . . . . . . . . . . . 28 4.8.4. Information Model . . . . . . . . . . . . . . . . . . 27
5. Control Plane Requirements . . . . . . . . . . . . . . . . . 30 5. Control Plane Requirements . . . . . . . . . . . . . . . . . 29
5.1. Support for Media Channels . . . . . . . . . . . . . . . 30 5.1. Support for Media Channels . . . . . . . . . . . . . . . 29
5.1.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 31 5.1.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 30
5.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 31 5.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Support for Media Channel Resizing . . . . . . . . . . . 32 5.2. Support for Media Channel Resizing . . . . . . . . . . . 31
5.3. Support for Logical Associations of Multiple Media 5.3. Support for Logical Associations of Multiple Media
Channels . . . . . . . . . . . . . . . . . . . . . . . . 32 Channels . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Support for Composite Media Channels . . . . . . . . . . 32 5.4. Support for Composite Media Channels . . . . . . . . . . 31
5.5. Support for Neighbor Discovery and Link Property 5.5. Support for Neighbor Discovery and Link Property
Correlation . . . . . . . . . . . . . . . . . . . . . . . 32 Correlation . . . . . . . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. Manageability Considerations . . . . . . . . . . . . . . . . 33 8. Manageability Considerations . . . . . . . . . . . . . . . . 32
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 34 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 33
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The term "Flexible grid" (flexi-grid for short) as defined by the The term "Flexible grid" (flexi-grid for short) as defined by the
International Telecommunication Union Telecommunication International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) Study Group 15 in the latest version Standardization Sector (ITU-T) Study Group 15 in the latest version
of [G.694.1], refers to the updated set of nominal central of [G.694.1], refers to the updated set of nominal central
frequencies (a frequency grid), channel spacing and optical spectrum frequencies (a frequency grid), channel spacing and optical spectrum
management/allocation considerations that have been defined in order management/allocation considerations that have been defined in order
to allow an efficient and flexible allocation and configuration of to allow an efficient and flexible allocation and configuration of
skipping to change at page 4, line 10 skipping to change at page 4, line 10
optical spectrum frequency ranges or frequency slots with typical optical spectrum frequency ranges or frequency slots with typical
channel separations of 50 GHz, a flexible grid network can select its channel separations of 50 GHz, a flexible grid network can select its
media channels with a more flexible choice of slot widths, allocating media channels with a more flexible choice of slot widths, allocating
as much optical spectrum as required. as much optical spectrum as required.
From a networking perspective, a flexible grid network is assumed to From a networking perspective, a flexible grid network is assumed to
be a layered network [G.872][G.800] in which the media layer is the be a layered network [G.872][G.800] in which the media layer is the
server layer and the optical signal layer is the client layer. In server layer and the optical signal layer is the client layer. In
the media layer, switching is based on a frequency slot, and the size the media layer, switching is based on a frequency slot, and the size
of a media channel is given by the properties of the associated of a media channel is given by the properties of the associated
frequency slot. In this layered network, the media channel can frequency slot. In this layered network, a media channel can
transport more than one Optical Tributary Signals. transport more than one Optical Tributary Signals (OTSi), as defined
later in this document.
A Wavelength Switched Optical Network (WSON), addressed in [RFC6163], A Wavelength Switched Optical Network (WSON), addressed in [RFC6163],
is a term commonly used to refer to the application/deployment of a is a term commonly used to refer to the application/deployment of a
GMPLS-based control plane for the control (provisioning/recovery, GMPLS-based control plane for the control (provisioning/recovery,
etc.) of a fixed grid wavelength division multiplexing (WDM) network etc.) of a fixed grid wavelength division multiplexing (WDM) network
in which media (spectrum) and signal are jointly considered. in which media (spectrum) and signal are jointly considered.
This document defines the framework for a GMPLS-based control of This document defines the framework for a GMPLS-based control of
flexi-grid enabled dense wavelength division multiplexing (DWDM) flexi-grid enabled dense wavelength division multiplexing (DWDM)
networks (in the scope defined by ITU-T layered Optical Transport networks (in the scope defined by ITU-T layered Optical Transport
skipping to change at page 4, line 51 skipping to change at page 5, line 4
FS: Frequency Slot FS: Frequency Slot
FSC: Fiber-Switch Capable FSC: Fiber-Switch Capable
LSR: Label Switching Router LSR: Label Switching Router
NCF: Nominal Central Frequency NCF: Nominal Central Frequency
OCh: Optical Channel OCh: Optical Channel
OCh-P: Optical Channel Payload OCh-P: Optical Channel Payload
OTN: Optical Transport Network
OTSi: Optical Tributary Signal OTSi: Optical Tributary Signal
OTSiG: OTSi Group is the set of OTSi signals OTSiG: OTSi Group is a set of OTSi
OCC: Optical Channel Carrier OCC: Optical Channel Carrier
PCE: Path Computation Element PCE: Path Computation Element
ROADM: Reconfigurable Optical Add-Drop Multiplexer ROADM: Reconfigurable Optical Add-Drop Multiplexer
SSON: Spectrum-Switched Optical Network SSON: Spectrum-Switched Optical Network
SWG: Slot Width Granularity SWG: Slot Width Granularity
3. Overview of Flexi-grid Networks 3. Overview of Flexi-grid Networks
3.1. Flexi-grid in the Context of OTN 3.1. Flexi-grid in the Context of OTN
[G.872] describes, from a network level, the functional architecture [G.872] describes, from a network level, the functional architecture
of Optical Transport Networks (OTN). The OTN is decomposed into of an OTN. It is decomposed into independent layer networks with
independent layer networks with client/layer relationships among client/layer relationships among them. A simplified view of the OTN
them. A simplified view of the OTN layers is shown in Figure 1. layers is shown in Figure 1.
+----------------+ +----------------+
| Digital Layer | | Digital Layer |
+----------------+ +----------------+
| Signal Layer | | Signal Layer |
+----------------+ +----------------+
| Media Layer | | Media Layer |
+----------------+ +----------------+
Figure 1: Generic OTN Overview Figure 1: Generic OTN Overview
skipping to change at page 6, line 17 skipping to change at page 6, line 17
This section presents the definition of the terms used in flexi-grid This section presents the definition of the terms used in flexi-grid
networks. More detail about these terms can be found in the ITU-T networks. More detail about these terms can be found in the ITU-T
Recommendations [G.694.1], [G.872]), [G.870], [G.8080], and Recommendations [G.694.1], [G.872]), [G.870], [G.8080], and
[G.959.1-2013]. [G.959.1-2013].
Where appropriate, this documents also uses terminology and Where appropriate, this documents also uses terminology and
lexicography from [RFC4397]. lexicography from [RFC4397].
3.2.1. Frequency Slots 3.2.1. Frequency Slots
This subsection is focused on the frequency slot related terms. This subsection is focused on the frequency slot and related terms.
o Frequency Slot [G.694.1]: The frequency range allocated to a slot o Frequency Slot [G.694.1]: The frequency range allocated to a slot
within the flexible grid and unavailable to other slots. A within the flexible grid and unavailable to other slots. A
frequency slot is defined by its nominal central frequency and its frequency slot is defined by its nominal central frequency and its
slot width. slot width.
o Effective Frequency Slot [G.870]: The effective frequency slot of
a media channel is that part of the frequency slots of the filters
along the media channel that is common to all of the filters'
frequency slots. Note that both the Frequency Slot and Effective
Frequency Slot are both local terms.
o Nominal Central Frequency: Each of the allowed frequencies as per o Nominal Central Frequency: Each of the allowed frequencies as per
the definition of flexible DWDM grid in [G.694.1]. The set of the definition of flexible DWDM grid in [G.694.1]. The set of
nominal central frequencies can be built using the following nominal central frequencies can be built using the following
expression expression
f = 193.1 THz + n x 0.00625 THz f = 193.1 THz + n x 0.00625 THz
where 193.1 THz is ITU-T "anchor frequency" for transmission over where 193.1 THz is ITU-T "anchor frequency" for transmission over
the C band, and n is a positive or negative integer including 0. the C band, and n is a positive or negative integer including 0.
-5 -4 -3 -2 -1 0 1 2 3 4 5 <- values of n -5 -4 -3 -2 -1 0 1 2 3 4 5 <- values of n
...+--+--+--+--+--+--+--+--+--+--+- ...+--+--+--+--+--+--+--+--+--+--+-
^ ^
193.1 THz <- anchor frequency 193.1 THz <- anchor frequency
Figure 2: Anchor Frequency and Set of Nominal Central Frequencies Figure 2: Anchor Frequency and Set of Nominal Central Frequencies
o Nominal Central Frequency Granularity: This is the spacing between o Nominal Central Frequency Granularity: This is the spacing between
allowed nominal central frequencies and it is set to 6.25 GHz. allowed nominal central frequencies and it is set to 6.25 GHz
[G.694.1].
o Slot Width Granularity (SWG): 12.5 GHz, as defined in [G.694.1]. o Slot Width Granularity (SWG): 12.5 GHz, as defined in [G.694.1].
o Slot Width: The slot width determines the "amount" of optical o Slot Width: The slot width determines the "amount" of optical
spectrum regardless of its actual "position" in the frequency spectrum regardless of its actual "position" in the frequency
axis. A slot width is constrained to be m x SWG (that is, m x axis. A slot width is constrained to be m x SWG (that is, m x
12.5 GHz), where m is an integer greater than or equal to 1. 12.5 GHz), where m is an integer greater than or equal to 1.
Frequency Slot 1 Frequency Slot 2 Frequency Slot 1 Frequency Slot 2
------------- ------------------- ------------- -------------------
skipping to change at page 7, line 34 skipping to change at page 7, line 29
* The symbol '+' represents the allowed nominal central * The symbol '+' represents the allowed nominal central
frequencies frequencies
* The '--' represents the nominal central frequency granularity * The '--' represents the nominal central frequency granularity
* The '^' represents the slot nominal central frequency * The '^' represents the slot nominal central frequency
* The number on the top of the '+' symbol represents the 'n' in * The number on the top of the '+' symbol represents the 'n' in
the frequency calculation formula. the frequency calculation formula.
* The nominal central frequency is 193.1 THz when n equals zero. * The nominal central frequency is 193.1 THz when n equals to
zero.
o Effective Frequency Slot: The effective frequency slot of a media o Effective Frequency Slot [G.870]: The effective frequency slot of
channel is the common part of the frequency slots along the media a media channel is that part of the frequency slots of the filters
channel through a particular path through the optical network. It along the media channel that is common to all of the filters'
is a logical construct derived from the (intersection of) frequency slots. Note that both the Frequency Slot and Effective
frequency slots allocated to each device in the path. The Frequency Slot are local terms.
effective frequency slot is an attribute of a media channel and,
being a frequency slot, it is described by its nominal central
frequency and slot width, according to the already described
rules.
Frequency Slot 1 Frequency Slot 1
------------- -------------
| | | |
-3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11
..--+--+--+--+--X--+--+--+--+--+--+--+--+--+--+--+--... ..--+--+--+--+--X--+--+--+--+--+--+--+--+--+--+--+--...
Frequency Slot 2 Frequency Slot 2
------------------- -------------------
| | | |
skipping to change at page 8, line 26 skipping to change at page 8, line 26
=============================================== ===============================================
Effective Frequency Slot Effective Frequency Slot
------------- -------------
| | | |
-3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11
..--+--+--+--+--X--+--+--+--+--+--+--+--+--+--+--+--... ..--+--+--+--+--X--+--+--+--+--+--+--+--+--+--+--+--...
Figure 4: Effective Frequency Slot Figure 4: Effective Frequency Slot
3.2.2. Media Channels 3.2.2. Media Layer Elements
o Media Element: A media element directs an optical signal or
affects the properties of an optical signal. It does not modify
the properties of the information that has been modulated to
produce the optical signal [G.870]. Examples of media elements
include fibers, amplifiers, filters, and switching matrices.
o Media Channel Matrixes: The media channel matrix provides flexible
connectivity for the media channels. That is, it represents a
point of flexibility where relationships between the media ports
at the edge of a media channel matrix may be created and broken.
The relationship between these ports is called a matrix channel.
(Network) Media Channels are switched in a Media Channel Matrix.
3.2.3. Media Channels
This section defines concepts such as (Network) Media Channel; the This section defines concepts such as (Network) Media Channel; the
mapping to GMPLS constructs (i.e., LSP) is detailed in Section 4. mapping to GMPLS constructs (i.e., LSP) is detailed in Section 4.
o Media Channel: A media association that represents both the o Media Channel: A media association that represents both the
topology (i.e., path through the media) and the resource topology (i.e., path through the media) and the resource
(frequency slot) that it occupies. As a topological construct, it (frequency slot) that it occupies. As a topological construct, it
represents a frequency slot (an effective frequency slot) represents a frequency slot (an effective frequency slot)
supported by a concatenation of media elements (fibers, supported by a concatenation of media elements (fibers,
amplifiers, filters, switching matrices...). This term is used to amplifiers, filters, switching matrices...). This term is used to
identify the end-to-end physical layer entity with its identify the end-to-end physical layer entity with its
corresponding (one or more) frequency slots local at each link corresponding (one or more) frequency slots local at each link
filters. filters.
o Network Media Channel: [G.870] defines the Network Media Channel o Network Media Channel: [G.870] defines the Network Media Channel
in terms of the media channel that transports the OTSi. This as a media channel that transports a single OTSi, defined next.
document broadens the definition to cover any OTSi so that a
Network Media Channel is a media channel that transports an OTSi.
3.2.3. Media Layer Elements
o Media Element: A media element directs an optical signal or
affects the properties of an optical signal. It does not modify
the properties of the information that has been modulated to
produce the optical signal [G.870]. Examples of media elements
include fibers, amplifiers, filters, and switching matrices.
o Media Channel Matrixes: The media channel matrix provides flexible
connectivity for the media channels. That is, it represents a
point of flexibility where relationships between the media ports
at the edge of a media channel matrix may be created and broken.
The relationship between these ports is called a matrix channel.
(Network) Media Channels are switched in a Media Channel Matrix.
3.2.4. Optical Tributary Signals 3.2.4. Optical Tributary Signals
o Optical Tributary Signal (OTSi) [G.959.1-2013]: The optical signal o Optical Tributary Signal (OTSi) [G.959.1-2013]: The optical signal
that is placed within a network media channel for transport across that is placed within a network media channel for transport across
the optical network. This may consist of a single modulated the optical network. This may consist of a single modulated
optical carrier or a group of modulated optical carriers or optical carrier or a group of modulated optical carriers or
subcarriers. To provide a connection between the OTSi source and subcarriers. To provide a connection between the OTSi source and
the OTSi sink the optical signal must be assigned to a network the OTSi sink the optical signal must be assigned to a network
media channel. media channel.
o OTSi Group (OTSiG): The set of OTSi signals that are carried by a o OTSi Group (OTSiG): The set of OTSi that are carried by a group of
group of network media channels. Each OTSi is carried by one network media channels. Each OTSi is carried by one network media
network media channel. From a management perspective it should be channel. From a management perspective it SHOULD be possible to
possible to manage both the OTSiG and a group of Network Media manage both the OTSiG and a group of Network Media Channels as
Channels as single entities. single entities.
3.2.5. Composite Media Channels 3.2.5. Composite Media Channels
o It is possible to construct an end-to-end media channel as a o It is possible to construct an end-to-end media channel as a
composite of more than one network media channels. A composite composite of more than one network media channels. A composite
media channel carries a group of OTSi (i.e., OTSiG). Each OTSi is media channel carries a group of OTSi (i.e., OTSiG). Each OTSi is
carried by one network media channel. This group of OTSi should carried by one network media channel. This group of OTSi are
be carried over a single fibre. carried over a single fibre.
o In this case, the effective frequency slots may be contiguous o In this case, the effective frequency slots may be contiguous
(i.e., there is no spectrum between them that can be used for (i.e., there is no spectrum between them that can be used for
other media channels) or non-contiguous. other media channels) or non-contiguous.
o It is not currently envisaged that such composite media channels o It is not currently envisaged that such composite media channels
may be constructed from slots carried on different fibers whether may be constructed from slots carried on different fibers whether
those fibers traverse the same hop-by-hop path through the network those fibers traverse the same hop-by-hop path through the network
or not. or not.
skipping to change at page 10, line 19 skipping to change at page 10, line 19
In summary, the concept of frequency slot is a logical abstraction In summary, the concept of frequency slot is a logical abstraction
that represents a frequency range, while the media layer represents that represents a frequency range, while the media layer represents
the underlying media support. Media Channels are media associations, the underlying media support. Media Channels are media associations,
characterized by their (effective) frequency slot, respectively; and characterized by their (effective) frequency slot, respectively; and
media channels are switched in media channel matrixes. From the media channels are switched in media channel matrixes. From the
control and management perspective, a media channel can be logically control and management perspective, a media channel can be logically
split into network media channels. split into network media channels.
In Figure 5, a media channel has been configured and dimensioned to In Figure 5, a media channel has been configured and dimensioned to
support two network media channels, each of them carrying one optical support two network media channels, each of them carrying one OTSi.
tributary signal.
Media Channel Frequency Slot Media Channel Frequency Slot
+-------------------------------X------------------------------+ +-------------------------------X------------------------------+
| | | |
| Frequency Slot Frequency Slot | | Frequency Slot Frequency Slot |
| +------------X-----------+ +----------X-----------+ | | +------------X----------+ +----------X-----------+ |
| | Opt Tributary Signal | | Opt Tributary Signal | | | | OTSi | | OTSi | |
| | o | | o | | | | o | | o | |
| | | | | | | | | | | | | | | |
-4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12
--+---+---+---+---+---+---+---+---+---+---+---+--+---+---+---+---+-- --+---+---+---+---+---+---+---+---+---+---+---+--+---+---+---+---+--
<- Network Media Channel-> <- Network Media Channel-> <- Network Media Channel-> <- Network Media Channel->
<------------------------ Media Channel -----------------------> <------------------------ Media Channel ----------------------->
X - Frequency Slot Central Frequency X - Frequency Slot Central Frequency
o - signal central frequency o - Signal Central Frequency
Figure 5: Example of Media Channel / Network Media Channels and Figure 5: Example of Media Channel / Network Media Channels and
Associated Frequency Slots Associated Frequency Slots
3.4. Flexi-grid Layered Network Model 3.4. Flexi-grid Layered Network Model
In the OTN layered network, the network media channel transports a In the OTN layered network, the network media channel transports a
single Optical Tributary Signal (see Figure 6) single OTSi (see Figure 6)
| Optical Tributary Signal | | OTSi |
O - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O O - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O
| | | |
| Channel Port Network Media Channel Channel Port | | Channel Port Network Media Channel Channel Port |
O - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O O - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O
| | | |
+--------+ +-----------+ +--------+ +--------+ +-----------+ +--------+
| \ (1) | | (1) | | (1) / | | \ (1) | | (1) | | (1) / |
| \----|-----------------|-----------|-------------------|-----/ | | \----|-----------------|-----------|-------------------|-----/ |
+--------+ Link Channel +-----------+ Link Channel +--------+ +--------+ Link Channel +-----------+ Link Channel +--------+
Media Channel Media Channel Media Channel Media Channel Media Channel Media Channel
Matrix Matrix Matrix Matrix Matrix Matrix
The symbol (1) indicates a Matrix Channel The symbol (1) indicates a Matrix Channel
Figure 6: Simplified Layered Network Model Figure 6: Simplified Layered Network Model
A particular example of Optical Tributary Signal is the OCh-P. Note that a particular example of OTSi is the OCh-P. Figure 7 shows
Figure 7 shows this specific example as defined in G.805 [G.805]. this specific example as defined in G.805 [G.805].
OCh AP Trail (OCh) OCh AP OCh AP Trail (OCh) OCh AP
O- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O O- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - O
| | | |
--- OCh-P OCh-P --- --- OCh-P OCh-P ---
\ / source sink \ / \ / source sink \ /
+ + + +
| OCh-P OCh-P Network Connection OCh-P | | OCh-P OCh-P Network Connection OCh-P |
O TCP - - - - - - - - - - - - - - - - - - - - - - - - - - -TCP O O TCP - - - - - - - - - - - - - - - - - - - - - - - - - - -TCP O
| | | |
skipping to change at page 12, line 5 skipping to change at page 12, line 5
| \ (1) | OCh-P LC | (1) | OCh-P LC | (1) / | | \ (1) | OCh-P LC | (1) | OCh-P LC | (1) / |
| \----|-----------------|-----------|-----------------|------/ | | \----|-----------------|-----------|-----------------|------/ |
+--------+ Link Channel +-----------+ Link Channel +---------+ +--------+ Link Channel +-----------+ Link Channel +---------+
Media Channel Media Channel Media Channel Media Channel Media Channel Media Channel
Matrix Matrix Matrix Matrix Matrix Matrix
The symbol (1) indicates a Matrix Channel The symbol (1) indicates a Matrix Channel
Figure 7: Layered Network Model According to G.805 Figure 7: Layered Network Model According to G.805
By definition, a network media channel supports only a single Optical
Tributary Signal.
3.4.1. DWDM Flexi-grid Enabled Network Element Models 3.4.1. DWDM Flexi-grid Enabled Network Element Models
A flexible grid network is constructed from subsystems that include A flexible grid network is constructed from subsystems that include
WDM links, tunable transmitters, and receivers, (i.e, media elements WDM links, tunable transmitters, and receivers, (i.e, media elements
including media layer switching elements that are media matrices) as including media layer switching elements that are media matrices) as
well as electro-optical network elements. This is just the same as well as electro-optical network elements. This is just the same as
in a fixed grid network except that each element has flexible grid in a fixed grid network except that each element has flexible grid
characteristics. characteristics.
As stated in Clause 7 of [G.694.1] the flexible DWDM grid has a As stated in Clause 7 of [G.694.1] the flexible DWDM grid has a
skipping to change at page 13, line 4 skipping to change at page 12, line 50
between the architectural concept/construct of media channel and its between the architectural concept/construct of media channel and its
control plane representations (e.g., as a TE link). control plane representations (e.g., as a TE link).
4.1. General Considerations 4.1. General Considerations
The GMPLS control of the media layer deals with the establishment of The GMPLS control of the media layer deals with the establishment of
media channels that are switched in media channel matrices. GMPLS media channels that are switched in media channel matrices. GMPLS
labels are used to locally represent the media channel and its labels are used to locally represent the media channel and its
associated frequency slot. Network media channels are considered a associated frequency slot. Network media channels are considered a
particular case of media channels when the end points are particular case of media channels when the end points are
transceivers (that is, source and destination of an Optical Tributary transceivers (that is, source and destination of an OTSi).
Signal)
4.2. Consideration of TE Links 4.2. Consideration of TE Links
From a theoretical / abstract point of view, a fiber can be modeled From a theoretical / abstract point of view, a fiber can be modeled
as having a frequency slot that ranges from minus infinity to plus as having a frequency slot that ranges from minus infinity to plus
infinity. This representation helps understand the relationship infinity. This representation helps understand the relationship
between frequency slots and ranges. between frequency slots and ranges.
The frequency slot is a local concept that applies within a component The frequency slot is a local concept that applies within a component
or element. When applied to a media channel, we are referring to its or element. When applied to a media channel, we are referring to its
effective frequency slot as defined in [G.872]. effective frequency slot as defined in [G.872].
The association of the three components a filter, a fiber, and a The association sequence of the three components (i.e., a filter, a
filter, is a media channel in its most basic form. From the control fiber, and a filter), is a media channel in its most basic form.
plane perspective this may modeled as a (physical) TE-link with a From the control plane perspective this may modeled as a (physical)
contiguous optical spectrum. This can be represented by saying that TE-link with a contiguous optical spectrum. This can be represented
the portion of spectrum available at time t0 depends on which filters by saying that the portion of spectrum available at time t0 depends
are placed at the ends of the fiber and how they have been on which filters are placed at the ends of the fiber and how they
configured. Once filters are placed we have a one-hop media channel. have been configured. Once filters are placed we have a one-hop
In practical terms, associating a fiber with the terminating filters media channel. In practical terms, associating a fiber with the
determines the usable optical spectrum. terminating filters determines the usable optical spectrum.
---------------+ +-----------------+ ---------------+ +-----------------+
| | | |
+--------+ +--------+ +--------+ +--------+
| | | | +--------- | | | | +---------
---o| =============================== o--| ---o| =============================== o--|
| | Fiber | | | --\ /-- | | Fiber | | | --\ /--
---o| | | o--| \/ ---o| | | o--| \/
| | | | | /\ | | | | | /\
---o| =============================== o--| --/ \-- ---o| =============================== o--| --/ \--
skipping to change at page 14, line 30 skipping to change at page 14, line 6
--------+ +-------- --------+ +--------
|--------------------------------------| |--------------------------------------|
LSR | TE link | LSR LSR | TE link | LSR
|--------------------------------------| |--------------------------------------|
+--------+ +-------- +--------+ +--------
Figure 8: (Basic) Media Channel and TE Link Figure 8: (Basic) Media Channel and TE Link
Additionally, when a cross-connect for a specific frequency slot is Additionally, when a cross-connect for a specific frequency slot is
considered, the underlying media support is still a media channel, considered, the resulting media support of joining basic media
augmented, so to speak, with a bigger association of media elements channels is still a media channel, i.e., a longer association
and a resulting effective slot. When this media channel is the sequence of media elements and its effective frequency slot. In
result of the association of basic media channels and media layer other words, It is possible to "concatenate" several media channels
matrix cross-connects, this architectural construct can be (e.g., patch on intermediate nodes) to create a single media channel.
The architectural construct resulting of the association sequence of
basic media channels and media layer matrix cross-connects can be
represented as (i.e., corresponds to) a Label Switched Path (LSP) represented as (i.e., corresponds to) a Label Switched Path (LSP)
from a control plane perspective. In other words, It is possible to from a control plane perspective.
"concatenate" several media channels (e.g., Patch on intermediate
nodes) to create a single media channel.
----------+ +------------------------------+ +--------- ----------+ +------------------------------+ +---------
| | | | | | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | | | +----------+ | | | | | | | | +----------+ | | | |
--o| ========= o--| |--o ========= o-- --o| ========= o--| |--o ========= o--
| | Fiber | | | --\ /-- | | | Fiber | | | | Fiber | | | --\ /-- | | | Fiber | |
--o| | | o--| \/ |--o | | o-- --o| | | o--| \/ |--o | | o--
| | | | | /\ | | | | | | | | | | /\ | | | | |
--o| ========= o--***********|--o ========= o-- --o| ========= o--***********|--o ========= o--
skipping to change at page 17, line 32 skipping to change at page 16, line 32
|------------------| |----------------| |------------------| |----------------|
LSR | TE link | LSR | TE link | LSR LSR | TE link | LSR | TE link | LSR
|------------------| |----------------| |------------------| |----------------|
-----+ +---------------+ +----- -----+ +---------------+ +-----
Figure 11: Flex-grid LSP Representing a Media Channel that Starts at Figure 11: Flex-grid LSP Representing a Media Channel that Starts at
the Filter of the Outgoing Interface of the Ingress LSR and ends at the Filter of the Outgoing Interface of the Ingress LSR and ends at
the Filter of the Incoming Interface of the Egress LSR the Filter of the Incoming Interface of the Egress LSR
In Figure 12 a Network Media Channel is represented as terminated at In Figure 12 a Network Media Channel is represented as terminated at
the DWDM side of the transponder. This is commonly named as OCh- the network side of the trnaponders. This is commonly names as OTSi-
trail connection. trail connection.
|--------------------- Network Media Channel ----------------------| |--------------------- Network Media Channel ----------------------|
+----------------------+ +----------------------+ +----------------------+ +----------------------+
| | | | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | +----+ | | | | +----+ | |OTSi | | +----+ | | | | +----+ | |OTSi
OTSi| o-| |-o | +-----+ | o-| |-o |sink OTSi| o-| |-o | +-----+ | o-| |-o |sink
src | | | | | ===+-+ +-+==| | | | | O---|R src | | | | | ===+-+ +-+==| | | | | O---|R
skipping to change at page 20, line 17 skipping to change at page 19, line 17
| | link | | link | | link | | link
| Matrix |o- - - - - - - - - - o| Matrix |o- - - - - - | Matrix |o- - - - - - - - - - o| Matrix |o- - - - - -
+--------------+ +--------------+ +--------------+ +--------------+
| +---------+ | | +---------+ |
| | Media | | | | Media | |
|o----| Channel |-----o| |o----| Channel |-----o|
| | | |
| Matrix | | Matrix |
+---------+ +---------+
Figure 14: MRN/MLN Topology View with TE Link / FA Figure 14: Topology View with TE Link / FA
Note that there is only one media layer switch matrix (one Note that there is only one media layer switch matrix (one
implementation is a FlexGrid ROADM) in SSON, while a signal layer LSP implementation is a FlexGrid ROADM) in SSON, while a signal layer LSP
(Network Media Channel) is established mainly for the purpose of (Network Media Channel) is established mainly for the purpose of
management and control of individual optical signals. Signal layer management and control of individual optical signals. Signal layer
LSPs with the same attributes (such as source and destination) can be LSPs with the same attributes (such as source and destination) can be
grouped into one media-layer LSP (media channel): this has advantages grouped into one media-layer LSP (media channel): this has advantages
in spectral efficiency (reduce guard band between adjacent OChs in in spectral efficiency (reduce guard band between adjacent OChs in
one FSC channel) and LSP management. However, assuming some network one FSC channel) and LSP management. However, assuming some network
elements perform signal layer switching in an SSON, there must be elements perform signal layer switching in an SSON, there must be
enough guard band between adjacent OTSis in any media channel to enough guard band between adjacent OTSis in any media channel to
compensate filter concatenation effect and other effects caused by compensate for the filter concatenation effects and other effects
signal layer switching elements. In such a situation, the separation caused by signal layer switching elements. In such a situation, the
of the signal layer from the media layer does not bring any benefit separation of the signal layer from the media layer does not bring
in spectral efficiency or in other aspects, but makes the network any benefit in spectral efficiency or in other aspects, but makes the
switch and control more complex. If two OTSis must be switched to network switch and control more complex. If two OTSis must be
different ports, it is better to carry them by diferent FSC channels, switched to different ports, it is better to carry them by diferent
and the media layer switch is enough in this scenario. FSC channels, and the media layer switch is enough in this scenario.
As discussed in Section 3.2.5, a media channel may be constructed As discussed in Section 3.2.5, a media channel may be constructed
from a compsite of network media channels. This may be achieved in from a compsite of network media channels. This may be achieved in
two ways using LSPs. These mechanisms may be compared to the two ways using LSPs. These mechanisms may be compared to the
techniques used in GMPLS to support inverse multiplexing in Time techniques used in GMPLS to support inverse multiplexing in Time
Division Multiplexing (TDM) networks and in OTN [RFC4606], [RFC6344], Division Multiplexing (TDM) networks and in OTN [RFC4606], [RFC6344],
and [RFC7139]. and [RFC7139].
o In the first case, a single LSP may be established in the control o In the first case, a single LSP may be established in the control
plane. The signaling messages include information for all of the plane. The signaling messages include information for all of the
skipping to change at page 24, line 8 skipping to change at page 23, line 8
o A downstream node cannot foresee what an upstream node will o A downstream node cannot foresee what an upstream node will
allocate. A way to ensure that the effective frequency slot is allocate. A way to ensure that the effective frequency slot is
valid along the length of the LSP is to ensure that the same value valid along the length of the LSP is to ensure that the same value
of n is allocated at each hop. By forcing the same value of n we of n is allocated at each hop. By forcing the same value of n we
avoid cases where the effective frequency slot of the media avoid cases where the effective frequency slot of the media
channel is invalid (that is, the resulting frequency slot cannot channel is invalid (that is, the resulting frequency slot cannot
be described by its n and m parameters). be described by its n and m parameters).
o This may be too restrictive, since a node (or even a centralized/ o This may be too restrictive, since a node (or even a centralized/
combined RSA entity) may be able ensure that the resulting end-to- combined RSA entity) may be able to ensure that the resulting end-
end effective frequency slot is valid even if n varies locally. to-end effective frequency slot is valid even if n varies locally.
That means, the effective frequency slot that characterizes the That means, the effective frequency slot that characterizes the
media channel from end to end is consistent and is determined by media channel from end to end is consistent and is determined by
its n and m values, but that the effective frequency slot and its n and m values, but that the effective frequency slot and
those values are logical (i.e., do not map direct to the those values are logical (i.e., do not map direct to the
physically assigned spectrum) in the sense that they are the physically assigned spectrum) in the sense that they are the
result of the intersection of locally-assigned frequency slots result of the intersection of locally-assigned frequency slots
applicable at local components (such as filters) each of which may applicable at local components (such as filters) each of which may
have assigned different frequency slots. have assigned different frequency slots.
For Figure 15 the effective slot is made valid by ensuring that the For Figure 15 the effective slot is made valid by ensuring that the
skipping to change at page 30, line 5 skipping to change at page 29, line 5
grid network grid network
full interworking of fixed and flexible grid devices within the full interworking of fixed and flexible grid devices within the
same network same network
interworking of flexgrid devices with different capabilities. interworking of flexgrid devices with different capabilities.
The information model is represented using Routing Backus-Naur Format The information model is represented using Routing Backus-Naur Format
(RBNF) as defined in [RFC5511]. (RBNF) as defined in [RFC5511].
<Available Spectrum in Fiber for frequency slot> ::= <Available Spectrum> ::=
<Available Frequency Range-List> <Available Frequency Range-List>
<Available Central Frequency Granularity > <Available Central Frequency Granularity >
<Available Slot Width Granularity> <Available Slot Width Granularity>
<Minimal Slot Width> <Minimal Slot Width>
<Maximal Slot Width> <Maximal Slot Width>
<Available Frequency Range-List> ::= <Available Frequency Range-List> ::=
<Available Frequency Range> [<Available Frequency Range-List>] <Available Frequency Range> [<Available Frequency Range-List>]
<Available Frequency Range> ::= <Available Frequency Range> ::=
( <Start Spectrum Position> <End Spectrum Position> ) | ( <Start Spectrum Position> <End Spectrum Position> ) |
<Sets of contiguous slices> <Sets of contiguous slices>
<Available Central Frequency Granularity> ::= (2^n) x 6.25GHz <Available Central Frequency Granularity> ::= (2^n) x 6.25GHz
where n is positive integer, giving rise to granularities where n is a non negative integer, giving rise to granularities
such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz
<Available Slot Width Granularity> ::= (2^m) x 12.5GHz <Available Slot Width Granularity> ::= (2^m) x 12.5GHz
where m is positive integer where m is positive integer
<Minimal Slot Width> ::= j x 12.5GHz, <Minimal Slot Width> ::= j x 12.5GHz,
j is a positive integer j is a positive integer
<Maximal Slot Width> ::= k x 12.5GHz, <Maximal Slot Width> ::= k x 12.5GHz,
k is a positive integer (k >= j) k is a positive integer (k >= j)
skipping to change at page 31, line 28 skipping to change at page 30, line 28
be able to configure local frequency slots. be able to configure local frequency slots.
The control plane architecture SHOULD allow for the support of L-band The control plane architecture SHOULD allow for the support of L-band
and S-band. and S-band.
The signalling process SHALL be able to collect the local frequency The signalling process SHALL be able to collect the local frequency
slot assigned at each link along the path. slot assigned at each link along the path.
The signaling procedures SHALL support all of the RSA architectural The signaling procedures SHALL support all of the RSA architectural
models (R&SA, R+SA, and R+DSA) within a single set of protocol models (R&SA, R+SA, and R+DSA) within a single set of protocol
objects although some objects may only be applicable within on of the objects although some objects may only be applicable within one of
models. the models.
5.1.2. Routing 5.1.2. Routing
The routing protocol will support all functions as described in The routing protocol will support all functions as described in
[RFC4202] and extend them to a flexi-grid data plane. [RFC4202] and extend them to a flexi-grid data plane.
The routing protocol SHALL distribute sufficient information to The routing protocol SHALL distribute sufficient information to
compute paths to enable the signaling procedure to establish LSPs as compute paths to enable the signaling procedure to establish LSPs as
described in the previous sections. This includes, at a minimum the described in the previous sections. This includes, at a minimum the
data described by the Information Model in Figure 17. data described by the Information Model in Figure 17.
skipping to change at page 35, line 35 skipping to change at page 34, line 35
Optics CTO Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy Via Trento 30 20059 Vimercate (Milano) Italy
+39 039 6863033 +39 039 6863033
sergio.belotti@alcatel-lucent.com sergio.belotti@alcatel-lucent.com
Yao Li Yao Li
Nanjing University Nanjing University
wsliguotou@hotmail.com wsliguotou@hotmail.com
Fei Zhang Fei Zhang
ZTE Huawei
Zijinghua Road, Nanjing, China zhangfei7@huawei.com
zhang.fei3@zte.com.cn
Lei Wang Lei Wang
ZTE wang.lei@bupt.edu.cn
East Huayuan Road, Haidian district, Beijing, China
wang.lei131@zte.com.cn
Guoying Zhang Guoying Zhang
China Academy of Telecom Research China Academy of Telecom Research
No.52 Huayuan Bei Road, Beijing, China No.52 Huayuan Bei Road, Beijing, China
zhangguoying@ritt.cn zhangguoying@ritt.cn
Takehiro Tsuritani Takehiro Tsuritani
KDDI R&D Laboratories Inc. KDDI R&D Laboratories Inc.
2-1-15 Ohara, Fujimino, Saitama, Japan 2-1-15 Ohara, Fujimino, Saitama, Japan
tsuri@kddilabs.jp tsuri@kddilabs.jp
 End of changes. 42 change blocks. 
139 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------060803020706090102050806-- From nobody Thu May 14 07:29:59 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5091E1AC3B2 for ; Thu, 14 May 2015 07:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.21 X-Spam-Level: X-Spam-Status: No, score=-12.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_FORM=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAUKZtJK3Vdh for ; Thu, 14 May 2015 07:29:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F481AC3A7 for ; Thu, 14 May 2015 07:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23992; q=dns/txt; s=iport; t=1431613792; x=1432823392; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6e42da7MZWYUNfWm8dbZVV8t5Q7MZT7BnNkwZc+P4Uw=; b=Cv3bvlK6d1rvDBFVLNUhW9KgmrcwufIa4tPHGKjoe5OSbXnAYG6PA7LJ gQ7QeCzEPhFDlvaliaVvoSgkomVi4P7nDgDHzl+7LHzGpm1ASSvd4lYXm aYkh2rOvUrobakrNm+Ipf0E7YOMI1OWzJB7gL4rwjh7+2279gPJ7jWqSp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBQBTsFRV/4YNJK1GFoJFSoEyBsw+AoE+TAEBAQEBAYELhCIBAQEEHRA6EhACAQgRBAEBCwkNBwcyFAkIAgQBDQUIiCTUVAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoQaOjEGAYMXgRYFi3CENoI6jBmDZJFuI2GBBSMcFYE9b4FFgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,429,1427760000"; d="scan'208,217";a="420055263" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 14 May 2015 14:29:51 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4EETp20025193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 May 2015 14:29:51 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.22]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 14 May 2015 09:29:51 -0500 From: "Matt Hartley (mhartley)" To: Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AQHQi+sCRbr+LifYa0qF5OmSNlKil513Qq8ggARIJACAAAIgIA== Date: Thu, 14 May 2015 14:29:50 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29C8A5EF@xmb-rcd-x03.cisco.com> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> In-Reply-To: <55546934.8070806@cttc.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.38] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC29C8A5EFxmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:29:58 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC29C8A5EFxmbrcdx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Ramon. Changes look good to me! Cheers Matt From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas Sent: Thursday, May 14, 2015 5:22 AM To: ccamp@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and= call for sheperd Dear Matt, all Thank you very much for the review and comments, please see inline (aligned= with Adrian's reply). For what is worth, there were some comments that I received post LC, that w= ill also be in next updated version. El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribi=F3: All, I've reviewed this revision of the document, and I think it's almost ready = for publication. I have a few comments (below) but I don't think there's an= y major issues. 3.1: definition of OTN could be moved up to section 2.2, if you want. Ramon> Added as acronym, and removed the expansion, thank you 3.2.1: you state that the Nominal Central Frequency Granularity is 6.25GHz,= but there's no reference for this. I assume it's in an ITU doc somewhere? = If so, it'd be good to say so (and where) Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1] The document refers to "OTSi signals" in several places, but the definition= of "OTSi" includes "signal" :) I don't know whether or not this is normal = usage or whether it's worth fixing... but it looks technically wrong to me = (like people talking about "PIN numbers" whenever they get cash out of the = bank). Ramon> changed OTSi signals to OTSi 3.2.5, first bullet: "This group of OTSi should be carried over a single fi= bre." Is that a normal English should, or a 2219 SHOULD? If the former, it = might be worth rephrasing to avoid ambiguity. Ramon> changed to "are" as per Adrian's suggestion 4.2: "The association of the three components a filter, a fiber, and a filt= er, is a media channel in its most basic form.". It'd be nice to clarify th= at this is a fiber with a filter at each end - that's not immediately obvio= us on first reading, especially with the diagram that makes it clear on the= next page. Ramon> Likewise, changed to "association sequence" The paragraph below figure 8 is... unclear. Is it just trying to say that m= edia channels can be joined together to make a new media channel? Or is the= re more to it than that? Ramon> Basically the intent is that one, although it should reflect more to= the join of "basic" media channels (defined as an association sequence of = filter-fiber-filter as above). This, and the architectural construct being = an LSP. Changed to also use the term "association sequence" OLD Additionally, when a cross-connect for a specific frequency slot is considered, the underlying media support is still a media channel, augmented, so to speak, with a bigger association of media elements and a resulting effective slot. When this media channel is the result of the association of basic media channels and media layer matrix cross-connects, this architectural construct can be represented as (i.e., corresponds to) a Label Switched Path (LSP) from a control plane perspective. In other words, It is possible to "concatenate" several media channels (e.g., Patch on intermediate nodes) to create a single media channel. NEW Additionally, when a cross-connect for a specific frequency slot is considered, the resulting media support of joining basic media channels is still a media channel, i.e., a longer association sequence of media elements and its effective frequency slot. In other words, It is possibl= e to "concatenate" several media channels (e.g., patch on intermediate nodes) to create a single media channel. The architectural construct resulting of the association sequence of basic media channels and media layer matrix cross-connects can be represented as (i.e., corresponds to) a Label Switched Path (LSP) from a control plane perspective. Fig 12: OTSi trail? Did you mean OCh trail? Ramon> The error comes from the text, since the correct term is OTSi. OLD In Figure 12 a Network Media Channel is represented as terminated at the DWDM side of the transponder. This is commonly named as OCh- trail connection. NEW In Figure 12 a Network Media Channel is represented as terminated at the network side of the transponders. This is commonly named as OTSi- trail connection. Fig 14: MLN/MRN needs explaining. Or removing. Ramon> Removed. 4.3, towards the end: "there must be enough guard band between adjacent OTS= is in any media channel to compensate filter concatenation effect and other= effects caused by signal layer switching elements". Maybe "...to compensat= e for the filter concatenation effect and..." or "...to compensate for filt= er concatenation effects and..."? Ramon> new text "there must be enough guard band between adjacent OTSis in any media chann= el to compensate for the filter concatenation effects and other effects ca= used by signal layer switching elements" 4.8.4: bear in mind that 0 is not a positive integer, and it looks like the= definitions involving (2^n) and (2^m) are intended to include the case whe= re n/m is 0. Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving= it as positive integer, since m=3D0 would imply an empty frequency slot. If no further comments, I will proceed to upload these changes for -04 (wit= h other backlogged changes such as affiliation changes, CCAMP WG, Informati= onal, nits, editorial changes , typos, etc. ). Please see the attached diff Thanks Ramon --_000_9D50FCE7413E3D4EA5E42331115FB5BC29C8A5EFxmbrcdx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks, Ramon.<= /o:p>

 

Changes look good to= me!

 

Cheers

 

Matt

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: Thursday, May 14, 2015 5:22 AM
To: ccamp@ietf.org
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk= -03 and call for sheperd

 

Dear Matt, all

Thank you very much for the review and comments, please see inline (aligned= with Adrian's reply).

For what is worth, there were some comments that I received post LC, that w= ill also be in next updated version.


El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribi=F3:

All,

 <= /o:p>

I’ve reviewed= this revision of the document, and I think it’s almost ready for pub= lication. I have a few comments (below) but I don’t think there’= ;s any major issues.

 <= /o:p>

3.1: definition of = OTN could be moved up to section 2.2, if you want.

Ramon> Added as acronym, and remo= ved the expansion, thank you

 <= /o:p>

3.2.1: you state th= at the Nominal Central Frequency Granularity is 6.25GHz, but there’s = no reference for this. I assume it’s in an ITU doc somewhere? If so, = it’d be good to say so (and where)

Ramon> Indeed. Much like SWG bein= g 12.5GHz, added [G.694.1]

 <= /o:p>

The document refers= to “OTSi signals” in several places, but the definition of = 220;OTSi” includes “signal” :) I don’t know whether= or not this is normal usage or whether it’s worth fixing… but = it looks technically wrong to me (like people talking about “PIN numbers” whenever = they get cash out of the bank).

 <= /o:p>

Ramon> changed OTSi signals to OT= Si


3.2.5, first bullet= : “This group of OTSi should be carried over a single fibre.” I= s that a normal English should, or a 2219 SHOULD? If the former, it might b= e worth rephrasing to avoid ambiguity.

Ramon> changed to "are"= as per Adrian's suggestion

 <= /o:p>

4.2: “The ass= ociation of the three components a filter, a fiber, and a filter, is a medi= a channel in its most basic form.”. It’d be nice to clarify tha= t this is a fiber with a filter at each end – that’s not immediately obvious on first reading, especially with the diagram that mak= es it clear on the next page.

 <= /o:p>

Ramon> Likewise, changed to "= ;association sequence"


The paragraph below= figure 8 is... unclear. Is it just trying to say that media channels can b= e joined together to make a new media channel? Or is there more to it than = that?

 <= /o:p>

Ramon> Basically the intent is th= at one, although it should reflect more to the join of "basic" me= dia channels (defined as an association sequence of filter-fiber-filter as above). This, and the architectural construct being an LSP.  Chang= ed to also use the term "association sequence"

OLD

&n=
bsp;  Additionally, when a cross-connect for a specific frequency slot=
 is
&n=
bsp;  considered, the underlying media support is still a media channe=
l,
&n=
bsp;  augmented, so to speak, with a bigger association of media eleme=
nts
&n=
bsp;  and a resulting effective slot.  When this media channel is=
 the
&n=
bsp;  result of the association of basic media channels and media laye=
r
&n=
bsp;  matrix cross-connects, this architectural construct can be<=
/o:p>
&n=
bsp;  represented as (i.e., corresponds to) a Label Switched Path (LSP=
)
&n=
bsp;  from a control plane perspective.  In other words, It is po=
ssible to
&n=
bsp;  "concatenate" several media channels (e.g., Patch on i=
ntermediate
&n=
bsp;  nodes) to create a single media channel.


NEW

&n=
bsp;  Additionally, when a cross-connect for a specific frequency slot=
 is
&n=
bsp;  considered, the resulting media support of joining basic media c=
hannels
&n=
bsp;  is still a media channel, i.e., a longer association sequence of=
 media 
&n=
bsp;  elements and its effective frequency slot. In other words, =
It is possible to
&n=
bsp;  "concatenate" several media channels (e.g., patch on i=
ntermediate
&n=
bsp;  nodes) to create a single media channel.
 
&n=
bsp;  The architectural construct resulting of the association sequenc=
e 
&n=
bsp;  of basic media channels and media layer matrix cross-connec=
ts can be
&n=
bsp;  represented as (i.e., corresponds to) a Label Switched Path (LSP=
)
&n=
bsp;  from a control plane perspective. 




Fig 12: OTSi trail?= Did you mean OCh trail?

Ramon> The error comes from the t= ext, since the correct term is OTSi.

OLD 

&n=
bsp;  In Figure 12 a Network Media Channel is represented as term=
inated at
&n=
bsp;  the DWDM side of the transponder.  This is commonly named a=
s OCh-
&n=
bsp;  trail connection.
 

NEW

&n=
bsp;  In Figure 12 a Network Media Channel is represented as terminate=
d at
&n=
bsp;  the network side of the transponders.  This is commonly nam=
ed as OTSi-
&n=
bsp;  trail connection.



 <= /o:p>

Fig 14: MLN/MRN nee= ds explaining. Or removing.

Ramon> Removed.

 <= /o:p>

4.3, towards the en= d: “there must be enough guard band between adjacent OTSis in any med= ia channel to compensate filter concatenation effect and other effects caus= ed by signal layer switching elements”. Maybe “…to compensate for the filter concatenation effect and…= ” or “…to compensate for filter concatenation effects and= …”?

 <= /o:p>

Ramon> new text
"there must be  enough guard band between adjacent OTSis in any m= edia channel to  compensate for the filter concatenation effects and o= ther effects caused by signal layer switching elements"


4.8.4: bear in mind= that 0 is not a positive integer, and it looks like the definitions involv= ing (2^n) and (2^m) are intended to include the case where n/m is 0.=

Ramon= > Changed for "n" to say "non-negative integer". For= "m", I am leaving it as positive integer, since m=3D0 would impl= y an empty frequency slot.


If no further comments, I will proceed to upload these changes for -04 (wit= h other backlogged changes such as affiliation changes, CCAMP WG, Informati= onal, nits, editorial changes , typos, etc. ). Please see the attached diff=


Thanks
Ramon

--_000_9D50FCE7413E3D4EA5E42331115FB5BC29C8A5EFxmbrcdx03ciscoc_-- From nobody Fri May 15 12:55:54 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E9F1A8860 for ; Fri, 15 May 2015 12:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEjv0FZvBD-9 for ; Fri, 15 May 2015 12:55:51 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id A86001A884D for ; Fri, 15 May 2015 12:55:51 -0700 (PDT) Received: (qmail 931 invoked by uid 0); 15 May 2015 19:55:33 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 15 May 2015 19:55:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id URod1q00N2SSUrH01Rogr8; Fri, 15 May 2015 19:48:40 -0600 X-Authority-Analysis: v=2.1 cv=D8zUdJhj c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=SY9aFQKHIdAA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=h1PgugrvaO0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=gZbpxnkM3yUA:10 a=48vgC7mUAAAA:8 a=RUgz4n3fVVhXmBK3xcUA:9 a=pILNOxqGKmIA:10 a=nTHCoUExaRkA:10 a=t9MFvKAEumoA:10 a=OhvvrwSMIqG0-J2YR-0A:9 a=uAH0aYtwcIdC-xXv:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=FkYF5HTSDarXTYwDC4uZG9XG0imx/FLl9IcfY2ErfOc=; b=IFkNK2TPhcjLmgYgtNG0OGBzHkmAK4l++KxB6dLS4Ls1aIozVIw+lgxJJkiaWoDtA5mnWZzFxVxzu1aeqxPA98yTttJJ8oS1t1i3O9p6VBG3Xq7VBEHMZOR2n6V8Jj9F; Received: from box313.bluehost.com ([69.89.31.113]:55876 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YtLi0-0002PL-0x; Fri, 15 May 2015 13:55:48 -0600 Message-ID: <55564F37.7010203@labn.net> Date: Fri, 15 May 2015 15:55:35 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "CCAMP (ccamp@ietf.org)" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------020509080206000005030600" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 19:55:53 -0000 This is a multi-part message in MIME format. --------------020509080206000005030600 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit All, I believe there has been sufficient time and support to indicate that this document is ready to move forward, i.e., as "consensus caller" I believe there is WG consensus behind publishing the document. That said, there were a few comments that were received during and (per Ramon) after Monday. I'd expect the authors to work with those making the comments, the WG, and the document Shepherd (who, per normal process, does the actual publication request) to ensure that the comments are addressed. Lou On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote: > > Working group, > > > > this starts a two weeks working group last call on > draft-ietf-ccamp-flexi-grid-fwk-03. > > The last call end on Monday May 11^th . Please send you comments to > the CCAMP mailing list. > > > > All the IPR declarations from authors and contributors have been > collected and can be found in the history of the document: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/ > > Please note that no IPR was disclosed against this draft. > > > > *_PLEASE NOTE_* > > 1. Since both the chairs and the secretary are involved in the > draft as co-authors, the consensus will be called by Lou. > > 2. This is a good opportunity to have the WG involved also in > the Post-WG Last call process nominating a document shepherd which is > not one of the chairs or the secretary. The document shepherd: > > a. MUST NOT be one of the authors/contributors of the draft > > b. SHOULD be an expert of the ID subject > > c. Will receive all the needed support from the chairs. > > > > Further details on the shepherd duties can be found in RFC4858 and at > https://www.ietf.org/iesg/statement/document-shepherds.html: > > Please volunteer if interested > > > > Thanks > > Daniele & Fatai > --------------020509080206000005030600 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit All,
    I believe there has been sufficient time and support to indicate that this document is ready to move forward, i.e., as "consensus caller" I believe there is WG consensus behind publishing the document.  That said, there were a few comments that were received during and (per Ramon) after Monday.  I'd expect the authors to work with those making the comments, the WG, and the document Shepherd (who, per normal process, does the actual publication request) to ensure that the comments are addressed.

Lou

On 4/27/2015 6:04 AM, Daniele Ceccarelli wrote:

Working group,

 

this starts a two weeks working group last call on draft-ietf-ccamp-flexi-grid-fwk-03.

The last call end on Monday May 11th. Please send you comments to the CCAMP mailing list.

 

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/history/

Please note that no IPR was disclosed against this draft.

 

PLEASE NOTE

1.       Since both the chairs and the secretary are involved in the draft as co-authors, the consensus will be called by Lou.

2.       This is a good opportunity to have the WG involved also in the Post-WG Last call process nominating a document shepherd which is not one of the chairs or the secretary. The document shepherd:

a.       MUST NOT be one of the authors/contributors of the draft

b.      SHOULD be an expert of the ID subject

c.       Will receive all the needed support from the chairs.

 

Further details on the shepherd duties can be found in RFC4858 and at https://www.ietf.org/iesg/statement/document-shepherds.html:

Please volunteer if interested

 

Thanks

Daniele & Fatai


--------------020509080206000005030600-- From nobody Sat May 16 02:12:51 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6B31B2AFC for ; Sat, 16 May 2015 02:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_FORM=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQNbLJxdhbQd for ; Sat, 16 May 2015 02:12:48 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FE21B2AFA for ; Sat, 16 May 2015 02:12:47 -0700 (PDT) Received: by wguv19 with SMTP id v19so76712587wgu.1 for ; Sat, 16 May 2015 02:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+ehI5K7hhwPDFLDaP2vBGbkFcngMyyl5itAwIDJGV1Y=; b=jPtyuxLEVwFvBoweJ382raX7k0G5dC9qrRyUEzFM9eonBc0BkPyi8Zhh+sS2eykd5h av5yZ3ByLmvynGscpT5kbvIxWK8ZvBcrUvU5hapeGJrXsx7O7uq3cuKdsaLWMHCC4z29 iWqfn4I/dxvnlZkJsEwv+exCMuVNiCXGkcMPRW8JG5BNgAE5C1deEH6rPwPwXBEjIiSV OWNYxmxcHvtt29u70g6nio0wsnf3n89q96atF3Ye/JeoMED2WurglF3NyLT03wz508Aq K8PIzbaw7qY0cimq4Ji6ny4zJ4JMtHOYT5LZebSmpKek0L88thNdqt55ufKuwam9l2+Y QnFg== X-Received: by 10.180.11.236 with SMTP id t12mr4533845wib.19.1431767566525; Sat, 16 May 2015 02:12:46 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id b10sm2019307wic.1.2015.05.16.02.12.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 02:12:45 -0700 (PDT) Message-ID: <55570A0C.8020204@gmail.com> Date: Sat, 16 May 2015 11:12:44 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Matt Hartley (mhartley)" , Ramon Casellas , "ccamp@ietf.org" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29C8A5EF@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29C8A5EF@xmb-rcd-x03.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 09:12:50 -0000 Hello Lou, Please excuse me for the late response (I was in extremely hot Andalucia this week) As one of the many contributors to this draft, I reviewed the most recent version, and comments and I believe it is ready for publication. Cheers, Huub. On 14-05-15 16:29, Matt Hartley (mhartley) wrote: > Thanks, Ramon. > > Changes look good to me! > > Cheers > > Matt > > *From:*CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Ramon Casellas > *Sent:* Thursday, May 14, 2015 5:22 AM > *To:* ccamp@ietf.org > *Subject:* Re: [CCAMP] WG Last Call on > draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd > > Dear Matt, all > > Thank you very much for the review and comments, please see inline > (aligned with Adrian's reply). > > For what is worth, there were some comments that I received post LC, > that will also be in next updated version. > > > El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribió: > > All, > > I’ve reviewed this revision of the document, and I think it’s almost > ready for publication. I have a few comments (below) but I don’t > think there’s any major issues. > > 3.1: definition of OTN could be moved up to section 2.2, if you want. > > Ramon> Added as acronym, and removed the expansion, thank you > > 3.2.1: you state that the Nominal Central Frequency Granularity is > 6.25GHz, but there’s no reference for this. I assume it’s in an ITU doc > somewhere? If so, it’d be good to say so (and where) > > Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1] > > The document refers to “OTSi signals†in several places, but the > definition of “OTSi†includes “signal†:) I don’t know whether or not > this is normal usage or whether it’s worth fixing… but it looks > technically wrong to me (like people talking about “PIN numbers†> whenever they get cash out of the bank). > > Ramon> changed OTSi signals to OTSi > > > 3.2.5, first bullet: “This group of OTSi should be carried over a single > fibre.†Is that a normal English should, or a 2219 SHOULD? If the > former, it might be worth rephrasing to avoid ambiguity. > > Ramon> changed to "are" as per Adrian's suggestion > > 4.2: “The association of the three components a filter, a fiber, and a > filter, is a media channel in its most basic form.â€. It’d be nice to > clarify that this is a fiber with a filter at each end – that’s not > immediately obvious on first reading, especially with the diagram that > makes it clear on the next page. > > Ramon> Likewise, changed to "association sequence" > > > The paragraph below figure 8 is... unclear. Is it just trying to say > that media channels can be joined together to make a new media channel? > Or is there more to it than that? > > Ramon> Basically the intent is that one, although it should reflect more > to the join of "basic" media channels (defined as an association > sequence of filter-fiber-filter as above). This, and the architectural > construct being an LSP. Changed to also use the term "association sequence" > > OLD > > Additionally, when a cross-connect for a specific frequency slot is > > considered, the underlying media support is still a media channel, > > augmented, so to speak, with a bigger association of media elements > > and a resulting effective slot. When this media channel is the > > result of the association of basic media channels and media layer > > matrix cross-connects, this architectural construct can be > > represented as (i.e., corresponds to) a Label Switched Path (LSP) > > from a control plane perspective. In other words, It is possible to > > "concatenate" several media channels (e.g., Patch on intermediate > > nodes) to create a single media channel. > > > NEW > > Additionally, when a cross-connect for a specific frequency slot is > > considered, the resulting media support of joining basic media channels > > is still a media channel, i.e., a longer association sequence of media > > elements and its effective frequency slot. In other words, It is possible to > > "concatenate" several media channels (e.g., patch on intermediate > > nodes) to create a single media channel. > > > > The architectural construct resulting of the association sequence > > of basic media channels and media layer matrix cross-connects can be > > represented as (i.e., corresponds to) a Label Switched Path (LSP) > > from a control plane perspective. > > > > > Fig 12: OTSi trail? Did you mean OCh trail? > > Ramon> The error comes from the text, since the correct term is OTSi. > > OLD > > In Figure 12 a Network Media Channel is represented as terminated at > > the DWDM side of the transponder. This is commonly named as OCh- > > trail connection. > > > > NEW > > In Figure 12 a Network Media Channel is represented as terminated at > > the network side of the transponders. This is commonly named as OTSi- > > trail connection. > > > > Fig 14: MLN/MRN needs explaining. Or removing. > > Ramon> Removed. > > 4.3, towards the end: “there must be enough guard band between adjacent > OTSis in any media channel to compensate filter concatenation effect and > other effects caused by signal layer switching elementsâ€. Maybe “…to > compensate for the filter concatenation effect and…†or “…to compensate > for filter concatenation effects and…â€? > > Ramon> new text > "there must be enough guard band between adjacent OTSis in any media > channel to compensate for the filter concatenation effects and other > effects caused by signal layer switching elements" > > > 4.8.4: bear in mind that 0 is not a positive integer, and it looks like > the definitions involving (2^n) and (2^m) are intended to include the > case where n/m is 0. > > Ramon> Changed for "n" to say "non-negative integer". For "m", I am > leaving it as positive integer, since m=0 would imply an empty frequency > slot. > > > If no further comments, I will proceed to upload these changes for -04 > (with other backlogged changes such as affiliation changes, CCAMP WG, > Informational, nits, editorial changes , typos, etc. ). Please see the > attached diff > > > Thanks > Ramon > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From nobody Mon May 18 01:22:49 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27C51A877A; Mon, 18 May 2015 01:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xebgy-RvQoVw; Mon, 18 May 2015 01:22:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0CA1A87C6; Mon, 18 May 2015 01:22:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150518082238.32478.13924.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 01:22:38 -0700 Archived-At: Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-flexi-grid-fwk-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 08:22:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework and Requirements for GMPLS-based control of Flexi-grid DWDM networks Authors : Oscar Gonzalez de Dios Ramon Casellas Fatai Zhang Xihua Fu Daniele Ceccarelli Iftekhar Hussain Filename : draft-ietf-ccamp-flexi-grid-fwk-04.txt Pages : 39 Date : 2015-05-18 Abstract: To allow efficient allocation of optical spectral bandwidth for high bit-rate systems, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new dense wavelength division multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings and the concept of "frequency slot". In such an environment, a data plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum creating what is known as a flexible grid (flexi- grid). This document defines a framework and the associated control plane requirements for the GMPLS-based control of flexi-grid DWDM networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ccamp-flexi-grid-fwk-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-flexi-grid-fwk-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 18 01:23:40 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D01C1A87B9 for ; Mon, 18 May 2015 01:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En9aO-nKCZsU for ; Mon, 18 May 2015 01:23:37 -0700 (PDT) Received: from navarro.puc.rediris.es (navarro.puc.rediris.es [IPv6:2001:720:418:ca01::131]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D68E1A877A for ; Mon, 18 May 2015 01:23:37 -0700 (PDT) Received: from [2001:40b0:7c22:6020:fd8b:8214:3949:6d11] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YuGKk-0003kK-Eq for ccamp@ietf.org; Mon, 18 May 2015 10:23:35 +0200 Received: from [192.168.101.69] (unknown [192.168.101.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 2FA331FD05 for ; Mon, 18 May 2015 10:23:28 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <5559A180.8090504@cttc.es> Date: Mon, 18 May 2015 10:23:28 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ccamp@ietf.org References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> In-Reply-To: <55564F37.7010203@labn.net> Content-Type: multipart/alternative; boundary="------------020601060301000307080600" X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -2.9 (--) X-Spamina-Spam-Report: Content analysis details: (-2.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0018] 0.0 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 08:23:39 -0000 This is a multi-part message in MIME format. --------------020601060301000307080600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit El 15/05/2015 a las 21:55, Lou Berger escribió: > All, > I believe there has been sufficient time and support to indicate > that this document is ready to move forward, i.e., as "consensus > caller" I believe there is WG consensus behind publishing the > document. That said, there were a few comments that were received > during and (per Ramon) after Monday. I'd expect the authors to work > with those making the comments, the WG, and the document Shepherd > (who, per normal process, does the actual publication request) to > ensure that the comments are addressed. > Dear Lou, all Version -04 has been uploaded with all comments received so far. Thanks Ramon --------------020601060301000307080600 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
El 15/05/2015 a las 21:55, Lou Berger escribió:
All,
    I believe there has been sufficient time and support to indicate that this document is ready to move forward, i.e., as "consensus caller" I believe there is WG consensus behind publishing the document.  That said, there were a few comments that were received during and (per Ramon) after Monday.  I'd expect the authors to work with those making the comments, the WG, and the document Shepherd (who, per normal process, does the actual publication request) to ensure that the comments are addressed.

Dear Lou, all

Version -04 has been uploaded with all comments received so far.

Thanks
Ramon

--------------020601060301000307080600-- From nobody Mon May 18 14:14:25 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8794F1A88F5; Mon, 18 May 2015 14:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjFuutl3afRp; Mon, 18 May 2015 14:14:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58E1ACCFF; Mon, 18 May 2015 14:14:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150518211423.23602.42149.idtracker@ietfa.amsl.com> Date: Mon, 18 May 2015 14:14:23 -0700 Archived-At: Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-12.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:14:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Signaling Extensions for Wavelength Switched Optical Networks Authors : Greg M. Bernstein Sugang Xu Young Lee Giovanni Martinelli Hiroaki Harai Filename : draft-ietf-ccamp-wson-signaling-12.txt Pages : 16 Date : 2015-05-18 Abstract: This document provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSON). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. This document provides mechanisms to support distributed wavelength assignment with choice in distributed wavelength assignment algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-wson-signaling-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 18 14:34:56 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C0E1ACD3A for ; Mon, 18 May 2015 14:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-IJg5ICRi1i for ; Mon, 18 May 2015 14:34:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FDA1ACD4D for ; Mon, 18 May 2015 14:34:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWF73143; Mon, 18 May 2015 21:34:51 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 22:34:50 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Mon, 18 May 2015 14:34:42 -0700 From: Leeyoung To: "ccamp@ietf.org" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-12.txt Thread-Index: AQHQka+qTKG6y4POY0aiiS4IPYRDFp2CPPmg Date: Mon, 18 May 2015 21:34:41 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729CC005A@dfweml706-chm> References: <20150518211423.23602.42149.idtracker@ietfa.amsl.com> In-Reply-To: <20150518211423.23602.42149.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "tjw.ietf@gmail.com" , "joelja@bogus.com" , "Kathleen.Moriarty.ietf@gmail.com" , "kaduk@MIT.EDU" , "bclaise@cisco.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-12.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:34:54 -0000 Hi,=20 This update incorporated all comments received for draft-ietf-ccamp-wson-si= gnaling (v.10).=20 Please let me know if you have any question for this update. Best regards, Young (on behalf of co-authors) -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Monday, May 18, 2015 4:14 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Signaling Extensions for Wavelength Switched Opti= cal Networks Authors : Greg M. Bernstein Sugang Xu Young Lee Giovanni Martinelli Hiroaki Harai Filename : draft-ietf-ccamp-wson-signaling-12.txt Pages : 16 Date : 2015-05-18 Abstract: This document provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSON). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. This document provides mechanisms to support distributed wavelength assignment with choice in distributed wavelength assignment algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-wson-signaling-12 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Tue May 19 10:29:07 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E801A1A8A for ; Tue, 19 May 2015 10:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkF3SMUHEfGP for ; Tue, 19 May 2015 10:29:03 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFCE1A1A15 for ; Tue, 19 May 2015 10:28:59 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-46-555b72dab617 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.35.17665.AD27B555; Tue, 19 May 2015 19:28:58 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.137]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Tue, 19 May 2015 19:28:57 +0200 From: Daniele Ceccarelli To: "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgOcXiaAAH6zzgAAST54UA== Date: Tue, 19 May 2015 17:28:56 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481291BA83@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> In-Reply-To: <5559A180.8090504@cttc.es> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE481291BA83ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvre6touhQg499AhZP5txgsehofsti Mecls8Xuud/YHVg8pvzeyOrRerSdxWPJkp9MHh82NbMFsERx2aSk5mSWpRbp2yVwZUza+4yx YLdRxfHTr5kbGBfpdDFyckgImEi0PrrNDmGLSVy4t54NxBYSOMoo8eOFVBcjF5C9hFHixa5V TF2MHBxsAlYSTw75gNSICKhKnLl5kRGkhllgBaNE++0+sEHCAnESPx5vZ4UoipeY3bCJCcJ2 knizsY0RxGYBav65YBUziM0r4CtxvHcPK8SyNkaJlleTwQZxCqhLrGt8DtbAKCArMWH3IjCb WUBc4taT+UwQVwtILNlznhnCFpV4+fgfK4StKNH+tAGqPl/i9cPDbBDLBCVOznzCMoFRdBaS UbOQlM1CUgYR15O4MXUKG4StLbFs4WtmCFtXYsa/QyzI4gsY2VcxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBMblwS2/dXcwrn7teIhRgINRiYdXYWZUqBBrYllxZe4hRmkOFiVxXq+ukFAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjGt1n266vEZqq2VFrtnS3fJCdmrLBddwHmvsyipn mNzM5Tj/UUvZipzJbdU6W+dd1Df8fmuGy8cUu60pr9t9pN/cePZf8nz3hecZ9Skb9rzmcGHn iOdbd/nA/UserwSsXSLfFSZcsHw9+6m0RZmu4wfhiWFSpZzB0aLvF388uvvwp+n5ir/sHJRY ijMSDbWYi4oTAfF+TAKsAgAA Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 17:29:05 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE481291BA83ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Many thanks to Ramon for the addressing the comments, to Lou for helping us= with the consensus call and to the many volunteers for being the shepherd = of the draft. Matt Hartley will be the shepherd and we'll proceed with the publication re= quest. Thanks Daniele & Fatai From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas Sent: luned=EC 18 maggio 2015 10:23 To: ccamp@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and= call for sheperd El 15/05/2015 a las 21:55, Lou Berger escribi=F3: All, I believe there has been sufficient time and support to indicate that t= his document is ready to move forward, i.e., as "consensus caller" I believ= e there is WG consensus behind publishing the document. That said, there w= ere a few comments that were received during and (per Ramon) after Monday. = I'd expect the authors to work with those making the comments, the WG, and= the document Shepherd (who, per normal process, does the actual publicatio= n request) to ensure that the comments are addressed. Dear Lou, all Version -04 has been uploaded with all comments received so far. Thanks Ramon --_000_4A1562797D64E44993C5CBF38CF1BE481291BA83ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Many thanks to Ramon for = the addressing the comments, to Lou for helping us with the consensus call = and to the many volunteers for being the shepherd of the draft.

 <= /p>

Matt Hartley will be the = shepherd and we’ll proceed with the publication request.

 <= /p>

Thanks<= /p>

Daniele & Fatai<= /o:p>

 <= /p>

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: luned=EC 18 maggio 2015 10:23
To: ccamp@ietf.org
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk= -03 and call for sheperd

 

El 15/05/2015 a las 21:55, Lou Berger escribi=F3:

All,
    I believe there has been sufficient time and support to = indicate that this document is ready to move forward, i.e., as "consen= sus caller" I believe there is WG consensus behind publishing the docu= ment.  That said, there were a few comments that were received during and (per Ramon) after Monday.  I'd expect the authors to work = with those making the comments, the WG, and the document Shepherd (who, per= normal process, does the actual publication request) to ensure that the co= mments are addressed.

Dear Lou, all

Version -04 has been uploaded with all comments received so far.

Thanks
Ramon

--_000_4A1562797D64E44993C5CBF38CF1BE481291BA83ESESSMB301erics_-- From nobody Wed May 20 00:29:35 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5E81B2D70 for ; Wed, 20 May 2015 00:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.401 X-Spam-Level: *** X-Spam-Status: No, score=3.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MANGLED_FORM=2.3, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dwgygcq_Y11g for ; Wed, 20 May 2015 00:29:29 -0700 (PDT) Received: from smtp303-outgoing.stejtech.net (smtp303.stejtech.net [IPv6:2001:67c:27e0:2212::5303]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1415A1B2D25 for ; Wed, 20 May 2015 00:29:26 -0700 (PDT) X-Spam-STAY-ID: v=2.0 cv=QJfqt33L c=1 sm=0 a=fpfCo9GHTwTpwwPQDU8l2g==:17 a=dBZgz0PQq4UA:10 a=xqWC_Br6kY4A:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=0Pnrb1QawpfMYe0ThfQA:9 a=wPNLvfGTeEIA:10 a=ZocR-70LVBqqEoFx:21 a=bIy3iEzxp3Wd8tdN:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=OATSh-GLmXdlWyUX7E4A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp303.stejtech.net (Postfix) with ESMTPSA id 54A17F813D4; Wed, 20 May 2015 09:29:22 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.03.0210.002; Wed, 20 May 2015 09:29:22 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgLE00wAABLQzYAAfE4sAAEtqgIQ Date: Wed, 20 May 2015 07:29:21 +0000 Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C290C76A@ACREOEXC02.ad.acreo.se> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> In-Reply-To: <55546934.8070806@cttc.es> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.144.165] Content-Type: multipart/alternative; boundary="_000_7ECED07E132D4B4F89DCC0FDA683C6C290C76AACREOEXC02adacreo_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 07:29:34 -0000 --_000_7ECED07E132D4B4F89DCC0FDA683C6C290C76AACREOEXC02adacreo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ramon, 4.8.4: bear in mind that 0 is not a positive integer, and it looks like the= definitions involving (2^n) and (2^m) are intended to include the case whe= re n/m is 0. Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving= it as positive integer, since m=3D0 would imply an empty frequency slot. How do you figure that? Doesn't ::=3D (2^m) x 12.5GHz imply that the available SWGs start at 25 GHz if "m" is positive integer? /Jonas From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas Sent: den 14 maj 2015 11:22 To: ccamp@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and= call for sheperd Dear Matt, all Thank you very much for the review and comments, please see inline (aligned= with Adrian's reply). For what is worth, there were some comments that I received post LC, that w= ill also be in next updated version. El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribi=F3: All, I've reviewed this revision of the document, and I think it's almost ready = for publication. I have a few comments (below) but I don't think there's an= y major issues. 3.1: definition of OTN could be moved up to section 2.2, if you want. Ramon> Added as acronym, and removed the expansion, thank you 3.2.1: you state that the Nominal Central Frequency Granularity is 6.25GHz,= but there's no reference for this. I assume it's in an ITU doc somewhere? = If so, it'd be good to say so (and where) Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1] The document refers to "OTSi signals" in several places, but the definition= of "OTSi" includes "signal" :) I don't know whether or not this is normal = usage or whether it's worth fixing... but it looks technically wrong to me = (like people talking about "PIN numbers" whenever they get cash out of the = bank). Ramon> changed OTSi signals to OTSi 3.2.5, first bullet: "This group of OTSi should be carried over a single fi= bre." Is that a normal English should, or a 2219 SHOULD? If the former, it = might be worth rephrasing to avoid ambiguity. Ramon> changed to "are" as per Adrian's suggestion 4.2: "The association of the three components a filter, a fiber, and a filt= er, is a media channel in its most basic form.". It'd be nice to clarify th= at this is a fiber with a filter at each end - that's not immediately obvio= us on first reading, especially with the diagram that makes it clear on the= next page. Ramon> Likewise, changed to "association sequence" The paragraph below figure 8 is... unclear. Is it just trying to say that m= edia channels can be joined together to make a new media channel? Or is the= re more to it than that? Ramon> Basically the intent is that one, although it should reflect more to= the join of "basic" media channels (defined as an association sequence of = filter-fiber-filter as above). This, and the architectural construct being = an LSP. Changed to also use the term "association sequence" OLD Additionally, when a cross-connect for a specific frequency slot is considered, the underlying media support is still a media channel, augmented, so to speak, with a bigger association of media elements and a resulting effective slot. When this media channel is the result of the association of basic media channels and media layer matrix cross-connects, this architectural construct can be represented as (i.e., corresponds to) a Label Switched Path (LSP) from a control plane perspective. In other words, It is possible to "concatenate" several media channels (e.g., Patch on intermediate nodes) to create a single media channel. NEW Additionally, when a cross-connect for a specific frequency slot is considered, the resulting media support of joining basic media channels is still a media channel, i.e., a longer association sequence of media elements and its effective frequency slot. In other words, It is possibl= e to "concatenate" several media channels (e.g., patch on intermediate nodes) to create a single media channel. The architectural construct resulting of the association sequence of basic media channels and media layer matrix cross-connects can be represented as (i.e., corresponds to) a Label Switched Path (LSP) from a control plane perspective. Fig 12: OTSi trail? Did you mean OCh trail? Ramon> The error comes from the text, since the correct term is OTSi. OLD In Figure 12 a Network Media Channel is represented as terminated at the DWDM side of the transponder. This is commonly named as OCh- trail connection. NEW In Figure 12 a Network Media Channel is represented as terminated at the network side of the transponders. This is commonly named as OTSi- trail connection. Fig 14: MLN/MRN needs explaining. Or removing. Ramon> Removed. 4.3, towards the end: "there must be enough guard band between adjacent OTS= is in any media channel to compensate filter concatenation effect and other= effects caused by signal layer switching elements". Maybe "...to compensat= e for the filter concatenation effect and..." or "...to compensate for filt= er concatenation effects and..."? Ramon> new text "there must be enough guard band between adjacent OTSis in any media chann= el to compensate for the filter concatenation effects and other effects ca= used by signal layer switching elements" 4.8.4: bear in mind that 0 is not a positive integer, and it looks like the= definitions involving (2^n) and (2^m) are intended to include the case whe= re n/m is 0. Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving= it as positive integer, since m=3D0 would imply an empty frequency slot. If no further comments, I will proceed to upload these changes for -04 (wit= h other backlogged changes such as affiliation changes, CCAMP WG, Informati= onal, nits, editorial changes , typos, etc. ). Please see the attached diff Thanks Ramon --_000_7ECED07E132D4B4F89DCC0FDA683C6C290C76AACREOEXC02adacreo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ramon,

 

4.8.4: bear in mind= that 0 is not a positive integer, and it looks like the definitions involv= ing (2^n) and (2^m) are intended to include the case where n/m is 0.=

Ramon> Changed for "n" = to say "non-negative integer". For "m", I am leaving it= as positive integer, since m=3D0 would imply an empty frequency slot.

 

How do you figure that= ? Doesn’t

 

<Available Slot Widt= h Granularity> ::=3D (2^m) x 12.5GHz

 

imply that the availab= le SWGs start at 25 GHz if “m” is positive integer?<= /span>

 

/Jonas

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: den 14 maj 2015 11:22
To: ccamp@ietf.org
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk= -03 and call for sheperd

 

Dear Matt, all

Thank you very much for the review and comments, please see inline (aligned= with Adrian's reply).

For what is worth, there were some comments that I received post LC, that w= ill also be in next updated version.


El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribi=F3:

All,

 <= /o:p>

I’ve reviewed= this revision of the document, and I think it’s almost ready for pub= lication. I have a few comments (below) but I don’t think there’= ;s any major issues.

 <= /o:p>

3.1: definition of = OTN could be moved up to section 2.2, if you want.

Ramon> Added as acronym, and remo= ved the expansion, thank you

 <= /o:p>

3.2.1: you state th= at the Nominal Central Frequency Granularity is 6.25GHz, but there’s = no reference for this. I assume it’s in an ITU doc somewhere? If so, = it’d be good to say so (and where)

Ramon> Indeed. Much like SWG bein= g 12.5GHz, added [G.694.1]

 <= /o:p>

The document refers= to “OTSi signals” in several places, but the definition of = 220;OTSi” includes “signal” :) I don’t know whether= or not this is normal usage or whether it’s worth fixing… but = it looks technically wrong to me (like people talking about “PIN numbers” whenever = they get cash out of the bank).

 <= /o:p>

Ramon> changed OTSi signals to OT= Si


3.2.5, first bullet= : “This group of OTSi should be carried over a single fibre.” I= s that a normal English should, or a 2219 SHOULD? If the former, it might b= e worth rephrasing to avoid ambiguity.

Ramon> changed to "are"= as per Adrian's suggestion

 <= /o:p>

4.2: “The ass= ociation of the three components a filter, a fiber, and a filter, is a medi= a channel in its most basic form.”. It’d be nice to clarify tha= t this is a fiber with a filter at each end – that’s not immediately obvious on first reading, especially with the diagram that mak= es it clear on the next page.

 <= /o:p>

Ramon> Likewise, changed to "= ;association sequence"


The paragraph below= figure 8 is... unclear. Is it just trying to say that media channels can b= e joined together to make a new media channel? Or is there more to it than = that?

 <= /o:p>

Ramon> Basically the intent is th= at one, although it should reflect more to the join of "basic" me= dia channels (defined as an association sequence of filter-fiber-filter as above). This, and the architectural construct being an LSP.  Chang= ed to also use the term "association sequence"

OLD

&n=
bsp;  Additionally, when a cross-connect for a specific frequency slot=
 is
&n=
bsp;  considered, the underlying media support is still a media channe=
l,
&n=
bsp;  augmented, so to speak, with a bigger association of media eleme=
nts
&n=
bsp;  and a resulting effective slot.  When this media channel is=
 the
&n=
bsp;  result of the association of basic media channels and media laye=
r
&n=
bsp;  matrix cross-connects, this architectural construct can be<=
/o:p>
&n=
bsp;  represented as (i.e., corresponds to) a Label Switched Path (LSP=
)
&n=
bsp;  from a control plane perspective.  In other words, It is po=
ssible to
&n=
bsp;  "concatenate" several media channels (e.g., Patch on i=
ntermediate
&n=
bsp;  nodes) to create a single media channel.


NEW

&n=
bsp;  Additionally, when a cross-connect for a specific frequency slot=
 is
&n=
bsp;  considered, the resulting media support of joining basic media c=
hannels
&n=
bsp;  is still a media channel, i.e., a longer association sequence of=
 media 
&n=
bsp;  elements and its effective frequency slot. In other words, =
It is possible to
&n=
bsp;  "concatenate" several media channels (e.g., patch on i=
ntermediate
&n=
bsp;  nodes) to create a single media channel.
 
&n=
bsp;  The architectural construct resulting of the association sequenc=
e 
&n=
bsp;  of basic media channels and media layer matrix cross-connec=
ts can be
&n=
bsp;  represented as (i.e., corresponds to) a Label Switched Path (LSP=
)
&n=
bsp;  from a control plane perspective. 




Fig 12: OTSi trail?= Did you mean OCh trail?

Ramon> The error comes from the t= ext, since the correct term is OTSi.

OLD 

&n=
bsp;  In Figure 12 a Network Media Channel is represented as term=
inated at
&n=
bsp;  the DWDM side of the transponder.  This is commonly named a=
s OCh-
&n=
bsp;  trail connection.
 

NEW

&n=
bsp;  In Figure 12 a Network Media Channel is represented as terminate=
d at
&n=
bsp;  the network side of the transponders.  This is commonly nam=
ed as OTSi-
&n=
bsp;  trail connection.



 <= /o:p>

Fig 14: MLN/MRN nee= ds explaining. Or removing.

Ramon> Removed.

 <= /o:p>

4.3, towards the en= d: “there must be enough guard band between adjacent OTSis in any med= ia channel to compensate filter concatenation effect and other effects caus= ed by signal layer switching elements”. Maybe “…to compensate for the filter concatenation effect and…= ” or “…to compensate for filter concatenation effects and= …”?

 <= /o:p>

Ramon> new text
"there must be  enough guard band between adjacent OTSis in any m= edia channel to  compensate for the filter concatenation effects and o= ther effects caused by signal layer switching elements"


4.8.4: bear in mind= that 0 is not a positive integer, and it looks like the definitions involv= ing (2^n) and (2^m) are intended to include the case where n/m is 0.=

Ramon= > Changed for "n" to say "non-negative integer". For= "m", I am leaving it as positive integer, since m=3D0 would impl= y an empty frequency slot.


If no further comments, I will proceed to upload these changes for -04 (wit= h other backlogged changes such as affiliation changes, CCAMP WG, Informati= onal, nits, editorial changes , typos, etc. ). Please see the attached diff=


Thanks
Ramon

--_000_7ECED07E132D4B4F89DCC0FDA683C6C290C76AACREOEXC02adacreo_-- From nobody Wed May 20 01:03:46 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3E91ACDB0 for ; Wed, 20 May 2015 01:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_FORM=2.3, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5-WuBkGTTX6 for ; Wed, 20 May 2015 01:03:42 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919BE1A8890 for ; Wed, 20 May 2015 01:03:40 -0700 (PDT) Received: from [2001:40b0:7c22:6020:1979:18d:bf0:ba5] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YuyyQ-0002iV-IH; Wed, 20 May 2015 10:03:35 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 8BBBA1FD05; Wed, 20 May 2015 10:03:26 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <555C3FC6.80106@cttc.es> Date: Wed, 20 May 2015 10:03:18 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Jonas_M=E5rtensson?= , "ccamp@ietf.org" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C76A@ACREOEXC02.ad.acreo.se> In-Reply-To: <7ECED07E132D4B4F89DCC0FDA683C6C290C76A@ACREOEXC02.ad.acreo.se> Content-Type: multipart/alternative; boundary="------------050302090200030404030009" X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -1.0 (-) X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% [score: 0.1871] 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ietf.org] Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 08:03:45 -0000 This is a multi-part message in MIME format. --------------050302090200030404030009 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit El 20/05/2015 a las 9:29, Jonas Mårtensson escribió: > > Hi Ramon, > > 4.8.4: bear in mind that 0 is not a positive integer, and it looks > like the definitions involving (2^n) and (2^m) are intended to include > the case where n/m is 0. > > Ramon> Changed for "n" to say "non-negative integer". For "m", I am > leaving it as positive integer, since m=0 would imply an empty > frequency slot. > > How do you figure that? Doesn’t > > ::= (2^m) x 12.5GHz > > imply that the available SWGs start at 25 GHz if “m” is positive integer? > Hi Jonas, True, I think you spotted an error; in any case there is significant room for confusion, and now I regret that the model in section 4.8.4 uses "n" and "m" mixing the ITU-T definitions and the variables in the formulas themselves to describe granularities. - The parameter m is defined by ITU G.694.1 "a slot width defined by: 12.5 × m where m is a positive integer and 12.5 is the slot width granularity in GHz." - The parameter n is defined 193.1 + n × 0.00625 where n is a positive or negative integer including 0, parameter to describe nominal central frequencies (for which n can be indeed negative). - Unfortunately both are used to describe granularities in the model and are not the same concepts. In the formulas, both are ok using 0. I would suggest this (using p and q). IMHO, we will need to upload a -05 asap. ::= (2^p) x 6.25GHz where p is a non negative integer, giving rise to granularities such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz ::= (2^q) x 12.5GHz where q is a non negative integer In other words, I guess that the text before latest changes was ok, barred the unfortunate choice of names. But I would like to request for comments on this. Or maybe I am making things worse :) R. > /Jonas > > *From:*CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Ramon Casellas > *Sent:* den 14 maj 2015 11:22 > *To:* ccamp@ietf.org > *Subject:* Re: [CCAMP] WG Last Call on > draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd > > Dear Matt, all > > Thank you very much for the review and comments, please see inline > (aligned with Adrian's reply). > > For what is worth, there were some comments that I received post LC, > that will also be in next updated version. > > > El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribió: > > All, > > I’ve reviewed this revision of the document, and I think it’s > almost ready for publication. I have a few comments (below) but I > don’t think there’s any major issues. > > 3.1: definition of OTN could be moved up to section 2.2, if you want. > > Ramon> Added as acronym, and removed the expansion, thank you > > 3.2.1: you state that the Nominal Central Frequency Granularity is > 6.25GHz, but there’s no reference for this. I assume it’s in an ITU > doc somewhere? If so, it’d be good to say so (and where) > > Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1] > > The document refers to “OTSi signals” in several places, but the > definition of “OTSi” includes “signal” :) I don’t know whether or not > this is normal usage or whether it’s worth fixing… but it looks > technically wrong to me (like people talking about “PIN numbers” > whenever they get cash out of the bank). > > Ramon> changed OTSi signals to OTSi > > > 3.2.5, first bullet: “This group of OTSi should be carried over a > single fibre.” Is that a normal English should, or a 2219 SHOULD? If > the former, it might be worth rephrasing to avoid ambiguity. > > Ramon> changed to "are" as per Adrian's suggestion > > 4.2: “The association of the three components a filter, a fiber, and a > filter, is a media channel in its most basic form.”. It’d be nice to > clarify that this is a fiber with a filter at each end – that’s not > immediately obvious on first reading, especially with the diagram that > makes it clear on the next page. > > Ramon> Likewise, changed to "association sequence" > > > The paragraph below figure 8 is... unclear. Is it just trying to say > that media channels can be joined together to make a new media > channel? Or is there more to it than that? > > Ramon> Basically the intent is that one, although it should reflect > more to the join of "basic" media channels (defined as an association > sequence of filter-fiber-filter as above). This, and the architectural > construct being an LSP. Changed to also use the term "association > sequence" > > OLD > > Additionally, when a cross-connect for a specific frequency slot is > considered, the underlying media support is still a media channel, > augmented, so to speak, with a bigger association of media elements > and a resulting effective slot. When this media channel is the > result of the association of basic media channels and media layer > matrix cross-connects, this architectural construct can be > represented as (i.e., corresponds to) a Label Switched Path (LSP) > from a control plane perspective. In other words, It is possible to > "concatenate" several media channels (e.g., Patch on intermediate > nodes) to create a single media channel. > > > NEW > > Additionally, when a cross-connect for a specific frequency slot is > considered, the resulting media support of joining basic media channels > is still a media channel, i.e., a longer association sequence of media > elements and its effective frequency slot. In other words, It is possible to > "concatenate" several media channels (e.g., patch on intermediate > nodes) to create a single media channel. > > The architectural construct resulting of the association sequence > of basic media channels and media layer matrix cross-connects can be > represented as (i.e., corresponds to) a Label Switched Path (LSP) > from a control plane perspective. > > > > > Fig 12: OTSi trail? Did you mean OCh trail? > > Ramon> The error comes from the text, since the correct term is OTSi. > > OLD > > In Figure 12 a Network Media Channel is represented as terminated at > the DWDM side of the transponder. This is commonly named as OCh- > trail connection. > > > NEW > > In Figure 12 a Network Media Channel is represented as terminated at > the network side of the transponders. This is commonly named as OTSi- > trail connection. > > > > Fig 14: MLN/MRN needs explaining. Or removing. > > Ramon> Removed. > > 4.3, towards the end: “there must be enough guard band between > adjacent OTSis in any media channel to compensate filter concatenation > effect and other effects caused by signal layer switching elements”. > Maybe “…to compensate for the filter concatenation effect and…” or > “…to compensate for filter concatenation effects and…”? > > Ramon> new text > "there must be enough guard band between adjacent OTSis in any media > channel to compensate for the filter concatenation effects and other > effects caused by signal layer switching elements" > > > 4.8.4: bear in mind that 0 is not a positive integer, and it looks > like the definitions involving (2^n) and (2^m) are intended to include > the case where n/m is 0. > > Ramon> Changed for "n" to say "non-negative integer". For "m", I am > leaving it as positive integer, since m=0 would imply an empty > frequency slot. > > > If no further comments, I will proceed to upload these changes for -04 > (with other backlogged changes such as affiliation changes, CCAMP WG, > Informational, nits, editorial changes , typos, etc. ). Please see the > attached diff > > > Thanks > Ramon > --------------050302090200030404030009 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
El 20/05/2015 a las 9:29, Jonas Mårtensson escribió:

Hi Ramon,

 

4.8.4: bear in mind that 0 is not a positive integer, and it looks like the definitions involving (2^n) and (2^m) are intended to include the case where n/m is 0.

Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving it as positive integer, since m=0 would imply an empty frequency slot.

 

How do you figure that? Doesn’t

 

<Available Slot Width Granularity> ::= (2^m) x 12.5GHz

 

imply that the available SWGs start at 25 GHz if “m” is positive integer?

 


Hi Jonas,

True, I think you spotted an error; in any case there is significant room for confusion, and now I regret that the model in section 4.8.4 uses "n" and "m" mixing the ITU-T definitions and the variables in the formulas themselves to describe granularities.

- The parameter m is defined by ITU G.694.1 "a slot width defined by: 12.5 × m where m is a positive integer and 12.5 is the slot width granularity in GHz."
- The parameter n is defined 193.1 + n × 0.00625 where n is a positive or negative integer including  0, parameter to describe nominal central frequencies (for which n can be indeed negative).
- Unfortunately both are used to describe granularities in the model and are not the same concepts.

In the formulas, both are ok using 0.
I would suggest this (using p and q). IMHO, we will need to upload a -05 asap.

   <Available Central Frequency Granularity> ::= (2^p) x 6.25GHz
     where p is a non negative integer, giving rise to granularities
     such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz

   <Available Slot Width Granularity> ::= (2^q) x 12.5GHz
     where q is a non negative integer

In other words, I guess that the text before latest changes was ok, barred the unfortunate choice of names. But I would like to request for comments on this. Or maybe I am making things worse :)

R.


/Jonas

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: den 14 maj 2015 11:22
To: ccamp@ietf.org
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

 

Dear Matt, all

Thank you very much for the review and comments, please see inline (aligned with Adrian's reply).

For what is worth, there were some comments that I received post LC, that will also be in next updated version.


El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribió:

All,

 

I’ve reviewed this revision of the document, and I think it’s almost ready for publication. I have a few comments (below) but I don’t think there’s any major issues.

 

3.1: definition of OTN could be moved up to section 2.2, if you want.

Ramon> Added as acronym, and removed the expansion, thank you

 

3.2.1: you state that the Nominal Central Frequency Granularity is 6.25GHz, but there’s no reference for this. I assume it’s in an ITU doc somewhere? If so, it’d be good to say so (and where)

Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1]

 

The document refers to “OTSi signals” in several places, but the definition of “OTSi” includes “signal” :) I don’t know whether or not this is normal usage or whether it’s worth fixing… but it looks technically wrong to me (like people talking about “PIN numbers” whenever they get cash out of the bank).

 

Ramon> changed OTSi signals to OTSi


3.2.5, first bullet: “This group of OTSi should be carried over a single fibre.” Is that a normal English should, or a 2219 SHOULD? If the former, it might be worth rephrasing to avoid ambiguity.

Ramon> changed to "are" as per Adrian's suggestion

 

4.2: “The association of the three components a filter, a fiber, and a filter, is a media channel in its most basic form.”. It’d be nice to clarify that this is a fiber with a filter at each end – that’s not immediately obvious on first reading, especially with the diagram that makes it clear on the next page.

 

Ramon> Likewise, changed to "association sequence"


The paragraph below figure 8 is... unclear. Is it just trying to say that media channels can be joined together to make a new media channel? Or is there more to it than that?

 

Ramon> Basically the intent is that one, although it should reflect more to the join of "basic" media channels (defined as an association sequence of filter-fiber-filter as above). This, and the architectural construct being an LSP.  Changed to also use the term "association sequence"

OLD

   Additionally, when a cross-connect for a specific frequency slot is
   considered, the underlying media support is still a media channel,
   augmented, so to speak, with a bigger association of media elements
   and a resulting effective slot.  When this media channel is the
   result of the association of basic media channels and media layer
   matrix cross-connects, this architectural construct can be
   represented as (i.e., corresponds to) a Label Switched Path (LSP)
   from a control plane perspective.  In other words, It is possible to
   "concatenate" several media channels (e.g., Patch on intermediate
   nodes) to create a single media channel.


NEW

   Additionally, when a cross-connect for a specific frequency slot is
   considered, the resulting media support of joining basic media channels
   is still a media channel, i.e., a longer association sequence of media 
   elements and its effective frequency slot. In other words, It is possible to
   "concatenate" several media channels (e.g., patch on intermediate
   nodes) to create a single media channel.
 
   The architectural construct resulting of the association sequence 
   of basic media channels and media layer matrix cross-connects can be
   represented as (i.e., corresponds to) a Label Switched Path (LSP)
   from a control plane perspective. 




Fig 12: OTSi trail? Did you mean OCh trail?

Ramon> The error comes from the text, since the correct term is OTSi.

OLD 

   In Figure 12 a Network Media Channel is represented as terminated at
   the DWDM side of the transponder.  This is commonly named as OCh-
   trail connection.
 

NEW

   In Figure 12 a Network Media Channel is represented as terminated at
   the network side of the transponders.  This is commonly named as OTSi-
   trail connection.



 

Fig 14: MLN/MRN needs explaining. Or removing.

Ramon> Removed.

 

4.3, towards the end: “there must be enough guard band between adjacent OTSis in any media channel to compensate filter concatenation effect and other effects caused by signal layer switching elements”. Maybe “…to compensate for the filter concatenation effect and…” or “…to compensate for filter concatenation effects and…”?

 

Ramon> new text
"there must be  enough guard band between adjacent OTSis in any media channel to  compensate for the filter concatenation effects and other effects caused by signal layer switching elements"


4.8.4: bear in mind that 0 is not a positive integer, and it looks like the definitions involving (2^n) and (2^m) are intended to include the case where n/m is 0.

Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving it as positive integer, since m=0 would imply an empty frequency slot.


If no further comments, I will proceed to upload these changes for -04 (with other backlogged changes such as affiliation changes, CCAMP WG, Informational, nits, editorial changes , typos, etc. ). Please see the attached diff


Thanks
Ramon


--------------050302090200030404030009-- From nobody Wed May 20 01:52:44 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB83C1A1AE6 for ; Wed, 20 May 2015 01:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_FORM=2.3, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQHyFey_rcCY for ; Wed, 20 May 2015 01:52:36 -0700 (PDT) Received: from smtp304-outgoing.stejtech.net (smtp304.stejtech.net [IPv6:2001:67c:27e0:2212::5304]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAA01A1A9F for ; Wed, 20 May 2015 01:52:35 -0700 (PDT) X-Spam-STAY-ID: v=2.0 cv=R+OB6KtX c=1 sm=0 a=fpfCo9GHTwTpwwPQDU8l2g==:17 a=dBZgz0PQq4UA:10 a=xqWC_Br6kY4A:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=k5Tf46Y5WNoERa5XVNwA:9 a=wPNLvfGTeEIA:10 a=QiUDj9SLOcNwOKlf:21 a=9l_7OMhDL6n5QtVy:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=u3KKLRwlgC032Lp_mGMA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=UBZuAtqXqftS4hJh:21 a=sC27VrhxhJXEUj7C:21 Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp304.stejtech.net (Postfix) with ESMTPSA id 8F51628205F; Wed, 20 May 2015 10:52:26 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.03.0210.002; Wed, 20 May 2015 10:52:25 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgLE00wAABLQzYAAfE4sAAEtqgIQ///qtAD//9RWQA== Date: Wed, 20 May 2015 08:52:24 +0000 Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C290C959@ACREOEXC02.ad.acreo.se> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C76A@ACREOEXC02.ad.acreo.se> <555C3FC6.80106@cttc.es> In-Reply-To: <555C3FC6.80106@cttc.es> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.144.165] Content-Type: multipart/alternative; boundary="_000_7ECED07E132D4B4F89DCC0FDA683C6C290C959ACREOEXC02adacreo_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 08:52:42 -0000 --_000_7ECED07E132D4B4F89DCC0FDA683C6C290C959ACREOEXC02adacreo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "In other words, I guess that the text before latest changes was ok, barred= the unfortunate choice of names. But I would like to request for comments = on this. Or maybe I am making things worse :)" Older versions had: ::=3D n x 6.25GHz ::=3D m x 12.5GHz In -03 it was instead: ::=3D (2^n) x 6.25GHz ::=3D (2^m) x 12.5GHz i.e. "n" and "m" were changed to "2^n" and "2^m" but it still said that "n"= and "m" were positive integers which is wrong. The new formulas (even if n= ,m =3D 0 is included) also change the available granularities but I assume = this was intended (I was not involved). Anyway, I agree with your suggestion to use different parameter names (p an= d q) for specifying granularities to reduce risk for confusion. /Jonas From: Ramon Casellas [mailto:ramon.casellas@cttc.es] Sent: den 20 maj 2015 10:03 To: Jonas M=E5rtensson; ccamp@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and= call for sheperd El 20/05/2015 a las 9:29, Jonas M=E5rtensson escribi=F3: Hi Ramon, 4.8.4: bear in mind that 0 is not a positive integer, and it looks like the= definitions involving (2^n) and (2^m) are intended to include the case whe= re n/m is 0. Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving= it as positive integer, since m=3D0 would imply an empty frequency slot. How do you figure that? Doesn't ::=3D (2^m) x 12.5GHz imply that the available SWGs start at 25 GHz if "m" is positive integer? Hi Jonas, True, I think you spotted an error; in any case there is significant room f= or confusion, and now I regret that the model in section 4.8.4 uses "n" and= "m" mixing the ITU-T definitions and the variables in the formulas themsel= ves to describe granularities. - The parameter m is defined by ITU G.694.1 "a slot width defined by: 12.5 = =D7 m where m is a positive integer and 12.5 is the slot width granularity = in GHz." - The parameter n is defined 193.1 + n =D7 0.00625 where n is a positive or= negative integer including 0, parameter to describe nominal central frequ= encies (for which n can be indeed negative). - Unfortunately both are used to describe granularities in the model and ar= e not the same concepts. In the formulas, both are ok using 0. I would suggest this (using p and q). IMHO, we will need to upload a -05 as= ap. ::=3D (2^p) x 6.25GHz where p is a non negative integer, giving rise to granularities such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz ::=3D (2^q) x 12.5GHz where q is a non negative integer In other words, I guess that the text before latest changes was ok, barred = the unfortunate choice of names. But I would like to request for comments o= n this. Or maybe I am making things worse :) R. /Jonas From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas Sent: den 14 maj 2015 11:22 To: ccamp@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and= call for sheperd Dear Matt, all Thank you very much for the review and comments, please see inline (aligned= with Adrian's reply). For what is worth, there were some comments that I received post LC, that w= ill also be in next updated version. El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribi=F3: All, I've reviewed this revision of the document, and I think it's almost ready = for publication. I have a few comments (below) but I don't think there's an= y major issues. 3.1: definition of OTN could be moved up to section 2.2, if you want. Ramon> Added as acronym, and removed the expansion, thank you 3.2.1: you state that the Nominal Central Frequency Granularity is 6.25GHz,= but there's no reference for this. I assume it's in an ITU doc somewhere? = If so, it'd be good to say so (and where) Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1] The document refers to "OTSi signals" in several places, but the definition= of "OTSi" includes "signal" :) I don't know whether or not this is normal = usage or whether it's worth fixing... but it looks technically wrong to me = (like people talking about "PIN numbers" whenever they get cash out of the = bank). Ramon> changed OTSi signals to OTSi 3.2.5, first bullet: "This group of OTSi should be carried over a single fi= bre." Is that a normal English should, or a 2219 SHOULD? If the former, it = might be worth rephrasing to avoid ambiguity. Ramon> changed to "are" as per Adrian's suggestion 4.2: "The association of the three components a filter, a fiber, and a filt= er, is a media channel in its most basic form.". It'd be nice to clarify th= at this is a fiber with a filter at each end - that's not immediately obvio= us on first reading, especially with the diagram that makes it clear on the= next page. Ramon> Likewise, changed to "association sequence" The paragraph below figure 8 is... unclear. Is it just trying to say that m= edia channels can be joined together to make a new media channel? Or is the= re more to it than that? Ramon> Basically the intent is that one, although it should reflect more to= the join of "basic" media channels (defined as an association sequence of = filter-fiber-filter as above). This, and the architectural construct being = an LSP. Changed to also use the term "association sequence" OLD Additionally, when a cross-connect for a specific frequency slot is considered, the underlying media support is still a media channel, augmented, so to speak, with a bigger association of media elements and a resulting effective slot. When this media channel is the result of the association of basic media channels and media layer matrix cross-connects, this architectural construct can be represented as (i.e., corresponds to) a Label Switched Path (LSP) from a control plane perspective. In other words, It is possible to "concatenate" several media channels (e.g., Patch on intermediate nodes) to create a single media channel. NEW Additionally, when a cross-connect for a specific frequency slot is considered, the resulting media support of joining basic media channels is still a media channel, i.e., a longer association sequence of media elements and its effective frequency slot. In other words, It is possibl= e to "concatenate" several media channels (e.g., patch on intermediate nodes) to create a single media channel. The architectural construct resulting of the association sequence of basic media channels and media layer matrix cross-connects can be represented as (i.e., corresponds to) a Label Switched Path (LSP) from a control plane perspective. Fig 12: OTSi trail? Did you mean OCh trail? Ramon> The error comes from the text, since the correct term is OTSi. OLD In Figure 12 a Network Media Channel is represented as terminated at the DWDM side of the transponder. This is commonly named as OCh- trail connection. NEW In Figure 12 a Network Media Channel is represented as terminated at the network side of the transponders. This is commonly named as OTSi- trail connection. Fig 14: MLN/MRN needs explaining. Or removing. Ramon> Removed. 4.3, towards the end: "there must be enough guard band between adjacent OTS= is in any media channel to compensate filter concatenation effect and other= effects caused by signal layer switching elements". Maybe "...to compensat= e for the filter concatenation effect and..." or "...to compensate for filt= er concatenation effects and..."? Ramon> new text "there must be enough guard band between adjacent OTSis in any media chann= el to compensate for the filter concatenation effects and other effects ca= used by signal layer switching elements" 4.8.4: bear in mind that 0 is not a positive integer, and it looks like the= definitions involving (2^n) and (2^m) are intended to include the case whe= re n/m is 0. Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving= it as positive integer, since m=3D0 would imply an empty frequency slot. If no further comments, I will proceed to upload these changes for -04 (wit= h other backlogged changes such as affiliation changes, CCAMP WG, Informati= onal, nits, editorial changes , typos, etc. ). Please see the attached diff Thanks Ramon --_000_7ECED07E132D4B4F89DCC0FDA683C6C290C959ACREOEXC02adacreo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

“In other words, I guess that = the text before latest changes was ok, barred the unfortunate choice of nam= es. But I would like to request for comments on this. Or maybe I am making things worse :)”

Older versions had:

 

<Available Central F= requency Granularity> ::=3D n x 6.25GHz

 

<Available Slot Widt= h Granularity> ::=3D m x 12.5GHz

 

In -03 it was instead:=

 

<Available Central F= requency Granularity> ::=3D (2^n) x 6.25GHz

 

<Available Slot Widt= h Granularity> ::=3D (2^m) x 12.5GHz

 

i.e. “n” and “m” were changed to “2^n&#= 8221; and “2^m” but it still said that “n” and R= 20;m” were positive integers which is wrong. The new formulas (even i= f n,m =3D 0 is included) also change the available granularities but I assume this was intended (I was not invo= lved).

 

Anyway, I agree with y= our suggestion to use different parameter names (p and q) for specifying gr= anularities to reduce risk for confusion.

 

/Jonas

 

From: Ramon Casellas [mailto:ramon.casellas@cttc.es]
Sent: den 20 maj 2015 10:03
To: Jonas M=E5rtensson; ccamp@ietf.org
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk= -03 and call for sheperd

 

El 20/05/2015 a las 9:29, Jonas M=E5rtensson escribi= =F3:

Hi Ramon,<= /o:p>

 

4.8.4: bear in mind= that 0 is not a positive integer, and it looks like the definitions involv= ing (2^n) and (2^m) are intended to include the case where n/m is 0.=

Ramon> Changed for "= n" to say "non-negative integer". For "m", I am le= aving it as positive integer, since m=3D0 would imply an empty frequency sl= ot.

 

How do you figure that= ? Doesn’t

 

<Available Slot Widt= h Granularity> ::=3D (2^m) x 12.5GHz

 

imply that the availab= le SWGs start at 25 GHz if “m” is positive integer?=

 


Hi Jonas,

True, I think you spotted an error; in any case there is significant room f= or confusion, and now I regret that the model in section 4.8.4 uses "n= " and "m" mixing the ITU-T definitions and the variables in = the formulas themselves to describe granularities.

- The parameter m is defined by ITU G.694.1 "a slot width defined by: = 12.5 =D7 m where m is a positive integer and 12.5 is the slot width granula= rity in GHz."
- The parameter n is defined 193.1 + n =D7 0.00625 where n is a positiv= e or negative integer including  0, parameter to describe nominal cent= ral frequencies (for which n can be indeed negative).
- Unfortunately both are used to describe granularities in the model and ar= e not the same concepts.

In the formulas, both are ok using 0.
I would suggest this (using p and q). IMHO, we will need to upload a -05 as= ap.


   <Available Central =
Frequency Granularity> ::=3D (2^p) x 6.25GHz
     where p is=
 a non negative integer, giving rise to granularities
     such as 6.=
25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz
 
   <Available Slot Wid=
th Granularity> ::=3D (2^q) x 12.5GHz
     where q is=
 a non negative integer


In other words, I guess that the text before latest changes was ok, barred = the unfortunate choice of names. But I would like to request for comments o= n this. Or maybe I am making things worse :)

R.



/Jonas

 

From: CCAMP [= mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: den 14 maj 2015 11:22
To: ccamp@ietf.org
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk= -03 and call for sheperd

 

Dear Matt, all

Thank you very much for the review and comments, please see inline (aligned= with Adrian's reply).

For what is worth, there were some comments that I received post LC, that w= ill also be in next updated version.


El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribi=F3:

All,

 <= /o:p>

I’ve reviewed= this revision of the document, and I think it’s almost ready for pub= lication. I have a few comments (below) but I don’t think there’= ;s any major issues.

 <= /o:p>

3.1: definition of = OTN could be moved up to section 2.2, if you want.

Ramon> Added as acronym, = and removed the expansion, thank you


 <= /o:p>

3.2.1: you state th= at the Nominal Central Frequency Granularity is 6.25GHz, but there’s = no reference for this. I assume it’s in an ITU doc somewhere? If so, = it’d be good to say so (and where)

Ramon> Indeed. Much like = SWG being 12.5GHz, added [G.694.1]


 <= /o:p>

The document refers= to “OTSi signals” in several places, but the definition of = 220;OTSi” includes “signal” :) I don’t know whether= or not this is normal usage or whether it’s worth fixing… but = it looks technically wrong to me (like people talking about “PIN numbers” whenever = they get cash out of the bank).

 <= /o:p>

Ramon> changed OTSi signa= ls to OTSi



3.2.5, first bullet= : “This group of OTSi should be carried over a single fibre.” I= s that a normal English should, or a 2219 SHOULD? If the former, it might b= e worth rephrasing to avoid ambiguity.

Ramon> changed to "a= re" as per Adrian's suggestion


 <= /o:p>

4.2: “The ass= ociation of the three components a filter, a fiber, and a filter, is a medi= a channel in its most basic form.”. It’d be nice to clarify tha= t this is a fiber with a filter at each end – that’s not immediately obvious on first reading, especially with the diagram that mak= es it clear on the next page.

 <= /o:p>

Ramon> Likewise, changed = to "association sequence"



The paragraph below= figure 8 is... unclear. Is it just trying to say that media channels can b= e joined together to make a new media channel? Or is there more to it than = that?

 <= /o:p>

Ramon> Basically the inte= nt is that one, although it should reflect more to the join of "basic&= quot; media channels (defined as an association sequence of filter-fiber-fi= lter as above). This, and the architectural construct being an LSP.  Chang= ed to also use the term "association sequence"

OLD


&n=
bsp;  Additionally, when a cross-connect for a specific frequency slot=
 is
&n=
bsp;  considered, the underlying media support is still a media channe=
l,
&n=
bsp;  augmented, so to speak, with a bigger association of media eleme=
nts
&n=
bsp;  and a resulting effective slot.  When this media channel is=
 the
&n=
bsp;  result of the association of basic media channels and media laye=
r
&n=
bsp;  matrix cross-connects, this architectural construct can be
&n=
bsp;  represented as (i.e., corresponds to) a Label Switched Path (LSP=
)
&n=
bsp;  from a control plane perspective.  In other words, It is po=
ssible to
&n=
bsp;  "concatenate" several media channels (e.g., Patch on i=
ntermediate
&n=
bsp;  nodes) to create a single media channel.


NEW


&n=
bsp;  Additionally, when a cross-connect for a specific frequency slot=
 is
&n=
bsp;  considered, the resulting media support of joining basic media c=
hannels
&n=
bsp;  is still a media channel, i.e., a longer association sequence of=
 media 
&n=
bsp;  elements and its effective frequency slot. In other words, =
It is possible to
&n=
bsp;  "concatenate" several media channels (e.g., patch on i=
ntermediate
&n=
bsp;  nodes) to create a single media channel.
&n=
bsp;
&n=
bsp;  The architectural construct resulting of the association sequenc=
e 
&n=
bsp;  of basic media channels and media layer matrix cross-connec=
ts can be
&n=
bsp;  represented as (i.e., corresponds to) a Label Switched Path (LSP=
)
&n=
bsp;  from a control plane perspective. 





Fig 12: OTSi trail?= Did you mean OCh trail?

Ramon> The error comes fr= om the text, since the correct term is OTSi.

OLD 


&n=
bsp;  In Figure 12 a Network Media Channel is represented as term=
inated at
&n=
bsp;  the DWDM side of the transponder.  This is commonly named a=
s OCh-
&n=
bsp;  trail connection.
&n=
bsp;

NEW


&n=
bsp;  In Figure 12 a Network Media Channel is represented as terminate=
d at
&n=
bsp;  the network side of the transponders.  This is commonly nam=
ed as OTSi-
&n=
bsp;  trail connection.




 <= /o:p>

Fig 14: MLN/MRN nee= ds explaining. Or removing.

Ramon> Removed.


 <= /o:p>

4.3, towards the en= d: “there must be enough guard band between adjacent OTSis in any med= ia channel to compensate filter concatenation effect and other effects caus= ed by signal layer switching elements”. Maybe “…to compensate for the filter concatenation effect and…= ” or “…to compensate for filter concatenation effects and= …”?

 <= /o:p>

Ramon> new text
"there must be  enough guard band between adjacent OTSis in any m= edia channel to  compensate for the filter concatenation effects and o= ther effects caused by signal layer switching elements"



4.8.4: bear in mind= that 0 is not a positive integer, and it looks like the definitions involv= ing (2^n) and (2^m) are intended to include the case where n/m is 0.=

Ramon> Changed for "n" to say "non-negative integer&qu= ot;. For "m", I am leaving it as positive integer, since m=3D0 wo= uld imply an empty frequency slot.


If no further comments, I will proceed to upload these changes for -04 (wit= h other backlogged changes such as affiliation changes, CCAMP WG, Informati= onal, nits, editorial changes , typos, etc. ). Please see the attached diff=


Thanks
Ramon

 

--_000_7ECED07E132D4B4F89DCC0FDA683C6C290C959ACREOEXC02adacreo_-- From nobody Wed May 20 03:27:13 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310481B3660 for ; Wed, 20 May 2015 03:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxvBuuFtoUb0 for ; Wed, 20 May 2015 03:27:11 -0700 (PDT) Received: from navarro.puc.rediris.es (navarro.puc.rediris.es [IPv6:2001:720:418:ca01::131]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929C81B35CC for ; Wed, 20 May 2015 03:27:10 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yv1DH-0001bL-7l; Wed, 20 May 2015 12:27:00 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 27CE41FD05; Wed, 20 May 2015 12:26:55 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <555C6167.4070101@cttc.es> Date: Wed, 20 May 2015 12:26:47 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Jonas_M=E5rtensson?= , "ccamp@ietf.org" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C76A@ACREOEXC02.ad.acreo.se> <555C3FC6.80106@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C959@ACREOEXC02.ad.acreo.se> In-Reply-To: <7ECED07E132D4B4F89DCC0FDA683C6C290C959@ACREOEXC02.ad.acreo.se> Content-Type: multipart/alternative; boundary="------------090700050202090906010305" X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -0.2 (/) X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: itu.int] 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4996] Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 10:27:13 -0000 This is a multi-part message in MIME format. --------------090700050202090906010305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit > i.e. “n” and “m” were changed to “2^n” and “2^m” but it still said > that “n” and “m” were positive integers which is wrong. The new > formulas (even if n,m = 0 is included) also change the available > granularities but I assume this was intended (I was not involved). Jonas, all Let's try to re-visit this again and come up with some definitive text. I also wonder about: * the need to introduce formulas or similar o just provide a list of acceptable values. * whether a single value captures the intended model attribute (e.g. granularity is X) or multiple values are acceptable. IMHO: we should ideally list the acceptable values and capture common deployments, rather than exotic configurations such as "this node only supports ncf of 6.25 if between this frequency and that frequency and 25 otherwise, or it can support width granulaties of x,y,z depending on ...) ITU rec is not extremely helpful, and only provides main guidelines: ITU-T Rec G.694.1 ( http://www.itu.int/rec/T-REC-G.694.1-201202-I/en ) states Appendix I: /"The flexible DWDM grid defined in clause 7 has a nominal central frequency granularity of 6.25 GHz and a slot width granularity of 12.5 GHz. However, devices or applications that make use of the flexible grid may not have to be capable of supporting every possible slot width or position. In other words, applications may be defined where only a subset of the possible slot widths and positions are required to be supported. For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and that only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even)."/ For nominal central frequency granularity ========================================= we had: A) ::= p x 6.25GHz B) ::= (2^p) x 6.25GHz for p>=0 Typically, values used for this (in fixed grid) "/The frequency grid defined by this Recommendation supports a variety of fixed channel spacings ranging from 12.5 GHz to 100 GHz and wider (integer multiples of 100 GHz) as well as a flexible grid. Uneven channel spacings using the fixed grids are also allowed./" Note that in section 6, values with n=0 are used as reference for all the grids. IOW, we are implying that the granularity is given wrt n=0. A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are not necessarily common or deployed. B) yields 6.25, 12.5, 50.0, 100, 200, 400... it fails to capture the "integer multiples of 100", Questions: Q1: should we cover values above 100/200 ? if yes, B) fails. Q2: do we need to explictly mention that granularity itself is not enough without mentioning a "reference/anchor" NCF that is not n=0? do we assume that n=0 is always available and the granularity is always wrt to it -- relying on the " " to complete this information?" For nominal central frequency granularity ========================================= we had : C) ::= q x 12.5GHz D) ::= (2^q) x 12.5GHz q>= 0 C) yields 12.5, 25, 37.5, 50, 62.5, 75 D) yields 12.5, 25, 50, 100, 200, 400, D) is excluding restrictions such as "frequency slots with m=3 (37.5 GHz)" so I am not sure it is ok if we want to cover those. It seems safer to stick to C) imho For available frequency range ========================================== In -03, -04 ::= ( ) | I don't like neither the use of "position" nor the use of the undefined term "slice" Proposed text ===================== ::= A value from within the list 6.25GHz, 12.5GHz, 25GHz, 50GHz, 100GHz, 200GHz, 300GHz, 400GHz... -- Note that the granularity is defined with respect to anchor frequency given by n=0 ::= A value from within the list defined byq x 12.5GHz where q is a positive integer (q>0) -- It is the minimum slot width that can be defined ::= ( ) | Any comments? Yes/no? suggested alternatives? much appreciated :) Thanks Ramon --------------090700050202090906010305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

i.e. “n” and “m” were changed to “2^n” and “2^m” but it still said that “n” and “m” were positive integers which is wrong. The new formulas (even if n,m = 0 is included) also change the available granularities but I assume this was intended (I was not involved).
Jonas, all

Let's try to re-visit this again and come up with some definitive text. I also wonder about:

* the need to introduce formulas or similar o just provide a list of acceptable values.
* whether a single value captures the intended model attribute (e.g. granularity is X) or multiple values are acceptable.

IMHO: we should ideally list the acceptable values and capture common deployments, rather than exotic configurations such as "this node only supports ncf of 6.25 if between this frequency and that frequency and 25 otherwise, or it can support width granulaties of x,y,z depending on ...)

ITU rec is not extremely helpful, and only provides main guidelines: ITU-T Rec G.694.1 ( http://www.itu.int/rec/T-REC-G.694.1-201202-I/en ) states Appendix I: "The flexible DWDM grid defined in clause 7 has a nominal central frequency granularity of 6.25 GHz and a slot width granularity of 12.5 GHz. However, devices or applications that make use of the flexible grid may not have to be capable of supporting every possible slot width or position. In other words, applications may be defined where only a subset of the possible slot widths and positions are required to be supported. For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and that only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even)."



For nominal central frequency granularity
=========================================
we had:

A) <Available Central Frequency Granularity> ::= p x 6.25GHz
B) <Available Central Frequency Granularity> ::= (2^p) x 6.25GHz for p>=0

Typically, values used for this (in fixed grid)  "The frequency grid defined by this Recommendation supports a variety of fixed channel spacings ranging from 12.5 GHz to 100 GHz and wider (integer multiples of 100 GHz) as well as a flexible grid. Uneven channel spacings using the fixed grids are also allowed." Note that in section 6, values with n=0 are used as reference for all the grids. IOW, we are implying that the granularity is given wrt n=0.

A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are not necessarily common or deployed.
B) yields 6.25, 12.5, 50.0, 100, 200, 400... it fails to capture the "integer multiples of 100",

Questions:
Q1: should we cover values above 100/200 ? if yes, B) fails.
Q2: do we need to explictly mention that granularity itself is not enough without mentioning a "reference/anchor" NCF that is not n=0? do we assume that n=0 is always available and the granularity is always wrt to it -- relying on the " <Available Frequency Range-List> " to complete this information?"


For nominal central frequency granularity
=========================================
we had :
C) <Available Slot Width Granularity> ::= q x 12.5GHz
D) <Available Slot Width Granularity> ::= (2^q) x 12.5GHz q>= 0

C) yields 12.5, 25, 37.5, 50, 62.5, 75
D) yields  12.5, 25, 50, 100, 200, 400,

D) is excluding restrictions such as "frequency slots with m=3 (37.5 GHz)" so I am not sure it is ok if we want to cover those. It seems safer to stick to C) imho

For available frequency range
==========================================
In -03, -04

   <Available Frequency Range> ::=
     ( <Start Spectrum Position> <End Spectrum Position> ) |
     <Sets of contiguous slices>

I don't like neither the use of "position" nor the use of the undefined term "slice"

Proposed text
=====================

<Available Central Frequency Granularity> ::= 
    A value from within the list 6.25GHz, 12.5GHz, 25GHz, 50GHz, 100GHz, 200GHz, 300GHz, 400GHz... 
    -- Note that the granularity is defined with respect to anchor frequency given by n=0

<Available Slot Width Granularity> ::=
    A value from within the list defined by q x 12.5GHz where q is a positive integer (q>0)
    -- It is the minimum slot width that can be defined

<Available Frequency Range> ::=
     ( <Start Nominal Central Frequency> <End Nominal Central Frequency> ) |
       <A frequency slot defined by its n and m contaning a set of contiguous nominal central frequencies>

Any comments? Yes/no? suggested alternatives?  much appreciated :)

Thanks

Ramon




--------------090700050202090906010305-- From nobody Wed May 20 05:51:30 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C61A0115 for ; Wed, 20 May 2015 05:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cauEjsrmEtFa for ; Wed, 20 May 2015 05:51:22 -0700 (PDT) Received: from smtp301-outgoing.stejtech.net (smtp301.stejtech.net [IPv6:2001:67c:27e0:2212::5301]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B692F1A0121 for ; Wed, 20 May 2015 05:51:18 -0700 (PDT) X-Spam-STAY-ID: v=2.0 cv=atIw+FlV c=1 sm=0 a=fpfCo9GHTwTpwwPQDU8l2g==:17 a=dBZgz0PQq4UA:10 a=xqWC_Br6kY4A:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=hZG83p_yAAAA:8 a=DiyQPNL_zmzEgXyKQ84A:9 a=wPNLvfGTeEIA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=ewTqpK25P96tV11YlpgA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp301.stejtech.net (Postfix) with ESMTPSA id 0D4FC196194F; Wed, 20 May 2015 14:51:14 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.03.0210.002; Wed, 20 May 2015 14:51:13 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgLE00wAABLQzYAAfE4sAAEtqgIQ///qtAD//9RWQIAAU8GA///H9HA= Date: Wed, 20 May 2015 12:51:13 +0000 Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C290CC98@ACREOEXC02.ad.acreo.se> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C76A@ACREOEXC02.ad.acreo.se> <555C3FC6.80106@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C959@ACREOEXC02.ad.acreo.se> <555C6167.4070101@cttc.es> In-Reply-To: <555C6167.4070101@cttc.es> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.144.165] Content-Type: multipart/alternative; boundary="_000_7ECED07E132D4B4F89DCC0FDA683C6C290CC98ACREOEXC02adacreo_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 12:51:27 -0000 --_000_7ECED07E132D4B4F89DCC0FDA683C6C290CC98ACREOEXC02adacreo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A) ::=3D p x 6.25GHz "A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are= not necessarily common or deployed." Still... I don't really see a good reason why you would exclude those value= s (which are compliant with G.694.1) at this point... More generally, I thi= nk an information model should describe the needed information, not necessa= rily limit values representing the information (that could be done in a fut= ure encoding draft). Anyway, and sorry if I confuse things even more, it seems to me that what y= ou actually want to capture with the information model is available center = frequencies and slot widths, not the granularities per se. Granularities ar= e one way to represent available values but how to represent those could be= left for a future encoding draft. So a more general information model coul= d be: ::=3D ::=3D the subset of supported n values (whe= re n is defined as in G.694.1) ::=3D the subset of supported m values (where m is = defined as in G.694.1) If you want to go one step further and limit how to represent these subsets= by introducing granularities (and possibly offsets but that is maybe unnec= essarily complex) you could have: ::=3D One possible representation would be to say that available center frequenci= es are the subset of supported n values given by p x n + q where p (granula= rity) is a positive integer and q (offset) belongs to 0,..,q-1. ::=3D /Jonas From: Ramon Casellas [mailto:ramon.casellas@cttc.es] Sent: den 20 maj 2015 12:27 To: Jonas M=E5rtensson; ccamp@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and= call for sheperd i.e. "n" and "m" were changed to "2^n" and "2^m" but it still said that "n"= and "m" were positive integers which is wrong. The new formulas (even if n= ,m =3D 0 is included) also change the available granularities but I assume = this was intended (I was not involved). Jonas, all Let's try to re-visit this again and come up with some definitive text. I a= lso wonder about: * the need to introduce formulas or similar o just provide a list of accept= able values. * whether a single value captures the intended model attribute (e.g. granul= arity is X) or multiple values are acceptable. IMHO: we should ideally list the acceptable values and capture common deplo= yments, rather than exotic configurations such as "this node only supports = ncf of 6.25 if between this frequency and that frequency and 25 otherwise, = or it can support width granulaties of x,y,z depending on ...) ITU rec is not extremely helpful, and only provides main guidelines: ITU-T = Rec G.694.1 ( http://www.itu.int/rec/T-REC-G.694.1-201202-I/en ) states App= endix I: "The flexible DWDM grid defined in clause 7 has a nominal central = frequency granularity of 6.25 GHz and a slot width granularity of 12.5 GHz.= However, devices or applications that make use of the flexible grid may no= t have to be capable of supporting every possible slot width or position. I= n other words, applications may be defined where only a subset of the possi= ble slot widths and positions are required to be supported. For example, an= application could be defined where the nominal central frequency granulari= ty is 12.5 GHz (by only requiring values of n that are even) and that only = requires slot widths as a multiple of 25 GHz (by only requiring values of m= that are even)." For nominal central frequency granularity =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D we had: A) ::=3D p x 6.25GHz B) ::=3D (2^p) x 6.25GHz for p>= =3D0 Typically, values used for this (in fixed grid) "The frequency grid define= d by this Recommendation supports a variety of fixed channel spacings rangi= ng from 12.5 GHz to 100 GHz and wider (integer multiples of 100 GHz) as wel= l as a flexible grid. Uneven channel spacings using the fixed grids are als= o allowed." Note that in section 6, values with n=3D0 are used as reference= for all the grids. IOW, we are implying that the granularity is given wrt = n=3D0. A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are = not necessarily common or deployed. B) yields 6.25, 12.5, 50.0, 100, 200, 400... it fails to capture the "integ= er multiples of 100", Questions: Q1: should we cover values above 100/200 ? if yes, B) fails. Q2: do we need to explictly mention that granularity itself is not enough w= ithout mentioning a "reference/anchor" NCF that is not n=3D0? do we assume = that n=3D0 is always available and the granularity is always wrt to it -- r= elying on the " " to complete this informa= tion?" For nominal central frequency granularity =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D we had : C) ::=3D q x 12.5GHz D) ::=3D (2^q) x 12.5GHz q>=3D 0 C) yields 12.5, 25, 37.5, 50, 62.5, 75 D) yields 12.5, 25, 50, 100, 200, 400, D) is excluding restrictions such as "frequency slots with m=3D3 (37.5 GHz)= " so I am not sure it is ok if we want to cover those. It seems safer to st= ick to C) imho For available frequency range =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In -03, -04 ::=3D ( ) | I don't like neither the use of "position" nor the use of the undefined ter= m "slice" Proposed text =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ::=3D A value from within the list 6.25GHz, 12.5GHz, 25GHz, 50GHz, 100GHz, 20= 0GHz, 300GHz, 400GHz... -- Note that the granularity is defined with respect to anchor frequenc= y given by n=3D0 ::=3D A value from within the list defined by q x 12.5GHz where q is a positi= ve integer (q>0) -- It is the minimum slot width that can be defined ::=3D ( ) = | Any comments? Yes/no? suggested alternatives? much appreciated :) Thanks Ramon --_000_7ECED07E132D4B4F89DCC0FDA683C6C290CC98ACREOEXC02adacreo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A)  <Available Central Frequency = Granularity> ::=3D p x 6.25GHz

 <= /p>

”A) yields 6.25, 1= 2.5, 18.75, 25.0, 31.25, etc... a list of values that are not necessarily c= ommon or deployed.”

 

Still… I don’= t really see a good reason why you would exclude those values (which are co= mpliant with G.694.1) at this point… More generally, I think an infor= mation model should describe the needed information, not necessarily limit values= representing the information (that could be done in a future encoding draf= t).

 <= /p>

Anyway, and sorry if I co= nfuse things even more, it seems to me that what you actually want to captu= re with the information model is available center frequencies and slot widths, not the granularities per se. Granularities are one way t= o represent available values but how to represent those could be left for a= future encoding draft. So a more general information model could be:<= /o:p>

 <= /p>

<A= vailable Spectrum> ::=3D

 = ;      <Available Frequency Range-List>=

 = ;      <Available Central Frequencies><= /o:p>

 = ;      <Available Slot Widths>

 

<A= vailable Central Frequencies> ::=3D the subset of supported n values (wh= ere n is defined as in G.694.1)

=  

<A= vailable Slot Widths> ::=3D the subset of supported m values (where m is= defined as in G.694.1)

=  

If you want to go one step further and limit how to represent the= se subsets by introducing granularities (and possibly offsets but that is maybe unnecessarily complex) you could have:=

 

<A= vailable Central Frequencies> ::=3D

 = ;       <Available Central Frequency Granu= larity>

 = ;       <Offset>

=  

One possible representation would be to say that available center= frequencies are the subset of supported n values given by p x n + q where p (granularity) is a positive integer and q (offset) b= elongs to 0,..,q-1.

=  

<A= vailable Slot Widths> ::=3D

 = ;       <Available Slot Width Granularity&= gt;

 = ;       <Min Slot Width>

 = ;       <Max Slot Width>

 

/Jonas<= /p>

 <= /p>

From: Ramon Casellas [mailto:ramon.casellas@cttc.es]
Sent: den 20 maj 2015 12:27
To: Jonas M=E5rtensson; ccamp@ietf.org
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk= -03 and call for sheperd

 



i.e. “n” a= nd “m” were changed to “2^n” and “2^m” = but it still said that “n” and “m” were positive in= tegers which is wrong. The new formulas (even if n,m =3D 0 is included) als= o change the available granularities but I assume this was intended (I was not involved).

Jonas, all

Let's try to re-visit this again and come up with some definitive text. I a= lso wonder about:

* the need to introduce formulas or similar o just provide a list of accept= able values.
* whether a single value captures the intended model attribute (e.g. granul= arity is X) or multiple values are acceptable.

IMHO: we should ideally list the acceptable values and capture common deplo= yments, rather than exotic configurations such as "this node only supp= orts ncf of 6.25 if between this frequency and that frequency and 25 otherw= ise, or it can support width granulaties of x,y,z depending on ...)

ITU rec is not extremely helpful, and only provides main guidelines: ITU-T = Rec G.694.1 ( http://www.itu= .int/rec/T-REC-G.694.1-201202-I/en ) states Appendix I: "The flexible DWDM grid defined in clause 7 has a nominal central f= requency granularity of 6.25 GHz and a slot width granularity of 12.5 GHz. = However, devices or applications that make use of the flexible grid may not= have to be capable of supporting every possible slot width or position. In other words, applications may be defin= ed where only a subset of the possible slot widths and positions are requir= ed to be supported. For example, an application could be defined where the = nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and that only re= quires slot widths as a multiple of 25 GHz (by only requiring values of m t= hat are even)."



For nominal central frequency granularity
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
we had:

A) <Available Central Frequency Granularity> ::=3D p x 6.25GHz
B) <Available Central Frequency Granularity> ::=3D (2^p) x 6.25GHz for p>=3D0

Typically, values used for this (in fixed grid)  "The frequenc= y grid defined by this Recommendation supports a variety of fixed channel s= pacings ranging from 12.5 GHz to 100 GHz and wider (integer multiples of 10= 0 GHz) as well as a flexible grid. Uneven channel spacings using the fixed grids are also allowed." Note th= at in section 6, values with n=3D0 are used as reference for all the grids.= IOW, we are implying that the granularity is given wrt n=3D0.

A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are = not necessarily common or deployed.
B) yields 6.25, 12.5, 50.0, 100, 200, 400... it fails to capture the "= integer multiples of 100",

Questions:
Q1: should we cover values above 100/200 ? if yes, B) fails.
Q2: do we need to explictly mention that granularity itself is not enough w= ithout mentioning a "reference/anchor" NCF that is not n=3D0? do = we assume that n=3D0 is always available and the granularity is always wrt = to it -- relying on the " <Available Frequency Range-List> " to complete this information?"


For nominal central frequency granularity
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
we had :
C) <Available Slot Width Granularity> ::=3D q x 12.5GHz
D) <Available Slot Width Granularity> ::=3D (2^q) x 12.5G= Hz q>=3D 0

C) yields 12.5, 25, 37.5, 50, 62.5, 75
D) yields  12.5, 25, 50, 100, 200, 400,

D) is excluding restrictions such as "frequency slots with m=3D3 (37.5= GHz)" so I am not sure it is ok if we want to cover those. It seems s= afer to stick to C) imho

For available frequency range
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
In -03, -04


   <Available Frequenc=
y Range> ::=3D
     ( <Star=
t Spectrum Position> <End Spectrum Position> ) |
     <Sets o=
f contiguous slices>


I don't like neither the use of "position" nor the use of the und= efined term "slice"

Proposed text
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


<Available Central Frequency Gra=
nularity> ::=3D 
    A value fro=
m within the list 6.25GHz, 12.5GHz, 25GHz, 50GHz, 100GHz, 200GHz, 300GHz, 4=
00GHz... 
    -- Note tha=
t the granularity is defined with respect to anchor frequency given by n=3D=
0
 
<Available Slot Width Granularit=
y> ::=3D
    A value from wit=
hin the list defined by q x 12.5GHz where q is a positive integer (q>0)<=
o:p>
    -- It is the min=
imum slot width that can be defined
 
<Available Frequency Range> :=
:=3D
     ( <Star=
t Nominal Central Frequency> <End Nominal Central Frequency> ) |
      =
; <A frequency slot defined by its n and m contaning a set of contiguous=
 nominal central frequencies>
 


Any comments? Yes/no? suggested alternatives?  much appreciated :)

Thanks

Ramon



--_000_7ECED07E132D4B4F89DCC0FDA683C6C290CC98ACREOEXC02adacreo_-- From nobody Wed May 20 06:38:18 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE29F1A1B4C for ; Wed, 20 May 2015 06:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9opp8gd7qjy for ; Wed, 20 May 2015 06:38:14 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCA11A1B46 for ; Wed, 20 May 2015 06:38:13 -0700 (PDT) Received: from [2001:40b0:7c22:6020:25a5:9baa:f8b1:eb83] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yv4CC-0000On-RZ; Wed, 20 May 2015 15:38:06 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 0BE8B1FD05; Wed, 20 May 2015 15:38:01 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <555C8E31.5030801@cttc.es> Date: Wed, 20 May 2015 15:37:53 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Jonas_M=E5rtensson?= , "ccamp@ietf.org" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C76A@ACREOEXC02.ad.acreo.se> <555C3FC6.80106@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C959@ACREOEXC02.ad.acreo.se> <555C6167.4070101@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290CC98@ACREOEXC02.ad.acreo.se> In-Reply-To: <7ECED07E132D4B4F89DCC0FDA683C6C290CC98@ACREOEXC02.ad.acreo.se> Content-Type: multipart/alternative; boundary="------------050605060706010509030902" X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -0.2 (/) X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4470] Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 13:38:17 -0000 This is a multi-part message in MIME format. --------------050605060706010509030902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Jonas, all Thanks for your careful review of the IM. Please see inline El 20/05/2015 a las 14:51, Jonas Mårtensson escribió: > > A) ::= p x 6.25GHz > > ”A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values > that are not necessarily common or deployed.” > > Still… I don’t really see a good reason why you would exclude those > values (which are compliant with G.694.1) at this point… More > generally, I think an information model should describe the needed > information, not necessarily limit values representing the information > (that could be done in a future encoding draft). > Ramon> good point. I guess we do not need to necessarily list the actual values themselves, and exclude compliant ones. > Anyway, and sorry if I confuse things even more, it seems to me that > what you actually want to capture with the information model is > available center frequencies and slot widths, not the granularities > per se. Granularities are one way to represent available values but > how to represent those could be left for a future encoding draft. So a > more general information model could be: > > ::= > > > > > > > > > ::= the subset of supported n values > (where n is defined as in G.694.1) > Ramon> It is true that I have been thinking whether the information on NCF granularity could be implied by its (dynamic) availability, and whether we were adding redundancy (e.g. those NCFs that are not supported by reasons of granularity would never appear as available e.g. in ). On a second thought, this seems to not be always the case (only when the choice of formats is chosen to be so). It seems perfectly valid to list both the available ranges e.g. by means of start/end and then which NCFs are possible/available, so +1 to your suggestion. See below once integrated > ::= the subset of supported m values (where m > is defined as in G.694.1) > > If you want to go one step further and limit how to represent these > subsets by introducing granularities (and possibly offsets but that is > maybe unnecessarily complex) you could have: > > ::= > > > > > > One possible representation would be to say that available center > frequencies are the subset of supported n values given by p x n + q > where p (granularity) is a positive integer and q (offset) belongs to > 0,..,q-1. > Ramon> I understand q (offset) belongs to 0,.., p-1, right? but ok. Ramon> In order to try to complete it, Would the following be ok ? OLD ::= ::= [] ::= ( ) | ::= (2^n) x 6.25GHz where n is a non negative integer, giving rise to granularities such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz ::= (2^m) x 12.5GHz where m is positive integer ::= j x 12.5GHz, j is a positive integer ::= k x 12.5GHz, k is a positive integer (k >= j) NEW NCF: Nominal Central Frequency ::= where ::= [] ::= ( ) | and ::= [] -- Subset of supported n values given by p x n + q where p is a positive integer and q (offset) belongs to 0,..,p-1. and ::= -- value given by j x 12.5GHz, with j a positive integer -- value given by k x 12.5, with k a positive integer (k >= j) --------------050605060706010509030902 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Jonas, all

Thanks for your careful review of the IM. Please see inline

El 20/05/2015 a las 14:51, Jonas Mårtensson escribió:

A)  <Available Central Frequency Granularity> ::= p x 6.25GHz

 

”A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are not necessarily common or deployed.”

 

Still… I don’t really see a good reason why you would exclude those values (which are compliant with G.694.1) at this point… More generally, I think an information model should describe the needed information, not necessarily limit values representing the information (that could be done in a future encoding draft).


Ramon> good point. I guess we do not need to necessarily list the actual values themselves, and exclude compliant ones.

 

Anyway, and sorry if I confuse things even more, it seems to me that what you actually want to capture with the information model is available center frequencies and slot widths, not the granularities per se. Granularities are one way to represent available values but how to represent those could be left for a future encoding draft. So a more general information model could be:

 

<Available Spectrum> ::=

       <Available Frequency Range-List>

       <Available Central Frequencies>

       <Available Slot Widths>


<Available Central Frequencies> ::= the subset of supported n values (where n is defined as in G.694.1)

Ramon> It is true that I have been thinking whether the information on NCF granularity could be implied by its (dynamic) availability, and whether we were adding redundancy (e.g. those NCFs that are not supported by reasons of granularity would never appear as available e.g. in  <Available Frequency Range-List>). On a second thought, this seems to not be always the case (only when the choice of formats is chosen to be so). It seems perfectly valid to list both the available ranges e.g. by means of start/end and then which NCFs are possible/available, so +1 to your suggestion. See below once integrated

 

<Available Slot Widths> ::= the subset of supported m values (where m is defined as in G.694.1)

 

If you want to go one step further and limit how to represent these subsets by introducing granularities (and possibly offsets but that is maybe unnecessarily complex) you could have:

 

<Available Central Frequencies> ::=

        <Available Central Frequency Granularity>

        <Offset>

 

One possible representation would be to say that available center frequencies are the subset of supported n values given by p x n + q where p (granularity) is a positive integer and q (offset) belongs to 0,..,q-1.

Ramon> I understand q (offset) belongs to 0,.., p-1, right? but ok.

Ramon> In order to try to complete it, Would the following be ok ?

OLD

   <Available Spectrum> ::=
       <Available Frequency Range-List>
       <Available Central Frequency Granularity >
       <Available Slot Width Granularity>
       <Minimal Slot Width>
       <Maximal Slot Width>

   <Available Frequency Range-List> ::=
       <Available Frequency Range> [<Available Frequency Range-List>]

   <Available Frequency Range> ::=
     ( <Start Spectrum Position> <End Spectrum Position> ) |
     <Sets of contiguous slices>

   <Available Central Frequency Granularity> ::= (2^n) x 6.25GHz
     where n is a non negative integer, giving rise to granularities
     such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz

   <Available Slot Width Granularity> ::= (2^m) x 12.5GHz
     where m is positive integer

   <Minimal Slot Width> ::= j x 12.5GHz,
     j is a positive integer

   <Maximal Slot Width> ::= k x 12.5GHz,
       k is a positive integer (k >= j)
NEW

      NCF: Nominal Central Frequency

   <Available Spectrum> ::=

       <Available Frequency Range-List>

       <Available NCFs>

       <Available Slot Widths> 
where 

   <Available Frequency Range-List> ::=
       <Available Frequency Range> [<Available Frequency Range-List>]

   <Available Frequency Range> ::=
     ( <Start NCF> <End NCF> ) |
       <FS defined by its (n, m) and containing a set of contiguous available NCFs>

and 

   <Available NCFs> ::= 
        <Available NCF Granularity> [<Offset>]
   -- Subset of supported n values given by p x n + q where p is a positive integer and q (offset) belongs to 0,..,p-1.

and 
   <Available Slot Widths> ::=
        <Available Slot Width Granularity>
        <Min Slot Width>
         -- value given by j x 12.5GHz, with j a positive integer
        <Max Slot Width>
         -- value given by k x 12.5, with k a positive integer (k >= j)


--------------050605060706010509030902-- From nobody Wed May 20 08:07:25 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7521A1B7D for ; Wed, 20 May 2015 08:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUDQAoe09gZ3 for ; Wed, 20 May 2015 08:07:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0601A1B29 for ; Wed, 20 May 2015 08:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8988; q=dns/txt; s=iport; t=1432134436; x=1433344036; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mLnxX0hxs77JvE1rizCkuzoCEba5Xx/PDAN9q+0Yr0A=; b=jX5v2zof+ALi4oSu8uvS3eeJ/1xEO1NJU+fuVXQFm4yzsj5fKRknsfKG wdh3iR/XyE9Nq3OsJGEXNjqeq4YWNezxReoovRBb0sQn/fzrz/+pntUQm IA5Ksqj9130tuH9vnL1rSLteLzOn04/JWtSeGX+RNXVVf2Xu8kGFbmr1u g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AZBQDcoVxV/4sNJK1cgkVLVGTMUQKBOUwBAQEBAQGBC4QjAQEEHRBMEAIBCCIkMiUCBAENDYgkzU0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqEVDEHgxeBFgWLeYQ7gjyiFCNhgSkcFYE9gjWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,464,1427760000"; d="scan'208,217";a="421257000" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP; 20 May 2015 15:07:15 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t4KF7EfR018059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 15:07:14 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 20 May 2015 10:07:14 -0500 From: "Matt Hartley (mhartley)" To: Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AQHQj0kbRbr+LifYa0qF5OmSNlKil52BvRQAgANAKmA= Date: Wed, 20 May 2015 15:07:13 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> In-Reply-To: <5559A180.8090504@cttc.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.59] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0xmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:07:23 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0xmbrcdx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ramon, A couple more things. Is this doc informational or standards-track? It claims to be informational= , but it has RFC 2119 language in it. Also, it's missing the standard boilerplate for this stuff: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Should that be added? Also: you currently have six main authors, and my understanding is that the= RFC Editor's guidelines are that there should be no more than five.... Cheers Matt El 15/05/2015 a las 21:55, Lou Berger escribi=F3: All, I believe there has been sufficient time and support to indicate that t= his document is ready to move forward, i.e., as "consensus caller" I believ= e there is WG consensus behind publishing the document. That said, there w= ere a few comments that were received during and (per Ramon) after Monday. = I'd expect the authors to work with those making the comments, the WG, and= the document Shepherd (who, per normal process, does the actual publicatio= n request) to ensure that the comments are addressed. Dear Lou, all Version -04 has been uploaded with all comments received so far. Thanks Ramon --_000_9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0xmbrcdx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ramon,

 

A couple more things= .

 

Is this doc informat= ional or standards-track? It claims to be informational, but it has RFC 211= 9 language in it.

 

Also, it’s mis= sing the standard boilerplate for this stuff:

 

      The key wo= rds "MUST", "MUST NOT", "REQUIRED", "SHA= LL", "SHALL

      NOT",= "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and

      "OPTI= ONAL" in this document are to be interpreted as described in

      RFC 2119.<= o:p>

 

Should that be added= ?

 

Also: you currently = have six main authors, and my understanding is that the RFC Editor’s = guidelines are that there should be no more than five….

 

Cheers

 

Matt

 

El 15/05/2015 a las 21:55, Lou Berger escribi=F3:

All,
    I believe there has been sufficient time and support to = indicate that this document is ready to move forward, i.e., as "consen= sus caller" I believe there is WG consensus behind publishing the docu= ment.  That said, there were a few comments that were received during and (per Ramon) after Monday.  I'd expect the authors to work = with those making the comments, the WG, and the document Shepherd (who, per= normal process, does the actual publication request) to ensure that the co= mments are addressed.

Dear Lou, all

Version -04 has been uploaded with all comments received so far.

Thanks
Ramon

--_000_9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0xmbrcdx03ciscoc_-- From nobody Wed May 20 10:07:01 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A488E1A88C2 for ; Wed, 20 May 2015 10:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaY2V6pfvXBn for ; Wed, 20 May 2015 10:06:57 -0700 (PDT) Received: from villa.puc.rediris.es (villa.puc.rediris.es [IPv6:2001:720:418:ca00::7]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED721A890B for ; Wed, 20 May 2015 10:06:57 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yv7SF-00056J-NE; Wed, 20 May 2015 19:06:53 +0200 Received: from [192.168.1.200] (81.61.180.55.dyn.user.ono.com [81.61.180.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 5753E1FEA7; Wed, 20 May 2015 19:06:47 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <555CBF29.3070305@cttc.es> Date: Wed, 20 May 2015 19:06:49 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Matt Hartley (mhartley)" , "ccamp@ietf.org" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> Content-Type: multipart/alternative; boundary="------------080100010700040301060804" X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -2.9 (--) X-Spamina-Spam-Report: Content analysis details: (-2.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0090] 0.0 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:06:59 -0000 This is a multi-part message in MIME format. --------------080100010700040301060804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear Matt, Please see inline El 20/05/2015 a las 17:07, Matt Hartley (mhartley) escribió: > > Ramon, > > Is this doc informational or standards-track? It claims to be > informational, but it has RFC 2119 language in it. It is a good question, which has been popping frequently during the lifetime of the draft. The last indication I received (internally) was that it should be informational, and I changed it. I guess the problem is that as a fwk document is mainly informational, but at some point in the distant past, it was decided to include also control plane requirements (I guess those are the sections that use RFC 2119 language). Maybe wiser people can comment on this, but it was my (admittedly limited) understanding that those are non-exclusive (i.e., RFCs may be informational but yet define requirements and use RFC2119 language to indicate requirement levels, adding the appropriate boilerplate). Also, it’s missing the standard boilerplate for this stuff: Uhm, afaik, it is not (I just checked both in -03 and -04 and the boilerplate is there $2.1). The change standards track -> informational happened in -04. In any case, no objection either way. I will proceed with whatever option is more appropriate > Also: you currently have six main authors, and my understanding is > that the RFC Editor’s guidelines are that there should be no more than > five…. > Thanks for pointing this out, we were told of this not so long ago,... I would like to ask whether five is a rigid limit and whether exceptions may be granted (consider this a not-so-subtle request for exception...), given that this draft was the result of merging several drafts -- which explains the amazingly long list of contributors -- and authorship was a quite hard thing to agree on. OTOH I guess that if this policy really needs to be enforced, we will have to find a way (hopefully not involving dice) Thanks for your feedback Ramon --------------080100010700040301060804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear Matt,

Please see inline

El 20/05/2015 a las 17:07, Matt Hartley (mhartley) escribió:

Ramon,

 

Is this doc informational or standards-track? It claims to be informational, but it has RFC 2119 language in it.
It is a good question, which has been popping frequently during the lifetime of the draft. The last indication I received (internally) was that it should be informational, and I changed it. I guess the problem is that as a fwk document is mainly informational, but at some point in the distant past, it was decided to include also control plane requirements (I guess those are the sections that use RFC 2119 language). Maybe wiser people can comment on this, but it was my (admittedly limited) understanding that those are non-exclusive (i.e., RFCs may be informational but yet define requirements and use RFC2119 language to indicate requirement levels, adding the appropriate boilerplate).


Also, it’s missing the standard boilerplate for this stuff:

Uhm, afaik, it is not (I just checked both in -03 and -04 and the boilerplate is there $2.1). The change standards track -> informational happened in -04.

In any case, no objection either way. I will proceed with whatever option is more appropriate


 

Also: you currently have six main authors, and my understanding is that the RFC Editor’s guidelines are that there should be no more than five….

Thanks for pointing this out, we were told of this not so long ago,...
I would like to ask whether five is a rigid limit and whether exceptions may be granted (consider this a not-so-subtle request for exception...), given that this draft was the result of merging several drafts -- which explains the amazingly long list of contributors -- and authorship was a quite hard thing to agree on. OTOH I guess that if this policy really needs to be enforced, we will have to find a way (hopefully not involving dice)

Thanks for your feedback
Ramon


--------------080100010700040301060804-- From nobody Wed May 20 10:12:01 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FFA1A8972 for ; Wed, 20 May 2015 10:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl0MPTV2koY8 for ; Wed, 20 May 2015 10:11:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EF41A890E for ; Wed, 20 May 2015 10:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12402; q=dns/txt; s=iport; t=1432141919; x=1433351519; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9DBIFY6zm+E/aCbLb0LLOUTynXJJSzg9oY9eakpq1C0=; b=RXyX1YUwUIq8o5JMpoLR2NciMY8yKyIDu4ay2ABlMSzOuo1oSVYheSGB HPLyEWsEoHLS3y5+SWM9j4MyC/aT7HiO9t3aifWuLcVuXs0tX42GMUp/o KehP6/njKwL0mZPC2v0Zd9jcf1Xp7O3YOnh564q+zISHQpPWU6ACzDOYm 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcBQCWv1xV/4QNJK1cgkVLVGSDGMk6AhyBH0wBAQEBAQGBC4QjAQEEHQYEBkwQAgEIIiACAgIwJQIEAQ0NiCSqOaQXAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s6hCwBJzEHgmgvgRYFknCMJ4NrjimDWSNhgQUkHBWBPYFyAR8jgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427760000"; d="scan'208,217";a="421265116" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 20 May 2015 17:11:58 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4KHBvT6018637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 17:11:57 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Wed, 20 May 2015 12:11:56 -0500 From: "Matt Hartley (mhartley)" To: Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AQHQj0kbRbr+LifYa0qF5OmSNlKil52BvRQAgANAKmCAAHa5gP//rT1A Date: Wed, 20 May 2015 17:11:55 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> In-Reply-To: <555CBF29.3070305@cttc.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.59] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBExmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:12:00 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBExmbrcdx03ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBSYW1vbi4NCg0KSG9wZWZ1bGx5IHRoZSBjaGFpcnMgYW5kIG90aGVyIGtub3dsZWRn ZWFibGUgZm9sa3MgY2FuIGNoaW1lIGluIG9uIHRoZSAyMTE5IGxhbmd1YWdlIHZzIGluZm9ybWF0 aW9uYWwgc3R1ZmYuDQoNCkFwb2xvZ2llcyBvbiB0aGUgcmVxdWlyZW1lbnRzIGJvaWxlcnBsYXRl IOKAkyBJIGp1c3QgZGlkbuKAmXQgc2Nyb2xsIGRvd24gZmFyIGVub3VnaCA6KQ0KDQpDaGVlcnMN Cg0KTWF0dA0KDQpEZWFyIE1hdHQsDQoNClBsZWFzZSBzZWUgaW5saW5lDQoNCkVsIDIwLzA1LzIw MTUgYSBsYXMgMTc6MDcsIE1hdHQgSGFydGxleSAobWhhcnRsZXkpIGVzY3JpYmnDszoNClJhbW9u LA0KDQpJcyB0aGlzIGRvYyBpbmZvcm1hdGlvbmFsIG9yIHN0YW5kYXJkcy10cmFjaz8gSXQgY2xh aW1zIHRvIGJlIGluZm9ybWF0aW9uYWwsIGJ1dCBpdCBoYXMgUkZDIDIxMTkgbGFuZ3VhZ2UgaW4g aXQuDQpJdCBpcyBhIGdvb2QgcXVlc3Rpb24sIHdoaWNoIGhhcyBiZWVuIHBvcHBpbmcgZnJlcXVl bnRseSBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIHRoZSBkcmFmdC4gVGhlIGxhc3QgaW5kaWNhdGlv biBJIHJlY2VpdmVkIChpbnRlcm5hbGx5KSB3YXMgdGhhdCBpdCBzaG91bGQgYmUgaW5mb3JtYXRp b25hbCwgYW5kIEkgY2hhbmdlZCBpdC4gSSBndWVzcyB0aGUgcHJvYmxlbSBpcyB0aGF0IGFzIGEg ZndrIGRvY3VtZW50IGlzIG1haW5seSBpbmZvcm1hdGlvbmFsLCBidXQgYXQgc29tZSBwb2ludCBp biB0aGUgZGlzdGFudCBwYXN0LCBpdCB3YXMgZGVjaWRlZCB0byBpbmNsdWRlIGFsc28gY29udHJv bCBwbGFuZSByZXF1aXJlbWVudHMgKEkgZ3Vlc3MgdGhvc2UgYXJlIHRoZSBzZWN0aW9ucyB0aGF0 IHVzZSBSRkMgMjExOSBsYW5ndWFnZSkuIE1heWJlIHdpc2VyIHBlb3BsZSBjYW4gY29tbWVudCBv biB0aGlzLCBidXQgaXQgd2FzIG15IChhZG1pdHRlZGx5IGxpbWl0ZWQpIHVuZGVyc3RhbmRpbmcg dGhhdCB0aG9zZSBhcmUgbm9uLWV4Y2x1c2l2ZSAoaS5lLiwgUkZDcyBtYXkgYmUgaW5mb3JtYXRp b25hbCBidXQgeWV0IGRlZmluZSByZXF1aXJlbWVudHMgYW5kIHVzZSBSRkMyMTE5IGxhbmd1YWdl IHRvIGluZGljYXRlIHJlcXVpcmVtZW50IGxldmVscywgYWRkaW5nIHRoZSBhcHByb3ByaWF0ZSBi b2lsZXJwbGF0ZSkuDQoNCg0KQWxzbywgaXTigJlzIG1pc3NpbmcgdGhlIHN0YW5kYXJkIGJvaWxl cnBsYXRlIGZvciB0aGlzIHN0dWZmOg0KDQpVaG0sIGFmYWlrLCBpdCBpcyBub3QgKEkganVzdCBj aGVja2VkIGJvdGggaW4gLTAzIGFuZCAtMDQgYW5kIHRoZSBib2lsZXJwbGF0ZSBpcyB0aGVyZSAk Mi4xKS4gVGhlIGNoYW5nZSBzdGFuZGFyZHMgdHJhY2sgLT4gaW5mb3JtYXRpb25hbCBoYXBwZW5l ZCBpbiAtMDQuDQoNCkluIGFueSBjYXNlLCBubyBvYmplY3Rpb24gZWl0aGVyIHdheS4gSSB3aWxs IHByb2NlZWQgd2l0aCB3aGF0ZXZlciBvcHRpb24gaXMgbW9yZSBhcHByb3ByaWF0ZQ0KDQoNCg0K DQpBbHNvOiB5b3UgY3VycmVudGx5IGhhdmUgc2l4IG1haW4gYXV0aG9ycywgYW5kIG15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCB0aGUgUkZDIEVkaXRvcuKAmXMgZ3VpZGVsaW5lcyBhcmUgdGhhdCB0 aGVyZSBzaG91bGQgYmUgbm8gbW9yZSB0aGFuIGZpdmXigKYuDQpUaGFua3MgZm9yIHBvaW50aW5n IHRoaXMgb3V0LCB3ZSB3ZXJlIHRvbGQgb2YgdGhpcyBub3Qgc28gbG9uZyBhZ28sLi4uDQpJIHdv dWxkIGxpa2UgdG8gYXNrIHdoZXRoZXIgZml2ZSBpcyBhIHJpZ2lkIGxpbWl0IGFuZCB3aGV0aGVy IGV4Y2VwdGlvbnMgbWF5IGJlIGdyYW50ZWQgKGNvbnNpZGVyIHRoaXMgYSBub3Qtc28tc3VidGxl IHJlcXVlc3QgZm9yIGV4Y2VwdGlvbi4uLiksIGdpdmVuIHRoYXQgdGhpcyBkcmFmdCB3YXMgdGhl IHJlc3VsdCBvZiBtZXJnaW5nIHNldmVyYWwgZHJhZnRzIC0tIHdoaWNoIGV4cGxhaW5zIHRoZSBh bWF6aW5nbHkgbG9uZyBsaXN0IG9mIGNvbnRyaWJ1dG9ycyAtLSBhbmQgYXV0aG9yc2hpcCB3YXMg YSBxdWl0ZSBoYXJkIHRoaW5nIHRvIGFncmVlIG9uLiBPVE9IIEkgZ3Vlc3MgdGhhdCBpZiB0aGlz IHBvbGljeSByZWFsbHkgbmVlZHMgdG8gYmUgZW5mb3JjZWQsIHdlIHdpbGwgaGF2ZSB0byBmaW5k IGEgd2F5IChob3BlZnVsbHkgbm90IGludm9sdmluZyBkaWNlKQ0KDQpUaGFua3MgZm9yIHlvdXIg ZmVlZGJhY2sNClJhbW9uDQoNCg== --_000_9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBExmbrcdx03ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBTdHlsZSI7DQoJcGFub3NlLTE6MiA1IDYgNCA1IDUg NSAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwic2VyaWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwic2VyaWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojNjMyNDIzIj5UaGFua3MsIFJhbW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2 MzI0MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4g T2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPkhvcGVmdWxs eSB0aGUgY2hhaXJzIGFuZCBvdGhlciBrbm93bGVkZ2VhYmxlIGZvbGtzIGNhbiBjaGltZSBpbiBv biB0aGUgMjExOSBsYW5ndWFnZSB2cyBpbmZvcm1hdGlvbmFsIHN0dWZmLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiM2MzI0MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2 MzI0MjMiPkFwb2xvZ2llcyBvbiB0aGUgcmVxdWlyZW1lbnRzIGJvaWxlcnBsYXRlIOKAkyBJIGp1 c3QgZGlkbuKAmXQgc2Nyb2xsIGRvd24gZmFyIGVub3VnaCA6KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O2NvbG9yOiM2MzI0MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMi PkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0 eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPk1hdHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjojNjMyNDIzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgTWF0dCwgPGJyPg0KPGJy Pg0KUGxlYXNlIHNlZSBpbmxpbmU8YnI+DQo8YnI+DQpFbCAyMC8wNS8yMDE1IGEgbGFzIDE3OjA3 LCBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KSBlc2NyaWJpw7M6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PlJhbW9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SXMgdGhp cyBkb2MgaW5mb3JtYXRpb25hbCBvciBzdGFuZGFyZHMtdHJhY2s/IEl0IGNsYWltcyB0byBiZSBp bmZvcm1hdGlvbmFsLCBidXQgaXQgaGFzIFJGQyAyMTE5IGxhbmd1YWdlIGluIGl0Ljwvc3Bhbj4N CjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQg aXMgYSBnb29kIHF1ZXN0aW9uLCB3aGljaCBoYXMgYmVlbiBwb3BwaW5nIGZyZXF1ZW50bHkgZHVy aW5nIHRoZSBsaWZldGltZSBvZiB0aGUgZHJhZnQuIFRoZSBsYXN0IGluZGljYXRpb24gSSByZWNl aXZlZCAoaW50ZXJuYWxseSkgd2FzIHRoYXQgaXQgc2hvdWxkIGJlIGluZm9ybWF0aW9uYWwsIGFu ZCBJIGNoYW5nZWQgaXQuIEkgZ3Vlc3MgdGhlIHByb2JsZW0gaXMgdGhhdCBhcyBhIGZ3ayBkb2N1 bWVudA0KIGlzIG1haW5seSBpbmZvcm1hdGlvbmFsLCBidXQgYXQgc29tZSBwb2ludCBpbiB0aGUg ZGlzdGFudCBwYXN0LCBpdCB3YXMgZGVjaWRlZCB0byBpbmNsdWRlIGFsc28gY29udHJvbCBwbGFu ZSByZXF1aXJlbWVudHMgKEkgZ3Vlc3MgdGhvc2UgYXJlIHRoZSBzZWN0aW9ucyB0aGF0IHVzZSBS RkMgMjExOSBsYW5ndWFnZSkuIE1heWJlIHdpc2VyIHBlb3BsZSBjYW4gY29tbWVudCBvbiB0aGlz LCBidXQgaXQgd2FzIG15IChhZG1pdHRlZGx5IGxpbWl0ZWQpDQogdW5kZXJzdGFuZGluZyB0aGF0 IHRob3NlIGFyZSBub24tZXhjbHVzaXZlIChpLmUuLCBSRkNzIG1heSBiZSBpbmZvcm1hdGlvbmFs IGJ1dCB5ZXQgZGVmaW5lIHJlcXVpcmVtZW50cyBhbmQgdXNlIFJGQzIxMTkgbGFuZ3VhZ2UgdG8g aW5kaWNhdGUgcmVxdWlyZW1lbnQgbGV2ZWxzLCBhZGRpbmcgdGhlIGFwcHJvcHJpYXRlIGJvaWxl cnBsYXRlKS48YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ QWxzbywgaXTigJlzIG1pc3NpbmcgdGhlIHN0YW5kYXJkIGJvaWxlcnBsYXRlIGZvciB0aGlzIHN0 dWZmOjxicj4NCjxicj4NCjwvc3Bhbj5VaG0sIGFmYWlrLCBpdCBpcyBub3QgKEkganVzdCBjaGVj a2VkIGJvdGggaW4gLTAzIGFuZCAtMDQgYW5kIHRoZSBib2lsZXJwbGF0ZSBpcyB0aGVyZSAkMi4x KS4gVGhlIGNoYW5nZSBzdGFuZGFyZHMgdHJhY2sgLSZndDsgaW5mb3JtYXRpb25hbCBoYXBwZW5l ZCBpbiAtMDQuPGJyPg0KPGJyPg0KSW4gYW55IGNhc2UsIG5vIG9iamVjdGlvbiBlaXRoZXIgd2F5 LiBJIHdpbGwgcHJvY2VlZCB3aXRoIHdoYXRldmVyIG9wdGlvbiBpcyBtb3JlIGFwcHJvcHJpYXRl PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPkFsc286IHlvdSBjdXJyZW50bHkgaGF2ZSBzaXggbWFpbiBhdXRob3JzLCBhbmQgbXkgdW5k ZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBSRkMgRWRpdG9y4oCZcyBndWlkZWxpbmVzIGFyZSB0aGF0 IHRoZXJlIHNob3VsZCBiZSBubyBtb3JlIHRoYW4gZml2ZeKApi48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRo YW5rcyBmb3IgcG9pbnRpbmcgdGhpcyBvdXQsIHdlIHdlcmUgdG9sZCBvZiB0aGlzIG5vdCBzbyBs b25nIGFnbywuLi48YnI+DQpJIHdvdWxkIGxpa2UgdG8gYXNrIHdoZXRoZXIgZml2ZSBpcyBhIHJp Z2lkIGxpbWl0IGFuZCB3aGV0aGVyIGV4Y2VwdGlvbnMgbWF5IGJlIGdyYW50ZWQgKGNvbnNpZGVy IHRoaXMgYSBub3Qtc28tc3VidGxlIHJlcXVlc3QgZm9yIGV4Y2VwdGlvbi4uLiksIGdpdmVuIHRo YXQgdGhpcyBkcmFmdCB3YXMgdGhlIHJlc3VsdCBvZiBtZXJnaW5nIHNldmVyYWwgZHJhZnRzIC0t IHdoaWNoIGV4cGxhaW5zIHRoZSBhbWF6aW5nbHkgbG9uZyBsaXN0IG9mIGNvbnRyaWJ1dG9ycw0K IC0tIGFuZCBhdXRob3JzaGlwIHdhcyBhIHF1aXRlIGhhcmQgdGhpbmcgdG8gYWdyZWUgb24uIE9U T0ggSSBndWVzcyB0aGF0IGlmIHRoaXMgcG9saWN5IHJlYWxseSBuZWVkcyB0byBiZSBlbmZvcmNl ZCwgd2Ugd2lsbCBoYXZlIHRvIGZpbmQgYSB3YXkgKGhvcGVmdWxseSBub3QgaW52b2x2aW5nIGRp Y2UpPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrPGJyPg0KUmFtb248YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBExmbrcdx03ciscoc_-- From nobody Thu May 21 00:58:04 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC291A6EE9 for ; Thu, 21 May 2015 00:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3sXIlksnQ9d for ; Thu, 21 May 2015 00:58:01 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8481A7D85 for ; Thu, 21 May 2015 00:57:59 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-92-555d90057f45 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D3.E3.04401.5009D555; Thu, 21 May 2015 09:57:58 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.137]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Thu, 21 May 2015 09:57:57 +0200 From: Daniele Ceccarelli To: "Matt Hartley (mhartley)" , Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgOcXiaAAH6zzgAAcq8DgAAELU+AAAAtmYAAIsVEwA== Date: Thu, 21 May 2015 07:57:57 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE481291DBE5ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3VpdtQmyoQV8Xp8WTOTdYLOa8ZLbY PfcbuwOzx5TfG1k9Wo+2s3gsWfKTKYA5issmJTUnsyy1SN8ugSuj41s3U8GrnYwVz5c1Mjcw ftnC2MXIySEhYCLR3jmVHcIWk7hwbz0biC0kcJRR4tEm7y5GLiB7CaPEuXuvWLoYOTjYBKwk nhzyAYmLCDQwSkzad4oZpEFYIE7ix+PtrCC2iEC8xOyGTUwg9SICYRLP73qBhFkEVCWmnzwL Vs4r4Cux+tReFoj5K5kkVnyczgZSzwmU2P3RDKSGUUBWYsLuRWB3MguIS9x6Mp8J4k4BiSV7 zjND2KISLx//YwVplRBQkpi2NQ2iPF9i7pw1rBCrBCVOznzCMoFRZBaSSbOQlM1CUjYLaBKz gKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokR GGcHt/xW3cF4+Y3jIUYBDkYlHl4Fm9hQIdbEsuLK3EOM0hwsSuK8nl0hoUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYC6xsCubovLCRYdUTYbrlm/WjcOW9kAk3dm8//4DTJHaPNJd07pzO RKYS5+xwxTDbJ2tPzX8tqCAkt9TWIPPBKv9I1zx+pmuNt8s+dfxQOc0v2fTrY0cnk7BluvIJ XY45rj9c1da7t366sPD9rd2rr0+7zGRRW7hd5Z3PjocL+48f/n7w2olQJZbijERDLeai4kQA DgOlFJQCAAA= Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:58:04 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE481291DBE5ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWF0dCwgUmFtb24sDQoNClNpbmNlIEkgZm91bmQgbm8gY2xlYXIgc3RhdGVtZW50cyBvbiB0 aGUgdXNhZ2Ugb2YgUkZDMjExOSBsYW5ndWFnZSB3aXRoIHJlc3BlY3QgdG8gdGhpcyBzaXR1YXRp b25zLCBJIGhhZCBhIGxvb2sgYXQgZXhpc3RpbmcgZnJhbWV3b3JrIGFuZCByZXF1aXJlbWVudCBS RkNzIHRyeWluZyB0byBmaW5kIGEgY29tbW9uIFdvVy4gTXkgdGFrZSBpczoNCg0KDQoNCi0gICAg ICAgICAgRnJhbWV3b3JrIGlzIGFsd2F5cyBpbmZvcm1hdGlvbmFsDQoNCi0gICAgICAgICAgUmVx dWlyZW1lbnRzIGFyZSBhbHdheXMgaW5mb3JtYXRpb25hbA0KDQotICAgICAgICAgIFJGQzIxMTkg bGFuZ3VhZ2UgaXMgbm90IGhvbW9nZW5lb3VzLiBTb21ldGltZXMgY2FwaXRhbCBsZXR0ZXJzIGFy ZSB1c2VkIGFuZCBzb21ldGltZXMgbm90Lg0KDQpNeSBwcmVmZXJlbmNlIGlzIHRvIHVzZSBjYXBp dGFsIGxldHRlcnMgb25seSB3aGVuIHByb3RvY29sIGJlaGF2aW9yIGlzIGRlZmluZWQsIG5vdCB3 aGVuIHJlcXVpcmVtZW50cyBmb3IgdGhlIGRlc2lnbiBvZiB0aGUgcHJvdG9jb2wgYXJlIGRlZmlu ZWQgKHRoaXMgaXMgaW4gbGluZSB3aXRoIGUuZy4gUkZDNzA2MiBhbmQgUkZDNjE2MykuDQpBcyBJ IHNhaWQgdGhpcyBpcyBqdXN0IGEgcHJlZmVyZW5jZSwgYnV0IGlmIHRoZXJlIGlzIG5vIHJlYXNv bmFibGUgb2JqZWN0aW9uIEkgd291bGQgc3VnZ2VzdCBub3QgdG8gdXNlIGFueSBjYXBpdGFsIGxl dHRlciBpbiB0aGUgZndrK3JlcSBkb2N1bWVudC4NCg0KVGhhbmtzDQpEYW5pZWxlDQoNCkZyb206 IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hdHQg SGFydGxleSAobWhhcnRsZXkpDQpTZW50OiBtZXJjb2xlZMOsIDIwIG1hZ2dpbyAyMDE1IDE5OjEy DQpUbzogUmFtb24gQ2FzZWxsYXM7IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NDQU1Q XSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1jY2FtcC1mbGV4aS1ncmlkLWZ3ay0wMyBhbmQg Y2FsbCBmb3Igc2hlcGVyZA0KDQpUaGFua3MsIFJhbW9uLg0KDQpIb3BlZnVsbHkgdGhlIGNoYWly cyBhbmQgb3RoZXIga25vd2xlZGdlYWJsZSBmb2xrcyBjYW4gY2hpbWUgaW4gb24gdGhlIDIxMTkg bGFuZ3VhZ2UgdnMgaW5mb3JtYXRpb25hbCBzdHVmZi4NCg0KQXBvbG9naWVzIG9uIHRoZSByZXF1 aXJlbWVudHMgYm9pbGVycGxhdGUg4oCTIEkganVzdCBkaWRu4oCZdCBzY3JvbGwgZG93biBmYXIg ZW5vdWdoIDopDQoNCkNoZWVycw0KDQpNYXR0DQoNCkRlYXIgTWF0dCwNCg0KUGxlYXNlIHNlZSBp bmxpbmUNCg0KRWwgMjAvMDUvMjAxNSBhIGxhcyAxNzowNywgTWF0dCBIYXJ0bGV5IChtaGFydGxl eSkgZXNjcmliacOzOg0KUmFtb24sDQoNCklzIHRoaXMgZG9jIGluZm9ybWF0aW9uYWwgb3Igc3Rh bmRhcmRzLXRyYWNrPyBJdCBjbGFpbXMgdG8gYmUgaW5mb3JtYXRpb25hbCwgYnV0IGl0IGhhcyBS RkMgMjExOSBsYW5ndWFnZSBpbiBpdC4NCkl0IGlzIGEgZ29vZCBxdWVzdGlvbiwgd2hpY2ggaGFz IGJlZW4gcG9wcGluZyBmcmVxdWVudGx5IGR1cmluZyB0aGUgbGlmZXRpbWUgb2YgdGhlIGRyYWZ0 LiBUaGUgbGFzdCBpbmRpY2F0aW9uIEkgcmVjZWl2ZWQgKGludGVybmFsbHkpIHdhcyB0aGF0IGl0 IHNob3VsZCBiZSBpbmZvcm1hdGlvbmFsLCBhbmQgSSBjaGFuZ2VkIGl0LiBJIGd1ZXNzIHRoZSBw cm9ibGVtIGlzIHRoYXQgYXMgYSBmd2sgZG9jdW1lbnQgaXMgbWFpbmx5IGluZm9ybWF0aW9uYWws IGJ1dCBhdCBzb21lIHBvaW50IGluIHRoZSBkaXN0YW50IHBhc3QsIGl0IHdhcyBkZWNpZGVkIHRv IGluY2x1ZGUgYWxzbyBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyAoSSBndWVzcyB0aG9zZSBh cmUgdGhlIHNlY3Rpb25zIHRoYXQgdXNlIFJGQyAyMTE5IGxhbmd1YWdlKS4gTWF5YmUgd2lzZXIg cGVvcGxlIGNhbiBjb21tZW50IG9uIHRoaXMsIGJ1dCBpdCB3YXMgbXkgKGFkbWl0dGVkbHkgbGlt aXRlZCkgdW5kZXJzdGFuZGluZyB0aGF0IHRob3NlIGFyZSBub24tZXhjbHVzaXZlIChpLmUuLCBS RkNzIG1heSBiZSBpbmZvcm1hdGlvbmFsIGJ1dCB5ZXQgZGVmaW5lIHJlcXVpcmVtZW50cyBhbmQg dXNlIFJGQzIxMTkgbGFuZ3VhZ2UgdG8gaW5kaWNhdGUgcmVxdWlyZW1lbnQgbGV2ZWxzLCBhZGRp bmcgdGhlIGFwcHJvcHJpYXRlIGJvaWxlcnBsYXRlKS4NCg0KDQpBbHNvLCBpdOKAmXMgbWlzc2lu ZyB0aGUgc3RhbmRhcmQgYm9pbGVycGxhdGUgZm9yIHRoaXMgc3R1ZmY6DQoNClVobSwgYWZhaWss IGl0IGlzIG5vdCAoSSBqdXN0IGNoZWNrZWQgYm90aCBpbiAtMDMgYW5kIC0wNCBhbmQgdGhlIGJv aWxlcnBsYXRlIGlzIHRoZXJlICQyLjEpLiBUaGUgY2hhbmdlIHN0YW5kYXJkcyB0cmFjayAtPiBp bmZvcm1hdGlvbmFsIGhhcHBlbmVkIGluIC0wNC4NCg0KSW4gYW55IGNhc2UsIG5vIG9iamVjdGlv biBlaXRoZXIgd2F5LiBJIHdpbGwgcHJvY2VlZCB3aXRoIHdoYXRldmVyIG9wdGlvbiBpcyBtb3Jl IGFwcHJvcHJpYXRlDQoNCg0KDQpBbHNvOiB5b3UgY3VycmVudGx5IGhhdmUgc2l4IG1haW4gYXV0 aG9ycywgYW5kIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgUkZDIEVkaXRvcuKAmXMgZ3Vp ZGVsaW5lcyBhcmUgdGhhdCB0aGVyZSBzaG91bGQgYmUgbm8gbW9yZSB0aGFuIGZpdmXigKYuDQpU aGFua3MgZm9yIHBvaW50aW5nIHRoaXMgb3V0LCB3ZSB3ZXJlIHRvbGQgb2YgdGhpcyBub3Qgc28g bG9uZyBhZ28sLi4uDQpJIHdvdWxkIGxpa2UgdG8gYXNrIHdoZXRoZXIgZml2ZSBpcyBhIHJpZ2lk IGxpbWl0IGFuZCB3aGV0aGVyIGV4Y2VwdGlvbnMgbWF5IGJlIGdyYW50ZWQgKGNvbnNpZGVyIHRo aXMgYSBub3Qtc28tc3VidGxlIHJlcXVlc3QgZm9yIGV4Y2VwdGlvbi4uLiksIGdpdmVuIHRoYXQg dGhpcyBkcmFmdCB3YXMgdGhlIHJlc3VsdCBvZiBtZXJnaW5nIHNldmVyYWwgZHJhZnRzIC0tIHdo aWNoIGV4cGxhaW5zIHRoZSBhbWF6aW5nbHkgbG9uZyBsaXN0IG9mIGNvbnRyaWJ1dG9ycyAtLSBh bmQgYXV0aG9yc2hpcCB3YXMgYSBxdWl0ZSBoYXJkIHRoaW5nIHRvIGFncmVlIG9uLiBPVE9IIEkg Z3Vlc3MgdGhhdCBpZiB0aGlzIHBvbGljeSByZWFsbHkgbmVlZHMgdG8gYmUgZW5mb3JjZWQsIHdl IHdpbGwgaGF2ZSB0byBmaW5kIGEgd2F5IChob3BlZnVsbHkgbm90IGludm9sdmluZyBkaWNlKQ0K DQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2sNClJhbW9uDQo= --_000_4A1562797D64E44993C5CBF38CF1BE481291DBE5ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQm9v a21hbiBPbGQgU3R5bGUiOw0KCXBhbm9zZS0xOjIgNSA2IDQgNSA1IDUgMiAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJs YWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwic2Vy aWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwic2VyaWYiOw0K CWNvbG9yOiM2MzI0MjM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjMzMjU3NDE7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwMTE4ODI2OTQgNDc2ODk3NjI0IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBNYXR0LCBSYW1vbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNpbmNlIEkgZm91bmQgbm8gY2xlYXIgc3Rh dGVtZW50cyBvbiB0aGUgdXNhZ2Ugb2YgUkZDMjExOSBsYW5ndWFnZSB3aXRoIHJlc3BlY3QgdG8g dGhpcyBzaXR1YXRpb25zLCBJIGhhZCBhIGxvb2sgYXQgZXhpc3RpbmcgZnJhbWV3b3JrIGFuZCBy ZXF1aXJlbWVudCBSRkNzDQogdHJ5aW5nIHRvIGZpbmQgYSBjb21tb24gV29XLiBNeSB0YWtlIGlz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZyYW1ld29yayBpcyBhbHdheXMgaW5mb3JtYXRp b25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXF1aXJlbWVudHMg YXJlIGFsd2F5cyBpbmZvcm1hdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJGQzIxMTkgbGFuZ3VhZ2UgaXMgbm90IGhvbW9nZW5lb3VzLiBTb21ldGltZXMgY2Fw aXRhbCBsZXR0ZXJzIGFyZSB1c2VkIGFuZCBzb21ldGltZXMgbm90LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgcHJl ZmVyZW5jZSBpcyB0byB1c2UgY2FwaXRhbCBsZXR0ZXJzIG9ubHkgd2hlbiBwcm90b2NvbCBiZWhh dmlvciBpcyBkZWZpbmVkLCBub3Qgd2hlbiByZXF1aXJlbWVudHMgZm9yIHRoZSBkZXNpZ24gb2Yg dGhlIHByb3RvY29sIGFyZSBkZWZpbmVkICh0aGlzIGlzIGluDQogbGluZSB3aXRoIGUuZy4gUkZD NzA2MiBhbmQgUkZDNjE2MykuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBJIHNh aWQgdGhpcyBpcyBqdXN0IGEgcHJlZmVyZW5jZSwgYnV0IGlmIHRoZXJlIGlzIG5vIHJlYXNvbmFi bGUgb2JqZWN0aW9uIEkgd291bGQgc3VnZ2VzdCBub3QgdG8gdXNlIGFueSBjYXBpdGFsIGxldHRl ciBpbiB0aGUgZndrJiM0MztyZXEgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW5pZWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBDQ0FN UCBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1h dHQgSGFydGxleSAobWhhcnRsZXkpPGJyPg0KPGI+U2VudDo8L2I+IG1lcmNvbGVkw6wgMjAgbWFn Z2lvIDIwMTUgMTk6MTI8YnI+DQo8Yj5Ubzo8L2I+IFJhbW9uIENhc2VsbGFzOyBjY2FtcEBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgb24gZHJh ZnQtaWV0Zi1jY2FtcC1mbGV4aS1ncmlkLWZ3ay0wMyBhbmQgY2FsbCBmb3Igc2hlcGVyZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPlRoYW5rcywgUmFtb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6IzYzMjQyMyI+SG9wZWZ1bGx5IHRoZSBjaGFpcnMgYW5kIG90aGVyIGtub3dsZWRnZWFibGUg Zm9sa3MgY2FuIGNoaW1lIGluIG9uIHRoZSAyMTE5IGxhbmd1YWdlIHZzIGluZm9ybWF0aW9uYWwg c3R1ZmYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5 bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+QXBvbG9naWVzIG9uIHRoZSByZXF1aXJlbWVudHMg Ym9pbGVycGxhdGUg4oCTIEkganVzdCBkaWRu4oCZdCBzY3JvbGwgZG93biBmYXIgZW5vdWdoIDop PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7Y29sb3I6IzYzMjQyMyI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYz MjQyMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBP bGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+TWF0dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGVhciBNYXR0LCA8YnI+DQo8YnI+DQpQbGVhc2Ugc2VlIGlubGluZTxicj4NCjxicj4NCkVsIDIw LzA1LzIwMTUgYSBsYXMgMTc6MDcsIE1hdHQgSGFydGxleSAobWhhcnRsZXkpIGVzY3JpYmnDszo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+UmFtb24sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5JcyB0aGlzIGRvYyBpbmZvcm1hdGlvbmFsIG9yIHN0YW5kYXJkcy10cmFj az8gSXQgY2xhaW1zIHRvIGJlIGluZm9ybWF0aW9uYWwsIGJ1dCBpdCBoYXMgUkZDIDIxMTkgbGFu Z3VhZ2UgaW4gaXQuPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkl0IGlzIGEgZ29v ZCBxdWVzdGlvbiwgd2hpY2ggaGFzIGJlZW4gcG9wcGluZyBmcmVxdWVudGx5IGR1cmluZyB0aGUg bGlmZXRpbWUgb2YgdGhlIGRyYWZ0LiBUaGUgbGFzdCBpbmRpY2F0aW9uIEkgcmVjZWl2ZWQgKGlu dGVybmFsbHkpIHdhcyB0aGF0IGl0IHNob3VsZCBiZSBpbmZvcm1hdGlvbmFsLCBhbmQgSSBjaGFu Z2VkIGl0LiBJIGd1ZXNzIHRoZSBwcm9ibGVtDQogaXMgdGhhdCBhcyBhIGZ3ayBkb2N1bWVudCBp cyBtYWlubHkgaW5mb3JtYXRpb25hbCwgYnV0IGF0IHNvbWUgcG9pbnQgaW4gdGhlIGRpc3RhbnQg cGFzdCwgaXQgd2FzIGRlY2lkZWQgdG8gaW5jbHVkZSBhbHNvIGNvbnRyb2wgcGxhbmUgcmVxdWly ZW1lbnRzIChJIGd1ZXNzIHRob3NlIGFyZSB0aGUgc2VjdGlvbnMgdGhhdCB1c2UgUkZDIDIxMTkg bGFuZ3VhZ2UpLiBNYXliZSB3aXNlciBwZW9wbGUgY2FuIGNvbW1lbnQgb24gdGhpcywgYnV0IGl0 DQogd2FzIG15IChhZG1pdHRlZGx5IGxpbWl0ZWQpIHVuZGVyc3RhbmRpbmcgdGhhdCB0aG9zZSBh cmUgbm9uLWV4Y2x1c2l2ZSAoaS5lLiwgUkZDcyBtYXkgYmUgaW5mb3JtYXRpb25hbCBidXQgeWV0 IGRlZmluZSByZXF1aXJlbWVudHMgYW5kIHVzZSBSRkMyMTE5IGxhbmd1YWdlIHRvIGluZGljYXRl IHJlcXVpcmVtZW50IGxldmVscywgYWRkaW5nIHRoZSBhcHByb3ByaWF0ZSBib2lsZXJwbGF0ZSku PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkFsc28sIGl0 4oCZcyBtaXNzaW5nIHRoZSBzdGFuZGFyZCBib2lsZXJwbGF0ZSBmb3IgdGhpcyBzdHVmZjo8YnI+ DQo8YnI+DQo8L3NwYW4+VWhtLCBhZmFpaywgaXQgaXMgbm90IChJIGp1c3QgY2hlY2tlZCBib3Ro IGluIC0wMyBhbmQgLTA0IGFuZCB0aGUgYm9pbGVycGxhdGUgaXMgdGhlcmUgJDIuMSkuIFRoZSBj aGFuZ2Ugc3RhbmRhcmRzIHRyYWNrIC0mZ3Q7IGluZm9ybWF0aW9uYWwgaGFwcGVuZWQgaW4gLTA0 Ljxicj4NCjxicj4NCkluIGFueSBjYXNlLCBubyBvYmplY3Rpb24gZWl0aGVyIHdheS4gSSB3aWxs IHByb2NlZWQgd2l0aCB3aGF0ZXZlciBvcHRpb24gaXMgbW9yZSBhcHByb3ByaWF0ZTxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BbHNvOiB5b3Ug Y3VycmVudGx5IGhhdmUgc2l4IG1haW4gYXV0aG9ycywgYW5kIG15IHVuZGVyc3RhbmRpbmcgaXMg dGhhdCB0aGUgUkZDIEVkaXRvcuKAmXMgZ3VpZGVsaW5lcyBhcmUgdGhhdCB0aGVyZSBzaG91bGQg YmUgbm8gbW9yZSB0aGFuIGZpdmXigKYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3MgZm9yIHBvaW50 aW5nIHRoaXMgb3V0LCB3ZSB3ZXJlIHRvbGQgb2YgdGhpcyBub3Qgc28gbG9uZyBhZ28sLi4uPGJy Pg0KSSB3b3VsZCBsaWtlIHRvIGFzayB3aGV0aGVyIGZpdmUgaXMgYSByaWdpZCBsaW1pdCBhbmQg d2hldGhlciBleGNlcHRpb25zIG1heSBiZSBncmFudGVkIChjb25zaWRlciB0aGlzIGEgbm90LXNv LXN1YnRsZSByZXF1ZXN0IGZvciBleGNlcHRpb24uLi4pLCBnaXZlbiB0aGF0IHRoaXMgZHJhZnQg d2FzIHRoZSByZXN1bHQgb2YgbWVyZ2luZyBzZXZlcmFsIGRyYWZ0cyAtLSB3aGljaCBleHBsYWlu cyB0aGUgYW1hemluZ2x5IGxvbmcgbGlzdCBvZiBjb250cmlidXRvcnMNCiAtLSBhbmQgYXV0aG9y c2hpcCB3YXMgYSBxdWl0ZSBoYXJkIHRoaW5nIHRvIGFncmVlIG9uLiBPVE9IIEkgZ3Vlc3MgdGhh dCBpZiB0aGlzIHBvbGljeSByZWFsbHkgbmVlZHMgdG8gYmUgZW5mb3JjZWQsIHdlIHdpbGwgaGF2 ZSB0byBmaW5kIGEgd2F5IChob3BlZnVsbHkgbm90IGludm9sdmluZyBkaWNlKTxicj4NCjxicj4N ClRoYW5rcyBmb3IgeW91ciBmZWVkYmFjazxicj4NClJhbW9uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A1562797D64E44993C5CBF38CF1BE481291DBE5ESESSMB301erics_-- From nobody Thu May 21 01:20:49 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC26B1A8711 for ; Thu, 21 May 2015 01:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdpMYbsYY_5w for ; Thu, 21 May 2015 01:20:45 -0700 (PDT) Received: from villa.puc.rediris.es (villa.puc.rediris.es [IPv6:2001:720:418:ca00::7]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941501A86F5 for ; Thu, 21 May 2015 01:20:44 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YvLiS-0003t9-D8; Thu, 21 May 2015 10:20:36 +0200 Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 920191FD05; Thu, 21 May 2015 10:20:29 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <555D9543.7000608@cttc.es> Date: Thu, 21 May 2015 10:20:19 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniele Ceccarelli , "Matt Hartley (mhartley)" , "ccamp@ietf.org" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------040002020802050601050808" X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -1.0 (-) X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.2370] 0.0 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 08:20:47 -0000 This is a multi-part message in MIME format. --------------040002020802050601050808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit El 21/05/2015 a las 9:57, Daniele Ceccarelli escribió: > > Hi Matt, Ramon, > > Since I found no clear statements on the usage of RFC2119 language > with respect to this situations, I had a look at existing framework > and requirement RFCs trying to find a common WoW. My take is: > > -Framework is always informational > > -Requirements are always informational > > -RFC2119 language is not homogeneous. Sometimes capital letters are > used and sometimes not. > > My preference is to use capital letters only when protocol behavior is > defined, not when requirements for the design of the protocol are > defined (this is in line with e.g. RFC7062 and RFC6163). > > As I said this is just a preference, but if there is no reasonable > objection I would suggest not to use any capital letter in the fwk+req > document. > > Hi Daniele, all I was also checking existing RFCs, and IMHO: - The document can stay informational, it is mainly fwk+reqs. We seem to agree on this. - While RFC2119 states "In many standards track documents several words are used to signify the requirements in the specification", there seems to be (some?) existing practice on using RFC2119 wording in reqs/info documents, including capitalization. - Usage of RFC2119 keywords seems scoped to the section on requirements in the draft. It could be argued that defining requirements is to some extent defining high level protocol behavior :) IIRC Adrian authored a significant part of the section, any views? That said, -05 needs to be uploaded anyway to reflect the new info-model (thanks Jonas!) , it is not game-changing to change to acomodate what you suggest. We could remove RFC2119 reference, the boilerplate text and re-visit the sections, mainly using lowercase. Thanks R. --------------040002020802050601050808 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
El 21/05/2015 a las 9:57, Daniele Ceccarelli escribió:

Hi Matt, Ramon,

 

Since I found no clear statements on the usage of RFC2119 language with respect to this situations, I had a look at existing framework and requirement RFCs trying to find a common WoW. My take is:

 

-          Framework is always informational

-          Requirements are always informational

-          RFC2119 language is not homogeneous. Sometimes capital letters are used and sometimes not.

 

My preference is to use capital letters only when protocol behavior is defined, not when requirements for the design of the protocol are defined (this is in line with e.g. RFC7062 and RFC6163).

As I said this is just a preference, but if there is no reasonable objection I would suggest not to use any capital letter in the fwk+req document.

 

Hi Daniele, all

 I was also checking existing RFCs, and IMHO:
- The document can stay informational, it is mainly fwk+reqs. We seem to agree on this.
- While RFC2119 states "In many standards track documents several words are used to signify the requirements in the specification", there seems to  be (some?) existing practice on using RFC2119 wording in reqs/info documents, including capitalization.
- Usage of RFC2119 keywords seems scoped to the section on requirements in the draft. It could be argued that defining requirements is to some extent defining high level protocol behavior :)

IIRC Adrian authored a significant part of the section, any views?

That said, -05 needs to be uploaded anyway to reflect the new info-model (thanks Jonas!) , it is not game-changing to change to acomodate what you suggest. We could remove RFC2119 reference, the boilerplate text and re-visit the sections, mainly using lowercase.

Thanks
R.
--------------040002020802050601050808-- From nobody Thu May 21 01:25:58 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718701A8741 for ; Thu, 21 May 2015 01:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.6 X-Spam-Level: X-Spam-Status: No, score=-5.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9lU20h8yuqo for ; Thu, 21 May 2015 01:25:55 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E061A8739 for ; Thu, 21 May 2015 01:25:52 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-19-555d968e187c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.FF.28096.E869D555; Thu, 21 May 2015 10:25:50 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.137]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Thu, 21 May 2015 10:25:49 +0200 From: Daniele Ceccarelli To: Ramon Casellas , "Matt Hartley (mhartley)" , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgOcXiaAAH6zzgAAcq8DgAAELU+AAAAtmYAAIsVEwP//56OA///d6CA= Date: Thu, 21 May 2015 08:25:49 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481291DCEB@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> <555D9543.7000608@cttc.es> In-Reply-To: <555D9543.7000608@cttc.es> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE481291DCEBESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3VrdvWmyowbfFyhZP5txgsZjzktli 99xv7A7MHlN+b2T1aD3azuKxZMlPpgDmKC6blNSczLLUIn27BK6MvydfMxf8mMFYsXLHTvYG xjdTGLsYOTkkBEwkJj24yQJhi0lcuLeeDcQWEjjKKHFmv00XIxeQvYRR4vPD00AJDg42ASuJ J4d8QOIiAg2MEtOPLGEGaRAWiJP48Xg7K4gtIhAvMbthExNIvYhAkkTX02qQMIuAqsSLZbPA 5vMK+Epsu/iQEWJ+F7PEzb6fYL2cAuoSZ6ZPBjuOUUBWYsLuRWA2s4C4xK0n85kgDhWQWLLn PDOELSrx8vE/VpBdEgJKEtO2pkGU50v8blvICLFLUOLkzCcsExhFZiGZNAtJ2SwkZbOAJjEL aEqs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiB kXZwy2+rHYwHnzseYhTgYFTi4VWwiQ0VYk0sK67MPcQozcGiJM7r2RUSKiSQnliSmp2aWpBa FF9UmpNafIiRiYNTqoEx8/mr+/orvdbUbD90XKt6fvqdc3wCVf2XDf+41mkdWrZf9Jpqy7+9 Ou+juFr1r9+Z6b+p7L8Pp4Xno8//6nyT4jJndFy3cUxgvxR/rZ/p+WQlGbdDsjlSM/xKN8mJ Png4887Jj8YTVs9f++q2kmL8wb0Ovxa8rxJtF5eRXpPnOYn5okgjQ0mUEktxRqKhFnNRcSIA O1slhpUCAAA= Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 08:25:57 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE481291DCEBESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFtb24sDQoNCk5vIHdvcnJpZXMsIHRoZSBsYXN0IGNhbGwgY29tbWVudHMgY2FuIGJlIHNv bHZlZCBpbiB0d28gZGlmZmVyZW50IHZlcnNpb24sIHdlIGNhbiBzZW5kIHRoZSAtMDUgdG8gdGhl IElFU0cgKGlmIHRoZXJlIGFyZSBubyBtYWpvciBjaGFuZ2VzIGZyb20gLTAzIHRvIC0wNSkuDQoN ClllcywgSeKAmWQgbGlrZSB0byBoZWFyIGZyb20gQWRyaWFuIG9uIHRoZSByZXF1aXJlbWVudHMg c2VjdGlvbi4NCg0KVGhhbmtzDQpEYW5pZWxlDQoNCkZyb206IFJhbW9uIENhc2VsbGFzIFttYWls dG86cmFtb24uY2FzZWxsYXNAY3R0Yy5lc10NClNlbnQ6IGdpb3ZlZMOsIDIxIG1hZ2dpbyAyMDE1 IDEwOjIwDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTsg Y2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBvbiBkcmFm dC1pZXRmLWNjYW1wLWZsZXhpLWdyaWQtZndrLTAzIGFuZCBjYWxsIGZvciBzaGVwZXJkDQoNCkVs IDIxLzA1LzIwMTUgYSBsYXMgOTo1NywgRGFuaWVsZSBDZWNjYXJlbGxpIGVzY3JpYmnDszoNCkhp IE1hdHQsIFJhbW9uLA0KDQpTaW5jZSBJIGZvdW5kIG5vIGNsZWFyIHN0YXRlbWVudHMgb24gdGhl IHVzYWdlIG9mIFJGQzIxMTkgbGFuZ3VhZ2Ugd2l0aCByZXNwZWN0IHRvIHRoaXMgc2l0dWF0aW9u cywgSSBoYWQgYSBsb29rIGF0IGV4aXN0aW5nIGZyYW1ld29yayBhbmQgcmVxdWlyZW1lbnQgUkZD cyB0cnlpbmcgdG8gZmluZCBhIGNvbW1vbiBXb1cuIE15IHRha2UgaXM6DQoNCg0KDQotICAgICAg ICAgIEZyYW1ld29yayBpcyBhbHdheXMgaW5mb3JtYXRpb25hbA0KDQotICAgICAgICAgIFJlcXVp cmVtZW50cyBhcmUgYWx3YXlzIGluZm9ybWF0aW9uYWwNCg0KLSAgICAgICAgICBSRkMyMTE5IGxh bmd1YWdlIGlzIG5vdCBob21vZ2VuZW91cy4gU29tZXRpbWVzIGNhcGl0YWwgbGV0dGVycyBhcmUg dXNlZCBhbmQgc29tZXRpbWVzIG5vdC4NCg0KTXkgcHJlZmVyZW5jZSBpcyB0byB1c2UgY2FwaXRh bCBsZXR0ZXJzIG9ubHkgd2hlbiBwcm90b2NvbCBiZWhhdmlvciBpcyBkZWZpbmVkLCBub3Qgd2hl biByZXF1aXJlbWVudHMgZm9yIHRoZSBkZXNpZ24gb2YgdGhlIHByb3RvY29sIGFyZSBkZWZpbmVk ICh0aGlzIGlzIGluIGxpbmUgd2l0aCBlLmcuIFJGQzcwNjIgYW5kIFJGQzYxNjMpLg0KQXMgSSBz YWlkIHRoaXMgaXMganVzdCBhIHByZWZlcmVuY2UsIGJ1dCBpZiB0aGVyZSBpcyBubyByZWFzb25h YmxlIG9iamVjdGlvbiBJIHdvdWxkIHN1Z2dlc3Qgbm90IHRvIHVzZSBhbnkgY2FwaXRhbCBsZXR0 ZXIgaW4gdGhlIGZ3aytyZXEgZG9jdW1lbnQuDQoNCkhpIERhbmllbGUsIGFsbA0KDQogSSB3YXMg YWxzbyBjaGVja2luZyBleGlzdGluZyBSRkNzLCBhbmQgSU1ITzoNCi0gVGhlIGRvY3VtZW50IGNh biBzdGF5IGluZm9ybWF0aW9uYWwsIGl0IGlzIG1haW5seSBmd2srcmVxcy4gV2Ugc2VlbSB0byBh Z3JlZSBvbiB0aGlzLg0KLSBXaGlsZSBSRkMyMTE5IHN0YXRlcyAiSW4gbWFueSBzdGFuZGFyZHMg dHJhY2sgZG9jdW1lbnRzIHNldmVyYWwgd29yZHMgYXJlIHVzZWQgdG8gc2lnbmlmeSB0aGUgcmVx dWlyZW1lbnRzIGluIHRoZSBzcGVjaWZpY2F0aW9uIiwgdGhlcmUgc2VlbXMgdG8gIGJlIChzb21l PykgZXhpc3RpbmcgcHJhY3RpY2Ugb24gdXNpbmcgUkZDMjExOSB3b3JkaW5nIGluIHJlcXMvaW5m byBkb2N1bWVudHMsIGluY2x1ZGluZyBjYXBpdGFsaXphdGlvbi4NCi0gVXNhZ2Ugb2YgUkZDMjEx OSBrZXl3b3JkcyBzZWVtcyBzY29wZWQgdG8gdGhlIHNlY3Rpb24gb24gcmVxdWlyZW1lbnRzIGlu IHRoZSBkcmFmdC4gSXQgY291bGQgYmUgYXJndWVkIHRoYXQgZGVmaW5pbmcgcmVxdWlyZW1lbnRz IGlzIHRvIHNvbWUgZXh0ZW50IGRlZmluaW5nIGhpZ2ggbGV2ZWwgcHJvdG9jb2wgYmVoYXZpb3Ig OikNCg0KSUlSQyBBZHJpYW4gYXV0aG9yZWQgYSBzaWduaWZpY2FudCBwYXJ0IG9mIHRoZSBzZWN0 aW9uLCBhbnkgdmlld3M/DQoNClRoYXQgc2FpZCwgLTA1IG5lZWRzIHRvIGJlIHVwbG9hZGVkIGFu eXdheSB0byByZWZsZWN0IHRoZSBuZXcgaW5mby1tb2RlbCAodGhhbmtzIEpvbmFzISkgLCBpdCBp cyBub3QgZ2FtZS1jaGFuZ2luZyB0byBjaGFuZ2UgdG8gYWNvbW9kYXRlIHdoYXQgeW91IHN1Z2dl c3QuIFdlIGNvdWxkIHJlbW92ZSBSRkMyMTE5IHJlZmVyZW5jZSwgdGhlIGJvaWxlcnBsYXRlIHRl eHQgYW5kIHJlLXZpc2l0IHRoZSBzZWN0aW9ucywgbWFpbmx5IHVzaW5nIGxvd2VyY2FzZS4NCg0K VGhhbmtzDQpSLg0K --_000_4A1562797D64E44993C5CBF38CF1BE481291DCEBESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQm9v a21hbiBPbGQgU3R5bGUiOw0KCXBhbm9zZS0xOjIgNSA2IDQgNSA1IDUgMiAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJs YWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdp bi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJCb29rbWFu IE9sZCBTdHlsZSIsInNlcmlmIjsNCgljb2xvcjojNjMyNDIzO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBT dHlsZSIsInNlcmlmIjsNCgljb2xvcjojNjMyNDIzO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2MzMyNTc0MTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjAxMTg4MjY5NCA0NzY4OTc2MjQgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0K CW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJhbW9uLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm8g d29ycmllcywgdGhlIGxhc3QgY2FsbCBjb21tZW50cyBjYW4gYmUgc29sdmVkIGluIHR3byBkaWZm ZXJlbnQgdmVyc2lvbiwgd2UgY2FuIHNlbmQgdGhlIC0wNSB0byB0aGUgSUVTRyAoaWYgdGhlcmUg YXJlIG5vIG1ham9yIGNoYW5nZXMgZnJvbSAtMDMgdG8gLTA1KS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgSeKA mWQgbGlrZSB0byBoZWFyIGZyb20gQWRyaWFuIG9uIHRoZSByZXF1aXJlbWVudHMgc2VjdGlvbi4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhbmllbGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6d2luZG93dGV4dCI+IFJhbW9uIENhc2VsbGFzIFttYWlsdG86cmFtb24uY2FzZWxs YXNAY3R0Yy5lc10NCjxicj4NCjxiPlNlbnQ6PC9iPiBnaW92ZWTDrCAyMSBtYWdnaW8gMjAxNSAx MDoyMDxicj4NCjxiPlRvOjwvYj4gRGFuaWVsZSBDZWNjYXJlbGxpOyBNYXR0IEhhcnRsZXkgKG1o YXJ0bGV5KTsgY2NhbXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0g V0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAtZmxleGktZ3JpZC1md2stMDMgYW5kIGNh bGwgZm9yIHNoZXBlcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RWwgMjEvMDUvMjAxNSBhIGxhcyA5OjU3LCBEYW5pZWxlIENlY2NhcmVsbGkg ZXNjcmliacOzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNYXR0LCBSYW1v biw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlNpbmNlIEkgZm91bmQgbm8gY2xlYXIgc3RhdGVtZW50cyBvbiB0aGUgdXNh Z2Ugb2YgUkZDMjExOSBsYW5ndWFnZSB3aXRoIHJlc3BlY3QgdG8gdGhpcyBzaXR1YXRpb25zLCBJ IGhhZCBhIGxvb2sgYXQgZXhpc3RpbmcgZnJhbWV3b3JrIGFuZCByZXF1aXJlbWVudCBSRkNzDQog dHJ5aW5nIHRvIGZpbmQgYSBjb21tb24gV29XLiBNeSB0YWtlIGlzOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RnJhbWV3b3JrIGlzIGFsd2F5cyBp bmZvcm1hdGlvbmFsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVxdWlyZW1lbnRzIGFyZSBhbHdheXMgaW5mb3JtYXRpb25h bDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJGQzIxMTkgbGFuZ3VhZ2UgaXMgbm90IGhvbW9nZW5lb3VzLiBTb21ldGltZXMg Y2FwaXRhbCBsZXR0ZXJzIGFyZSB1c2VkIGFuZCBzb21ldGltZXMgbm90Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkg cHJlZmVyZW5jZSBpcyB0byB1c2UgY2FwaXRhbCBsZXR0ZXJzIG9ubHkgd2hlbiBwcm90b2NvbCBi ZWhhdmlvciBpcyBkZWZpbmVkLCBub3Qgd2hlbiByZXF1aXJlbWVudHMgZm9yIHRoZSBkZXNpZ24g b2YgdGhlIHByb3RvY29sIGFyZSBkZWZpbmVkICh0aGlzIGlzIGluDQogbGluZSB3aXRoIGUuZy4g UkZDNzA2MiBhbmQgUkZDNjE2MykuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBJ IHNhaWQgdGhpcyBpcyBqdXN0IGEgcHJlZmVyZW5jZSwgYnV0IGlmIHRoZXJlIGlzIG5vIHJlYXNv bmFibGUgb2JqZWN0aW9uIEkgd291bGQgc3VnZ2VzdCBub3QgdG8gdXNlIGFueSBjYXBpdGFsIGxl dHRlciBpbiB0aGUgZndrJiM0MztyZXEgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIERhbmllbGUsIGFsbDxicj4NCjxicj4NCiZuYnNwO0kgd2FzIGFs c28gY2hlY2tpbmcgZXhpc3RpbmcgUkZDcywgYW5kIElNSE86PGJyPg0KLSBUaGUgZG9jdW1lbnQg Y2FuIHN0YXkgaW5mb3JtYXRpb25hbCwgaXQgaXMgbWFpbmx5IGZ3ayYjNDM7cmVxcy4gV2Ugc2Vl bSB0byBhZ3JlZSBvbiB0aGlzLjxicj4NCi0gV2hpbGUgUkZDMjExOSBzdGF0ZXMgJnF1b3Q7SW4g bWFueSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnRzIHNldmVyYWwgd29yZHMgYXJlIHVzZWQgdG8g c2lnbmlmeSB0aGUgcmVxdWlyZW1lbnRzIGluIHRoZSBzcGVjaWZpY2F0aW9uJnF1b3Q7LCB0aGVy ZSBzZWVtcyB0byZuYnNwOyBiZSAoc29tZT8pIGV4aXN0aW5nIHByYWN0aWNlIG9uIHVzaW5nIFJG QzIxMTkgd29yZGluZyBpbiByZXFzL2luZm8gZG9jdW1lbnRzLCBpbmNsdWRpbmcgY2FwaXRhbGl6 YXRpb24uPGJyPg0KLSBVc2FnZSBvZiBSRkMyMTE5IGtleXdvcmRzIHNlZW1zIHNjb3BlZCB0byB0 aGUgc2VjdGlvbiBvbiByZXF1aXJlbWVudHMgaW4gdGhlIGRyYWZ0LiBJdCBjb3VsZCBiZSBhcmd1 ZWQgdGhhdCBkZWZpbmluZyByZXF1aXJlbWVudHMgaXMgdG8gc29tZSBleHRlbnQgZGVmaW5pbmcg aGlnaCBsZXZlbCBwcm90b2NvbCBiZWhhdmlvciA6KTxicj4NCjxicj4NCklJUkMgQWRyaWFuIGF1 dGhvcmVkIGEgc2lnbmlmaWNhbnQgcGFydCBvZiB0aGUgc2VjdGlvbiwgYW55IHZpZXdzPzxicj4N Cjxicj4NClRoYXQgc2FpZCwgLTA1IG5lZWRzIHRvIGJlIHVwbG9hZGVkIGFueXdheSB0byByZWZs ZWN0IHRoZSBuZXcgaW5mby1tb2RlbCAodGhhbmtzIEpvbmFzISkgLCBpdCBpcyBub3QgZ2FtZS1j aGFuZ2luZyB0byBjaGFuZ2UgdG8gYWNvbW9kYXRlIHdoYXQgeW91IHN1Z2dlc3QuIFdlIGNvdWxk IHJlbW92ZSBSRkMyMTE5IHJlZmVyZW5jZSwgdGhlIGJvaWxlcnBsYXRlIHRleHQgYW5kIHJlLXZp c2l0IHRoZSBzZWN0aW9ucywgbWFpbmx5IHVzaW5nIGxvd2VyY2FzZS48YnI+DQo8YnI+DQpUaGFu a3M8YnI+DQpSLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_4A1562797D64E44993C5CBF38CF1BE481291DCEBESESSMB301erics_-- From nobody Thu May 21 01:43:04 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FA81A8AA8 for ; Thu, 21 May 2015 01:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEtFUgMdBQyF for ; Thu, 21 May 2015 01:43:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621C61A8741 for ; Thu, 21 May 2015 01:42:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWI55074; Thu, 21 May 2015 08:42:57 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 09:42:55 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.3]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Thu, 21 May 2015 16:42:50 +0800 From: "Zhangxian (Xian)" To: Daniele Ceccarelli , "Matt Hartley (mhartley)" , Ramon Casellas Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgOPy3+AAH6zzgAAcq8DgAAELU+AAAAtmYAAHvHBgAARHRwg Date: Thu, 21 May 2015 08:42:48 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B471D4BA7SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 08:43:03 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471D4BA7SZXEMA512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgdW5kZXJzdGFuZGluZyBpcyB0aGUgc2FtZSB3aGF0IERhbmllbGUgc3VtbWFyaXplZCBhbmQg SSBzZWNvbmQgdGhlIHByb3Bvc2FsIGJlbG93Lg0KDQpSRkM3MDYyIHByb3ZpZGVzIGEgZ29vZCBy ZWZlcmVuY2UuIFdpdGhvdXQgdXNpbmcgUkZDMjExOSBsYW5ndWFnZSwgSXQgaW5jbHVkZXMgb3B0 aW9uYWwgYW5kIGNvbXB1bHNvcnkgcmVxdWlyZW1lbnRzIHRvIEdNUExTIHByb3RvY29scyAoT1NQ Ri1URSwgUlNWUC1URSwgTE1QKS4NCg0KUmVnYXJkcywNClhpYW4NCg0KRnJvbTogQ0NBTVAgW21h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGFuaWVsZSBDZWNjYXJl bGxpDQpTZW50OiAyMDE15bm0NeaciDIx5pelIDE1OjU4DQpUbzogTWF0dCBIYXJ0bGV5IChtaGFy dGxleSk7IFJhbW9uIENhc2VsbGFzOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDQ0FN UF0gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAtZmxleGktZ3JpZC1md2stMDMgYW5k IGNhbGwgZm9yIHNoZXBlcmQNCg0KSGkgTWF0dCwgUmFtb24sDQoNClNpbmNlIEkgZm91bmQgbm8g Y2xlYXIgc3RhdGVtZW50cyBvbiB0aGUgdXNhZ2Ugb2YgUkZDMjExOSBsYW5ndWFnZSB3aXRoIHJl c3BlY3QgdG8gdGhpcyBzaXR1YXRpb25zLCBJIGhhZCBhIGxvb2sgYXQgZXhpc3RpbmcgZnJhbWV3 b3JrIGFuZCByZXF1aXJlbWVudCBSRkNzIHRyeWluZyB0byBmaW5kIGEgY29tbW9uIFdvVy4gTXkg dGFrZSBpczoNCg0KDQoNCi0gICAgICAgIEZyYW1ld29yayBpcyBhbHdheXMgaW5mb3JtYXRpb25h bA0KDQotICAgICAgICBSZXF1aXJlbWVudHMgYXJlIGFsd2F5cyBpbmZvcm1hdGlvbmFsDQoNCi0g ICAgICAgIFJGQzIxMTkgbGFuZ3VhZ2UgaXMgbm90IGhvbW9nZW5lb3VzLiBTb21ldGltZXMgY2Fw aXRhbCBsZXR0ZXJzIGFyZSB1c2VkIGFuZCBzb21ldGltZXMgbm90Lg0KDQpNeSBwcmVmZXJlbmNl IGlzIHRvIHVzZSBjYXBpdGFsIGxldHRlcnMgb25seSB3aGVuIHByb3RvY29sIGJlaGF2aW9yIGlz IGRlZmluZWQsIG5vdCB3aGVuIHJlcXVpcmVtZW50cyBmb3IgdGhlIGRlc2lnbiBvZiB0aGUgcHJv dG9jb2wgYXJlIGRlZmluZWQgKHRoaXMgaXMgaW4gbGluZSB3aXRoIGUuZy4gUkZDNzA2MiBhbmQg UkZDNjE2MykuDQpBcyBJIHNhaWQgdGhpcyBpcyBqdXN0IGEgcHJlZmVyZW5jZSwgYnV0IGlmIHRo ZXJlIGlzIG5vIHJlYXNvbmFibGUgb2JqZWN0aW9uIEkgd291bGQgc3VnZ2VzdCBub3QgdG8gdXNl IGFueSBjYXBpdGFsIGxldHRlciBpbiB0aGUgZndrK3JlcSBkb2N1bWVudC4NCg0KVGhhbmtzDQpE YW5pZWxlDQoNCkZyb206IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE1hdHQgSGFydGxleSAobWhhcnRsZXkpDQpTZW50OiBtZXJjb2xlZMOsIDIwIG1h Z2dpbyAyMDE1IDE5OjEyDQpUbzogUmFtb24gQ2FzZWxsYXM7IGNjYW1wQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1jY2FtcC1mbGV4aS1n cmlkLWZ3ay0wMyBhbmQgY2FsbCBmb3Igc2hlcGVyZA0KDQpUaGFua3MsIFJhbW9uLg0KDQpIb3Bl ZnVsbHkgdGhlIGNoYWlycyBhbmQgb3RoZXIga25vd2xlZGdlYWJsZSBmb2xrcyBjYW4gY2hpbWUg aW4gb24gdGhlIDIxMTkgbGFuZ3VhZ2UgdnMgaW5mb3JtYXRpb25hbCBzdHVmZi4NCg0KQXBvbG9n aWVzIG9uIHRoZSByZXF1aXJlbWVudHMgYm9pbGVycGxhdGUg4oCTIEkganVzdCBkaWRu4oCZdCBz Y3JvbGwgZG93biBmYXIgZW5vdWdoIDopDQoNCkNoZWVycw0KDQpNYXR0DQoNCkRlYXIgTWF0dCwN Cg0KUGxlYXNlIHNlZSBpbmxpbmUNCg0KRWwgMjAvMDUvMjAxNSBhIGxhcyAxNzowNywgTWF0dCBI YXJ0bGV5IChtaGFydGxleSkgZXNjcmliacOzOg0KUmFtb24sDQoNCklzIHRoaXMgZG9jIGluZm9y bWF0aW9uYWwgb3Igc3RhbmRhcmRzLXRyYWNrPyBJdCBjbGFpbXMgdG8gYmUgaW5mb3JtYXRpb25h bCwgYnV0IGl0IGhhcyBSRkMgMjExOSBsYW5ndWFnZSBpbiBpdC4NCkl0IGlzIGEgZ29vZCBxdWVz dGlvbiwgd2hpY2ggaGFzIGJlZW4gcG9wcGluZyBmcmVxdWVudGx5IGR1cmluZyB0aGUgbGlmZXRp bWUgb2YgdGhlIGRyYWZ0LiBUaGUgbGFzdCBpbmRpY2F0aW9uIEkgcmVjZWl2ZWQgKGludGVybmFs bHkpIHdhcyB0aGF0IGl0IHNob3VsZCBiZSBpbmZvcm1hdGlvbmFsLCBhbmQgSSBjaGFuZ2VkIGl0 LiBJIGd1ZXNzIHRoZSBwcm9ibGVtIGlzIHRoYXQgYXMgYSBmd2sgZG9jdW1lbnQgaXMgbWFpbmx5 IGluZm9ybWF0aW9uYWwsIGJ1dCBhdCBzb21lIHBvaW50IGluIHRoZSBkaXN0YW50IHBhc3QsIGl0 IHdhcyBkZWNpZGVkIHRvIGluY2x1ZGUgYWxzbyBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyAo SSBndWVzcyB0aG9zZSBhcmUgdGhlIHNlY3Rpb25zIHRoYXQgdXNlIFJGQyAyMTE5IGxhbmd1YWdl KS4gTWF5YmUgd2lzZXIgcGVvcGxlIGNhbiBjb21tZW50IG9uIHRoaXMsIGJ1dCBpdCB3YXMgbXkg KGFkbWl0dGVkbHkgbGltaXRlZCkgdW5kZXJzdGFuZGluZyB0aGF0IHRob3NlIGFyZSBub24tZXhj bHVzaXZlIChpLmUuLCBSRkNzIG1heSBiZSBpbmZvcm1hdGlvbmFsIGJ1dCB5ZXQgZGVmaW5lIHJl cXVpcmVtZW50cyBhbmQgdXNlIFJGQzIxMTkgbGFuZ3VhZ2UgdG8gaW5kaWNhdGUgcmVxdWlyZW1l bnQgbGV2ZWxzLCBhZGRpbmcgdGhlIGFwcHJvcHJpYXRlIGJvaWxlcnBsYXRlKS4NCg0KDQpBbHNv LCBpdOKAmXMgbWlzc2luZyB0aGUgc3RhbmRhcmQgYm9pbGVycGxhdGUgZm9yIHRoaXMgc3R1ZmY6 DQoNClVobSwgYWZhaWssIGl0IGlzIG5vdCAoSSBqdXN0IGNoZWNrZWQgYm90aCBpbiAtMDMgYW5k IC0wNCBhbmQgdGhlIGJvaWxlcnBsYXRlIGlzIHRoZXJlICQyLjEpLiBUaGUgY2hhbmdlIHN0YW5k YXJkcyB0cmFjayAtPiBpbmZvcm1hdGlvbmFsIGhhcHBlbmVkIGluIC0wNC4NCg0KSW4gYW55IGNh c2UsIG5vIG9iamVjdGlvbiBlaXRoZXIgd2F5LiBJIHdpbGwgcHJvY2VlZCB3aXRoIHdoYXRldmVy IG9wdGlvbiBpcyBtb3JlIGFwcHJvcHJpYXRlDQoNCg0KQWxzbzogeW91IGN1cnJlbnRseSBoYXZl IHNpeCBtYWluIGF1dGhvcnMsIGFuZCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIFJGQyBF ZGl0b3LigJlzIGd1aWRlbGluZXMgYXJlIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG5vIG1vcmUgdGhh biBmaXZl4oCmLg0KVGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dCwgd2Ugd2VyZSB0b2xkIG9m IHRoaXMgbm90IHNvIGxvbmcgYWdvLC4uLg0KSSB3b3VsZCBsaWtlIHRvIGFzayB3aGV0aGVyIGZp dmUgaXMgYSByaWdpZCBsaW1pdCBhbmQgd2hldGhlciBleGNlcHRpb25zIG1heSBiZSBncmFudGVk IChjb25zaWRlciB0aGlzIGEgbm90LXNvLXN1YnRsZSByZXF1ZXN0IGZvciBleGNlcHRpb24uLi4p LCBnaXZlbiB0aGF0IHRoaXMgZHJhZnQgd2FzIHRoZSByZXN1bHQgb2YgbWVyZ2luZyBzZXZlcmFs IGRyYWZ0cyAtLSB3aGljaCBleHBsYWlucyB0aGUgYW1hemluZ2x5IGxvbmcgbGlzdCBvZiBjb250 cmlidXRvcnMgLS0gYW5kIGF1dGhvcnNoaXAgd2FzIGEgcXVpdGUgaGFyZCB0aGluZyB0byBhZ3Jl ZSBvbi4gT1RPSCBJIGd1ZXNzIHRoYXQgaWYgdGhpcyBwb2xpY3kgcmVhbGx5IG5lZWRzIHRvIGJl IGVuZm9yY2VkLCB3ZSB3aWxsIGhhdmUgdG8gZmluZCBhIHdheSAoaG9wZWZ1bGx5IG5vdCBpbnZv bHZpbmcgZGljZSkNCg0KVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrDQpSYW1vbg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471D4BA7SZXEMA512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBTdHlsZSI7DQoJcGFub3NlLTE6MiA1IDYg NCA1IDUgNSAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJz ZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsN CgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwic2VyaWYiOw0KCWNvbG9yOiM2MzI0 MjM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwic2VyaWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0K c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTYz MzI1NzQxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoy MDExODgyNjk0IDQ3Njg5NzYyNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciLCJzZXJpZiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYi O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgaXMgdGhlIHNhbWUgd2hhdCBEYW5pZWxlIHN1 bW1hcml6ZWQgYW5kIEkgc2Vjb25kIHRoZSBwcm9wb3NhbCBiZWxvdy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SRkM3MDYyIHByb3ZpZGVzIGEgZ29vZCByZWZlcmVuY2Uu IFdpdGhvdXQgdXNpbmcgUkZDMjExOSBsYW5ndWFnZSwgSXQgaW5jbHVkZXMgb3B0aW9uYWwgYW5k IGNvbXB1bHNvcnkgcmVxdWlyZW1lbnRzIHRvIEdNUExTIHByb3RvY29scyAoT1NQRi1URSwNCiBS U1ZQLVRFLCBMTVApLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRz LDxicj4NClhpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQ0NBTVAgW21h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYW5pZWxl IENlY2NhcmVsbGk8YnI+DQo8Yj5TZW50OjwvYj4gMjAxNTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+5bm0PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0 ZXh0Ij41PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWu i+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPjIxPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7ml6U8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPg0KIDE1OjU4PGJyPg0KPGI+VG86PC9iPiBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTsg UmFtb24gQ2FzZWxsYXM7IGNjYW1wQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb Q0NBTVBdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWNjYW1wLWZsZXhpLWdyaWQtZndrLTAz IGFuZCBjYWxsIGZvciBzaGVwZXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hdHQsIFJhbW9uLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaW5jZSBJIGZvdW5kIG5vIGNsZWFyIHN0 YXRlbWVudHMgb24gdGhlIHVzYWdlIG9mIFJGQzIxMTkgbGFuZ3VhZ2Ugd2l0aCByZXNwZWN0IHRv IHRoaXMgc2l0dWF0aW9ucywgSSBoYWQgYSBsb29rIGF0IGV4aXN0aW5nIGZyYW1ld29yayBhbmQg cmVxdWlyZW1lbnQNCiBSRkNzIHRyeWluZyB0byBmaW5kIGEgY29tbW9uIFdvVy4gTXkgdGFrZSBp czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5G cmFtZXdvcmsgaXMgYWx3YXlzIGluZm9ybWF0aW9uYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXF1aXJlbWVudHMgYXJlIGFsd2F5cyBpbmZv cm1hdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UkZDMjExOSBsYW5ndWFnZSBpcyBub3QgaG9tb2dlbmVvdXMuIFNvbWV0aW1lcyBjYXBp dGFsIGxldHRlcnMgYXJlIHVzZWQgYW5kIHNvbWV0aW1lcyBub3QuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHByZWZlcmVuY2UgaXMgdG8gdXNlIGNhcGl0YWwgbGV0dGVy cyBvbmx5IHdoZW4gcHJvdG9jb2wgYmVoYXZpb3IgaXMgZGVmaW5lZCwgbm90IHdoZW4gcmVxdWly ZW1lbnRzIGZvciB0aGUgZGVzaWduIG9mIHRoZSBwcm90b2NvbCBhcmUgZGVmaW5lZA0KICh0aGlz IGlzIGluIGxpbmUgd2l0aCBlLmcuIFJGQzcwNjIgYW5kIFJGQzYxNjMpLiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIEkgc2FpZCB0aGlzIGlzIGp1c3QgYSBw cmVmZXJlbmNlLCBidXQgaWYgdGhlcmUgaXMgbm8gcmVhc29uYWJsZSBvYmplY3Rpb24gSSB3b3Vs ZCBzdWdnZXN0IG5vdCB0byB1c2UgYW55IGNhcGl0YWwgbGV0dGVyIGluIHRoZSBmd2smIzQzO3Jl cSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhbmllbGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEND QU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ TWF0dCBIYXJ0bGV5IChtaGFydGxleSk8YnI+DQo8Yj5TZW50OjwvYj4gbWVyY29sZWTDrCAyMCBt YWdnaW8gMjAxNSAxOToxMjxicj4NCjxiPlRvOjwvYj4gUmFtb24gQ2FzZWxsYXM7IGNjYW1wQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIFdHIExhc3QgQ2FsbCBvbiBk cmFmdC1pZXRmLWNjYW1wLWZsZXhpLWdyaWQtZndrLTAzIGFuZCBjYWxsIGZvciBzaGVwZXJkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzYzMjQyMyI+VGhhbmtzLCBSYW1vbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiM2MzI0MjMiPkhvcGVmdWxseSB0aGUgY2hhaXJzIGFuZCBvdGhlciBrbm93 bGVkZ2VhYmxlIGZvbGtzIGNhbiBjaGltZSBpbiBvbiB0aGUgMjExOSBsYW5ndWFnZSB2cyBpbmZv cm1hdGlvbmFsIHN0dWZmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjoj NjMyNDIzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzYz MjQyMyI+QXBvbG9naWVzIG9uIHRoZSByZXF1aXJlbWVudHMgYm9pbGVycGxhdGUg4oCTIEkganVz dCBkaWRu4oCZdCBzY3JvbGwgZG93biBmYXIgZW5vdWdoIDopPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjojNjMyNDIzIj5DaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6IzYzMjQyMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiM2MzI0MjMiPk1hdHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Qm9va21hbiBPbGQgU3R5bGUmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6IzYzMjQyMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+RGVhciBNYXR0LCA8YnI+DQo8YnI+DQpQbGVhc2Ugc2VlIGlubGluZTxicj4NCjxicj4N CkVsIDIwLzA1LzIwMTUgYSBsYXMgMTc6MDcsIE1hdHQgSGFydGxleSAobWhhcnRsZXkpIGVzY3Jp YmnDszo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5SYW1vbiw8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPklzIHRoaXMgZG9jIGluZm9ybWF0aW9uYWwgb3Igc3RhbmRhcmRzLXRyYWNrPyBJdCBjbGFp bXMgdG8gYmUgaW5mb3JtYXRpb25hbCwgYnV0IGl0IGhhcyBSRkMgMjExOSBsYW5ndWFnZSBpbiBp dC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SXQgaXMgYSBnb29kIHF1ZXN0aW9uLCB3aGljaCBoYXMg YmVlbiBwb3BwaW5nIGZyZXF1ZW50bHkgZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgZHJhZnQu IFRoZSBsYXN0IGluZGljYXRpb24gSSByZWNlaXZlZCAoaW50ZXJuYWxseSkgd2FzIHRoYXQgaXQg c2hvdWxkIGJlIGluZm9ybWF0aW9uYWwsIGFuZCBJIGNoYW5nZWQgaXQuDQogSSBndWVzcyB0aGUg cHJvYmxlbSBpcyB0aGF0IGFzIGEgZndrIGRvY3VtZW50IGlzIG1haW5seSBpbmZvcm1hdGlvbmFs LCBidXQgYXQgc29tZSBwb2ludCBpbiB0aGUgZGlzdGFudCBwYXN0LCBpdCB3YXMgZGVjaWRlZCB0 byBpbmNsdWRlIGFsc28gY29udHJvbCBwbGFuZSByZXF1aXJlbWVudHMgKEkgZ3Vlc3MgdGhvc2Ug YXJlIHRoZSBzZWN0aW9ucyB0aGF0IHVzZSBSRkMgMjExOSBsYW5ndWFnZSkuIE1heWJlIHdpc2Vy IHBlb3BsZSBjYW4gY29tbWVudA0KIG9uIHRoaXMsIGJ1dCBpdCB3YXMgbXkgKGFkbWl0dGVkbHkg bGltaXRlZCkgdW5kZXJzdGFuZGluZyB0aGF0IHRob3NlIGFyZSBub24tZXhjbHVzaXZlIChpLmUu LCBSRkNzIG1heSBiZSBpbmZvcm1hdGlvbmFsIGJ1dCB5ZXQgZGVmaW5lIHJlcXVpcmVtZW50cyBh bmQgdXNlIFJGQzIxMTkgbGFuZ3VhZ2UgdG8gaW5kaWNhdGUgcmVxdWlyZW1lbnQgbGV2ZWxzLCBh ZGRpbmcgdGhlIGFwcHJvcHJpYXRlIGJvaWxlcnBsYXRlKS48YnI+DQo8YnI+DQo8YnI+DQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BbHNvLCBpdOKA mXMgbWlzc2luZyB0aGUgc3RhbmRhcmQgYm9pbGVycGxhdGUgZm9yIHRoaXMgc3R1ZmY6PGJyPg0K PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5VaG0sIGFmYWlrLCBpdCBpcyBub3QgKEkg anVzdCBjaGVja2VkIGJvdGggaW4gLTAzIGFuZCAtMDQgYW5kIHRoZSBib2lsZXJwbGF0ZSBpcyB0 aGVyZSAkMi4xKS4gVGhlIGNoYW5nZSBzdGFuZGFyZHMgdHJhY2sgLSZndDsgaW5mb3JtYXRpb25h bCBoYXBwZW5lZCBpbiAtMDQuPGJyPg0KPGJyPg0KSW4gYW55IGNhc2UsIG5vIG9iamVjdGlvbiBl aXRoZXIgd2F5LiBJIHdpbGwgcHJvY2VlZCB3aXRoIHdoYXRldmVyIG9wdGlvbiBpcyBtb3JlIGFw cHJvcHJpYXRlPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+QWxzbzogeW91IGN1cnJlbnRseSBoYXZlIHNpeCBtYWluIGF1dGhvcnMsIGFuZCBteSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgdGhlIFJGQyBFZGl0b3LigJlzIGd1aWRlbGluZXMgYXJlIHRoYXQg dGhlcmUgc2hvdWxkIGJlIG5vIG1vcmUgdGhhbiBmaXZl4oCmLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciBwb2lu dGluZyB0aGlzIG91dCwgd2Ugd2VyZSB0b2xkIG9mIHRoaXMgbm90IHNvIGxvbmcgYWdvLC4uLjxi cj4NCkkgd291bGQgbGlrZSB0byBhc2sgd2hldGhlciBmaXZlIGlzIGEgcmlnaWQgbGltaXQgYW5k IHdoZXRoZXIgZXhjZXB0aW9ucyBtYXkgYmUgZ3JhbnRlZCAoY29uc2lkZXIgdGhpcyBhIG5vdC1z by1zdWJ0bGUgcmVxdWVzdCBmb3IgZXhjZXB0aW9uLi4uKSwgZ2l2ZW4gdGhhdCB0aGlzIGRyYWZ0 IHdhcyB0aGUgcmVzdWx0IG9mIG1lcmdpbmcgc2V2ZXJhbCBkcmFmdHMgLS0gd2hpY2ggZXhwbGFp bnMgdGhlIGFtYXppbmdseSBsb25nIGxpc3Qgb2YgY29udHJpYnV0b3JzDQogLS0gYW5kIGF1dGhv cnNoaXAgd2FzIGEgcXVpdGUgaGFyZCB0aGluZyB0byBhZ3JlZSBvbi4gT1RPSCBJIGd1ZXNzIHRo YXQgaWYgdGhpcyBwb2xpY3kgcmVhbGx5IG5lZWRzIHRvIGJlIGVuZm9yY2VkLCB3ZSB3aWxsIGhh dmUgdG8gZmluZCBhIHdheSAoaG9wZWZ1bGx5IG5vdCBpbnZvbHZpbmcgZGljZSk8YnI+DQo8YnI+ DQpUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2s8YnI+DQpSYW1vbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471D4BA7SZXEMA512MBSchi_-- From nobody Thu May 21 01:58:33 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE99A1A8AE7 for ; Thu, 21 May 2015 01:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8uobMxL-gEy for ; Thu, 21 May 2015 01:58:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4A51A8971 for ; Thu, 21 May 2015 01:58:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWI57139; Thu, 21 May 2015 08:58:28 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 09:58:26 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.112]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Thu, 21 May 2015 16:57:02 +0800 From: Fatai Zhang To: Daniele Ceccarelli , Ramon Casellas , "Matt Hartley (mhartley)" , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgOPy3+AAH6zzgAAcq8DgAAELU+AAAAtmYAAHvHBgAAAx/qAAAAxLIAAEWQG4A== Date: Thu, 21 May 2015 08:57:02 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> <555D9543.7000608@cttc.es> <4A1562797D64E44993C5CBF38CF1BE481291DCEB@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481291DCEB@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CC4A91BSZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 08:58:33 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF85CC4A91BSZXEMA504MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KSSB3b3VsZCBsaWtlIHRvIHNoYXJlIHRoZSBleHBlcmllbmNlIGluIFJGQzcwNjIs IHdoaWNoIGFsc28gZGVzY3JpYmVzIGEgc2V0IG9mIHJlcXVpcm1lbnRzIGluIFNlY3Rpb24gNS4N CklmIG15IG1lbW9yeSBpcyBjb3JyZWN0LCBJIGFzIHRoZSBlZGl0b3Igb2YgUkZDNzA2MiB3YXMg YXNrZWQgYnkgTG91IChhcyB0aGUgQ0NBTVAgY2hhaXIgYXQgdGhhdCB0aW1lKSAgdG8gcmVtb3Zl IFJGQzIxMTkgbGFuZ3VhZ2UgZHVyaW5nIHRoZSBMQyBvZiB0aGlzIGRyYWZ0Lg0KSSB3b3VsZCBh bHNvIGxpa2UgdG8gaGVhciB0aGUgY29uZmlybWF0aW9uIGZyb20gQWRyaWFuIGFuZCBvdXIgQUQs IERlYm9yYWguDQoNCg0KQmVzdCBSZWdhcmRzDQoNCkZhdGFpDQoNCkZyb206IENDQU1QIFttYWls dG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbGUgQ2VjY2FyZWxs aQ0KU2VudDogVGh1cnNkYXksIE1heSAyMSwgMjAxNSA0OjI2IFBNDQpUbzogUmFtb24gQ2FzZWxs YXM7IE1hdHQgSGFydGxleSAobWhhcnRsZXkpOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAtZmxleGktZ3JpZC1md2st MDMgYW5kIGNhbGwgZm9yIHNoZXBlcmQNCg0KSGkgUmFtb24sDQoNCk5vIHdvcnJpZXMsIHRoZSBs YXN0IGNhbGwgY29tbWVudHMgY2FuIGJlIHNvbHZlZCBpbiB0d28gZGlmZmVyZW50IHZlcnNpb24s IHdlIGNhbiBzZW5kIHRoZSAtMDUgdG8gdGhlIElFU0cgKGlmIHRoZXJlIGFyZSBubyBtYWpvciBj aGFuZ2VzIGZyb20gLTAzIHRvIC0wNSkuDQoNClllcywgSeKAmWQgbGlrZSB0byBoZWFyIGZyb20g QWRyaWFuIG9uIHRoZSByZXF1aXJlbWVudHMgc2VjdGlvbi4NCg0KVGhhbmtzDQpEYW5pZWxlDQoN CkZyb206IFJhbW9uIENhc2VsbGFzIFttYWlsdG86cmFtb24uY2FzZWxsYXNAY3R0Yy5lc10NClNl bnQ6IGdpb3ZlZMOsIDIxIG1hZ2dpbyAyMDE1IDEwOjIwDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxp OyBNYXR0IEhhcnRsZXkgKG1oYXJ0bGV5KTsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYt Y2NhbXAtZmxleGktZ3JpZC1md2stMDMgYW5kIGNhbGwgZm9yIHNoZXBlcmQNCg0KRWwgMjEvMDUv MjAxNSBhIGxhcyA5OjU3LCBEYW5pZWxlIENlY2NhcmVsbGkgZXNjcmliacOzOg0KSGkgTWF0dCwg UmFtb24sDQoNClNpbmNlIEkgZm91bmQgbm8gY2xlYXIgc3RhdGVtZW50cyBvbiB0aGUgdXNhZ2Ug b2YgUkZDMjExOSBsYW5ndWFnZSB3aXRoIHJlc3BlY3QgdG8gdGhpcyBzaXR1YXRpb25zLCBJIGhh ZCBhIGxvb2sgYXQgZXhpc3RpbmcgZnJhbWV3b3JrIGFuZCByZXF1aXJlbWVudCBSRkNzIHRyeWlu ZyB0byBmaW5kIGEgY29tbW9uIFdvVy4gTXkgdGFrZSBpczoNCg0KDQoNCi0gICAgICAgIEZyYW1l d29yayBpcyBhbHdheXMgaW5mb3JtYXRpb25hbA0KDQotICAgICAgICBSZXF1aXJlbWVudHMgYXJl IGFsd2F5cyBpbmZvcm1hdGlvbmFsDQoNCi0gICAgICAgIFJGQzIxMTkgbGFuZ3VhZ2UgaXMgbm90 IGhvbW9nZW5lb3VzLiBTb21ldGltZXMgY2FwaXRhbCBsZXR0ZXJzIGFyZSB1c2VkIGFuZCBzb21l dGltZXMgbm90Lg0KDQpNeSBwcmVmZXJlbmNlIGlzIHRvIHVzZSBjYXBpdGFsIGxldHRlcnMgb25s eSB3aGVuIHByb3RvY29sIGJlaGF2aW9yIGlzIGRlZmluZWQsIG5vdCB3aGVuIHJlcXVpcmVtZW50 cyBmb3IgdGhlIGRlc2lnbiBvZiB0aGUgcHJvdG9jb2wgYXJlIGRlZmluZWQgKHRoaXMgaXMgaW4g bGluZSB3aXRoIGUuZy4gUkZDNzA2MiBhbmQgUkZDNjE2MykuDQpBcyBJIHNhaWQgdGhpcyBpcyBq dXN0IGEgcHJlZmVyZW5jZSwgYnV0IGlmIHRoZXJlIGlzIG5vIHJlYXNvbmFibGUgb2JqZWN0aW9u IEkgd291bGQgc3VnZ2VzdCBub3QgdG8gdXNlIGFueSBjYXBpdGFsIGxldHRlciBpbiB0aGUgZndr K3JlcSBkb2N1bWVudC4NCg0KSGkgRGFuaWVsZSwgYWxsDQoNCiBJIHdhcyBhbHNvIGNoZWNraW5n IGV4aXN0aW5nIFJGQ3MsIGFuZCBJTUhPOg0KLSBUaGUgZG9jdW1lbnQgY2FuIHN0YXkgaW5mb3Jt YXRpb25hbCwgaXQgaXMgbWFpbmx5IGZ3aytyZXFzLiBXZSBzZWVtIHRvIGFncmVlIG9uIHRoaXMu DQotIFdoaWxlIFJGQzIxMTkgc3RhdGVzICJJbiBtYW55IHN0YW5kYXJkcyB0cmFjayBkb2N1bWVu dHMgc2V2ZXJhbCB3b3JkcyBhcmUgdXNlZCB0byBzaWduaWZ5IHRoZSByZXF1aXJlbWVudHMgaW4g dGhlIHNwZWNpZmljYXRpb24iLCB0aGVyZSBzZWVtcyB0byAgYmUgKHNvbWU/KSBleGlzdGluZyBw cmFjdGljZSBvbiB1c2luZyBSRkMyMTE5IHdvcmRpbmcgaW4gcmVxcy9pbmZvIGRvY3VtZW50cywg aW5jbHVkaW5nIGNhcGl0YWxpemF0aW9uLg0KLSBVc2FnZSBvZiBSRkMyMTE5IGtleXdvcmRzIHNl ZW1zIHNjb3BlZCB0byB0aGUgc2VjdGlvbiBvbiByZXF1aXJlbWVudHMgaW4gdGhlIGRyYWZ0LiBJ dCBjb3VsZCBiZSBhcmd1ZWQgdGhhdCBkZWZpbmluZyByZXF1aXJlbWVudHMgaXMgdG8gc29tZSBl eHRlbnQgZGVmaW5pbmcgaGlnaCBsZXZlbCBwcm90b2NvbCBiZWhhdmlvciA6KQ0KDQpJSVJDIEFk cmlhbiBhdXRob3JlZCBhIHNpZ25pZmljYW50IHBhcnQgb2YgdGhlIHNlY3Rpb24sIGFueSB2aWV3 cz8NCg0KVGhhdCBzYWlkLCAtMDUgbmVlZHMgdG8gYmUgdXBsb2FkZWQgYW55d2F5IHRvIHJlZmxl Y3QgdGhlIG5ldyBpbmZvLW1vZGVsICh0aGFua3MgSm9uYXMhKSAsIGl0IGlzIG5vdCBnYW1lLWNo YW5naW5nIHRvIGNoYW5nZSB0byBhY29tb2RhdGUgd2hhdCB5b3Ugc3VnZ2VzdC4gV2UgY291bGQg cmVtb3ZlIFJGQzIxMTkgcmVmZXJlbmNlLCB0aGUgYm9pbGVycGxhdGUgdGV4dCBhbmQgcmUtdmlz aXQgdGhlIHNlY3Rpb25zLCBtYWlubHkgdXNpbmcgbG93ZXJjYXNlLg0KDQpUaGFua3MNClIuDQo= --_000_F82A4B6D50F9464B8EBA55651F541CF85CC4A91BSZXEMA504MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIjsNCglwYW5vc2Ut MToyIDUgNiA0IDUgNSA1IDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpoMQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAxIENoYXIiOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsN CgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwi c2VyaWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0eWxlIiwic2VyaWYi Ow0KCWNvbG9yOiM2MzI0MjM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSGVhZGluZzFDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2MzMyNTc0MTsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjAxMTg4MjY5 NCA0NzY4OTc2MjQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2Vy aWYiO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlmIjt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGgxPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtmb250LXdlaWdodDpub3JtYWwi Pkkgd291bGQgbGlrZSB0byBzaGFyZSB0aGUgZXhwZXJpZW5jZSBpbiBSRkM3MDYyLCB3aGljaCBh bHNvIGRlc2NyaWJlcyBhIHNldCBvZiByZXF1aXJtZW50cyBpbiBTZWN0aW9uIDUuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L2gxPg0KPGgxPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDtmb250LXdlaWdodDpub3JtYWwiPklmIG15IG1lbW9yeSBpcyBj b3JyZWN0LCBJIGFzIHRoZSBlZGl0b3Igb2YgUkZDNzA2MiB3YXMgYXNrZWQgYnkgTG91IChhcyB0 aGUgQ0NBTVAgY2hhaXIgYXQgdGhhdCB0aW1lKSAmbmJzcDt0byByZW1vdmUgUkZDMjExOSBsYW5n dWFnZSBkdXJpbmcgdGhlDQogTEMgb2YgdGhpcyBkcmFmdC4gPG86cD48L286cD48L3NwYW4+PC9o MT4NCjxoMT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7Zm9udC13ZWlnaHQ6bm9ybWFsIj5JIHdvdWxkIGFsc28gbGlrZSB0byBoZWFyIHRoZSBj b25maXJtYXRpb24gZnJvbSBBZHJpYW4gYW5kIG91ciBBRCwgRGVib3JhaC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvaDE+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3Rp Znk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQt anVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1 c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5Omlu dGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5GYXRhaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+RGFuaWVsZSBDZWNjYXJlbGxpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBN YXkgMjEsIDIwMTUgNDoyNiBQTTxicj4NCjxiPlRvOjwvYj4gUmFtb24gQ2FzZWxsYXM7IE1hdHQg SGFydGxleSAobWhhcnRsZXkpOyBjY2FtcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0NDQU1QXSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1jY2FtcC1mbGV4aS1ncmlkLWZ3 ay0wMyBhbmQgY2FsbCBmb3Igc2hlcGVyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSYW1vbiw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm8gd29ycmllcywgdGhlIGxhc3QgY2FsbCBj b21tZW50cyBjYW4gYmUgc29sdmVkIGluIHR3byBkaWZmZXJlbnQgdmVyc2lvbiwgd2UgY2FuIHNl bmQgdGhlIC0wNSB0byB0aGUgSUVTRyAoaWYgdGhlcmUgYXJlIG5vIG1ham9yIGNoYW5nZXMgZnJv bQ0KIC0wMyB0byAtMDUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMs IEnigJlkIGxpa2UgdG8gaGVhciBmcm9tIEFkcmlhbiBvbiB0aGUgcmVxdWlyZW1lbnRzIHNlY3Rp b24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW5pZWxlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBSYW1vbiBDYXNl bGxhcyBbPGEgaHJlZj0ibWFpbHRvOnJhbW9uLmNhc2VsbGFzQGN0dGMuZXMiPm1haWx0bzpyYW1v bi5jYXNlbGxhc0BjdHRjLmVzPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBnaW92ZWTDrCAyMSBt YWdnaW8gMjAxNSAxMDoyMDxicj4NCjxiPlRvOjwvYj4gRGFuaWVsZSBDZWNjYXJlbGxpOyBNYXR0 IEhhcnRsZXkgKG1oYXJ0bGV5KTsgPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj4NCmNj YW1wQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NDQU1QXSBXRyBMYXN0 IENhbGwgb24gZHJhZnQtaWV0Zi1jY2FtcC1mbGV4aS1ncmlkLWZ3ay0wMyBhbmQgY2FsbCBmb3Ig c2hlcGVyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5FbCAyMS8w NS8yMDE1IGEgbGFzIDk6NTcsIERhbmllbGUgQ2VjY2FyZWxsaSBlc2NyaWJpw7M6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWF0dCwgUmFt b24sPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaW5jZSBJIGZvdW5kIG5vIGNsZWFy IHN0YXRlbWVudHMgb24gdGhlIHVzYWdlIG9mIFJGQzIxMTkgbGFuZ3VhZ2Ugd2l0aCByZXNwZWN0 IHRvIHRoaXMgc2l0dWF0aW9ucywgSSBoYWQgYSBsb29rIGF0IGV4aXN0aW5nIGZyYW1ld29yayBh bmQgcmVxdWlyZW1lbnQNCiBSRkNzIHRyeWluZyB0byBmaW5kIGEgY29tbW9uIFdvVy4gTXkgdGFr ZSBpczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GcmFtZXdvcmsgaXMgYWx3YXlzIGluZm9ybWF0aW9uYWw8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVxdWlyZW1l bnRzIGFyZSBhbHdheXMgaW5mb3JtYXRpb25hbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SRkMyMTE5IGxhbmd1YWdlIGlzIG5vdCBob21vZ2VuZW91cy4g U29tZXRpbWVzIGNhcGl0YWwgbGV0dGVycyBhcmUgdXNlZCBhbmQgc29tZXRpbWVzIG5vdC48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHByZWZlcmVuY2UgaXMgdG8gdXNlIGNhcGl0 YWwgbGV0dGVycyBvbmx5IHdoZW4gcHJvdG9jb2wgYmVoYXZpb3IgaXMgZGVmaW5lZCwgbm90IHdo ZW4gcmVxdWlyZW1lbnRzIGZvciB0aGUgZGVzaWduIG9mIHRoZSBwcm90b2NvbCBhcmUgZGVmaW5l ZA0KICh0aGlzIGlzIGluIGxpbmUgd2l0aCBlLmcuIFJGQzcwNjIgYW5kIFJGQzYxNjMpLiA8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QXMgSSBzYWlkIHRoaXMgaXMganVzdCBhIHByZWZlcmVuY2UsIGJ1dCBpZiB0aGVy ZSBpcyBubyByZWFzb25hYmxlIG9iamVjdGlvbiBJIHdvdWxkIHN1Z2dlc3Qgbm90IHRvIHVzZSBh bnkgY2FwaXRhbCBsZXR0ZXIgaW4gdGhlIGZ3ayYjNDM7cmVxIGRvY3VtZW50Ljwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I aSBEYW5pZWxlLCBhbGw8YnI+DQo8YnI+DQombmJzcDtJIHdhcyBhbHNvIGNoZWNraW5nIGV4aXN0 aW5nIFJGQ3MsIGFuZCBJTUhPOjxicj4NCi0gVGhlIGRvY3VtZW50IGNhbiBzdGF5IGluZm9ybWF0 aW9uYWwsIGl0IGlzIG1haW5seSBmd2smIzQzO3JlcXMuIFdlIHNlZW0gdG8gYWdyZWUgb24gdGhp cy48YnI+DQotIFdoaWxlIFJGQzIxMTkgc3RhdGVzICZxdW90O0luIG1hbnkgc3RhbmRhcmRzIHRy YWNrIGRvY3VtZW50cyBzZXZlcmFsIHdvcmRzIGFyZSB1c2VkIHRvIHNpZ25pZnkgdGhlIHJlcXVp cmVtZW50cyBpbiB0aGUgc3BlY2lmaWNhdGlvbiZxdW90OywgdGhlcmUgc2VlbXMgdG8mbmJzcDsg YmUgKHNvbWU/KSBleGlzdGluZyBwcmFjdGljZSBvbiB1c2luZyBSRkMyMTE5IHdvcmRpbmcgaW4g cmVxcy9pbmZvIGRvY3VtZW50cywgaW5jbHVkaW5nIGNhcGl0YWxpemF0aW9uLjxicj4NCi0gVXNh Z2Ugb2YgUkZDMjExOSBrZXl3b3JkcyBzZWVtcyBzY29wZWQgdG8gdGhlIHNlY3Rpb24gb24gcmVx dWlyZW1lbnRzIGluIHRoZSBkcmFmdC4gSXQgY291bGQgYmUgYXJndWVkIHRoYXQgZGVmaW5pbmcg cmVxdWlyZW1lbnRzIGlzIHRvIHNvbWUgZXh0ZW50IGRlZmluaW5nIGhpZ2ggbGV2ZWwgcHJvdG9j b2wgYmVoYXZpb3IgOik8YnI+DQo8YnI+DQpJSVJDIEFkcmlhbiBhdXRob3JlZCBhIHNpZ25pZmlj YW50IHBhcnQgb2YgdGhlIHNlY3Rpb24sIGFueSB2aWV3cz88YnI+DQo8YnI+DQpUaGF0IHNhaWQs IC0wNSBuZWVkcyB0byBiZSB1cGxvYWRlZCBhbnl3YXkgdG8gcmVmbGVjdCB0aGUgbmV3IGluZm8t bW9kZWwgKHRoYW5rcyBKb25hcyEpICwgaXQgaXMgbm90IGdhbWUtY2hhbmdpbmcgdG8gY2hhbmdl IHRvIGFjb21vZGF0ZSB3aGF0IHlvdSBzdWdnZXN0LiBXZSBjb3VsZCByZW1vdmUgUkZDMjExOSBy ZWZlcmVuY2UsIHRoZSBib2lsZXJwbGF0ZSB0ZXh0IGFuZCByZS12aXNpdCB0aGUgc2VjdGlvbnMs IG1haW5seSB1c2luZyBsb3dlcmNhc2UuPGJyPg0KPGJyPg0KVGhhbmtzPGJyPg0KUi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F82A4B6D50F9464B8EBA55651F541CF85CC4A91BSZXEMA504MBSchi_-- From nobody Thu May 21 05:40:23 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD47E1AD33F for ; Thu, 21 May 2015 05:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sre_bk7rwe6Y for ; Thu, 21 May 2015 05:40:20 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id A57191AD333 for ; Thu, 21 May 2015 05:40:20 -0700 (PDT) Received: (qmail 17676 invoked by uid 0); 21 May 2015 12:40:20 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 21 May 2015 12:40:20 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id WiZM1q0092SSUrH01iZQsM; Thu, 21 May 2015 12:33:28 -0600 X-Authority-Analysis: v=2.1 cv=d9Vml3TE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=d8zPNJv4eCMA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=g7Xe4o7xjiXMUuvHxMkA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=HcDTe+ND74YRE0Dg52fhCixrSMRncYkFcDZhSRVbzbM=; b=qa93yYP8Nd3KXGVOyxi2a+pNO4J7sa34a46RfIN88SZZ5TFiALtFU5XluFBZWZ2Mwid7nU0rr5AYpYBYy3Ci20UlunhjS4PIpihXnItq+GdeKpR6IIDK3YDSTgXd571N; Received: from box313.bluehost.com ([69.89.31.113]:49490 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YvPll-0003Ae-Ai; Thu, 21 May 2015 06:40:13 -0600 Message-ID: <555DD22A.3030902@labn.net> Date: Thu, 21 May 2015 08:40:10 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Fatai Zhang , Daniele Ceccarelli , Ramon Casellas , "Matt Hartley (mhartley)" , "ccamp@ietf.org" References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> <555D9543.7000608@cttc.es> <4A1562797D64E44993C5CBF38CF1BE481291DCEB@ESESSMB301.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 12:40:22 -0000 On 05/21/2015 04:57 AM, Fatai Zhang wrote: > Hi all, > > > I would like to share the experience in RFC7062, which also describes > a set of requirments in Section 5. > > > If my memory is correct, I as the editor of RFC7062 was asked by Lou > (as the CCAMP chair at that time) to remove RFC2119 language during > the LC of this draft. Sounds right. In general RFC 2119 conformance language is only appropriate when discussing things that can impact interoperability, formats and behavior "on the wire". This is a general rule, and their are exceptions... Lou > > > I would also like to hear the confirmation from Adrian and our AD, > Deborah. > > > > > > Best Regards > > > > Fatai > > > > *From:*CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Daniele > Ceccarelli > *Sent:* Thursday, May 21, 2015 4:26 PM > *To:* Ramon Casellas; Matt Hartley (mhartley); ccamp@ietf.org > *Subject:* Re: [CCAMP] WG Last Call on > draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd > > > > Hi Ramon, > > > > No worries, the last call comments can be solved in two different > version, we can send the -05 to the IESG (if there are no major changes > from -03 to -05). > > > > Yes, I’d like to hear from Adrian on the requirements section. > > > > Thanks > > Daniele > > > > *From:*Ramon Casellas [mailto:ramon.casellas@cttc.es] > *Sent:* giovedì 21 maggio 2015 10:20 > *To:* Daniele Ceccarelli; Matt Hartley (mhartley); ccamp@ietf.org > > *Subject:* Re: [CCAMP] WG Last Call on > draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd > > > > El 21/05/2015 a las 9:57, Daniele Ceccarelli escribió: > > Hi Matt, Ramon, > > > > Since I found no clear statements on the usage of RFC2119 language > with respect to this situations, I had a look at existing framework > and requirement RFCs trying to find a common WoW. My take is: > > > > - Framework is always informational > > - Requirements are always informational > > - RFC2119 language is not homogeneous. Sometimes capital > letters are used and sometimes not. > > > > My preference is to use capital letters only when protocol behavior > is defined, not when requirements for the design of the protocol are > defined (this is in line with e.g. RFC7062 and RFC6163). > > As I said this is just a preference, but if there is no reasonable > objection I would suggest not to use any capital letter in the > fwk+req document. > > > > Hi Daniele, all > > I was also checking existing RFCs, and IMHO: > - The document can stay informational, it is mainly fwk+reqs. We seem to > agree on this. > - While RFC2119 states "In many standards track documents several words > are used to signify the requirements in the specification", there seems > to be (some?) existing practice on using RFC2119 wording in reqs/info > documents, including capitalization. > - Usage of RFC2119 keywords seems scoped to the section on requirements > in the draft. It could be argued that defining requirements is to some > extent defining high level protocol behavior :) > > IIRC Adrian authored a significant part of the section, any views? > > That said, -05 needs to be uploaded anyway to reflect the new info-model > (thanks Jonas!) , it is not game-changing to change to acomodate what > you suggest. We could remove RFC2119 reference, the boilerplate text and > re-visit the sections, mainly using lowercase. > > Thanks > R. > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From nobody Thu May 21 08:34:11 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C43E1A887A for ; Thu, 21 May 2015 08:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wdfhgweQOGN for ; Thu, 21 May 2015 08:34:07 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB951A88CA for ; Thu, 21 May 2015 08:34:01 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4LFX5gm028568; Thu, 21 May 2015 16:33:05 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4LFX4WH028486 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 16:33:04 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'Fatai Zhang'" , "'Daniele Ceccarelli'" , "'Ramon Casellas'" , "'Matt Hartley \(mhartley\)'" , References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> <555D9543.7000608@cttc.es> <4A1562797D64E44993C5CBF38CF1BE481291DCEB@ESESSMB301.ericsson.se> <555DD22A.3030902@labn.net> In-Reply-To: <555DD22A.3030902@labn.net> Date: Thu, 21 May 2015 16:33:03 +0100 Message-ID: <00ea01d093db$6e158790$4a4096b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEJ8z7OtFL3qSQ0EA1ynidDf4RrAgIffr/OAqJ+OxgBlpoUkwEKaZ+CAlSAPIsA8sCTRAH+B62XAaGb24kB4618vAGSNS+ynoXOtCA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21560.000 X-TM-AS-Result: No--29.674-10.0-31-10 X-imss-scan-details: No--29.674-10.0-31-10 X-TMASE-MatchedRID: x2HXvaraFokwJ6xbTjBa5samcgjprEPzbv16+gil4jcwplGJ7NxS0/K8 Mm1/oHIxt1mOTd3gWROcFzBKTpa3/lq/w+Qp55pkQr2qXCJMSV/FphRdtkn03pCngwEFj8IxE7I u9Rs4SLhoVMBch8rEm8swrEghLf6doDo1e3A5Z1Xx5KZMlKYS/ZLcb1TGljGwtXl9IxEPXOq+zM 8YQoXubM3DBOwul+3LN5PbzyayxNQxly0V6hjlMBLuW4a3q2WGMVx/3ZYby7+CsBeCv8CM/Y7Ht fuH0O7rEv0kmovGJce88HWbIlfkg9GUhjH1DfU2SEQN/D/3cG7HeXKrbMIpAIm19K09MS2Nz7Jr a7lTvbEVlsvFGmNosZVDJnQfIYk+wV5ZD2sQLdVoMLOoNHsM9nnL427v8Q469YBezwhBfW6wQli WBbE2aePuvJMVlqsEERnQCcQN8oKqMZyz/RcGLgXysW33GYMpM3PBQtDBME/gT7/U3eRk3x/XWB LkU7fuztKbHse/QEdUf7lcX/v7VjQYriqcplwN/bxP0FQ1eSHDHSNFHFxB8zLZyQk29Rf44Hw51 6InYmqoWUvc+GVnUJYlxuk1ogQAq9wA+ttQocyeAiCmPx4NwGNn8XPiALIb+gD2vYtOFhgqtq5d 3cxkNQP90fJP9eHt Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:34:09 -0000 I'm not going to get excited about this. I was pretty much OK with Standards Track in -03. I thought that the = document told folk how build a network as well as setting the requirements. So in = -03 the 2119 language was fine, IMHO. However, if we want to go Informational I also don't mind. Clearly 2119 = language is less relevant in an informational document, although I often find it = is helpful in requirements specs to clarify the requirements. I have = handled this in the past by using a variation of the 2119 boilerplate such as in = section 2 of https://www.rfc-editor.org/rfc/rfc5862.txt (completely random example). But I really, really don't care. path of least resistance to raid = publication, please. Adrian > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 21 May 2015 13:40 > To: Fatai Zhang; Daniele Ceccarelli; Ramon Casellas; Matt Hartley = (mhartley); > ccamp@ietf.org > Subject: Re: [CCAMP] WG Last Call on = draft-ietf-ccamp-flexi-grid-fwk-03 and call > for sheperd >=20 >=20 >=20 > On 05/21/2015 04:57 AM, Fatai Zhang wrote: > > Hi all, > > > > > > I would like to share the experience in RFC7062, which also = describes > > a set of requirments in Section 5. > > > > > > If my memory is correct, I as the editor of RFC7062 was asked by = Lou > > (as the CCAMP chair at that time) to remove RFC2119 language = during > > the LC of this draft. >=20 > Sounds right. In general RFC 2119 conformance language is only > appropriate when discussing things that can impact interoperability, > formats and behavior "on the wire". This is a general rule, and their > are exceptions... >=20 > Lou >=20 > > > > > > I would also like to hear the confirmation from Adrian and our AD, > > Deborah. > > > > > > > > > > > > Best Regards > > > > > > > > Fatai > > > > > > > > *From:*CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Daniele > > Ceccarelli > > *Sent:* Thursday, May 21, 2015 4:26 PM > > *To:* Ramon Casellas; Matt Hartley (mhartley); ccamp@ietf.org > > *Subject:* Re: [CCAMP] WG Last Call on > > draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd > > > > > > > > Hi Ramon, > > > > > > > > No worries, the last call comments can be solved in two different > > version, we can send the -05 to the IESG (if there are no major = changes > > from -03 to -05). > > > > > > > > Yes, I=92d like to hear from Adrian on the requirements section. > > > > > > > > Thanks > > > > Daniele > > > > > > > > *From:*Ramon Casellas [mailto:ramon.casellas@cttc.es] > > *Sent:* gioved=EC 21 maggio 2015 10:20 > > *To:* Daniele Ceccarelli; Matt Hartley (mhartley); ccamp@ietf.org > > > > *Subject:* Re: [CCAMP] WG Last Call on > > draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd > > > > > > > > El 21/05/2015 a las 9:57, Daniele Ceccarelli escribi=F3: > > > > Hi Matt, Ramon, > > > > > > > > Since I found no clear statements on the usage of RFC2119 = language > > with respect to this situations, I had a look at existing = framework > > and requirement RFCs trying to find a common WoW. My take is: > > > > > > > > - Framework is always informational > > > > - Requirements are always informational > > > > - RFC2119 language is not homogeneous. Sometimes capital > > letters are used and sometimes not. > > > > > > > > My preference is to use capital letters only when protocol = behavior > > is defined, not when requirements for the design of the protocol = are > > defined (this is in line with e.g. RFC7062 and RFC6163). > > > > As I said this is just a preference, but if there is no = reasonable > > objection I would suggest not to use any capital letter in the > > fwk+req document. > > > > > > > > Hi Daniele, all > > > > I was also checking existing RFCs, and IMHO: > > - The document can stay informational, it is mainly fwk+reqs. We = seem to > > agree on this. > > - While RFC2119 states "In many standards track documents several = words > > are used to signify the requirements in the specification", there = seems > > to be (some?) existing practice on using RFC2119 wording in = reqs/info > > documents, including capitalization. > > - Usage of RFC2119 keywords seems scoped to the section on = requirements > > in the draft. It could be argued that defining requirements is to = some > > extent defining high level protocol behavior :) > > > > IIRC Adrian authored a significant part of the section, any views? > > > > That said, -05 needs to be uploaded anyway to reflect the new = info-model > > (thanks Jonas!) , it is not game-changing to change to acomodate = what > > you suggest. We could remove RFC2119 reference, the boilerplate text = and > > re-visit the sections, mainly using lowercase. > > > > Thanks > > R. > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From nobody Thu May 21 08:43:11 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE6F1A8836 for ; Thu, 21 May 2015 08:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xVnAN6siD5E for ; Thu, 21 May 2015 08:43:09 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B111A882B for ; Thu, 21 May 2015 08:43:05 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 90dfd555.2b146022c940.1423658.00-2424.3878776.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 21 May 2015 15:43:05 +0000 (UTC) X-MXL-Hash: 555dfd092c6157e3-51bc7455108f77d9536e007d80ad484d4fce5af9 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 80dfd555.0.1423618.00-2211.3878704.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 21 May 2015 15:43:04 +0000 (UTC) X-MXL-Hash: 555dfd083856c27c-31f2d6dbcefd3c13c472a52fe14aeb8571c4989d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4LFh1G8031584; Thu, 21 May 2015 11:43:02 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4LFgalk031138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 May 2015 11:42:54 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 21 May 2015 15:42:23 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.196]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0224.002; Thu, 21 May 2015 11:42:22 -0400 From: "BRUNGARD, DEBORAH A" To: Lou Berger , Fatai Zhang , Daniele Ceccarelli , Ramon Casellas , "Matt Hartley (mhartley)" , "ccamp@ietf.org" Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgOo8MyAAH6zzgAAcq8EgAAELU6AAAAtmYAAHvHCgAAAx/mAAAAxLIAAARcaAAAHyvcAAANGhoA= Date: Thu, 21 May 2015 15:42:22 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> <555D9543.7000608@cttc.es> <4A1562797D64E44993C5CBF38CF1BE481291DCEB@ESESSMB301.ericsson.se> <555DD22A.3030902@labn.net> In-Reply-To: <555DD22A.3030902@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.129.42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=RJUE6fe+ c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=nmaf2ELyxPYA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=h1PgugrvaO0A:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=HLomeh1Sbdcg3P-j88cA:9 a=wPNLvfGTeEIA:10 a=EX4pE2C] X-AnalysisOut: [UxJbtMUsj:21 a=gWM4PrAZdUdc5eYD:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:43:11 -0000 Hi all, There is no "correct way" as you all have noted. Quickly looking at example= s, when we did RFC4139, we did use RFC2119 language but that was important = as it was reflecting ITU-T requirements. It's really up to the working grou= p. Reading the draft, I don't see an overuse of it, and the authors seem to= have thought carefully on it. So it may help as start doing the protocol w= ork. So...it really is up to you. If keep, you may want to put a couple of sente= nces as in RFC4139 (section 2) on the use of RFC2119 language in an informa= tional document. On another comment - you do need to have only 5 names on the front page. Th= ere are many ways to do it (e.g. only have the editor(s) on the front page)= . Thanks, Deborah -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Thursday, May 21, 2015 8:40 AM To: Fatai Zhang; Daniele Ceccarelli; Ramon Casellas; Matt Hartley (mhartley= ); ccamp@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and= call for sheperd On 05/21/2015 04:57 AM, Fatai Zhang wrote: > Hi all, >=20 >=20 > I would like to share the experience in RFC7062, which also describes > a set of requirments in Section 5. >=20 >=20 > If my memory is correct, I as the editor of RFC7062 was asked by Lou > (as the CCAMP chair at that time) to remove RFC2119 language during > the LC of this draft. Sounds right. In general RFC 2119 conformance language is only appropriate when discussing things that can impact interoperability, formats and behavior "on the wire". This is a general rule, and their are exceptions... Lou >=20 >=20 > I would also like to hear the confirmation from Adrian and our AD, > Deborah. >=20 > =20 >=20 > =20 >=20 > Best Regards >=20 > =20 >=20 > Fatai >=20 > =20 >=20 > *From:*CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Daniele > Ceccarelli > *Sent:* Thursday, May 21, 2015 4:26 PM > *To:* Ramon Casellas; Matt Hartley (mhartley); ccamp@ietf.org > *Subject:* Re: [CCAMP] WG Last Call on > draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd >=20 > =20 >=20 > Hi Ramon, >=20 > =20 >=20 > No worries, the last call comments can be solved in two different > version, we can send the -05 to the IESG (if there are no major changes > from -03 to -05). >=20 > =20 >=20 > Yes, I'd like to hear from Adrian on the requirements section. >=20 > =20 >=20 > Thanks >=20 > Daniele >=20 > =20 >=20 > *From:*Ramon Casellas [mailto:ramon.casellas@cttc.es] > *Sent:* gioved=EC 21 maggio 2015 10:20 > *To:* Daniele Ceccarelli; Matt Hartley (mhartley); ccamp@ietf.org > > *Subject:* Re: [CCAMP] WG Last Call on > draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd >=20 > =20 >=20 > El 21/05/2015 a las 9:57, Daniele Ceccarelli escribi=F3: >=20 > Hi Matt, Ramon, >=20 > =20 >=20 > Since I found no clear statements on the usage of RFC2119 language > with respect to this situations, I had a look at existing framework > and requirement RFCs trying to find a common WoW. My take is: >=20 > =20 >=20 > - Framework is always informational >=20 > - Requirements are always informational >=20 > - RFC2119 language is not homogeneous. Sometimes capital > letters are used and sometimes not. >=20 > =20 >=20 > My preference is to use capital letters only when protocol behavior > is defined, not when requirements for the design of the protocol are > defined (this is in line with e.g. RFC7062 and RFC6163). >=20 > As I said this is just a preference, but if there is no reasonable > objection I would suggest not to use any capital letter in the > fwk+req document. >=20 > =20 >=20 > Hi Daniele, all >=20 > I was also checking existing RFCs, and IMHO: > - The document can stay informational, it is mainly fwk+reqs. We seem to > agree on this. > - While RFC2119 states "In many standards track documents several words > are used to signify the requirements in the specification", there seems > to be (some?) existing practice on using RFC2119 wording in reqs/info > documents, including capitalization. > - Usage of RFC2119 keywords seems scoped to the section on requirements > in the draft. It could be argued that defining requirements is to some > extent defining high level protocol behavior :) >=20 > IIRC Adrian authored a significant part of the section, any views? >=20 > That said, -05 needs to be uploaded anyway to reflect the new info-model > (thanks Jonas!) , it is not game-changing to change to acomodate what > you suggest. We could remove RFC2119 reference, the boilerplate text and > re-visit the sections, mainly using lowercase. >=20 > Thanks > R. >=20 >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Thu May 21 08:51:28 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745131B29DA for ; Thu, 21 May 2015 08:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGptLmLHc_fS for ; Thu, 21 May 2015 08:51:17 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 61AE11B29D7 for ; Thu, 21 May 2015 08:51:17 -0700 (PDT) Received: (qmail 18992 invoked by uid 0); 21 May 2015 15:51:14 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 21 May 2015 15:51:14 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id WlkG1q0032SSUrH01lkKcS; Thu, 21 May 2015 15:44:21 -0600 X-Authority-Analysis: v=2.1 cv=d9Vml3TE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=d8zPNJv4eCMA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=h1PgugrvaO0A:10 a=BqEg4_3jAAAA:8 a=48vgC7mUAAAA:8 a=huzfeuSKuB5QVkHpO8MA:9 a=Wc46lIqdnKPZ7jd4:21 a=ShSGaEGXtYkjdMpc:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=TsHyupJ2gwnD0Bg/CkSvO8mc2OhjFqvPkM1Me0S2ry8=; b=JR/GmkFLQixNAn6OJXsTpD67eo8NmT5JPnaapdiCCOZDKcyqyf7JPHtCoD7Fd1QDBfyg4Ay7TbqzQ41HBl1SyBLBPItw1sdoDZRK3DRxX60oz7WO7LMG9KHHLgO0QXuz; Received: from box313.bluehost.com ([69.89.31.113]:33374 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YvSkW-0005Bg-94; Thu, 21 May 2015 09:51:08 -0600 Message-ID: <555DFEE9.3060208@labn.net> Date: Thu, 21 May 2015 11:51:05 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Fatai Zhang' , 'Daniele Ceccarelli' , 'Ramon Casellas' , "'Matt Hartley (mhartley)'" , ccamp@ietf.org References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> <555D9543.7000608@cttc.es> <4A1562797D64E44993C5CBF38CF1BE481291DCEB@ESESSMB301.ericsson.se> <555DD22A.3030902@labn.net> <00ea01d093db$6e158790$4a4096b0$@olddog.co.uk> In-Reply-To: <00ea01d093db$6e158790$4a4096b0$@olddog.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:51:23 -0000 I don't have a strong opinion on this either way for this draft. My statement was WRT Fatai's comment on RFC7062 and the general usage of 2119 language. Lou On 05/21/2015 11:33 AM, Adrian Farrel wrote: > I'm not going to get excited about this. > > I was pretty much OK with Standards Track in -03. I thought that the document > told folk how build a network as well as setting the requirements. So in -03 the > 2119 language was fine, IMHO. > > However, if we want to go Informational I also don't mind. Clearly 2119 language > is less relevant in an informational document, although I often find it is > helpful in requirements specs to clarify the requirements. I have handled this > in the past by using a variation of the 2119 boilerplate such as in section 2 of > https://www.rfc-editor.org/rfc/rfc5862.txt (completely random example). > > But I really, really don't care. path of least resistance to raid publication, > please. > > Adrian > > >> -----Original Message----- >> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: 21 May 2015 13:40 >> To: Fatai Zhang; Daniele Ceccarelli; Ramon Casellas; Matt Hartley (mhartley); >> ccamp@ietf.org >> Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and > call >> for sheperd >> >> >> >> On 05/21/2015 04:57 AM, Fatai Zhang wrote: >>> Hi all, >>> >>> >>> I would like to share the experience in RFC7062, which also describes >>> a set of requirments in Section 5. >>> >>> >>> If my memory is correct, I as the editor of RFC7062 was asked by Lou >>> (as the CCAMP chair at that time) to remove RFC2119 language during >>> the LC of this draft. >> >> Sounds right. In general RFC 2119 conformance language is only >> appropriate when discussing things that can impact interoperability, >> formats and behavior "on the wire". This is a general rule, and their >> are exceptions... >> >> Lou >> >>> >>> >>> I would also like to hear the confirmation from Adrian and our AD, >>> Deborah. >>> >>> >>> >>> >>> >>> Best Regards >>> >>> >>> >>> Fatai >>> >>> >>> >>> *From:*CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Daniele >>> Ceccarelli >>> *Sent:* Thursday, May 21, 2015 4:26 PM >>> *To:* Ramon Casellas; Matt Hartley (mhartley); ccamp@ietf.org >>> *Subject:* Re: [CCAMP] WG Last Call on >>> draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd >>> >>> >>> >>> Hi Ramon, >>> >>> >>> >>> No worries, the last call comments can be solved in two different >>> version, we can send the -05 to the IESG (if there are no major changes >>> from -03 to -05). >>> >>> >>> >>> Yes, I’d like to hear from Adrian on the requirements section. >>> >>> >>> >>> Thanks >>> >>> Daniele >>> >>> >>> >>> *From:*Ramon Casellas [mailto:ramon.casellas@cttc.es] >>> *Sent:* giovedì 21 maggio 2015 10:20 >>> *To:* Daniele Ceccarelli; Matt Hartley (mhartley); ccamp@ietf.org >>> >>> *Subject:* Re: [CCAMP] WG Last Call on >>> draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd >>> >>> >>> >>> El 21/05/2015 a las 9:57, Daniele Ceccarelli escribió: >>> >>> Hi Matt, Ramon, >>> >>> >>> >>> Since I found no clear statements on the usage of RFC2119 language >>> with respect to this situations, I had a look at existing framework >>> and requirement RFCs trying to find a common WoW. My take is: >>> >>> >>> >>> - Framework is always informational >>> >>> - Requirements are always informational >>> >>> - RFC2119 language is not homogeneous. Sometimes capital >>> letters are used and sometimes not. >>> >>> >>> >>> My preference is to use capital letters only when protocol behavior >>> is defined, not when requirements for the design of the protocol are >>> defined (this is in line with e.g. RFC7062 and RFC6163). >>> >>> As I said this is just a preference, but if there is no reasonable >>> objection I would suggest not to use any capital letter in the >>> fwk+req document. >>> >>> >>> >>> Hi Daniele, all >>> >>> I was also checking existing RFCs, and IMHO: >>> - The document can stay informational, it is mainly fwk+reqs. We seem to >>> agree on this. >>> - While RFC2119 states "In many standards track documents several words >>> are used to signify the requirements in the specification", there seems >>> to be (some?) existing practice on using RFC2119 wording in reqs/info >>> documents, including capitalization. >>> - Usage of RFC2119 keywords seems scoped to the section on requirements >>> in the draft. It could be argued that defining requirements is to some >>> extent defining high level protocol behavior :) >>> >>> IIRC Adrian authored a significant part of the section, any views? >>> >>> That said, -05 needs to be uploaded anyway to reflect the new info-model >>> (thanks Jonas!) , it is not game-changing to change to acomodate what >>> you suggest. We could remove RFC2119 reference, the boilerplate text and >>> re-visit the sections, mainly using lowercase. >>> >>> Thanks >>> R. >>> >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > From nobody Thu May 21 12:08:49 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138201A889D for ; Thu, 21 May 2015 12:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEYYkq4KGPJ4 for ; Thu, 21 May 2015 12:08:46 -0700 (PDT) Received: from villa.puc.rediris.es (villa.puc.rediris.es [IPv6:2001:720:418:ca00::7]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319E81A884F for ; Thu, 21 May 2015 12:08:45 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YvVpW-0007QF-2u; Thu, 21 May 2015 21:08:33 +0200 Received: from [192.168.1.200] (81.61.180.55.dyn.user.ono.com [81.61.180.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id A4CDE1FD05; Thu, 21 May 2015 21:08:27 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <555E2D2B.50107@cttc.es> Date: Thu, 21 May 2015 21:08:27 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lou Berger , adrian@olddog.co.uk, 'Fatai Zhang' , 'Daniele Ceccarelli' , "'Matt Hartley (mhartley)'" , ccamp@ietf.org References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <55564F37.7010203@labn.net> <5559A180.8090504@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA28E0@xmb-rcd-x03.cisco.com> <555CBF29.3070305@cttc.es> <9D50FCE7413E3D4EA5E42331115FB5BC29CA2DBE@xmb-rcd-x03.cisco.com> <4A1562797D64E44993C5CBF38CF1BE481291DBE5@ESESSMB301.ericsson.se> <555D9543.7000608@cttc.es> <4A1562797D64E44993C5CBF38CF1BE481291DCEB@ESESSMB301.ericsson.se> <555DD22A.3030902@labn.net> <00ea01d093db$6e158790$4a4096b0$@olddog.co.uk> <555DFEE9.3060208@labn.net> In-Reply-To: <555DFEE9.3060208@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -1.0 (-) X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ietf.org] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% [score: 0.1052] Archived-At: Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:08:49 -0000 All Thank you very much for stating your opinions. In view of the circulated examples, I will proceed to add extra text to qualify the use of RFC2119 language. Since we were given the choice, I think that this approach minimizes the number of edits and changes, is less error prone and does not require sub-sub-subsequent review of the sections (even if a :%s/MUST/must/cg could do it...) OTOH no one has objected to the new IM following Jonas' comments. I will leave a few more days and update these two changes in a -05 version I have contacted the authors privately to follow RFC editor guidelines regarding authorship. Regards Ramon El 21/05/2015 a las 17:51, Lou Berger escribió: > I don't have a strong opinion on this either way for this draft. My > statement was WRT Fatai's comment on RFC7062 and the general usage of > 2119 language. > > Lou > > On 05/21/2015 11:33 AM, Adrian Farrel wrote: >> I'm not going to get excited about this. >> >> I was pretty much OK with Standards Track in -03. I thought that the document >> told folk how build a network as well as setting the requirements. So in -03 the >> 2119 language was fine, IMHO. >> >> However, if we want to go Informational I also don't mind. Clearly 2119 language >> is less relevant in an informational document, although I often find it is >> helpful in requirements specs to clarify the requirements. I have handled this >> in the past by using a variation of the 2119 boilerplate such as in section 2 of >> https://www.rfc-editor.org/rfc/rfc5862.txt (completely random example). >> >> But I really, really don't care. path of least resistance to raid publication, >> please. >> >> Adrian >> >> >>> -----Original Message----- >>> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger >>> Sent: 21 May 2015 13:40 >>> To: Fatai Zhang; Daniele Ceccarelli; Ramon Casellas; Matt Hartley (mhartley); >>> ccamp@ietf.org >>> Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and >> call >>> for sheperd >>> >>> >>> >>> On 05/21/2015 04:57 AM, Fatai Zhang wrote: >>>> Hi all, >>>> >>>> >>>> I would like to share the experience in RFC7062, which also describes >>>> a set of requirments in Section 5. >>>> >>>> >>>> If my memory is correct, I as the editor of RFC7062 was asked by Lou >>>> (as the CCAMP chair at that time) to remove RFC2119 language during >>>> the LC of this draft. >>> Sounds right. In general RFC 2119 conformance language is only >>> appropriate when discussing things that can impact interoperability, >>> formats and behavior "on the wire". This is a general rule, and their >>> are exceptions... >>> >>> Lou >>> >>>> >>>> I would also like to hear the confirmation from Adrian and our AD, >>>> Deborah. >>>> >>>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> >>>> >>>> Fatai >>>> >>>> >>>> >>>> *From:*CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Daniele >>>> Ceccarelli >>>> *Sent:* Thursday, May 21, 2015 4:26 PM >>>> *To:* Ramon Casellas; Matt Hartley (mhartley); ccamp@ietf.org >>>> *Subject:* Re: [CCAMP] WG Last Call on >>>> draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd >>>> >>>> >>>> >>>> Hi Ramon, >>>> >>>> >>>> >>>> No worries, the last call comments can be solved in two different >>>> version, we can send the -05 to the IESG (if there are no major changes >>>> from -03 to -05). >>>> >>>> >>>> >>>> Yes, I’d like to hear from Adrian on the requirements section. >>>> >>>> >>>> >>>> Thanks >>>> >>>> Daniele >>>> >>>> >>>> >>>> *From:*Ramon Casellas [mailto:ramon.casellas@cttc.es] >>>> *Sent:* giovedì 21 maggio 2015 10:20 >>>> *To:* Daniele Ceccarelli; Matt Hartley (mhartley); ccamp@ietf.org >>>> >>>> *Subject:* Re: [CCAMP] WG Last Call on >>>> draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd >>>> >>>> >>>> >>>> El 21/05/2015 a las 9:57, Daniele Ceccarelli escribió: >>>> >>>> Hi Matt, Ramon, >>>> >>>> >>>> >>>> Since I found no clear statements on the usage of RFC2119 language >>>> with respect to this situations, I had a look at existing framework >>>> and requirement RFCs trying to find a common WoW. My take is: >>>> >>>> >>>> >>>> - Framework is always informational >>>> >>>> - Requirements are always informational >>>> >>>> - RFC2119 language is not homogeneous. Sometimes capital >>>> letters are used and sometimes not. >>>> >>>> >>>> >>>> My preference is to use capital letters only when protocol behavior >>>> is defined, not when requirements for the design of the protocol are >>>> defined (this is in line with e.g. RFC7062 and RFC6163). >>>> >>>> As I said this is just a preference, but if there is no reasonable >>>> objection I would suggest not to use any capital letter in the >>>> fwk+req document. >>>> >>>> >>>> >>>> Hi Daniele, all >>>> >>>> I was also checking existing RFCs, and IMHO: >>>> - The document can stay informational, it is mainly fwk+reqs. We seem to >>>> agree on this. >>>> - While RFC2119 states "In many standards track documents several words >>>> are used to signify the requirements in the specification", there seems >>>> to be (some?) existing practice on using RFC2119 wording in reqs/info >>>> documents, including capitalization. >>>> - Usage of RFC2119 keywords seems scoped to the section on requirements >>>> in the draft. It could be argued that defining requirements is to some >>>> extent defining high level protocol behavior :) >>>> >>>> IIRC Adrian authored a significant part of the section, any views? >>>> >>>> That said, -05 needs to be uploaded anyway to reflect the new info-model >>>> (thanks Jonas!) , it is not game-changing to change to acomodate what >>>> you suggest. We could remove RFC2119 reference, the boilerplate text and >>>> re-visit the sections, mainly using lowercase. From nobody Thu May 21 21:11:25 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BF61A90EC; Thu, 21 May 2015 21:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzboUwfdlOXf; Thu, 21 May 2015 21:11:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBB71A90E6; Thu, 21 May 2015 21:11:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150522041120.20117.75171.idtracker@ietfa.amsl.com> Date: Thu, 21 May 2015 21:11:20 -0700 Archived-At: Cc: draft-ietf-ccamp-wson-signaling@ietf.org, ccamp@ietf.org, ccamp-chairs@ietf.org Subject: [CCAMP] Barry Leiba's No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 04:11:22 -0000 Barry Leiba has entered the following ballot position for draft-ietf-ccamp-wson-signaling-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think the choice of registration policies for the new registries -- Standards Action or Specification Required -- is a good one, and provides good flexibility. Thanks for that. From nobody Mon May 25 04:54:03 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F541B2C2A; Mon, 25 May 2015 04:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8Bh8g8_sehE; Mon, 25 May 2015 04:53:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D14F61B2C24; Mon, 25 May 2015 04:53:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150525115359.26249.7139.idtracker@ietfa.amsl.com> Date: Mon, 25 May 2015 04:53:59 -0700 Archived-At: Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-flexi-grid-fwk-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 11:54:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework and Requirements for GMPLS-based control of Flexi-grid DWDM networks Authors : Oscar Gonzalez de Dios Ramon Casellas Filename : draft-ietf-ccamp-flexi-grid-fwk-05.txt Pages : 39 Date : 2015-05-25 Abstract: To allow efficient allocation of optical spectral bandwidth for high bit-rate systems, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new dense wavelength division multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings and the concept of "frequency slot". In such an environment, a data plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum creating what is known as a flexible grid (flexi- grid). This document defines a framework and the associated control plane requirements for the GMPLS-based control of flexi-grid DWDM networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ccamp-flexi-grid-fwk-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-flexi-grid-fwk-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 25 04:58:25 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747411B2C39 for ; Mon, 25 May 2015 04:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxIOhDyQQg_f for ; Mon, 25 May 2015 04:58:23 -0700 (PDT) Received: from torres.puc.rediris.es (torres.puc.rediris.es [IPv6:2001:720:418:ca00::9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BCD1B2C3E for ; Mon, 25 May 2015 04:57:56 -0700 (PDT) Received: from [2001:40b0:7c22:6020:9c51:b4c6:4ec2:7def] (helo=leo) by torres.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Ywr0y-0003vw-Su for ccamp@ietf.org; Mon, 25 May 2015 13:57:53 +0200 Received: from [192.168.101.69] (unknown [192.168.101.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 38ED61FD05 for ; Mon, 25 May 2015 13:57:49 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <55630E3D.1050305@cttc.es> Date: Mon, 25 May 2015 13:57:49 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ccamp@ietf.org References: <20150525115359.26249.7139.idtracker@ietfa.amsl.com> In-Reply-To: <20150525115359.26249.7139.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -0.2 (/) X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: ietf.org] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4794] Archived-At: Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexi-grid-fwk-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 11:58:24 -0000 All, Uploaded -05 with : - Agreement on the use of RFC2119 language in requirements. Added text " While [RFC2119] describes interpretations of these key words in terms of protocol specifications and implementations, they are used in this document to describe design requirements for protocol extensions." - Limited to 2 editors in front page (as agreed with WG chairs and AD) - Updated info model as suggested by Jonas Thanks R. El 25/05/2015 a las 13:53, internet-drafts@ietf.org escribió: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. From nobody Tue May 26 07:10:29 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CA01B2EE2; Tue, 26 May 2015 07:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzx6Wp9AGiPq; Tue, 26 May 2015 07:10:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7E41B2EE7; Tue, 26 May 2015 07:10:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150526141022.22480.6172.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 07:10:22 -0700 Archived-At: Cc: draft-ietf-ccamp-wson-signaling@ietf.org, ccamp@ietf.org, ccamp-chairs@ietf.org Subject: [CCAMP] Stephen Farrell's No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 14:10:23 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ccamp-wson-signaling-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just wondering: does this (or some other document) provide me with a way to say that node X should take an input lambda and replicate it out twice? (I.e. forking the traffic) If so, then that probably ought be noted somewhere as it'd enable forms of monitoring that might otherwise require a visit to the physical node. From nobody Tue May 26 09:58:43 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D0A1A89F9; Tue, 26 May 2015 08:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg69CLVmANa7; Tue, 26 May 2015 08:41:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 517441A8A75; Tue, 26 May 2015 08:39:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150526153945.8320.38115.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 08:39:45 -0700 Archived-At: X-Mailman-Approved-At: Tue, 26 May 2015 09:58:43 -0700 Cc: draft-ietf-ccamp-wson-signaling@ietf.org, ccamp@ietf.org, ccamp-chairs@ietf.org Subject: [CCAMP] Ben Campbell's No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:41:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ccamp-wson-signaling-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The security considerations say this document differs from 3473 only in "specific information communicated". In general, a change in the information carried can make a huge difference. I infer that the working group believes that this specific information does not (I hold no opinion on that), but it would be good to state that explicitly. From nobody Tue May 26 11:27:01 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D771B2FCC for ; Tue, 26 May 2015 11:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3boICItUEuJ1 for ; Tue, 26 May 2015 11:27:00 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 7184F1B2FDD for ; Tue, 26 May 2015 11:26:52 -0700 (PDT) Received: (qmail 10390 invoked by uid 0); 26 May 2015 18:26:47 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 26 May 2015 18:26:47 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id YiJz1q01Z2SSUrH01iK23V; Tue, 26 May 2015 12:19:12 -0600 X-Authority-Analysis: v=2.1 cv=efyuId0H c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=d8zPNJv4eCMA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=bUr0-f1PUU35AiNAwZQA:9 a=QEXdDO2ut3YA:10 a=mYAOWqAtFUkA:10 a=1dbGxDndw2gA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9HdWyljAU22W5m3c9rlFgzcFYlwOUdiooZ5z3q71cjE=; b=k8S4fx4Dj5C2lQLg3Uv9vPj8lBsPDimgxMbtxcvqjt7y8QjOEiK32DLc2KTrlAbpH//OIEm+t9x0bZR4oGGn/TtZUWA9QQ7LKGoUB6/cqGxmnaBauL93Tk/1rjZyMMJi; Received: from box313.bluehost.com ([69.89.31.113]:55041 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YxJYh-0000Eh-1c; Tue, 26 May 2015 12:26:35 -0600 Message-ID: <5564BAD8.1010301@labn.net> Date: Tue, 26 May 2015 14:26:32 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150526141022.22480.6172.idtracker@ietfa.amsl.com> In-Reply-To: <20150526141022.22480.6172.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-ietf-ccamp-wson-signaling@ietf.org, ccamp@ietf.org, ccamp-chairs@ietf.org Subject: Re: [CCAMP] Stephen Farrell's No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 18:27:01 -0000 Hi Stephen, See below. On 05/26/2015 10:10 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-ccamp-wson-signaling-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Just wondering: does this (or some other document) provide me > with a way to say that node X should take an input lambda and > replicate it out twice? RFC4875 allows this under signaled control. So nothing new is introduced by this document. > (I.e. forking the traffic) If so, then > that probably ought be noted somewhere as it'd enable forms of > monitoring that might otherwise require a visit to the physical > node. > I'm sorry, I don't understand this. signaling allows one to automate what is already possible via other mechanisms, e.g., network management. If the equipment requires a physical change to provision/split (aka drop and continue) a lambda, adding support for signaling doesn't change this. Lou From nobody Tue May 26 12:48:12 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72BC1A003B; Tue, 26 May 2015 12:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opYqvTkFtG-0; Tue, 26 May 2015 12:48:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793AE1A0010; Tue, 26 May 2015 12:48:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AAC37BECF; Tue, 26 May 2015 20:48:06 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91AZwJ6gh0kC; Tue, 26 May 2015 20:48:05 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2CF9FBECC; Tue, 26 May 2015 20:48:05 +0100 (IST) Message-ID: <5564CDF4.1030407@cs.tcd.ie> Date: Tue, 26 May 2015 20:48:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lou Berger , The IESG References: <20150526141022.22480.6172.idtracker@ietfa.amsl.com> <5564BAD8.1010301@labn.net> In-Reply-To: <5564BAD8.1010301@labn.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-ccamp-wson-signaling@ietf.org, ccamp@ietf.org, ccamp-chairs@ietf.org Subject: Re: [CCAMP] Stephen Farrell's No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:48:10 -0000 On 26/05/15 19:26, Lou Berger wrote: > Hi Stephen, > > See below. > > On 05/26/2015 10:10 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-ccamp-wson-signaling-12: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Just wondering: does this (or some other document) provide me >> with a way to say that node X should take an input lambda and >> replicate it out twice? > > RFC4875 allows this under signaled control. So nothing new is introduced > by this document. Thanks. That's all I was after - I really was just curious and not trying to find a problem with this draft:-) S. > >> (I.e. forking the traffic) If so, then >> that probably ought be noted somewhere as it'd enable forms of >> monitoring that might otherwise require a visit to the physical >> node. >> > > I'm sorry, I don't understand this. signaling allows one to automate > what is already possible via other mechanisms, e.g., network management. > If the equipment requires a physical change to provision/split (aka > drop and continue) a lambda, adding support for signaling doesn't change > this. > > Lou > > > From nobody Tue May 26 13:28:53 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D66B1B3136 for ; Tue, 26 May 2015 13:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNuKIvUdjfhe for ; Tue, 26 May 2015 13:28:50 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 12C641A0105 for ; Tue, 26 May 2015 13:28:49 -0700 (PDT) Received: (qmail 14139 invoked by uid 0); 26 May 2015 20:28:49 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 26 May 2015 20:28:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id YkM11q00k2SSUrH01kM4VC; Tue, 26 May 2015 14:21:13 -0600 X-Authority-Analysis: v=2.1 cv=efyuId0H c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=d8zPNJv4eCMA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=hysohF4vzuW0jHGFvWkA:9 a=QEXdDO2ut3YA:10 a=mYAOWqAtFUkA:10 a=1dbGxDndw2gA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=EFOknDCNBlOtHBvMApGdzdHkuZv6Kww8smzpIpfenfY=; b=tLW/z5X0CY6p4v7IVNfc/9c9i7BUgraI9L+J9A9KZgQIL9fGJ08/IC9hmi8e9RCQtoA8aOV992EPFswWToq2GlubRpEPw1ChBAJgfPNcl1Btx//67HrhA2ro5k4HP4vP; Received: from box313.bluehost.com ([69.89.31.113]:36477 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YxLSn-0002Qk-Iz; Tue, 26 May 2015 14:28:37 -0600 Message-ID: <5564D772.9070705@labn.net> Date: Tue, 26 May 2015 16:28:34 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150526141022.22480.6172.idtracker@ietfa.amsl.com> <5564BAD8.1010301@labn.net> <5564CDF4.1030407@cs.tcd.ie> In-Reply-To: <5564CDF4.1030407@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-ietf-ccamp-wson-signaling@ietf.org, ccamp@ietf.org, ccamp-chairs@ietf.org Subject: Re: [CCAMP] Stephen Farrell's No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:28:51 -0000 Stephen, No problem and I was trying to respond to the comment. I just didn't quite understand the point you were making. It sounds like the comment is addressed so we don't need to discuss and further. Do feel free to respond privately if you want more background info... Thanks, Lou On 05/26/2015 03:48 PM, Stephen Farrell wrote: > > > On 26/05/15 19:26, Lou Berger wrote: >> Hi Stephen, >> >> See below. >> >> On 05/26/2015 10:10 AM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-ccamp-wson-signaling-12: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> Just wondering: does this (or some other document) provide me >>> with a way to say that node X should take an input lambda and >>> replicate it out twice? >> >> RFC4875 allows this under signaled control. So nothing new is introduced >> by this document. > > Thanks. That's all I was after - I really was just curious > and not trying to find a problem with this draft:-) > > S. > >> >>> (I.e. forking the traffic) If so, then >>> that probably ought be noted somewhere as it'd enable forms of >>> monitoring that might otherwise require a visit to the physical >>> node. >>> >> >> I'm sorry, I don't understand this. signaling allows one to automate >> what is already possible via other mechanisms, e.g., network management. >> If the equipment requires a physical change to provision/split (aka >> drop and continue) a lambda, adding support for signaling doesn't change >> this. >> >> Lou >> >> >> > From nobody Wed May 27 12:29:43 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E4E1A9069; Wed, 27 May 2015 12:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92877dnObpqS; Wed, 27 May 2015 12:29:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6552F1A038A; Wed, 27 May 2015 12:29:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150527192941.20358.5048.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 12:29:41 -0700 Archived-At: Cc: draft-ietf-ccamp-wson-signaling@ietf.org, ccamp@ietf.org, ccamp-chairs@ietf.org Subject: [CCAMP] Alia Atlas' No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 19:29:42 -0000 Alia Atlas has entered the following ballot position for draft-ietf-ccamp-wson-signaling-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a bit startled that the WavelengthSelection sub-TLV has a used value of 8 bits (really 1 bit plus a handful of the 127 values) but has a length of 4 which thus forces 2 octets of padding. I expect that there are implementations and this isn't a flaw - just wasteful. From nobody Wed May 27 14:13:52 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982F91A0155; Wed, 27 May 2015 14:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qof7mfbQduUj; Wed, 27 May 2015 14:13:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121AD1A0021; Wed, 27 May 2015 14:13:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWO93421; Wed, 27 May 2015 21:13:45 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 May 2015 22:13:42 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 27 May 2015 14:13:38 -0700 From: Leeyoung To: Alia Atlas , The IESG Thread-Topic: Alia Atlas' No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) Thread-Index: AQHQmLOAQ5c0TreuM0eTSV9Y+M1ZmZ2QTcPQ Date: Wed, 27 May 2015 21:13:37 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729CCE6A0@dfweml706-chm> References: <20150527192941.20358.5048.idtracker@ietfa.amsl.com> In-Reply-To: <20150527192941.20358.5048.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.213] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-ccamp-wson-signaling@ietf.org" , "ccamp@ietf.org" , "ccamp-chairs@ietf.org" Subject: Re: [CCAMP] Alia Atlas' No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 21:13:50 -0000 SGkgQWxpYSwNCg0KVGhhbmtzIGZvciBwcm92aWRpbmcgeW91ciBjb21tZW50LiBJIHRoaW5rIGl0 IGhhcyBiZWVuIHR5cGljYWwgaW4gR01QTFMgdG8gZ2l2ZSBhIHN1Yi1UTFYgYSB1bml0IG9mIDMy LWJpdCBmaWVsZC4gVW5mb3J0dW5hdGVseSwgd2l0aCB0aGlzLCB3ZSBoYWQgdG8gZ2l2ZSBhd2F5 IGFub3RoZXIgMiBieXRlcyBvZiBwYWRkaW5nLiANCg0KVGhhbmtzLA0KWW91bmcNCg0KIA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxpYSBBdGxhcyBbbWFpbHRvOmFrYXRs YXNAZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgTWF5IDI3LCAyMDE1IDI6MzAgUE0NClRv OiBUaGUgSUVTRw0KQ2M6IGNjYW1wLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC13 c29uLXNpZ25hbGluZ0BpZXRmLm9yZzsgbGJlcmdlckBsYWJuLm5ldDsgY2NhbXBAaWV0Zi5vcmcN ClN1YmplY3Q6IEFsaWEgQXRsYXMnIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWNjYW1wLXdz b24tc2lnbmFsaW5nLTEyOiAod2l0aCBDT01NRU5UKQ0KDQpBbGlhIEF0bGFzIGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1jY2FtcC13c29u LXNpZ25hbGluZy0xMjogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVz c2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRo aXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0 byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0 bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBw b3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbGluZy8NCg0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkknbSBhIGJpdCBzdGFydGxlZCB0aGF0IHRoZSBX YXZlbGVuZ3RoU2VsZWN0aW9uIHN1Yi1UTFYgaGFzIGEgdXNlZCB2YWx1ZQ0Kb2YgOCBiaXRzIChy ZWFsbHkgMSBiaXQgcGx1cyBhIGhhbmRmdWwgb2YgdGhlIDEyNyB2YWx1ZXMpIGJ1dCBoYXMgYQ0K bGVuZ3RoIG9mIDQgd2hpY2ggdGh1cyBmb3JjZXMgMiBvY3RldHMgb2YgcGFkZGluZy4gICBJIGV4 cGVjdCB0aGF0IHRoZXJlDQphcmUgaW1wbGVtZW50YXRpb25zIGFuZCB0aGlzIGlzbid0IGEgZmxh dyAtIGp1c3Qgd2FzdGVmdWwuDQoNCg0K From nobody Wed May 27 16:25:29 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7571B2ABA; Wed, 27 May 2015 16:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l0aM0dBItDz; Wed, 27 May 2015 16:25:22 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BF01B2AB8; Wed, 27 May 2015 16:25:22 -0700 (PDT) Received: by obbnx5 with SMTP id nx5so19951664obb.0; Wed, 27 May 2015 16:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kfmqhV66CI1vc9OvzqD+N1FfHL5SjPud6XWQtN7wXBo=; b=cnDJC7IFZwYZHAEard8QiavIXI2g+QJgC5zxiCFxeUWlClgMJbUJ9Hjw29RCFiP1MM IwKMnhkXqMFWKSIBLIBca0CJPYttR2zePMuP3wY7n5jRd3rP3J2w+qm68RxZhCdJBmjC tQqynZdwTL1rUsxD29EpfU6zvSADv3oh03m9+ayrYUNvmOBlC4GJe5Ud5w2uHeKBaZf2 NxQHFBkPxkjrvodZV9Us9g7caV0kxy+F+0e4GsHhc4PHgnKsm9S8T+WaingCvxPb55oF OcHb9q2e3MkVDTjeVmAxpDIUYJBWPbs5ttfTKqhjMfNi5Xkk/RIAArwCjiaJElBFC0dj pMag== MIME-Version: 1.0 X-Received: by 10.182.186.106 with SMTP id fj10mr2007953obc.54.1432769122101; Wed, 27 May 2015 16:25:22 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Wed, 27 May 2015 16:25:22 -0700 (PDT) Received: by 10.60.172.77 with HTTP; Wed, 27 May 2015 16:25:22 -0700 (PDT) In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729CCE6A0@dfweml706-chm> References: <20150527192941.20358.5048.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E1729CCE6A0@dfweml706-chm> Date: Wed, 27 May 2015 19:25:22 -0400 Message-ID: From: Alia Atlas To: Leeyoung Content-Type: multipart/alternative; boundary=089e0149bbb09172200517188ee1 Archived-At: Cc: "draft-ietf-ccamp-wson-signaling@ietf.org" , CCAMP , "ccamp-chairs@ietf.org" , The IESG Subject: Re: [CCAMP] Alia Atlas' No Objection on draft-ietf-ccamp-wson-signaling-12: (with COMMENT) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 23:25:25 -0000 --089e0149bbb09172200517188ee1 Content-Type: text/plain; charset=UTF-8 Hi Young, Yes, I had forgotten that. Thanks for the reminder. Alia On May 27, 2015 5:13 PM, "Leeyoung" wrote: > Hi Alia, > > Thanks for providing your comment. I think it has been typical in GMPLS to > give a sub-TLV a unit of 32-bit field. Unfortunately, with this, we had to > give away another 2 bytes of padding. > > Thanks, > Young > > > > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, May 27, 2015 2:30 PM > To: The IESG > Cc: ccamp-chairs@ietf.org; draft-ietf-ccamp-wson-signaling@ietf.org; > lberger@labn.net; ccamp@ietf.org > Subject: Alia Atlas' No Objection on draft-ietf-ccamp-wson-signaling-12: > (with COMMENT) > > Alia Atlas has entered the following ballot position for > draft-ietf-ccamp-wson-signaling-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm a bit startled that the WavelengthSelection sub-TLV has a used value > of 8 bits (really 1 bit plus a handful of the 127 values) but has a > length of 4 which thus forces 2 octets of padding. I expect that there > are implementations and this isn't a flaw - just wasteful. > > > --089e0149bbb09172200517188ee1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Young,

Yes,=C2=A0 I had forgotten that.=C2=A0 Thanks for the remind= er.=C2=A0=C2=A0

Alia

On May 27, 2015 5:13 PM, "Leeyoung" &l= t;leeyoung@huawei.com> wrote:=
Hi Alia,

Thanks for providing your comment. I think it has been typical in GMPLS to = give a sub-TLV a unit of 32-bit field. Unfortunately, with this, we had to = give away another 2 bytes of padding.

Thanks,
Young



-----Original Message-----
From: Alia Atlas [mailto:akatlas@gmail= .com]
Sent: Wednesday, May 27, 2015 2:30 PM
To: The IESG
Cc: ccamp-chairs@ietf.org; draft-ietf-ccamp-w= son-signaling@ietf.org; lberger@lab= n.net; ccamp@ietf.org
Subject: Alia Atlas' No Objection on draft-ietf-ccamp-wson-signaling-12= : (with COMMENT)

Alia Atlas has entered the following ballot position for
draft-ietf-ccamp-wson-signaling-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-cr= iteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson= -signaling/



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

I'm a bit startled that the WavelengthSelection sub-TLV has a used valu= e
of 8 bits (really 1 bit plus a handful of the 127 values) but has a
length of 4 which thus forces 2 octets of padding.=C2=A0 =C2=A0I expect tha= t there
are implementations and this isn't a flaw - just wasteful.


--089e0149bbb09172200517188ee1-- From nobody Fri May 29 14:17:50 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A61C1B2D7F for ; Fri, 29 May 2015 14:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_-9Suffmzq6 for ; Fri, 29 May 2015 14:17:45 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3366B1B2D8C for ; Fri, 29 May 2015 14:17:36 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-cd-5568d76e4a15 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5A.3B.17665.E67D8655; Fri, 29 May 2015 23:17:34 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.137]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Fri, 29 May 2015 23:17:33 +0200 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 Thread-Index: AdCaVM3VCKebMKwKSkqeh2eaU0NgxQ== Date: Fri, 29 May 2015 21:17:32 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE481293B337ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvrW7e9YxQg93vRCyezLnB4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEPv97EWnDGsmHN9NUsD4z6tLkZODgkBE4ldU16zQdhiEhfu rQezhQSOMkp8eB3bxcgFZC9hlJj9aytzFyMHB5uAlcSTQz4gNSICuhJ7N15nBrGFgcJX27ey Q8TtJR78m88KUi4ioCdx9j0TSJhFQFXiQ2sn2BReAV+JF+3OIGFGAVmJCbsXMYLYzALiEree zGeCuEZAYsme88wQtqjEy8f/WCFsJYnGJU9YIerzJTqvLgOr5xUQlDg58wnLBEahWUhGzUJS NgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eX WrKJERgNB7f81t3BuPq14yFGAQ5GJR7eRIaMUCHWxLLiytxDjNIcLErivF5dIaFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGCd0uCZcEWe+LOYXX8yVsv5gHnP17otr3d84fVitUL7UYYMf x5Ebcj8ms4jt+CPY2F+v7f8t3ddJOsu1UPhOYfSMrR2PNXZE5i+aK//ovsfqVLmgNScLnS6U KJyzVF/34IJO0oY4HYPZWlN2+zAdtJqlcEZ+jbol/6Feje8LUgLZj9x0YNl7QomlOCPRUIu5 qDgRAECI8JJnAgAA Archived-At: Subject: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 21:17:48 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE481293B337ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Contributors, CCAMP Let's progress the flexi grid work with the preparation for the last call o= f the flexi label and the poll for IPR declarations. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. This document will not advance to the next stage un= til a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty. Thank you, Daniele & Fatai --_000_4A1562797D64E44993C5CBF38CF1BE481293B337ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors, Contributors, CCAMP

 

Let’s progress the flexi grid work with the pr= eparation for the last call of the flexi label and the poll for IPR declara= tions.

 

Are you aware of any IPR that applies to draft ident= ified above?

 

Please state either:

"No, I'm not aware of any IPR that applies to t= his draft"

or

"Yes, I'm aware of IPR that applies to this dra= ft"

 

If so, has this IPR been disclosed in compliance wit= h IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:=

 

"Yes, the IPR has been disclosed in compliance = with IETF IPR rules"

or

"No, the IPR has not been disclosed"<= /o:p>

 

If you answer no, please provide any additional deta= ils you think appropriate. If you are listed as a document author or contri= butor please answer the above by responding to this email regardless of whe= ther or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has= been received from each author and listed contributor.

 

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESS= AGE'S TO LINES.

 

If you are on the CCAMP WG email list but are not li= sted as an author or contributor, we remind you of your obligations under t= he IETF IPR rules which encourages you to notify the IETF if you are aware = of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related= to your undisclosed IPR. For more information, please see the RFCs listed = above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPrope= rty.

 

Thank you,

Daniele & Fatai

--_000_4A1562797D64E44993C5CBF38CF1BE481293B337ESESSMB301erics_-- From nobody Fri May 29 18:02:40 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFC21ACE19 for ; Fri, 29 May 2015 18:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iyYP7eFQAMQ for ; Fri, 29 May 2015 18:02:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D70A1A89F5 for ; Fri, 29 May 2015 18:02:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWR17219; Sat, 30 May 2015 01:02:34 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 May 2015 02:02:33 +0100 Received: from NKGEML509-MBX.china.huawei.com ([169.254.1.53]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 30 May 2015 09:02:27 +0800 From: "Zhangfei (Philip)" To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" Thread-Topic: IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 Thread-Index: AdCaVM3VCKebMKwKSkqeh2eaU0NgxQAH2UQQ Date: Sat, 30 May 2015 01:02:27 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.164.33.140] Content-Type: multipart/alternative; boundary="_000_AF82500E245ACF498991B9F5FFCC6DB2C80F88nkgeml509mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 01:02:38 -0000 --_000_AF82500E245ACF498991B9F5FFCC6DB2C80F88nkgeml509mbxchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRo aXMgZHJhZnQNCg0KQi5SLg0KDQpGZWkNCg0Kt6K8/sjLOiBDQ0FNUCBbbWFpbHRvOmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gRGFuaWVsZSBDZWNjYXJlbGxpDQq3osvNyrG85DogMjAxNcTq NdTCMjnI1SAyMzoxOA0KytW8/sjLOiBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQrW98ziOiBbQ0NB TVBdIElQUiBvbiBkcmFmdC1pZXRmLWNjYW1wLWZsZXhpZ3JpZC1sYW1iZGEtbGFiZWwtMDMNCg0K QXV0aG9ycywgQ29udHJpYnV0b3JzLCBDQ0FNUA0KDQpMZXShr3MgcHJvZ3Jlc3MgdGhlIGZsZXhp IGdyaWQgd29yayB3aXRoIHRoZSBwcmVwYXJhdGlvbiBmb3IgdGhlIGxhc3QgY2FsbCBvZiB0aGUg ZmxleGkgbGFiZWwgYW5kIHRoZSBwb2xsIGZvciBJUFIgZGVjbGFyYXRpb25zLg0KDQpBcmUgeW91 IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/ DQoNClBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0 aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQoiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRo YXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwg NDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCklmIHllcyB0byB0aGUgYWJv dmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xv c2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCm9yDQoiTm8sIHRoZSBJUFIg aGFzIG5vdCBiZWVuIGRpc2Nsb3NlZCINCg0KSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3Zp ZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsgYXBwcm9wcmlhdGUuIElmIHlvdSBh cmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3 ZXIgdGhlIGFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdo ZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1 bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2Ug aGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9y Lg0KDQpOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNT QUdFJ1MgVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIENDQU1QIFdHIGVtYWlsIGxpc3Qg YnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5k IHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBl bmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIg b2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFy dGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5 b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhl IFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9p ZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KVGhhbmsgeW91LA0KRGFuaWVs ZSAmIEZhdGFpDQo= --_000_AF82500E245ACF498991B9F5FFCC6DB2C80F88nkgeml509mbxchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all

 

No, I'm not aware of any IPR th= at applies to this draft

 

B.R.

 

Fei

 

=B7=A2=BC=FE=C8=CB: CCAMP [mailto:ccamp-b= ounces@ietf.org] =B4=FA=B1=ED = Daniele Ceccarelli
=B7=A2=CB=CD= =CA=B1=BC=E4: 2015=C4=EA5=D4=C2<= span lang=3D"EN-US">29=C8=D5 23:18
=CA=D5=BC=FE=C8=CB: CCAMP (ccamp@ietf.org)
=D6=F7=CC=E2: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03

 

Authors, Contributors, CCAMP

 

Let=A1=AFs progress the flexi g= rid work with the preparation for the last call of the flexi label and the = poll for IPR declarations.

 

Are you aware of any IPR that a= pplies to draft identified above?

 

Please state either:=

"No, I'm not aware of any = IPR that applies to this draft"

or

"Yes, I'm aware of IPR tha= t applies to this draft"

 

If so, has this IPR been disclo= sed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 f= or more details)?

If yes to the above, please sta= te either:

 

"Yes, the IPR has been dis= closed in compliance with IETF IPR rules"

or

"No, the IPR has not been = disclosed"

 

If you answer no, please provid= e any additional details you think appropriate. If you are listed as a docu= ment author or contributor please answer the above by responding to this em= ail regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next = stage until a response has been received from each author and listed contri= butor.

 

NOTE: THIS APPLIES TO ALL OF YO= U LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG emai= l list but are not listed as an author or contributor, we remind you of you= r obligations under the IETF IPR rules which encourages you to notify the I= ETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribut= ion or discussion related to your undisclosed IPR. For more information, pl= ease see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty<= /a>.

 

Thank you,

Daniele & Fatai<= /span>

--_000_AF82500E245ACF498991B9F5FFCC6DB2C80F88nkgeml509mbxchina_-- From nobody Fri May 29 21:27:47 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FF81AD35A for ; Fri, 29 May 2015 21:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypW6EgfwszJG for ; Fri, 29 May 2015 21:27:45 -0700 (PDT) Received: from rudy.puc.rediris.es (rudy.puc.rediris.es [IPv6:2001:720:418:ca01::132]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19041AD062 for ; Fri, 29 May 2015 21:27:44 -0700 (PDT) Received: from [84.88.62.208] (helo=leo) by rudy.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YyYN3-00011A-P3 for ccamp@ietf.org; Sat, 30 May 2015 06:27:42 +0200 Received: from [192.168.1.200] (81.61.180.55.dyn.user.ono.com [81.61.180.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 71D6B1FEA7 for ; Sat, 30 May 2015 06:27:39 +0200 (CEST) X-Envelope-From: ramon.casellas@cttc.es Message-ID: <55693C39.2000401@cttc.es> Date: Sat, 30 May 2015 06:27:37 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: ccamp@ietf.org References: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------040800000307020105070504" X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -1.5 (-) X-Spamina-Spam-Report: Content analysis details: (-1.5 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% [score: 0.0422] Archived-At: Subject: Re: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 04:27:46 -0000 This is a multi-part message in MIME format. --------------040800000307020105070504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit El 29/05/2015 a las 23:17, Daniele Ceccarelli escribió: > > Authors, Contributors, CCAMP > > Let’s progress the flexi grid work with the preparation for the last > call of the flexi label and the poll for IPR declarations. > No, I'm not aware of any IPR that applies to this draft Thanks R. --------------040800000307020105070504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
El 29/05/2015 a las 23:17, Daniele Ceccarelli escribió:

Authors, Contributors, CCAMP

 

Let’s progress the flexi grid work with the preparation for the last call of the flexi label and the poll for IPR declarations.

No, I'm not aware of any IPR that applies to this draft
Thanks
R.




--------------040800000307020105070504-- From nobody Sat May 30 01:42:54 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A460B1A0470 for ; Sat, 30 May 2015 01:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joLHbIUbDU_g for ; Sat, 30 May 2015 01:42:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5E91A0423 for ; Sat, 30 May 2015 01:42:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWR39267; Sat, 30 May 2015 08:42:48 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 May 2015 09:42:46 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.112]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Sat, 30 May 2015 16:42:40 +0800 From: Fatai Zhang To: Daniele Ceccarelli , "CCAMP (ccamp@ietf.org)" Thread-Topic: IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 Thread-Index: AdCaVM3VCKebMKwKSkqeh2eaU0NgxQAX7uyw Date: Sat, 30 May 2015 08:42:40 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CC503EFSZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 08:42:52 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF85CC503EFSZXEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, No, I'm not aware of any IPR that applies to this draft. Best Regards Fatai From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Saturday, May 30, 2015 5:18 AM To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 Authors, Contributors, CCAMP Let's progress the flexi grid work with the preparation for the last call o= f the flexi label and the poll for IPR declarations. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the= above by responding to this email regardless of whether or not you are awa= re of any relevant IPR. This document will not advance to the next stage un= til a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please se= e the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki= /IntellectualProperty. Thank you, Daniele & Fatai --_000_F82A4B6D50F9464B8EBA55651F541CF85CC503EFSZXEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,=

 

No, I'm not aware of = any IPR that applies to this draft.

 

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

Best Re= gards

&n= bsp;

Fatai

 

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Saturday, May 30, 2015 5:18 AM
To: CCAMP (ccamp@ietf.org)
Subject: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03

 

Authors, Contributors, CCAMP

 

Let’s progress the flexi = grid work with the preparation for the last call of the flexi label and the= poll for IPR declarations.

 

Are you aware of any IPR that a= pplies to draft identified above?

 

Please state either:=

"No, I'm not aware of any = IPR that applies to this draft"

or

"Yes, I'm aware of IPR tha= t applies to this draft"

 

If so, has this IPR been disclo= sed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 f= or more details)?

If yes to the above, please sta= te either:

 

"Yes, the IPR has been dis= closed in compliance with IETF IPR rules"

or

"No, the IPR has not been = disclosed"

 

If you answer no, please provid= e any additional details you think appropriate. If you are listed as a docu= ment author or contributor please answer the above by responding to this em= ail regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next = stage until a response has been received from each author and listed contri= butor.

 

NOTE: THIS APPLIES TO ALL OF YO= U LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG emai= l list but are not listed as an author or contributor, we remind you of you= r obligations under the IETF IPR rules which encourages you to notify the I= ETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribut= ion or discussion related to your undisclosed IPR. For more information, pl= ease see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty<= /a>.

 

Thank you,

Daniele & Fatai<= /span>

--_000_F82A4B6D50F9464B8EBA55651F541CF85CC503EFSZXEMA504MBSchi_-- From nobody Sat May 30 21:49:34 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4B1B2C38 for ; Sat, 30 May 2015 21:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.591 X-Spam-Level: * X-Spam-Status: No, score=1.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09N-mjLv65a9 for ; Sat, 30 May 2015 21:49:30 -0700 (PDT) Received: from COL004-OMC4S12.hotmail.com (col004-omc4s12.hotmail.com [65.55.34.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685E21B2C37 for ; Sat, 30 May 2015 21:49:30 -0700 (PDT) Received: from COL129-W9 ([65.55.34.201]) by COL004-OMC4S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sat, 30 May 2015 21:49:29 -0700 X-TMN: [IS0cTqjiJBDpfb96GvnFHOEavyQZMF72DUkfKLmULTk=] X-Originating-Email: [wsliguotou@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_999c2a19-61f9-44bf-abb0-8f5027341fd9_" From: =?gb2312?B?wOjSow==?= To: Daniele Ceccarelli , "CCAMP ccamp@ietf.org" Date: Sun, 31 May 2015 12:49:29 +0800 Importance: Normal In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 31 May 2015 04:49:29.0899 (UTC) FILETIME=[2DF43FB0:01D09B5D] Archived-At: Subject: Re: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 04:49:32 -0000 --_999c2a19-61f9-44bf-abb0-8f5027341fd9_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N CkJlc3Qgd2lzaGVzLFlhbyBMaQ0KDQpGcm9tOiBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24u Y29tDQpUbzogY2NhbXBAaWV0Zi5vcmcNCkRhdGU6IEZyaSwgMjkgTWF5IDIwMTUgMjE6MTc6MzIg KzAwMDANClN1YmplY3Q6IFtDQ0FNUF0gSVBSIG9uIGRyYWZ0LWlldGYtY2NhbXAtZmxleGlncmlk LWxhbWJkYS1sYWJlbC0wMw0KDQoKCgoKCgoKCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgQ0NBTVAK IApMZXShr3MgcHJvZ3Jlc3MgdGhlIGZsZXhpIGdyaWQgd29yayB3aXRoIHRoZSBwcmVwYXJhdGlv biBmb3IgdGhlIGxhc3QgY2FsbCBvZiB0aGUgZmxleGkgbGFiZWwgYW5kIHRoZSBwb2xsIGZvciBJ UFIgZGVjbGFyYXRpb25zLgogCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMg dG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8KIApQbGVhc2Ugc3RhdGUgZWl0aGVyOgoiTm8sIEkn bSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCIKb3IKIlll cywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCIKIApJZiBzbywg aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy dWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxz KT8KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoKIAoiWWVzLCB0aGUg SVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMi Cm9yCiJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIgogCklmIHlvdSBhbnN3ZXIg bm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIGFwcHJv cHJpYXRlLiBJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmli dXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFu dAogSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2Ug dW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBs aXN0ZWQgY29udHJpYnV0b3IuCiAKTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElT VEVEIElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLgogCklmIHlvdSBhcmUgb24gdGhlIENDQU1Q IFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmli dXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQ UiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFy ZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLAogb3IgdG8g cmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNz aW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9u LCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQgaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuCiAKVGhh bmsgeW91LApEYW5pZWxlICYgRmF0YWkKCgoKDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpDQ0FNUCBtYWlsaW5nIGxpc3QKQ0NBTVBAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcCAJCSAJICAgCQkgIA== --_999c2a19-61f9-44bf-abb0-8f5027341fd9_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5Os6iyO3RxbraDQp9DQotLT48L3N0eWxlPjwvaGVhZD4NCjxib2R5IGNsYXNzPSdo bW1lc3NhZ2UnPjxkaXYgZGlyPSdsdHInPk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuPGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0IHdpc2hlcyw8 L2Rpdj48ZGl2PllhbyBMaTxicj48YnI+PGRpdj48aHIgaWQ9InN0b3BTcGVsbGluZyI+RnJvbTog ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTxicj5UbzogY2NhbXBAaWV0Zi5vcmc8YnI+ RGF0ZTogRnJpLCAyOSBNYXkgMjAxNSAyMToxNzozMiArMDAwMDxicj5TdWJqZWN0OiBbQ0NBTVBd IElQUiBvbiBkcmFmdC1pZXRmLWNjYW1wLWZsZXhpZ3JpZC1sYW1iZGEtbGFiZWwtMDM8YnI+PGJy PgoKCgo8c3R5bGU+PCEtLQouRXh0ZXJuYWxDbGFzcyBwLmVjeE1zb05vcm1hbCwgLkV4dGVybmFs Q2xhc3MgbGkuZWN4TXNvTm9ybWFsLCAuRXh0ZXJuYWxDbGFzcyBkaXYuZWN4TXNvTm9ybWFsIHsK Zm9udC1zaXplOjExLjBwdDsKZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsKfQoK LkV4dGVybmFsQ2xhc3MgYTpsaW5rLCAuRXh0ZXJuYWxDbGFzcyBzcGFuLmVjeE1zb0h5cGVybGlu ayB7CmNvbG9yOmJsdWU7CnRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7Cn0KCi5FeHRlcm5hbENs YXNzIHNwYW4uZWN4TXNvSHlwZXJsaW5rRm9sbG93ZWQgewpjb2xvcjpwdXJwbGU7CnRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7Cn0KCi5FeHRlcm5hbENsYXNzIHNwYW4uZWN4RW1haWxTdHlsZTE3 IHsKZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsKY29sb3I6d2luZG93dGV4dDsK fQoKLkV4dGVybmFsQ2xhc3MgLmVjeE1zb0NocERlZmF1bHQgewp9CgouRXh0ZXJuYWxDbGFzcyBk aXYuZWN4V29yZFNlY3Rpb24xIHsKfQoKLS0+PC9zdHlsZT4KCgo8ZGl2IGNsYXNzPSJlY3hXb3Jk U2VjdGlvbjEiPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj5BdXRob3JzLCBDb250cmlidXRvcnMs IENDQU1QPC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4mbmJzcDs8L3A+CjxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiPkxldKGvcyBwcm9ncmVzcyB0aGUgZmxleGkgZ3JpZCB3b3JrIHdpdGggdGhl IHByZXBhcmF0aW9uIGZvciB0aGUgbGFzdCBjYWxsIG9mIHRoZSBmbGV4aSBsYWJlbCBhbmQgdGhl IHBvbGwgZm9yIElQUiBkZWNsYXJhdGlvbnMuPC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4m bmJzcDs8L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPkFyZSB5b3UgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT88L3A+CjxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiPiZuYnNwOzwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+UGxlYXNlIHN0 YXRlIGVpdGhlcjo8L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiJObywgSSdtIG5vdCBhd2Fy ZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0IjwvcD4KPHAgY2xhc3M9ImVj eE1zb05vcm1hbCI+b3I8L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiJZZXMsIEknbSBhd2Fy ZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiPC9wPgo8cCBjbGFzcz0iZWN4TXNv Tm9ybWFsIj4mbmJzcDs8L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPklmIHNvLCBoYXMgdGhp cyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPzwvcD4K PHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+SWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRl IGVpdGhlcjo8L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiZuYnNwOzwvcD4KPHAgY2xhc3M9 ImVjeE1zb05vcm1hbCI+IlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp YW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+b3I8 L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPiJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlz Y2xvc2VkIjwvcD4KPHAgY2xhc3M9ImVjeE1zb05vcm1hbCI+Jm5ic3A7PC9wPgo8cCBjbGFzcz0i ZWN4TXNvTm9ybWFsIj5JZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRp b25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4gSWYgeW91IGFyZSBsaXN0ZWQgYXMg YSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUg YnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3Qg eW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQKIElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5v dCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVj ZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLjwvcD4KPHAgY2xh c3M9ImVjeE1zb05vcm1hbCI+Jm5ic3A7PC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj5OT1RF OiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MgVE8g TElORVMuPC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFsIj4mbmJzcDs8L3A+CjxwIGNsYXNzPSJl Y3hNc29Ob3JtYWwiPklmIHlvdSBhcmUgb24gdGhlIENDQU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFy ZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBv ZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJh Z2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3Ro ZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLAogb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lw YXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1 bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBSRkNz IGxpc3RlZCBhYm92ZSBhbmQgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90 cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuPC9wPgo8cCBjbGFzcz0iZWN4TXNvTm9ybWFs Ij4mbmJzcDs8L3A+CjxwIGNsYXNzPSJlY3hNc29Ob3JtYWwiPlRoYW5rIHlvdSw8L3A+CjxwIGNs YXNzPSJlY3hNc29Ob3JtYWwiPkRhbmllbGUgJmFtcDsgRmF0YWk8L3A+CjwvZGl2PgoKCjxicj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpDQ0FNUCBtYWls aW5nIGxpc3QKQ0NBTVBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jY2FtcDwvZGl2PjwvZGl2PiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_999c2a19-61f9-44bf-abb0-8f5027341fd9_-- From nobody Sun May 31 12:39:38 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193761A8A0D for ; Sun, 31 May 2015 12:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UjaXloLhITb for ; Sun, 31 May 2015 12:39:33 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E35D1A8A05 for ; Sun, 31 May 2015 12:39:32 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4VJdRiq015809; Sun, 31 May 2015 20:39:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t4VJdPv6015794 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 31 May 2015 20:39:25 +0100 From: "Adrian Farrel" To: "'Daniele Ceccarelli'" , "'CCAMP'" References: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> Date: Sun, 31 May 2015 20:39:26 +0100 Message-ID: <037201d09bd9$81a16170$84e42450$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0373_01D09BE1.E365C970" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFc5mf6wJbyb7mcf17hWuEODmEPDp595gzA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21582.000 X-TM-AS-Result: No--18.864-10.0-31-10 X-imss-scan-details: No--18.864-10.0-31-10 X-TMASE-MatchedRID: I31hiQfYWUMwJ6xbTjBa5umc4/pDEQa2GbJMFqqIm9ydI/DikZ1UPC3Q WVWHNjYyJKXTjaosEZJvYihi4DB4lFwbcxoyLgaZvHKClHGjjr0h9mNF8ZPJ2JTVN3FiLkyozAD QE9qHiSRowYal4wRiYCxIdq6LJ503XaS5Ieafe4N7sw7yO+Y9LGl5nVxdmJvHxe3blg14hRJncp GQs7S9GTDBUYimuP0v2W8kB86ctV6qQ5WmlFFeJ5mug812qIbz21y0oPfgygpq4coTktrGX5VEF uOCmbPDaeXbW3aJqoa0q5UeVCg1wEdb73gUDwkXQr2qXCJMSV+uiAW0p38/t9KWShEsIp8TnpBW eVcwjKBet9iiyf76iqEgGCR+ger2Ih2a2QHA7cOXA4Z4r9atc1PgO2JKQydYKAzGd8VeOIh1cNs cXGbYX52/tGtKiEAkKSbyS6Wz3z9oSgcD5h7Dxbu9iqQJLR0vtiJ1egGj+pWVIU9/CM32keygQW dkAVMsT4nzcaax9nLrpa671LAoP4cWjt28Nz4w462sl6NKNzCH7D1bP/FcOhHyswgJ7SqQOiaWf AZyIxIXlh2Nyyp8x7Rd0WwZSVdNNJyAyqAmcb/kcOvbQGFzRpdhffisWXfHC/+dM49Ci+wWPu+d PbD1+2SzR4iZcmlhLWN7JnJVmAmCIg7tJ//usdjDJsU1r62b/F4fd+T2Eg6XfY/lmJ+9hvPRCvs YnLTLXi2Kvy2p4MRucz/xUkOEzWiPLqyJ4rpQDrDTQZ5YEVp9LQinZ4QefK9dKZJ2VxiayeMtMD 9QOgDGlDvsLUDW2gYQPpLYSwkTSbITRM9k9VToQP+NxNLMjjVZAHViG6aaPK/Ise3IavhagJmwg w7SIXricLNVaxWVHjd5jG01MhTpfOF8oFfB29pCN7QUaFBt/y7RzICoc8I1F3P6+jRd1eEBZ0Af 3vRVMdpEp4CgjTTyxTfnf5kzTk5irWQDcJvQkoS02Gh/6R/9nCvKqbB/2L968JC/YIzW Archived-At: Subject: Re: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 19:39:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0373_01D09BE1.E365C970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Daniele, No, I'm not aware of any IPR that applies to this draft. Cheers, Adrian From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 29 May 2015 22:18 To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 Authors, Contributors, CCAMP Let's progress the flexi grid work with the preparation for the last call of the flexi label and the poll for IPR declarations. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, Daniele & Fatai ------=_NextPart_000_0373_01D09BE1.E365C970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Daniele,

 

No, I'm not aware of = any IPR that applies to this draft.

 

Cheers,

Adrian

 

From: CCAMP = [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele = Ceccarelli
Sent: 29 May 2015 22:18
To: CCAMP = (ccamp@ietf.org)
Subject: [CCAMP] IPR on = draft-ietf-ccamp-flexigrid-lambda-label-03

 

Authors, Contributors, = CCAMP

 

Let’s progress the flexi grid = work with the preparation for the last call of the flexi label and the = poll for IPR declarations.

 

Are you aware of any IPR that applies = to draft identified above?

 

Please state = either:

"No, I'm not aware of any IPR = that applies to this draft"

or

"Yes, I'm aware of IPR that = applies to this draft"

 

If so, has this IPR been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details)?

If yes to the above, = please state either:

 

"Yes, the IPR has been disclosed = in compliance with IETF IPR rules"

or

"No, the IPR has not been = disclosed"

 

If you answer no, please provide any = additional details you think appropriate. If you are listed as a = document author or contributor please answer the above by responding to = this email regardless of whether or not you are aware of any relevant = IPR. This document will not advance to the next stage until a response = has been received from each author and listed = contributor.

 

NOTE: THIS APPLIES TO ALL OF YOU = LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email list = but are not listed as an author or contributor, we remind you of your = obligations under the IETF IPR rules which encourages you to notify the = IETF if you are aware of IPR of others on an IETF contribution, or to = refrain from participating in any contribution or discussion related to = your undisclosed IPR. For more information, please see the RFCs listed = above and = http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

 

Thank you,

Daniele & = Fatai

------=_NextPart_000_0373_01D09BE1.E365C970-- From nobody Sun May 31 12:57:18 2015 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457AB1A8AC3 for ; Sun, 31 May 2015 12:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou4VGTWjzKzk for ; Sun, 31 May 2015 12:57:14 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701761A8940 for ; Sun, 31 May 2015 12:57:14 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so99138134wgb.3 for ; Sun, 31 May 2015 12:57:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-type:thread-index :content-language; bh=SYuAsOHFmkV3iO6aD3U7/3P222nYvNCW2EvfAaBFIaU=; b=OULSv+rsv7Z8yS81IS8Twk5sTTz8ogWsSo25DEvP/ksj6qm6pA2S1rv19spQi2uh0j 7ITQIbrTJbiQXHBKyDqGFjhD+PaOSQiPFLZDvLLlzkef6g+fjKdYxTEGDR8fEaZbsB61 Di2DDXIHr69rpCIHFx9gsK/dOHyQw0Hb8A+HMDoSkizm8AEOWbW2/eHbvmXAFdH8+O10 Zxp0he0RA2/WvYJOq4mysESg3R5DqzcwZg6xpZ1jMP3knHe9bV9B1m/nY9OQVNBoK+cY 45XFNgoNNnm9PSnsTPCw37RZcImAh9XGYlebn2bErCHYYsZ4y/amejBGjfZJwKkSvlvP EjVw== X-Gm-Message-State: ALoCoQnv6ryiRLZU0ZD02PGrGMdfV7+i/LlaJmplfDOKdsIgueAQnWnQScCGgtphkQv5/umX9XNR X-Received: by 10.180.92.162 with SMTP id cn2mr14471346wib.26.1433102233026; Sun, 31 May 2015 12:57:13 -0700 (PDT) Received: from Mal ([213.205.251.143]) by mx.google.com with ESMTPSA id fs9sm18533472wjc.34.2015.05.31.12.57.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 31 May 2015 12:57:11 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: "'Daniele Ceccarelli'" References: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481293B337@ESESSMB301.ericsson.se> Date: Sun, 31 May 2015 20:57:09 +0100 Message-ID: <002d01d09bdb$fb07cd40$f11767c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01D09BE4.5CCEA640" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFc5mf6wJbyb7mcf17hWuEODmEPDp596uxw Content-Language: en-gb Archived-At: Cc: 'CCAMP' Subject: Re: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 19:57:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01D09BE4.5CCEA640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Danielle & Fatai, No, I'm not aware of any IPR that applies to this draft. BR, Dan. From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 29 May 2015 22:18 To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] IPR on draft-ietf-ccamp-flexigrid-lambda-label-03 Authors, Contributors, CCAMP Let's progress the flexi grid work with the preparation for the last call of the flexi label and the poll for IPR declarations. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, Daniele & Fatai ------=_NextPart_000_002E_01D09BE4.5CCEA640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Danielle & = Fatai,

 

No, I'm not aware of = any IPR that applies to this draft.

 

BR, Dan. =

 

From: CCAMP = [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele = Ceccarelli
Sent: 29 May 2015 22:18
To: CCAMP = (ccamp@ietf.org)
Subject: [CCAMP] IPR on = draft-ietf-ccamp-flexigrid-lambda-label-03

 

Authors, Contributors, CCAMP

 

Let’s progress the flexi grid = work with the preparation for the last call of the flexi label and the = poll for IPR declarations.

 

Are you aware of any IPR that = applies to draft identified above?

 

Please state = either:

"No, I'm not aware of any IPR that applies to this = draft"

or

"Yes, I'm aware of IPR that applies to this = draft"

 

If so, has this IPR been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more = details)?

If yes to the above, please state = either:

 

"Yes, the IPR has been disclosed in compliance with = IETF IPR rules"

or

"No, the IPR has not been = disclosed"

 

If you answer no, please provide any additional details you = think appropriate. If you are listed as a document author or contributor = please answer the above by responding to this email regardless of = whether or not you are aware of any relevant IPR. This document will not = advance to the next stage until a response has been received from each = author and listed contributor.

 

NOTE: THIS APPLIES TO ALL OF YOU = LISTED IN THIS MESSAGE'S TO LINES.

 

If you are on the CCAMP WG email = list but are not listed as an author or contributor, we remind you of = your obligations under the IETF IPR rules which encourages you to notify = the IETF if you are aware of IPR of others on an IETF contribution, or = to refrain from participating in any contribution or discussion related = to your undisclosed IPR. For more information, please see the RFCs = listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty= .

 

Thank you,

Daniele & = Fatai

------=_NextPart_000_002E_01D09BE4.5CCEA640--