From nobody Fri Jan 2 12:14: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 62C9E1A09CF for ; Fri, 2 Jan 2015 12:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.879 X-Spam-Level: X-Spam-Status: No, score=-96.879 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FRT_SLUT=2.522, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 OaO0NUd5UA9U for ; Fri, 2 Jan 2015 12:14:54 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC06C1A009E for ; Fri, 2 Jan 2015 12:14:53 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t02KEp76024246; Fri, 2 Jan 2015 20:14:51 GMT Received: from 950129200 (089144233147.atnat0042.highway.a1.net [89.144.233.147]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t02KElOs024218 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2015 20:14:48 GMT From: "Adrian Farrel" To: Date: Fri, 2 Jan 2015 20:14:47 -0000 Message-ID: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAmyKqM3E2i5eP+S/KXayUoWZed4Q== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21220.002 X-TM-AS-Result: No--11.280-10.0-31-10 X-imss-scan-details: No--11.280-10.0-31-10 X-TMASE-MatchedRID: O84fAHwL3yYO1mBHjZk2Z2zBijri5+RVQPCWRE0Lo8INht78/JfyBH4i YBGxt1fkimtAwSiXdMtKfNd/iba9Mghqh+u1IaR7vR08UROkEAfiXOoSlo9AtYie9XwPLRloWDy 2IMXTT3OdBKKWd1ffcre9jPJWA+Z/gRy3HHXz6cZiv30iYhlp+Isp+viXR4XPEvoxTu3fj1skMu XjuduJJBIN0bzkIrLm973/oIMFf3XyvcecKfVZZrMjW/sniEQKO4pKSa7Lv+h9LdeLUfy09FdvB nmDaArQ26g0kDjoXKRuBT6o3iOHLu7ou6E91dhwlUgQqGVMqmzNXgP7liZ5IpnNlSgGlfGpkdvI xNucy79gB3SIGroEhuAbxsLrrMxvJVWqk0NljVxCnGIuUMP0VTpA2zZYJjv1tWFMPVR2CrwDXUJ oExxkYVK50ScIKuW/3ZVgL7zR0YOsrZTs2119PGZUc2jtcaSdecvjbu/xDjrGcoKvwj5q6MxFQx p3PhHy3Jcd+STYx3M1JoIJPO9ekae6VD7Jgj7YttAWxuM5sl5Aq6/y5AEOOn3hz57t9YhwIDyud jRTUrMZCUGt3x2RMeQWkLhsbF5/NtywwIf5ksXCz1ymGcrCUeZ0LhZsHFMkmP1Huhu1yDJf20sY TM3N/zM2G9lx61E59tznvLHRcTxFSULGbXbuRMOvQCMFyZ9GlzlaNFD3vRR0QbvL4PujkEdOR0K gb7aXiNl9h5S6sqlvWlwOrq3+QR6Hacd6Ohq7gnu8EE+WsiWbKpAlY2y6STdZML5k/9dKmk14jx up4NFbxNgmsP4hvMTVAQw8lyq7Gbix+omBY2yeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07YnxgmBGuBcXo0xeBPTo8Mqkgy5YF8m5Y528B9uAHu4vH+0ecsOF9dM= Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/12UA5MgvRO8TY4K7xnltK7qI3-c Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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: Fri, 02 Jan 2015 20:14:57 -0000 Hello, I've now done my AD review of this document. I am rather regretting starting the IETF last call for draft-ietf-ccamp-general-constraint- encode on which this document depends because it seems that this document introduces WSON-specific encodings (all of those before Section 4) that should/could have been made generic. In fact, I thought the point of the general encodings document was to produce protocol objects that could be used by technology-specific documents like this one. If you can respond to my comments below, we can work out whether the general encodings document needs to be brought back for more work. Thanks for your efforts with this. Adrian =========== Abstract while other parts are fairly specific to WSONs. They are either specific or they are not. I think you need s/fairly specific/specific/ --- Shouldn't the Introduction include a discussion of and reference to [Gen-encode]? --- The Introduction has This document provides efficient encodings and Note that since these encodings are relatively efficient Which are they? And relative to what? --- Section 1.1 has Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool. I think you mean [RWA-Info]. That would also make [RWA-Info] a normative reference which seems correct anyway. --- Section 1.1 makes RFC 6163 a normative reference. --- Section 2.1 seems somewhere between a copy of and a modification of the Link Set Field in 2.3 of [Gen-Encode]. Some clarification would be useful. If this is different, why is it not using one of the generic encodings applied in a specific way? If it is the same, you should probably just reference the encoding in [Gen-Encode] and describe here how the fields are used, but if you insist in re-drawing the figure it should be aligned with the figure in [Gen-Encode]. --- Section 2.1 The RB identifier represents the ID of the resource block which is a 32 bit integer. You might note that the scope of the RB identifier is local to the node on which it is applied although that node may choose to use a globally known encoding such as from RFC 6205. I assume that flexi-grid is out of scope for WSON. If it is not, then you need to think further about your 32 bit identifiers. --- Section 3.1 Why isn't the Resource Accessibility Field expressed in terms of the use of a generic Connectivity Matrix Field from section 2.1 of [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive application agnostic encodings that could be used without modification (but with applicability notes) by specific technologies. --- Section 3.2 I looked for the equivalent of the Resource Wavelength Constraints Field in [Gen-Encode]. I understand that Input Wavelength Constraints Field and Output Wavelength Constraints Field are encoded using the generic Label Set of [Gen-Encode], but I thought that the whole concept of Resource Constraints would be generic. --- Section 3.3 As with the previous section I don't see anything that is WSON-specific in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field and I wondered why [Gen-Encode] doesn't have anything to cover this. --- Section 3.3 Where Action = 0 denotes a list of 16 bit integers and Action = 1 denotes a bit map. In both cases the elements of the RB Set field are in a one-to-one correspondence with the values in the usage RB usage state area. This is not clear. I think the Action field is explaining how the RB Usage State field is encoded. - Not sure why you call it "Action" - Would be good if you could make it clear that "16 bit integers" or "bit map" apply to the RB Usage State field. But... RB#i State (16 bits, unsigned integer): indicates Resource Block #i is in use or available. - You might say what value of the 16 bit unsigned integer indicates in use and what value indicates available. - You should explain to me why a list of 16 bit integers to encode a set of Booleans is in anyway efficient or appropriate. It is *really* hard to parse from this section that the state applies to the whole RB when Action is 0, but applies to the elements of the RBs when Action is 1. At least, that is what I think I parsed from the text although I also found text in the section that convinced me you meant something else. In short, this section is not clear! --- Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? --- Sections 3.4 and 4 should list the allowed settings of I and O (presumably: 01, 10, 11). Cf. Section 3.2. --- Section 4 How do I know the length of the ResourceBlockInfo field? I need to know this to decide whether to try to parse the next bytes as another Optional subfield. I *do* when I reach the end of one Optional subfield, but I don't know whether another follows. Possibly you intend the object that includes a ResourceBlockInfo field to provide the length information, but other fields defined in this document do include lengths or enough information to deduce the lengths. --- Section 4.1 The following I and E combination are defined: s/E/O/ --- Section 4.1 1: [ITU-G.698.1] application code. 2: [ITU-G.698.2] application code. 3: [ITU-G.959.1] application code. 4: [ITU-G.695] application code. You should use the same format as in the references section. E.g., [G.959.1]. Do you mean 698 or 694? You have references for 694.1 and 694.2, but not 698.1 or 698.2. But 694.1 does not seem to include any "application codes" - they're in 698.1 and 698.2. Each of the subsections 4.1.1-4.1.4 should include a citations. --- Section 4.1 How do I interpret a Vendor-Specific Application Code? Is there an OUI I'm missing? --- I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and have asked the chairs to send a liaison to ITU-T Q6/15 asking them to cast an eye over the text of these sections. --- 4.1.1 Where (values between parenthesis refer to ITU defined values as reported above): Please remove the parentheses from this sentence. --- 4.1.1 and 4.1.2 An Optional F can be added indicating a FEC Encoding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| D |S| c | W | y | t | z | v | F | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F (suffix): = 0 reserved, = 1 Fec Encoding Values not mentioned here are not allowed in this application code If F is optional but only one value is allowed (viz. 1) how do I opt to not indicate a FEC Encoding? --- 4.1.1 and 4.1.2 Your definition of parameter c makes RFC 6205 a normative reference. . I think you could usefully point with more precision to Figure 2 in Section 3.2 of RFC 6205. However, I wonder whether you want to allow new values that may be added to the IANA registry created by Section 5.2 of RFC 6205 --- 4.1.3 and 4.1.4 n: maximum number of channels (10 bits, up to 1024 channels) Hmmm, 2^10 is 1024, but 10 bits can only encode 1023 unless you say that n=0 is not valid and so n is actually max channels minus one. --- 4.4 The processing capability list field is then given by: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Processing Cap ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional capability parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the processing ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the processing Cap ID is "regeneration capability", the I don't believe you have told me how to encode "regeneration capability" into the Processing Cap ID field. Possibly you mean that the numbered list above is intended to define the settings of this field. If so then: - say so - explain that "Fault and performance monitoring" and "Vendor Specific capability" have no additional capability parameters - probably remove the note about "Fault and performance monitoring" and "vendor specific capability" because if it isn't here it is, of course, for future study. --- 4.4 Note that when the capability of regenerator is indicated to be Selective Regeneration Pools, regeneration pool properties such as input and output restrictions and availability need to be specified. The code point for this is subject to further study. I think you mean to replace that final line with... These properties will be encoded in the capabilities field starting with the bits marked Reserved in the figure. An additional specification describing the encoding of these parameters is required before the value C=2 can be used. --- Section 6 In Section 6 and 6.1 you appear to be creating a new top-level registry called "GMPLS Routing Parameters for WSON" with a sub-registry called "Types for subfields of WSON Resource Block Information". It's a shame to create a whole new top-level registry. I suppose you think that this information will only ever be used in routing and never in signaling. Probably right, in which case you are good to go, although your text could be clearer. --- Section A.3 is using some form of BNF to represent information. This is probably RBNF from RFC 5511. Anyway, you need to give a reference so people can read it. It would be nice to lay the BNF out on the page in a more readable way. From nobody Sun Jan 4 02:31: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 F37521A7D81; Sun, 4 Jan 2015 02:31:35 -0800 (PST) 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 hKobyh2eK6C5; Sun, 4 Jan 2015 02:31:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A151A7034; Sun, 4 Jan 2015 02:31:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150104103134.5358.74067.idtracker@ietfa.amsl.com> Date: Sun, 04 Jan 2015 02:31:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/ZauJySXxrEQvL_rQUi7aByweXXM Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-03.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: Sun, 04 Jan 2015 10:31:36 -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 : Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers Authors : Adrian Farrel Daniel King Yao Li Fatai Zhang Filename : draft-ietf-ccamp-flexigrid-lambda-label-03.txt Pages : 14 Date : 2015-01-04 Abstract: GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid. This document updates RFC 3471 and RFC 6205 by introducing a new label format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-lambda-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-flexigrid-lambda-label-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-flexigrid-lambda-label-03 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 Sun Jan 4 02:32:41 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 EF5741A7D81 for ; Sun, 4 Jan 2015 02:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Mpcr0WTROkGD for ; Sun, 4 Jan 2015 02:32:39 -0800 (PST) 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 BA6401A7034 for ; Sun, 4 Jan 2015 02:32:38 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t04AWZpV025494 for ; Sun, 4 Jan 2015 10:32:35 GMT Received: from 950129200 (089144230000.atnat0039.highway.a1.net [89.144.230.0]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t04AWXgc025480 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 4 Jan 2015 10:32:34 GMT From: "Adrian Farrel" To: References: <20150104103134.5358.97573.idtracker@ietfa.amsl.com> In-Reply-To: <20150104103134.5358.97573.idtracker@ietfa.amsl.com> Date: Sun, 4 Jan 2015 10:32:32 -0000 Message-ID: <00e101d02809$c14b5220$43e1f660$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLrPb4A0GR9gqTX8GRw1pmAN8XaqZp5l9XQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21222.006 X-TM-AS-Result: No--10.685-10.0-31-10 X-imss-scan-details: No--10.685-10.0-31-10 X-TMASE-MatchedRID: QnouyRTPIlpDKVWWbGcmRriMC5wdwKqdr4ukWaaTegDOS3qd4Dd5VsLm p4jPUF8tdps0hZoS9mJhbVwEmz1Ybeslee39anPslVHM/F6YkvSHxi2fvkKUM/Q1K5DO1u1D0L2 eqCmMq5aCLemkJzU5Xg/87VUpZ/8Gey2hwIiqvBNwUSK4/EeOxSOSuAnftGqPjNnoU1fopotpgr Yvic2QdZyujR9JCXla1wze+AUePnxI5I2GT1aZYYGU23hVIa8hGSqdEmeD/nVZps+y1VXzqZm3C kZsyRGFO3icd6nCIucOYLFb+3JssZmRr1k6e+lgngIgpj8eDcBZDL1gLmoa/MMVrGYAcjcWq7rF UcuGp/EgBwKKRHe+rzyhTaNxm1ojWS1sqYeq9uFn3dzPuYanDLUUYGUCJoVHP7guE0gdlIw= Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/CgI11SqEtSxkRcC-SxNZPb-1Zh0 Subject: [CCAMP] FW: New Version Notification for draft-ietf-ccamp-flexigrid-lambda-label-03.txt 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, 04 Jan 2015 10:32:41 -0000 Just an update for the New Year and to fix a nit in the Acknowledgements = section. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 04 January 2015 10:32 > To: Daniel King; Fatai Zhang; Adrian Farrel; Daniel King; Yao Li; = Fatai Zhang; Yao Li; > Adrian Farrel > Subject: New Version Notification for = draft-ietf-ccamp-flexigrid-lambda-label- > 03.txt >=20 >=20 > A new version of I-D, draft-ietf-ccamp-flexigrid-lambda-label-03.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Name: draft-ietf-ccamp-flexigrid-lambda-label > Revision: 03 > Title: Generalized Labels for the Flexi-Grid in Lambda Switch Capable > (LSC) Label Switching Routers > Document date: 2015-01-04 > Group: ccamp > Pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-flexigrid- > lambda-label-03.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-lambda- > label/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-ccamp-flexigrid-lambda-label- > 03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-flexigrid-lambda- > label-03 >=20 > Abstract: > GMPLS supports the description of optical switching by identifying > entries in fixed lists of switchable wavelengths (called grids) > through the encoding of lambda labels. Work within the ITU-T Study > Group 15 has defined a finer granularity grid, and the facility to > flexibly select different widths of spectrum from the grid. This > document defines a new GMPLS lambda label format to support this > flexi-grid. >=20 > This document updates RFC 3471 and RFC 6205 by introducing a new > label format. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Sun Jan 4 18:57: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 D2F6B1A19E9 for ; Sun, 4 Jan 2015 18:57:11 -0800 (PST) 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 jQvwH0RYUqXO for ; Sun, 4 Jan 2015 18:57:08 -0800 (PST) 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 5AB461A19E4 for ; Sun, 4 Jan 2015 18:57:08 -0800 (PST) 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 BQV94849; Mon, 05 Jan 2015 02:57:05 +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; Mon, 5 Jan 2015 02:57:04 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.250]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Mon, 5 Jan 2015 10:56:59 +0800 From: Fatai Zhang To: "ccamp@ietf.org" Thread-Topic: Draft Text for CCAMP to ITU-T Liason regarding WSON-Encode Thread-Index: AdAok0Tdo77YxRLDTYqpfVotXwpc/g== Date: Mon, 5 Jan 2015 02:56:58 +0000 Message-ID: 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_F82A4B6D50F9464B8EBA55651F541CF85CBD4AA1SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/LFdGdGgvrMmfCRuaXru6SBKKj1A Subject: [CCAMP] Draft Text for CCAMP to ITU-T Liason regarding WSON-Encode 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, 05 Jan 2015 02:57:12 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF85CBD4AA1SZXEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The AD is reviewing [draft-ietf-ccamp-rwa-wson-encode] and has asked us to = check the data plane details with the ITU-T. Therefore, we prepared the following draft liaison to ITU-T Q6/15. Please review the draft text to see if you have any comments ASAP, and then= we are going to send the liaison to ITU-T before this Friday. =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=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=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=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 The CCAMP working group of the IETF would like to draft the attention of Q6= /15 to https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ .= This document describes encodings for a number of parameters that will be = used in GMPLS protocols for operation of Wavelength Switched Optical Networ= ks. The document is in its final stages and will soon progress to IETF last cal= l. We would particularly welcome your review of sections 4.1.1-4.1.4. These se= ctions describe the encoding of Application Codes as described in G.698.1, = G.698.2, G.959.1, and G.695. The questions you might like to consider in th= is respect are: - Are we capturing current application codes? In other words, are our references correct and correctly used? - Are there any application codes we are missing? Is our set of references correct and have we included all of the applicat= ion codes in the references? - Have we captured all of the parameters of the application codes? In our attempt to capture the application codes into formats we can use i= n our protocols, have we found all of the parameters that comprise the appl= ication codes? - Are the fields for each parameter of each application code appropriately = sized and with the correct ranges? In other words, will we be able to properly encode the application codes = defined today and their possible future extensions? In view of the progress of this work, we would be very happy to receive inf= ormal responses and guidance from individuals or from the Question as a who= le if it has time to formulate an agreed response. Many thanks for your attention. Fatai Zhang and Daniele Ceccarelli (CCAMP WG chairs) =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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Best Regards Fatai --_000_F82A4B6D50F9464B8EBA55651F541CF85CBD4AA1SZXEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The AD is reviewing [draft-i= etf-ccamp-rwa-wson-encode] and has asked us to check the data plane details= with the ITU-T.

 

Therefore, we prepared the f= ollowing draft liaison to ITU-T Q6/15.

 

Please review the draft text= to see if you have any comments ASAP, and then we are going to send the li= aison to ITU-T before this Friday.

 

=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=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=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=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

The CCAMP working group of t= he IETF would like to draft the attention of Q6/15 to https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ = . This document describes encodings for a number of parameters that will be= used in GMPLS protocols for operation of Wavelength Switched Optical Networks.

The document is in its final= stages and will soon progress to IETF last call.

 

We would particularly welcom= e your review of sections 4.1.1-4.1.4. These sections describe the encoding= of Application Codes as described in G.698.1, G.698.2, G.959.1, and G.695.= The questions you might like to consider in this respect are:

 

- Are we capturing current a= pplication codes?

  In other words, are o= ur references correct and correctly used?

- Are there any application = codes we are missing?

  Is our set of referen= ces correct and have we included all of the application codes in the refere= nces?

- Have we captured all of th= e parameters of the application codes?

  In our attempt to cap= ture the application codes into formats we can use in our protocols, have w= e found all of the parameters that comprise the application codes?

- Are the fields for each pa= rameter of each application code appropriately sized and with the correct r= anges?

  In other words, will = we be able to properly encode the application codes defined today and their= possible future extensions?

 

In view of the progress of t= his work, we would be very happy to receive informal responses and guidance= from individuals or from the Question as a whole if it has time to formula= te an agreed response.

 

Many thanks for your attenti= on.

 

Fatai Zhang and Daniele Cecc= arelli (CCAMP WG chairs)

&n= bsp;

=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=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

&n= bsp;

&n= bsp;

Best Re= gards

&n= bsp;

Fatai

 

--_000_F82A4B6D50F9464B8EBA55651F541CF85CBD4AA1SZXEMA504MBSchi_-- From nobody Tue Jan 6 01:09: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 9B6091A1EEE for ; Tue, 6 Jan 2015 01:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.396 X-Spam-Level: ** X-Spam-Status: No, score=2.396 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_27=0.6, 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 m2s5uWzQRhjs for ; Tue, 6 Jan 2015 01:09:05 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4681A0079 for ; Tue, 6 Jan 2015 01:09:04 -0800 (PST) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t06994CK001337 for ; Tue, 6 Jan 2015 18:09:04 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id E890D5F591 for ; Tue, 6 Jan 2015 18:09:03 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1.m.ecl.ntt.co.jp [129.60.5.246]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id DBCC25F587 for ; Tue, 6 Jan 2015 18:09:03 +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 t06993Uu008366 for ; Tue, 6 Jan 2015 18:09:03 +0900 Message-ID: <54ABA6E5.4080501@lab.ntt.co.jp> Date: Tue, 06 Jan 2015 18:12:05 +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: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/azJXIpRknRE8hnStMLnFoDgSowk Subject: [CCAMP] Call for Presentation: iPOP 2015 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, 06 Jan 2015 09:09:07 -0000 [Apologies, if you receive multiple copies of this CFP] --------------------------------------- Call for Presentation 11th International Conference on IP + Optical Network (iPOP 2015) April 20-22, 2015 Okinawa Jichikaikan, Naha Okinawa Japan http://www.pilab.jp/ipop2015/ Important Dates: Submission deadline of one-page abstract: January 16, 2015 Notification of acceptance: February 23, 2015 Submission deadline of final presentation slides: March 13, 2015 Following the successful events of iPOP, the 11th Conference on IP+Optical Network (iPOP 2015) will be held at Okinawa Jichikaikan, Naha Okinawa Japan, April 20-22, 2015. The conference has been provided opportunities for both of the industry and the academia to share their knowledge, new findings, and experiences on the state-of-the-art IP and optical networking technologies for these ten years. The Technical Program Committee for iPOP 2015 is soliciting presentation proposals for this conference. Architecture and protocol designs, experiments/PoCs/field trials, theories/algorithms, implementations, and operational experiences are solicited. The topics of the conference will include but not be limited to the following: * Control plane (MPLS/GMPLS, OpenFlow, etc) * SDN for packet and optical transport networks * MLN (Multi-Layer Network), MRN (Multi-Region Network) * TE (Traffic Engineering), PCE (Path Computation Element) * Network abstraction/virtualization * Flex-grid, elastic optical networks * Optical networking/switching for cloud services * Data center and WAN orchestration * Carrier Ethernet and MPLS-TP for backhauling * Service function chaining for mobile networks * Security * QoS (Quality of Service)/QoE (Quality of Experience) * Network operation and management * Standardization/interoperability * Open Source Software (OSS) for SDN/NFV * DevOps Submit an extended abstract (400 words, 1 page), including figures and diagrams, speaker鈥檚 name, affiliation, and contact information, to the Technical Program Committee: ipop2015-cfp@pilab.jp. Please see http://www.pilab.jp/ipop2015/ for more details. ------------------------------------------------------------------------ -- 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 From nobody Tue Jan 6 23:02:10 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 9EA4F1A896A; Tue, 6 Jan 2015 23:02:08 -0800 (PST) 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 ayH4jY1Uh8fw; Tue, 6 Jan 2015 23:02:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5621A8960; Tue, 6 Jan 2015 23:02:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107070206.9128.91206.idtracker@ietfa.amsl.com> Date: Tue, 06 Jan 2015 23:02:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/_TolSQhfoozx2CaZAY4qthljOuc Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-rsvp-te-ext-01.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: Wed, 07 Jan 2015 07:02:09 -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 : RSVP-TE Signaling Extensions in support of Flexible Grid Authors : Fatai Zhang Xian Zhang Adrian Farrel Oscar Gonzalez de Dios Daniele Ceccarelli Filename : draft-ietf-ccamp-flexible-grid-rsvp-te-ext-01.txt Pages : 12 Date : 2015-01-06 Abstract: This memo describes the extensions to the Resource reservation Protocol Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexible-grid-rsvp-te-ext/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-rsvp-te-ext-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-flexible-grid-rsvp-te-ext-01 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 Jan 6 23:06: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 088831A8974 for ; Tue, 6 Jan 2015 23:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 mJf3v7-SKmjr for ; Tue, 6 Jan 2015 23:06:04 -0800 (PST) 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 E85FD1A8970 for ; Tue, 6 Jan 2015 23:06:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNQ95099; Wed, 07 Jan 2015 07:06:02 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 7 Jan 2015 07:06:01 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.43]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 7 Jan 2015 15:05:59 +0800 From: "Zhangxian (Xian)" To: CCAMP Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-rsvp-te-ext-01.txt Thread-Index: AQHQKkffuf68xiNR/kuqPfgfMuqgA5y0O0/Q Date: Wed, 7 Jan 2015 07:05:58 +0000 Message-ID: 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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/MT6_uztSaBnxgw_uaIyiPpO-OCc Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-flexible-grid-rsvp-te-ext-01.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: Wed, 07 Jan 2015 07:06:19 -0000 SGksIA0KDQogICBXZSBoYXZlIHVwZGF0ZWQgdGhpcyBkcmFmdCBzaW5jZSBpdCB3YXMgZXhwaXJl ZCBkdXJpbmcgQ2hyaXN0bWFzIHRpbWUuIFRoZSBtYWluIGNoYW5nZXMgYXJlOg0KDQoxKSBBZGQg c29tZSBleHBsYW5hdGlvbiB0ZXh0LCB0byBpbmRpY2F0ZSB0aGUgdXNlIG9mIGNvbXBvc2l0ZSBs YWJlbC4gPT4gdGhpcyBmb2xsb3dzIHRoZSBjaGFuZ2Ugb2YgZmxleGktZ3JpZCBsYWJlbCBkcmFm dDsNCjIpIGdyYW1tYXRpY2FsIHRpZHktdXAuDQoNCiAgSWYgeW91IGhhdmUgYW55IGZ1cnRoZXIg Y29tbWVudHMsIHBsZWFzZSBsZXQgdXMga25vdy4gDQoNClJlZ2FyZHMsDQpYaWFuICgmIGFsbCBh dXRob3JzKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ0NBTVAgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnDQpTZW50OiAyMDE1xOox1MI3yNUgMTU6MDINClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmcNCkNjOiBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWNjYW1wLWZsZXhpYmxlLWdyaWQtcnN2cC10ZS1leHQtMDEudHh0DQoNCg0KQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbW1v biBDb250cm9sIGFuZCBNZWFzdXJlbWVudCBQbGFuZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRG Lg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFJTVlAtVEUgU2lnbmFsaW5nIEV4dGVuc2lv bnMgaW4gc3VwcG9ydCBvZiBGbGV4aWJsZSBHcmlkDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6 IEZhdGFpIFpoYW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgIFhpYW4gWmhhbmcNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgQWRyaWFuIEZhcnJlbA0KICAgICAgICAgICAgICAgICAgICAg ICAgICBPc2NhciBHb256YWxleiBkZSBEaW9zDQogICAgICAgICAgICAgICAgICAgICAgICAgIERh bmllbGUgQ2VjY2FyZWxsaQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtZmxl eGlibGUtZ3JpZC1yc3ZwLXRlLWV4dC0wMS50eHQNCglQYWdlcyAgICAgICAgICAgOiAxMg0KCURh dGUgICAgICAgICAgICA6IDIwMTUtMDEtMDYNCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gZGVz Y3JpYmVzIHRoZSBleHRlbnNpb25zIHRvIHRoZSBSZXNvdXJjZSByZXNlcnZhdGlvbg0KICAgUHJv dG9jb2wgVHJhZmZpYyBFbmdpbmVlcmluZyAoUlNWUC1URSkgc2lnbmFsaW5nIHByb3RvY29sIHRv IHN1cHBvcnQNCiAgIExhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1BzKSBpbiBhIEdNUExTLWNvbnRy b2xsZWQgbmV0d29yayB0aGF0DQogICBpbmNsdWRlcyBkZXZpY2VzIHVzaW5nIHRoZSBmbGV4aWJs ZSBvcHRpY2FsIGdyaWQuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWNjYW1wLWZsZXhpYmxlLWdyaWQtcnN2cC10ZS1leHQvDQoNClRoZXJlJ3MgYWxzbyBhIGh0 bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jY2FtcC1mbGV4aWJsZS1ncmlkLXJzdnAtdGUtZXh0LTAxDQoNCkEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2NhbXAtZmxleGlibGUtZ3JpZC1yc3ZwLXRl LWV4dC0wMQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo= From nobody Wed Jan 7 05:06:32 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 40E001A8A4D for ; Wed, 7 Jan 2015 05:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gin9nZLePn9h for ; Wed, 7 Jan 2015 05:06:27 -0800 (PST) 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 E2F151A8A15 for ; Wed, 7 Jan 2015 05:06:26 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-13-54ad2f507012 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.60.24955.05F2DA45; Wed, 7 Jan 2015 14:06:25 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 14:06:24 +0100 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: New Liaison Statement, "LS on ITU-T SG15 OTNT standardization work plan to ccamp" Thread-Index: AQHQG9BSMPUCpwqbAkG/XCmbfSf27Zy0u4Iw Date: Wed, 7 Jan 2015 13:06:24 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481282962C@ESESSMB301.ericsson.se> References: <20141219211111.31859.42822.idtracker@ietfa.amsl.com> In-Reply-To: <20141219211111.31859.42822.idtracker@ietfa.amsl.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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+JvjW6g/toQg5ajLBZP5txgsehrPs/q wOTRcuQtq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDK6296yFjwSrti0fhdjA+MC4S5GTg4JAROJ /xteMUHYYhIX7q1n62Lk4hASOMIoceDHRVYIZxGjxIZbl4EcDg42ASuJJ4d8QBpEBHQl9m68 zgwSZhZwlNh93R4kLCyQIPH2aSMzREmixPxZU1khbCOJNfMfgMVZBFQkTiz/ywJi8wr4Shy/ cRXsBiGgMctPnQOzOQWcJKb3zmAHsRkFZCUm7F7ECGIzC4hL3HoyH+pmAYkle84zQ9iiEi8f /2OFsJUkGpc8YYU4TVNi/S59iFZFiSndD9kh1gpKnJz5hGUCo9gsJFNnIXTMQtIxC0nHAkaW VYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBkXNwy2/VHYyX3zgeYhTgYFTi4TVYuCZEiDWx rLgy9xCjNAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwusr2lwXud5rSafBN bHGtScKX886Sv6Jmp699fDPVJdzdUSbAoVv/Ks8uO//lBZMf6UioMui2skSu0jh7+KmaudKm 8gqD10snmD1xbxHvnvVs/8dIXePw4wVfnxx00+MwP1f+ekf2w3/pa3Ma9FXFpRom211YUpV9 mW/Z1Xte7tpKjDq/nsxXYinOSDTUYi4qTgQAAn7rrX0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/1Ts0O11mrVlYh-4W2itwN9xe0lI Subject: [CCAMP] FW: New Liaison Statement, "LS on ITU-T SG15 OTNT standardization work plan to ccamp" 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, 07 Jan 2015 13:06:30 -0000 QWxsLA0KDQpXZSByZWNlaXZlZCBhIGxpYWlzb24gZnJvbSB0aGUgSVRVLVQgU0cxNSB3aXRoIGFu IHVwZGF0ZSBvbiB0aGVpciBPVE5UIHN0YW5kYXJkaXphdGlvbiB3b3JrIHBsYW4gKGxpbmsgYmVs b3cpLg0KDQpQbGVhc2UgcmV2aWV3IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3Qu DQoNClRoYW5rcw0KRGFuaWVsZSAmIEZhdGFpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBMaWFpc29uIFN0YXRlbWVudCBNYW5hZ2VtZW50IFRvb2wgW21haWx0bzpsc210QGll dGYub3JnXSANClNlbnQ6IHZlbmVyZMOsIDE5IGRpY2VtYnJlIDIwMTQgMjI6MTENClRvOiBEYW5p ZWxlIENlY2NhcmVsbGk7IEZhdGFpIFpoYW5nDQpDYzogQWRyaWFuIEZhcnJlbDsgQWxpYSBBdGxh czsgY2NhbXBAaWV0Zi5vcmc7IEpvaG4gRHJha2U7IFNjb3R0IE1hbnNmaWVsZDsgbmFvdGFrYS5t b3JpdGFAbnR0LWF0LmNvLmpwDQpTdWJqZWN0OiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJMUyBv biBJVFUtVCBTRzE1IE9UTlQgc3RhbmRhcmRpemF0aW9uIHdvcmsgcGxhbiB0byBjY2FtcCINCg0K VGl0bGU6IExTIG9uIElUVS1UIFNHMTUgT1ROVCBzdGFuZGFyZGl6YXRpb24gd29yayBwbGFuIHRv IGNjYW1wIFN1Ym1pc3Npb24gRGF0ZTogMjAxNC0xMi0xOSBVUkwgb2YgdGhlIElFVEYgV2ViIHBh Z2U6IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEzNjcvDQpQbGVhc2UgcmVw bHkgYnkgMjAxNS0wNi0wNw0KRnJvbTogSVRVLVQgU0cgMTUgIChHcmVnIEpvbmVzIDxncmVnLmpv bmVzQGl0dS5pbnQ+KQ0KVG86IENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJlbWVudCBQbGFuZSAo RGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPiwgRmF0 YWkgWmhhbmcgPHpoYW5nZmF0YWlAaHVhd2VpLmNvbT4pDQpDYzogQWRyaWFuIEZhcnJlbCA8YWRy aWFuQG9sZGRvZy5jby51az4sQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb20+LGNjYW1wQGll dGYub3JnLEpvaG4gRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldD4sU2NvdHQgTWFuc2ZpZWxkIDxT Y290dC5NYW5zZmllbGRARXJpY3Nzb24uY29tPiBSZXNwb25zZSBDb250YWN0OiBuYW90YWthLm1v cml0YUBudHQtYXQuY28uanAgVGVjaG5pY2FsIENvbnRhY3Q6IA0KUHVycG9zZTogRm9yIGNvbW1l bnQNCg0KQm9keTogVGhhbmsgeW91IGZvciB5b3VyIHByZXZpb3VzIHJldmlldyBhbmQgY29tbWVu dHMgb24g4oCcT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya3MgJiBUZWNobm9sb2dpZXMgc3RhbmRh cmRpemF0aW9uIHdvcmsgcGxhbi7igJ0gQXR0YWNoZWQgaXMgSXNzdWUgMTksIHRoZSBsYXRlc3Qg dmVyc2lvbiB0aGF0IHdhcyB1cGRhdGVkIGJ5IHRoZSBTRzE1IG1lZXRpbmcgaW4gRGVjZW1iZXIg MjAxNC4gV2UgYXBwcmVjaWF0ZSB5b3VyIGNvbnRpbnVlZCByZXZpZXcgYW5kIGNvbW1lbnRzIHdo aWNoIGFsbG93IHVzIHRvIGtlZXAgdGhlIGRvY3VtZW50IHVwLXRvLWRhdGUuDQoNCkF0dGFjaDoN CuKIkglPVE5UIHN0YW5kYXJkaXphdGlvbiB3b3JrIHBsYW4sIElzc3VlIDE5IChURDI4Mi9QTEVO IFJldi4xKQ0KQXR0YWNobWVudHM6DQoNCiAgICBMUyBvbiBJVFUtVCBTRzE1IE9UTlQgc3RhbmRh cmRpemF0aW9uIHdvcmsgcGxhbiB0byBjY2FtcA0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE0LTEyLTE5LWl0dS10LXNnLTE1LWNj YW1wLWxzLW9uLWl0dS10LXNnMTUtb3RudC1zdGFuZGFyZGl6YXRpb24td29yay1wbGFuLXRvLWNj YW1wLWF0dGFjaG1lbnQtMS56aXANCg0K From nobody Sun Jan 11 16:38:08 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 848521A8895; Sun, 11 Jan 2015 16:38:06 -0800 (PST) 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 YYEenUo96LWS; Sun, 11 Jan 2015 16:38:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD1A1A8873; Sun, 11 Jan 2015 16:38:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112003805.25090.47753.idtracker@ietfa.amsl.com> Date: Sun, 11 Jan 2015 16:38:05 -0800 Archived-At: Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.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, 12 Jan 2015 00:38:06 -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 : Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE Authors : Elisa Bellagamba Attila Takacs Gregory Mirsky Loa Andersson Pontus Skoldstrom Dave Ward Filename : draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt Pages : 28 Date : 2015-01-11 Abstract: This specification describes the configuration of pro-active MPLS-TP (MPLS-Transport Profile) Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15 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 Wed Jan 14 15:20:42 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 B15111ACF1D for ; Wed, 14 Jan 2015 15:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_SLUT=2.522, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 iYn-sZBzjoDU for ; Wed, 14 Jan 2015 15:20:37 -0800 (PST) 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 147441ACEA7 for ; Wed, 14 Jan 2015 15:20:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOB02565; Wed, 14 Jan 2015 23:20:33 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 14 Jan 2015 23:20:32 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Wed, 14 Jan 2015 15:20:21 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Thread-Index: AdAmyKqM3E2i5eP+S/KXayUoWZed4QFfHtyw Date: Wed, 14 Jan 2015 23:20:20 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> In-Reply-To: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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, 14 Jan 2015 23:20:40 -0000 Hi Adrian, Thanks.=20 My comment for general vs. WSON-specific issue is that the design philosophy of general encoding was to generalize a common elemen= t that can be applied to different technologies. For instance, connectivity matrix definitely can= be applied to WSON, OTN and other Switching technology as one encoding can fit to all. You seemed to desire a= sharing of the same encoding to describe=20 different entities where possible. This is fine for label vs. wavelength as= there is one-to-one mapping for this. However, Resource Block encoding cannot properly share with the connectivit= y matrix encoding with two reasons: 1. They refer to different elements in the node. 2. They require different sets of fields with different number of fields.=20 Please also see my comment in-line for details. Thanks, Young -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 02, 2015 2:15 PM To: draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Hello, I've now done my AD review of this document. I am rather regretting starting the IETF last call for draft-ietf-ccamp-general-constraint- encode on which this document depends because it seems that this document introduces WSON-specific encodings (all of those before Section 4) that should/could have been made generic. In fact, I thought the point of the general encodings document was to produce protocol objects that could be used by technology-specific documents like this one. If you can respond to my comments below, we can work out whether the general encodings document needs to be brought back for more work. Thanks for your efforts with this. Adrian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract while other parts are fairly specific to WSONs. They are either specific or they are not. I think you need s/fairly specific/specific/ [YOUNG] YES.=20 --- Shouldn't the Introduction include a discussion of and reference to [Gen-encode]? [YOUNG] A good point. Will add this.=20 --- The Introduction has This document provides efficient encodings and Note that since these encodings are relatively efficient Which are they? And relative to what? [YOUNG] will remove 'relatively'. --- Section 1.1 has Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool. I think you mean [RWA-Info]. That would also make [RWA-Info] a normative reference which seems correct anyway. [YOUNG] Yes. Will change.=20 --- Section 1.1 makes RFC 6163 a normative reference. [YOUNG] Yes. Will correct.=20 --- Section 2.1 seems somewhere between a copy of and a modification of the Link Set Field in 2.3 of [Gen-Encode]. Some clarification would be useful. If this is different, why is it not using one of the generic encodings applied in a specific way? If it is the same, you should probably just reference the encoding in [Gen-Encode] and describe here how the fields are used, but if you insist in re-drawing the figure it should be aligned with the figure in [Gen-Encode]. [YOUNG] not quite. Link Set and Label Set are two different things with dif= ferent fields.=20 Link Set has directionality and identifier format while Label Set does not = have these fields but has connectivity field. Not sure how we can point to each other.=20 --- Section 2.1 The RB identifier represents the ID of the resource block which is a 32 bit integer. You might note that the scope of the RB identifier is local to the node on which it is applied although that node may choose to use a globally known encoding such as from RFC 6205. I assume that flexi-grid is out of scope for WSON. If it is not, then you need to think further about your 32 bit identifiers. [YOUNG] Flex-grid is out of scope here. In addition, RB identifier is a res= ource block ID Which is different from wavelength identifier. I am sure how a globally kno= wn encoding for Wavelength id can be used for RB identifier. They seemed to refer two diffe= rent entities.=20 =20 --- Section 3.1 Why isn't the Resource Accessibility Field expressed in terms of the use of a generic Connectivity Matrix Field from section 2.1 of [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive application agnostic encodings that could be used without modification (but with applicability notes) by specific technologies. [YOUNG] Not quite. Connectivity Matrix encoding cannot be used for Resource= Accessibility Field as the latter has additional entity (namely, RB set field) to describe. We generalized a = single-stage connectivity matrix in [Gen-Encode] that can=20 be applicable to any switching technology. Here in WSON, we have a need to = model RB constraints (for the pool of Wavelength Converters) from/to input/output link sets. Putting two different entities into one cod= ing was not the choice of the authors.=20 --- Section 3.2 I looked for the equivalent of the Resource Wavelength Constraints Field in [Gen-Encode]. I understand that Input Wavelength Constraints Field and Output Wavelength Constraints Field are encoded using the generic Label Set of [Gen-Encode], but I thought that the whole concept of Resource Constraints would be generic. [YOUNG] Again, I think the design of generalization is not intended to=20 share the same encoding to describe two different entities. Besides, I do not see the need to generalize encoding of an entity that has no particular use in other technologies than WSON.=20 --- Section 3.3 As with the previous section I don't see anything that is WSON-specific in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field and I wondered why [Gen-Encode] doesn't have anything to cover this. [YOUNG] RB is wavelength converters, which is a unique WSON element.=20 --- Section 3.3 Where Action =3D 0 denotes a list of 16 bit integers and Action =3D 1 denotes a bit map. In both cases the elements of the RB Set field are in a one-to-one correspondence with the values in the usage RB usage state area. This is not clear. I think the Action field is explaining how the RB Usage State field is encoded. - Not sure why you call it "Action" - Would be good if you could make it clear that "16 bit integers" or "bit map" apply to the RB Usage State field. But... RB#i State (16 bits, unsigned integer): indicates Resource Block #i is in use or available. - You might say what value of the 16 bit unsigned integer indicates in use and what value indicates available. - You should explain to me why a list of 16 bit integers to encode a set of Booleans is in anyway efficient or appropriate. It is *really* hard to parse from this section that the state applies to the whole RB when Action is 0, but applies to the elements of the RBs when Action is 1. At least, that is what I think I parsed from the text although I also found text in the section that convinced me you meant something else. In short, this section is not clear! [YOUNG] Indeed it is not clear. For this, let me get back to you shortly.=20 --- Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? [YOUNG] I think the reason for B bit is not included in Section 3.4 is the = context where it won't be very useful (even if we have a B bit) as input wa= velengths available will hardly match with output wavelength available in m= ost cases. Compared to this, wavelength constraints can more often be same = for input and output.=20 --- Sections 3.4 and 4 should list the allowed settings of I and O (presumably: 01, 10, 11). Cf. Section 3.2. [YOUNG] OK. How adding: Currently the only valid combinations of (I,O) are (0,1), (1,0), or (1,1).= =20 --- Section 4 How do I know the length of the ResourceBlockInfo field? I need to know this to decide whether to try to parse the next bytes as another Optional subfield. I *do* when I reach the end of one Optional subfield, but I don't know whether another follows. Possibly you intend the object that includes a ResourceBlockInfo field to provide the length information, but other fields defined in this document do include lengths or enough information to deduce the lengths. [YOUNG] Yes, you're right. It is not completely consistent. How about the f= ollowing Encoding:=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|O| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RB Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional subfield 1 | : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional subfield N | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Length: 16 bits The total length of this field in bytes. --- Section 4.1 The following I and E combination are defined: s/E/O/ [YOUNG] Agree. Thanks. --- Section 4.1 1: [ITU-G.698.1] application code. 2: [ITU-G.698.2] application code. 3: [ITU-G.959.1] application code. 4: [ITU-G.695] application code. You should use the same format as in the references section. E.g., [G.959.1]. Do you mean 698 or 694? You have references for 694.1 and 694.2, but not 698.1 or 698.2. But 694.1 does not seem to include any "application codes" - they're in 698.1 and 698.2. Each of the subsections 4.1.1-4.1.4 should include a citations. [YOUNG] Yes, for the reference format. The right references are 698.1 and 6= 98.2 --- will correct with the right references. Citations will be added in= each of the subsections.=20 --- Section 4.1 How do I interpret a Vendor-Specific Application Code? Is there an OUI I'm missing? [YOUNG] Not sure if I understood this question. What is "OUI"?=20 --- I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and have asked the chairs to send a liaison to ITU-T Q6/15 asking them to cast an eye over the text of these sections. [YOUNG] Thanks. It is a good idea to send a liaison to Q6/15.=20 --- 4.1.1=20 Where (values between parenthesis refer to ITU defined values as reported above): Please remove the parentheses from this sentence. [YOUNG] OK.=20 --- 4.1.1 and 4.1.2 An Optional F can be added indicating a FEC Encoding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| D |S| c | W | y | t | z | v | F | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F (suffix): =3D 0 reserved, =3D 1 Fec Encoding Values not mentioned here are not allowed in this application code If F is optional but only one value is allowed (viz. 1) how do I opt to not indicate a FEC Encoding? [YOUNG] I guess 0 will do it.=20 --- 4.1.1 and 4.1.2 Your definition of parameter c makes RFC 6205 a normative reference. = . I think you could usefully point with more precision to Figure 2 in=20 Section 3.2 of RFC 6205. However, I wonder whether you want to allow new values that may be added to the IANA registry created by Section 5.2 of RFC 6205 [YOUNG] OK. Will change RFC 6205 as a normative reference and point with mo= re precision to Fig. 2 in Section 3.2 of RFC 6205. Since we are not adding = values to the channel spacing here, I am not sure if it is appropriate to d= iscuss this in this document. --- 4.1.3 and 4.1.4 n: maximum number of channels (10 bits, up to 1024 channels) Hmmm, 2^10 is 1024, but 10 bits can only encode 1023 unless you say that n=3D0 is not valid and so n is actually max channels minus one. [YOUNG] I would change: 1024 -> 1023. --- 4.4 The processing capability list field is then given by: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Processing Cap ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional capability parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the processing ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the processing Cap ID is "regeneration capability", the I don't believe you have told me how to encode "regeneration capability" into the Processing Cap ID field. Possibly you mean that the numbered list above is intended to define the settings of this field. =20 If so then: - say so - explain that "Fault and performance monitoring" and "Vendor Specific capability" have no additional capability parameters - probably remove the note about "Fault and performance monitoring" and "vendor specific capability" because if it isn't here it is, of course, for future study. [YOUNG] Yes, how about adding right after the encoding and before, "when ..= ." the following:=20 The processing capability ID field defines the following processing capa= bilities: 0: Reserved 1: Regeneration capability 2: Fault and performance monitoring 3: Vendor Specific capability [YOUNG] OK, will remove the note on the further study and add:=20 "Fault and performance monitoring" and "Vendor Specific capability" have no additional capability parameters.=20 --- 4.4 Note that when the capability of regenerator is indicated to be Selective Regeneration Pools, regeneration pool properties such as input and output restrictions and availability need to be specified. The code point for this is subject to further study. I think you mean to replace that final line with... These properties will be encoded in the capabilities field starting with the bits marked Reserved in the figure. An additional specification describing the encoding of these parameters is required before the value C=3D2 can be used. [YOUNG] Thanks. Agree.=20 --- Section 6 In Section 6 and 6.1 you appear to be creating a new top-level registry called "GMPLS Routing Parameters for WSON" with a sub-registry called "Types for subfields of WSON Resource Block Information". It's a shame to create a whole new top-level registry. I suppose you=20 think that this information will only ever be used in routing and never in signaling. Probably right, in which case you are good to go, although your text could be clearer. [YOUNG] Unfortunately it is only intended for Routing. Will add this is the= case in the text.=20 --- Section A.3 is using some form of BNF to represent information. This is probably RBNF from RFC 5511. Anyway, you need to give a reference so people can read it. It would be nice to lay the BNF out on the page in a more readable way. [YOUNG] OK, will reference and do some cosmetic surgery on this.=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Thu Jan 15 12:07: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 341A31B327D for ; Thu, 15 Jan 2015 12:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_SLUT=2.522, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 xbbcs7QilDCU for ; Thu, 15 Jan 2015 12:06:45 -0800 (PST) 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 B04551B3244 for ; Thu, 15 Jan 2015 12:06:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOB94673; Thu, 15 Jan 2015 20:06:43 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 Jan 2015 20:06:42 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Thu, 15 Jan 2015 12:06:22 -0800 From: Leeyoung To: Leeyoung , "adrian@olddog.co.uk" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Thread-Index: AdAmyKqM3E2i5eP+S/KXayUoWZed4QFfHtywAS3uxSA= Date: Thu, 15 Jan 2015 20:06:22 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C71EBC@dfweml706-chm> References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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, 15 Jan 2015 20:06:54 -0000 Hi Adrian,=20 There was one question I left unanswered in the previous email. Here's my c= omment. You said: --- Section 3.3 Where Action =3D 0 denotes a list of 16 bit integers and Action =3D 1 denotes a bit map. In both cases the elements of the RB Set field are in a one-to-one correspondence with the values in the usage RB usage state area. This is not clear. I think the Action field is explaining how the RB Usage State field is encoded. - Not sure why you call it "Action" - Would be good if you could make it clear that "16 bit integers" or "bit map" apply to the RB Usage State field. But... RB#i State (16 bits, unsigned integer): indicates Resource Block #i is in use or available. - You might say what value of the 16 bit unsigned integer indicates in use and what value indicates available. - You should explain to me why a list of 16 bit integers to encode a set of Booleans is in anyway efficient or appropriate. It is *really* hard to parse from this section that the state applies to the whole RB when Action is 0, but applies to the elements of the RBs when Action is 1. At least, that is what I think I parsed from the text although I also found text in the section that convinced me you meant something else. In short, this section is not clear! [YOUNG] How about:=20 OLD: RB#i State (16 bits, unsigned integer): indicates Resource Block #i is in use or available. NEW: RB#i State (16 bits, unsigned integer): indicates the number of resour= ces available in Resource Block #i. Action =3D 1 covers the case where each resource block only contains a sing= le element.=20 Action =3D 0 covers the case where there are multiple elements for each res= ource block.=20 Hope this helps. Thanks. Young =20 -----Original Message----- From: Leeyoung=20 Sent: Wednesday, January 14, 2015 5:20 PM To: 'adrian@olddog.co.uk'; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.= org Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Hi Adrian, Thanks.=20 My comment for general vs. WSON-specific issue is that the design philosophy of general encoding was to generalize a common elemen= t that can be applied to different technologies. For instance, connectivity matrix definitely can= be applied to WSON, OTN and other Switching technology as one encoding can fit to all. You seemed to desire a= sharing of the same encoding to describe=20 different entities where possible. This is fine for label vs. wavelength as= there is one-to-one mapping for this. However, Resource Block encoding cannot properly share with the connectivit= y matrix encoding with two reasons: 1. They refer to different elements in the node. 2. They require different sets of fields with different number of fields.=20 Please also see my comment in-line for details. Thanks, Young -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 02, 2015 2:15 PM To: draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Hello, I've now done my AD review of this document. I am rather regretting starting the IETF last call for draft-ietf-ccamp-general-constraint- encode on which this document depends because it seems that this document introduces WSON-specific encodings (all of those before Section 4) that should/could have been made generic. In fact, I thought the point of the general encodings document was to produce protocol objects that could be used by technology-specific documents like this one. If you can respond to my comments below, we can work out whether the general encodings document needs to be brought back for more work. Thanks for your efforts with this. Adrian =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract while other parts are fairly specific to WSONs. They are either specific or they are not. I think you need s/fairly specific/specific/ [YOUNG] YES.=20 --- Shouldn't the Introduction include a discussion of and reference to [Gen-encode]? [YOUNG] A good point. Will add this.=20 --- The Introduction has This document provides efficient encodings and Note that since these encodings are relatively efficient Which are they? And relative to what? [YOUNG] will remove 'relatively'. --- Section 1.1 has Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool. I think you mean [RWA-Info]. That would also make [RWA-Info] a normative reference which seems correct anyway. [YOUNG] Yes. Will change.=20 --- Section 1.1 makes RFC 6163 a normative reference. [YOUNG] Yes. Will correct.=20 --- Section 2.1 seems somewhere between a copy of and a modification of the Link Set Field in 2.3 of [Gen-Encode]. Some clarification would be useful. If this is different, why is it not using one of the generic encodings applied in a specific way? If it is the same, you should probably just reference the encoding in [Gen-Encode] and describe here how the fields are used, but if you insist in re-drawing the figure it should be aligned with the figure in [Gen-Encode]. [YOUNG] not quite. Link Set and Label Set are two different things with dif= ferent fields.=20 Link Set has directionality and identifier format while Label Set does not = have these fields but has connectivity field. Not sure how we can point to each other.=20 --- Section 2.1 The RB identifier represents the ID of the resource block which is a 32 bit integer. You might note that the scope of the RB identifier is local to the node on which it is applied although that node may choose to use a globally known encoding such as from RFC 6205. I assume that flexi-grid is out of scope for WSON. If it is not, then you need to think further about your 32 bit identifiers. [YOUNG] Flex-grid is out of scope here. In addition, RB identifier is a res= ource block ID Which is different from wavelength identifier. I am sure how a globally kno= wn encoding for Wavelength id can be used for RB identifier. They seemed to refer two diffe= rent entities.=20 =20 --- Section 3.1 Why isn't the Resource Accessibility Field expressed in terms of the use of a generic Connectivity Matrix Field from section 2.1 of [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive application agnostic encodings that could be used without modification (but with applicability notes) by specific technologies. [YOUNG] Not quite. Connectivity Matrix encoding cannot be used for Resource= Accessibility Field as the latter has additional entity (namely, RB set field) to describe. We generalized a = single-stage connectivity matrix in [Gen-Encode] that can=20 be applicable to any switching technology. Here in WSON, we have a need to = model RB constraints (for the pool of Wavelength Converters) from/to input/output link sets. Putting two different entities into one cod= ing was not the choice of the authors.=20 --- Section 3.2 I looked for the equivalent of the Resource Wavelength Constraints Field in [Gen-Encode]. I understand that Input Wavelength Constraints Field and Output Wavelength Constraints Field are encoded using the generic Label Set of [Gen-Encode], but I thought that the whole concept of Resource Constraints would be generic. [YOUNG] Again, I think the design of generalization is not intended to=20 share the same encoding to describe two different entities. Besides, I do not see the need to generalize encoding of an entity that has no particular use in other technologies than WSON.=20 --- Section 3.3 As with the previous section I don't see anything that is WSON-specific in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field and I wondered why [Gen-Encode] doesn't have anything to cover this. [YOUNG] RB is wavelength converters, which is a unique WSON element.=20 --- Section 3.3 Where Action =3D 0 denotes a list of 16 bit integers and Action =3D 1 denotes a bit map. In both cases the elements of the RB Set field are in a one-to-one correspondence with the values in the usage RB usage state area. This is not clear. I think the Action field is explaining how the RB Usage State field is encoded. - Not sure why you call it "Action" - Would be good if you could make it clear that "16 bit integers" or "bit map" apply to the RB Usage State field. But... RB#i State (16 bits, unsigned integer): indicates Resource Block #i is in use or available. - You might say what value of the 16 bit unsigned integer indicates in use and what value indicates available. - You should explain to me why a list of 16 bit integers to encode a set of Booleans is in anyway efficient or appropriate. It is *really* hard to parse from this section that the state applies to the whole RB when Action is 0, but applies to the elements of the RBs when Action is 1. At least, that is what I think I parsed from the text although I also found text in the section that convinced me you meant something else. In short, this section is not clear! [YOUNG] Indeed it is not clear. For this, let me get back to you shortly.=20 --- Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? [YOUNG] I think the reason for B bit is not included in Section 3.4 is the = context where it won't be very useful (even if we have a B bit) as input wa= velengths available will hardly match with output wavelength available in m= ost cases. Compared to this, wavelength constraints can more often be same = for input and output.=20 --- Sections 3.4 and 4 should list the allowed settings of I and O (presumably: 01, 10, 11). Cf. Section 3.2. [YOUNG] OK. How adding: Currently the only valid combinations of (I,O) are (0,1), (1,0), or (1,1).= =20 --- Section 4 How do I know the length of the ResourceBlockInfo field? I need to know this to decide whether to try to parse the next bytes as another Optional subfield. I *do* when I reach the end of one Optional subfield, but I don't know whether another follows. Possibly you intend the object that includes a ResourceBlockInfo field to provide the length information, but other fields defined in this document do include lengths or enough information to deduce the lengths. [YOUNG] Yes, you're right. It is not completely consistent. How about the f= ollowing Encoding:=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|O| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RB Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional subfield 1 | : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional subfield N | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Length: 16 bits The total length of this field in bytes. --- Section 4.1 The following I and E combination are defined: s/E/O/ [YOUNG] Agree. Thanks. --- Section 4.1 1: [ITU-G.698.1] application code. 2: [ITU-G.698.2] application code. 3: [ITU-G.959.1] application code. 4: [ITU-G.695] application code. You should use the same format as in the references section. E.g., [G.959.1]. Do you mean 698 or 694? You have references for 694.1 and 694.2, but not 698.1 or 698.2. But 694.1 does not seem to include any "application codes" - they're in 698.1 and 698.2. Each of the subsections 4.1.1-4.1.4 should include a citations. [YOUNG] Yes, for the reference format. The right references are 698.1 and 6= 98.2 --- will correct with the right references. Citations will be added in= each of the subsections.=20 --- Section 4.1 How do I interpret a Vendor-Specific Application Code? Is there an OUI I'm missing? [YOUNG] Not sure if I understood this question. What is "OUI"?=20 --- I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and have asked the chairs to send a liaison to ITU-T Q6/15 asking them to cast an eye over the text of these sections. [YOUNG] Thanks. It is a good idea to send a liaison to Q6/15.=20 --- 4.1.1=20 Where (values between parenthesis refer to ITU defined values as reported above): Please remove the parentheses from this sentence. [YOUNG] OK.=20 --- 4.1.1 and 4.1.2 An Optional F can be added indicating a FEC Encoding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| D |S| c | W | y | t | z | v | F | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F (suffix): =3D 0 reserved, =3D 1 Fec Encoding Values not mentioned here are not allowed in this application code If F is optional but only one value is allowed (viz. 1) how do I opt to not indicate a FEC Encoding? [YOUNG] I guess 0 will do it.=20 --- 4.1.1 and 4.1.2 Your definition of parameter c makes RFC 6205 a normative reference. = . I think you could usefully point with more precision to Figure 2 in=20 Section 3.2 of RFC 6205. However, I wonder whether you want to allow new values that may be added to the IANA registry created by Section 5.2 of RFC 6205 [YOUNG] OK. Will change RFC 6205 as a normative reference and point with mo= re precision to Fig. 2 in Section 3.2 of RFC 6205. Since we are not adding = values to the channel spacing here, I am not sure if it is appropriate to d= iscuss this in this document. --- 4.1.3 and 4.1.4 n: maximum number of channels (10 bits, up to 1024 channels) Hmmm, 2^10 is 1024, but 10 bits can only encode 1023 unless you say that n=3D0 is not valid and so n is actually max channels minus one. [YOUNG] I would change: 1024 -> 1023. --- 4.4 The processing capability list field is then given by: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Processing Cap ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Possible additional capability parameters depending upon | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : the processing ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the processing Cap ID is "regeneration capability", the I don't believe you have told me how to encode "regeneration capability" into the Processing Cap ID field. Possibly you mean that the numbered list above is intended to define the settings of this field. =20 If so then: - say so - explain that "Fault and performance monitoring" and "Vendor Specific capability" have no additional capability parameters - probably remove the note about "Fault and performance monitoring" and "vendor specific capability" because if it isn't here it is, of course, for future study. [YOUNG] Yes, how about adding right after the encoding and before, "when ..= ." the following:=20 The processing capability ID field defines the following processing capa= bilities: 0: Reserved 1: Regeneration capability 2: Fault and performance monitoring 3: Vendor Specific capability [YOUNG] OK, will remove the note on the further study and add:=20 "Fault and performance monitoring" and "Vendor Specific capability" have no additional capability parameters.=20 --- 4.4 Note that when the capability of regenerator is indicated to be Selective Regeneration Pools, regeneration pool properties such as input and output restrictions and availability need to be specified. The code point for this is subject to further study. I think you mean to replace that final line with... These properties will be encoded in the capabilities field starting with the bits marked Reserved in the figure. An additional specification describing the encoding of these parameters is required before the value C=3D2 can be used. [YOUNG] Thanks. Agree.=20 --- Section 6 In Section 6 and 6.1 you appear to be creating a new top-level registry called "GMPLS Routing Parameters for WSON" with a sub-registry called "Types for subfields of WSON Resource Block Information". It's a shame to create a whole new top-level registry. I suppose you=20 think that this information will only ever be used in routing and never in signaling. Probably right, in which case you are good to go, although your text could be clearer. [YOUNG] Unfortunately it is only intended for Routing. Will add this is the= case in the text.=20 --- Section A.3 is using some form of BNF to represent information. This is probably RBNF from RFC 5511. Anyway, you need to give a reference so people can read it. It would be nice to lay the BNF out on the page in a more readable way. [YOUNG] OK, will reference and do some cosmetic surgery on this.=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Fri Jan 16 09:55:22 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 BD1731B29F3; Fri, 16 Jan 2015 09:55:18 -0800 (PST) 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 5bSKHs6WP2Nz; Fri, 16 Jan 2015 09:55:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A381AD371; Fri, 16 Jan 2015 09:55:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: greg.jones@itu.int X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150116175512.4392.88935.idtracker@ietfa.amsl.com> Date: Fri, 16 Jan 2015 09:55:12 -0800 Archived-At: Cc: daniele.cecccarelli@ericsson.com, lbpanslow@ciena.com, Peter.Stassar@huawei.com, akatlas@juniper.net, iesg@ietf.org, tsbsg15@itu.int, ccamp@ietf.org, ghani.abbas@ericsson.com Subject: [CCAMP] New Liaison Statement, "Application Codes for Wavelength Switched Optical Networks" 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, 16 Jan 2015 17:55:18 -0000 Title: Application Codes for Wavelength Switched Optical Networks Submission Date: 2015-01-16 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1377/ Please reply by 2015-03-02 From: The IETF (John Drake ) To: ITU-T SG 15 (greg.jones@itu.int) Cc: ghani.abbas@ericsson.com,lbpanslow@ciena.com,akatlas@juniper.net,Malcolm.BETTS@zte.com.cn,daniele.cecccarelli@ericsson.com,adrian@olddog.co.uk,greg.jones@itu.int,kam.lam@alcatel-lucent.com,scott.mansfield@ericsson.com,Peter.Stassar@huawei.com,sshew@ciena.com,Steve.Trowbridge@alcatel-lucent.com,zhangfatai@huawei.com,ccamp@ietf.org,tsbsg15@itu.int,iesg@ietf.org Response Contact: jdrake@juniper.net Technical Contact: jdrake@juniper.net Purpose: For comment Body: Dear Q6/15 (WP2/15), The CCAMP working group of the IETF would like to draft the attention of Q6/15 to https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/ . This document describes encodings for a number of parameters that will be used in GMPLS protocols for operation of Wavelength Switched Optical Networks. The document is in its final stages and will soon progress to IETF last call. We would particularly welcome your review of sections 4.1.1-4.1.4. These sections describe the encoding of Application Codes as described in G.698.1, G.698.2, G.959.1, and G.695. The questions you might like to consider in this respect are: - Are we capturing current application codes? In other words, are our references correct and correctly used? - Are there any application codes we are missing? Is our set of references correct and have we included all of the application codes in the references? - Have we captured all of the parameters of the application codes? In our attempt to capture the application codes into formats we can use in our protocols, have we found all of the parameters that comprise the application codes? - Are the fields for each parameter of each application code appropriately sized and with the correct ranges? In other words, will we be able to properly encode the application codes defined today and their possible future extensions? In view of the progress of this work, we would be very happy to receive informal responses and guidance from individuals or from the Question as a whole if it has time to formulate an agreed response. Please use the CCAMP mailing list to provide input in accordance with standard IETF process. Many thanks for your attention. Fatai Zhang and Daniele Ceccarelli (CCAMP WG chairs) Attachments: No document has been attached From nobody Fri Jan 16 12:36: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 EB05C1B2B89 for ; Fri, 16 Jan 2015 12:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.778 X-Spam-Level: X-Spam-Status: No, score=-98.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_SLUT=2.522, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 QCl3x105BEOU for ; Fri, 16 Jan 2015 12:35:58 -0800 (PST) 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 A18BE1B2B88 for ; Fri, 16 Jan 2015 12:35:57 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0GKZpnm018887; Fri, 16 Jan 2015 20:35:51 GMT Received: from 950129200 (80-121-133-160.adsl.highway.telekom.at [80.121.133.160]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0GKZnrv018881 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2015 20:35:50 GMT From: "Adrian Farrel" To: "'Leeyoung'" , References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71EBC@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C71EBC@dfweml706-chm> Date: Fri, 16 Jan 2015 20:35:50 -0000 Message-ID: <061c01d031cc$04913920$0db3ab60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQMMa/K0nO8nu3A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21258.002 X-TM-AS-Result: No--16.827-10.0-31-10 X-imss-scan-details: No--16.827-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFqnykMun0J1wvHkpkyUphL9Ud7Bjfo+5jQ5CCUkHUNu7l8P CCxSDY8vxBVPBDt9NWDtztXOOYV+4FBcD+fUZsB3p9ciXoJ/pWvNXgP7liZ5IpnNlSgGlfGpkdv IxNucy7+/7P8Kn+XkCX1KuvpUktmcNGfbF3CuxektMfCdg6KRDbQtUQGcjvHVIFBEE5CFomKSo7 YBtVK4/LrpeJrM1CK5OXh+vcntO3Bg0s9CJc8XvB3EEAbn+GRbnbR1KGab5Xm7+NPPxj+R6sXyP yHR36DVS1ayce3yAb6caX6Dvv+qh064sLvrq1LKdXz3l78F3Yk6En2bnefhoFfXgfL55invOgzl DZRw74sfhcUQijhd/wbqZM3zDkF0vycUQR1kwKYgKw/iul4Zx/cSIoniEyWosp5O052MzLryb35 SZdaBrJM0aoaSyIzHwwsK8ezn183au9iF5mAFeylrosmS0SOAMZm0+sEE9mslP1vFxquW9hnFeU hjgGQW+PU3j/oc0qUPs83S68xkMDcDLA95do+zhsE+u3nnCfDJ5SXtoJPLyI0F/H1BKHLgfYU2C f7Gf9lgHXrd7zy3WPCmupLh2jJ53MzeZlPGORdUJ1Ud7T8U/hNwWv2dBrmkH1bhq4z+yfSVP+jF +CZwUSBvW/mLOyUJsJZHwROosuK0TGHcoEhE3jDfgfM3Zc/RhQaFqMRElgkcXmBZ3mI5SQDDWSS ylqoGWkp65qH3viM5pYX88gSRnwvuBkbttOjik3ewifG2MNPGdQx1K0CtmTnKpbGL4ChVKSyMl4 Bp7a5TKmVbi8YBkjflP41njKHUGJBzk6LE3bOeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47gc4WL5J jd88I2j49Ftap9EOwBXM346/+zb82p5LoMxQYuPT1OGWzOyPqsSflAyF97P28hvfc+BmfDQtSx7 RCad Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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: Fri, 16 Jan 2015 20:36:02 -0000 This is much clearer. Thanks! Adrian > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: 15 January 2015 20:06 > To: Leeyoung; adrian@olddog.co.uk; draft-ietf-ccamp-rwa-wson- > encode.all@tools.ietf.org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > Hi Adrian, > > There was one question I left unanswered in the previous email. Here's my > comment. You said: > > --- > > Section 3.3 > > Where Action = 0 denotes a list of 16 bit integers and Action = 1 > denotes a bit map. In both cases the elements of the RB Set field > are in a one-to-one correspondence with the values in the usage RB > usage state area. > > This is not clear. I think the Action field is explaining how the > RB Usage State field is encoded. > - Not sure why you call it "Action" > - Would be good if you could make it clear that "16 bit integers" > or "bit map" apply to the RB Usage State field. > > But... > > RB#i State (16 bits, unsigned integer): indicates Resource Block #i > is in use or available. > > - You might say what value of the 16 bit unsigned integer indicates in > use and what value indicates available. > - You should explain to me why a list of 16 bit integers to encode a > set of Booleans is in anyway efficient or appropriate. > > It is *really* hard to parse from this section that the state applies > to the whole RB when Action is 0, but applies to the elements of the RBs > when Action is 1. At least, that is what I think I parsed from the text > although I also found text in the section that convinced me you meant > something else. > > In short, this section is not clear! > > [YOUNG] How about: > > OLD: RB#i State (16 bits, unsigned integer): indicates Resource Block #i > is in use or available. > NEW: RB#i State (16 bits, unsigned integer): indicates the number of resources > available in Resource Block #i. > > Action = 1 covers the case where each resource block only contains a single > element. > Action = 0 covers the case where there are multiple elements for each resource > block. > > Hope this helps. Thanks. > > Young > > > -----Original Message----- > From: Leeyoung > Sent: Wednesday, January 14, 2015 5:20 PM > To: 'adrian@olddog.co.uk'; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > Hi Adrian, > > Thanks. > > My comment for general vs. WSON-specific issue is that > the design philosophy of general encoding was to generalize a common element > that can be applied > to different technologies. For instance, connectivity matrix definitely can be > applied to WSON, OTN and other > Switching technology as one encoding can fit to all. You seemed to desire a > sharing of the same encoding to describe > different entities where possible. This is fine for label vs. wavelength as there is > one-to-one mapping for this. > However, Resource Block encoding cannot properly share with the connectivity > matrix encoding with two reasons: > > 1. They refer to different elements in the node. > 2. They require different sets of fields with different number of fields. > > Please also see my comment in-line for details. > > Thanks, > Young > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, January 02, 2015 2:15 PM > To: draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > Hello, > > I've now done my AD review of this document. I am rather regretting > starting the IETF last call for draft-ietf-ccamp-general-constraint- > encode on which this document depends because it seems that this > document introduces WSON-specific encodings (all of those before > Section 4) that should/could have been made generic. In fact, I > thought the point of the general encodings document was to produce > protocol objects that could be used by technology-specific documents > like this one. > > If you can respond to my comments below, we can work out whether the > general encodings document needs to be brought back for more work. > > Thanks for your efforts with this. > > Adrian > > =========== > > Abstract > > while other parts are fairly specific to WSONs. > > They are either specific or they are not. I think you need > s/fairly specific/specific/ > > [YOUNG] YES. > > --- > > Shouldn't the Introduction include a discussion of and reference to > [Gen-encode]? > > [YOUNG] A good point. Will add this. > > --- > > > The Introduction has > > > This document provides efficient encodings > > and > > Note that since these encodings are relatively efficient > > Which are they? And relative to what? > > [YOUNG] will remove 'relatively'. > > --- > > Section 1.1 has > > Refer to Section 5 of [Gen-Encode] for the terminology of Resources, > Resources Blocks, and Resource Pool. > > I think you mean [RWA-Info]. That would also make [RWA-Info] a normative > reference which seems correct anyway. > > [YOUNG] Yes. Will change. > --- > > Section 1.1 makes RFC 6163 a normative reference. > > [YOUNG] Yes. Will correct. > > --- > > Section 2.1 seems somewhere between a copy of and a modification of > the Link Set Field in 2.3 of [Gen-Encode]. > > Some clarification would be useful. If this is different, why is it not > using one of the generic encodings applied in a specific way? If it is > the same, you should probably just reference the encoding in > [Gen-Encode] and describe here how the fields are used, but if you > insist in re-drawing the figure it should be aligned with the figure in > [Gen-Encode]. > > [YOUNG] not quite. Link Set and Label Set are two different things with different > fields. > Link Set has directionality and identifier format while Label Set does not have > these fields but has connectivity field. > Not sure how we can point to each other. > --- > > Section 2.1 > > The RB identifier represents the ID of the resource block which is a > 32 bit integer. > > You might note that the scope of the RB identifier is local to the node > on which it is applied although that node may choose to use a globally > known encoding such as from RFC 6205. > > I assume that flexi-grid is out of scope for WSON. If it is not, then > you need to think further about your 32 bit identifiers. > > [YOUNG] Flex-grid is out of scope here. In addition, RB identifier is a resource > block ID > Which is different from wavelength identifier. I am sure how a globally known > encoding for > Wavelength id can be used for RB identifier. They seemed to refer two different > entities. > > --- > > Section 3.1 > > Why isn't the Resource Accessibility Field expressed in terms of the > use of a generic Connectivity Matrix Field from section 2.1 of > [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive > application agnostic encodings that could be used without modification > (but with applicability notes) by specific technologies. > > [YOUNG] Not quite. Connectivity Matrix encoding cannot be used for Resource > Accessibility Field as the latter > has additional entity (namely, RB set field) to describe. We generalized a single- > stage connectivity matrix in [Gen-Encode] that can > be applicable to any switching technology. Here in WSON, we have a need to > model RB constraints (for the pool of Wavelength Converters) > from/to input/output link sets. Putting two different entities into one coding was > not the choice of the authors. > > --- > > Section 3.2 > > I looked for the equivalent of the Resource Wavelength Constraints > Field in [Gen-Encode]. I understand that Input Wavelength Constraints > Field and Output Wavelength Constraints Field are encoded using the > generic Label Set of [Gen-Encode], but I thought that the whole concept > of Resource Constraints would be generic. > > [YOUNG] Again, I think the design of generalization is not intended to > share the same encoding to describe two different entities. Besides, I do > not see the need to generalize encoding of an entity that has no particular > use in other technologies than WSON. > > --- > > Section 3.3 > > As with the previous section I don't see anything that is WSON-specific > in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field > and I wondered why [Gen-Encode] doesn't have anything to cover this. > > [YOUNG] RB is wavelength converters, which is a unique WSON element. > --- > > Section 3.3 > > Where Action = 0 denotes a list of 16 bit integers and Action = 1 > denotes a bit map. In both cases the elements of the RB Set field > are in a one-to-one correspondence with the values in the usage RB > usage state area. > > This is not clear. I think the Action field is explaining how the > RB Usage State field is encoded. > - Not sure why you call it "Action" > - Would be good if you could make it clear that "16 bit integers" > or "bit map" apply to the RB Usage State field. > > But... > > RB#i State (16 bits, unsigned integer): indicates Resource Block #i > is in use or available. > > - You might say what value of the 16 bit unsigned integer indicates in > use and what value indicates available. > - You should explain to me why a list of 16 bit integers to encode a > set of Booleans is in anyway efficient or appropriate. > > It is *really* hard to parse from this section that the state applies > to the whole RB when Action is 0, but applies to the elements of the RBs > when Action is 1. At least, that is what I think I parsed from the text > although I also found text in the section that convinced me you meant > something else. > > In short, this section is not clear! > > [YOUNG] Indeed it is not clear. For this, let me get back to you shortly. > > --- > > Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? > > [YOUNG] I think the reason for B bit is not included in Section 3.4 is the context > where it won't be very useful (even if we have a B bit) as input wavelengths > available will hardly match with output wavelength available in most cases. > Compared to this, wavelength constraints can more often be same for input and > output. > > --- > > Sections 3.4 and 4 should list the allowed settings of I and O > (presumably: 01, 10, 11). Cf. Section 3.2. > > [YOUNG] OK. How adding: > > Currently the only valid combinations of (I,O) are (0,1), (1,0), or (1,1). > > --- > > Section 4 > > How do I know the length of the ResourceBlockInfo field? I need to know > this to decide whether to try to parse the next bytes as another > Optional subfield. I *do* when I reach the end of one Optional subfield, > but I don't know whether another follows. > > Possibly you intend the object that includes a ResourceBlockInfo field > to provide the length information, but other fields defined in this > document do include lengths or enough information to deduce the lengths. > > [YOUNG] Yes, you're right. It is not completely consistent. How about the > following > Encoding: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I|O| Reserved | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set Field | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional subfield 1 | > : ... : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : : > : : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional subfield N | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Length: 16 bits > > The total length of this field in bytes. > > --- > > Section 4.1 > > The following I and E combination are defined: > > s/E/O/ > > [YOUNG] Agree. Thanks. > --- > > Section 4.1 > > 1: [ITU-G.698.1] application code. > > 2: [ITU-G.698.2] application code. > > 3: [ITU-G.959.1] application code. > > 4: [ITU-G.695] application code. > > You should use the same format as in the references section. E.g., > [G.959.1]. > > Do you mean 698 or 694? You have references for 694.1 and 694.2, but > not 698.1 or 698.2. But 694.1 does not seem to include any "application > codes" - they're in 698.1 and 698.2. > > Each of the subsections 4.1.1-4.1.4 should include a citations. > > [YOUNG] Yes, for the reference format. The right references are 698.1 and 698.2 > --- will correct with the right references. Citations will be added in each of the > subsections. > --- > > Section 4.1 > How do I interpret a Vendor-Specific Application Code? Is there an OUI > I'm missing? > > [YOUNG] Not sure if I understood this question. What is "OUI"? > > --- > > I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and > have asked the chairs to send a liaison to ITU-T Q6/15 asking them to > cast an eye over the text of these sections. > > [YOUNG] Thanks. It is a good idea to send a liaison to Q6/15. > > --- > > 4.1.1 > > Where (values between parenthesis refer to ITU defined values as > reported above): > > Please remove the parentheses from this sentence. > > [YOUNG] OK. > --- > > 4.1.1 and 4.1.2 > > An Optional F can be added indicating a FEC Encoding. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |B| D |S| c | W | y | t | z | v | F | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > F (suffix): = 0 reserved, = 1 Fec Encoding > > Values not mentioned here are not allowed in this application > code > > If F is optional but only one value is allowed (viz. 1) how do I opt to > not indicate a FEC Encoding? > > [YOUNG] I guess 0 will do it. > > --- > > 4.1.1 and 4.1.2 > > Your definition of parameter c makes RFC 6205 a normative reference. > . > I think you could usefully point with more precision to Figure 2 in > Section 3.2 of RFC 6205. > > However, I wonder whether you want to allow new values that may be added > to the IANA registry created by Section 5.2 of RFC 6205 > > [YOUNG] OK. Will change RFC 6205 as a normative reference and point with more > precision to Fig. 2 in Section 3.2 of RFC 6205. Since we are not adding values to the > channel spacing here, I am not sure if it is appropriate to discuss this in this > document. > --- > > 4.1.3 and 4.1.4 > > > n: maximum number of channels (10 bits, up to 1024 channels) > > Hmmm, 2^10 is 1024, but 10 bits can only encode 1023 unless you say that > n=0 is not valid and so n is actually max channels minus one. > > [YOUNG] I would change: 1024 -> 1023. > --- > > 4.4 > > The processing capability list field is then given by: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Processing Cap ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Possible additional capability parameters depending upon | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : the processing ID : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > When the processing Cap ID is "regeneration capability", the > > I don't believe you have told me how to encode "regeneration > capability" into the Processing Cap ID field. Possibly you mean that the > numbered list above is intended to define the settings of this field. > > If so then: > - say so > - explain that "Fault and performance monitoring" and "Vendor Specific > capability" have no additional capability parameters > - probably remove the note about "Fault and performance monitoring" and > "vendor specific capability" because if it isn't here it is, of > course, for future study. > > [YOUNG] Yes, how about adding right after the encoding and before, "when ..." > the following: > > The processing capability ID field defines the following processing capabilities: > > 0: Reserved > > 1: Regeneration capability > > 2: Fault and performance monitoring > > 3: Vendor Specific capability > > [YOUNG] OK, will remove the note on the further study and add: > > "Fault and performance monitoring" and "Vendor Specific > capability" have no additional capability parameters. > > --- > > 4.4 > > Note that when the capability of regenerator is indicated to be > Selective Regeneration Pools, regeneration pool properties such as > input and output restrictions and availability need to be specified. > The code point for this is subject to further study. > > I think you mean to replace that final line with... > > These properties will be encoded in the capabilities field starting > with the bits marked Reserved in the figure. An additional > specification describing the encoding of these parameters is required > before the value C=2 can be used. > > [YOUNG] Thanks. Agree. > > --- > > Section 6 > > In Section 6 and 6.1 you appear to be creating a new top-level registry > called "GMPLS Routing Parameters for WSON" with a sub-registry called > "Types for subfields of WSON Resource Block Information". > > It's a shame to create a whole new top-level registry. I suppose you > think that this information will only ever be used in routing and > never in signaling. Probably right, in which case you are good to go, > although your text could be clearer. > > [YOUNG] Unfortunately it is only intended for Routing. Will add this is the case in > the text. > > --- > > Section A.3 is using some form of BNF to represent information. > > This is probably RBNF from RFC 5511. Anyway, you need to give a > reference so people can read it. > > It would be nice to lay the BNF out on the page in a more readable way. > > [YOUNG] OK, will reference and do some cosmetic surgery on this. > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From nobody Sat Jan 17 06:48: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 A02C41ACD54; Sat, 17 Jan 2015 05:58:41 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z2VtcjJbwS0v; Sat, 17 Jan 2015 05:58:38 -0800 (PST) Received: from mgw020.noc.ntt.com (mgw020.noc.ntt.com [210.160.55.2]) by ietfa.amsl.com (Postfix) with ESMTP id 321C91ACD57; Sat, 17 Jan 2015 05:58:37 -0800 (PST) Received: from c0044i0.coe.ntt.com (c0044i0.nc.agilit-hosting.com [10.18.161.13]) by mgw020.noc.ntt.com (NTT Com MailSV) with ESMTP id E16EA44600A7; Sat, 17 Jan 2015 22:58:36 +0900 (JST) Received: from C0038I0.coe.ntt.com (10.18.160.42) by c0044i0.coe.ntt.com (10.18.161.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 17 Jan 2015 22:58:29 +0900 Received: from C0010I0.coe.ntt.com ([169.254.2.243]) by C0038I0.coe.ntt.com ([10.18.160.42]) with mapi id 14.03.0181.006; Sat, 17 Jan 2015 22:58:36 +0900 From: Tomonori Takeda To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt Thread-Index: AdAyVmdKICzu0mt5SZ+spYC7d3T1cA== Date: Sat, 17 Jan 2015 13:58:35 +0000 Message-ID: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: rtg-ads@tools.ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org, ccamp@ietf.org x-originating-ip: [10.25.133.87] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 17 Jan 2015 06:48:57 -0800 Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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: Sat, 17 Jan 2015 13:58:42 -0000 SGVsbG8sIA0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3Mg dG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBw YXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVz IG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92 aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIA0KDQpBbHRob3VnaCB0aGVz ZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywg aXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRo IGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQg c3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcg dGhlIGRyYWZ0LiANCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJh aW50LWVuY29kZS0xNi50eHQgDQpSZXZpZXdlcjogVG9tb25vcmkgVGFrZWRhDQpSZXZpZXcgRGF0 ZTogMTcgSmFudWFyeSwgMjAxNQ0KSUVURiBMQyBFbmQgRGF0ZTogMTcgSmFudWFyeSwgMjAxNQ0K SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCg0KU3VtbWFyeToNCg0KVGhpcyBkb2N1 bWVudCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhh dCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6 DQoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHByb3RvY29sLWFnbm9zdGljIGVuY29kaW5ncyBm b3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiBlbGVtZW50cyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1j Y2FtcC1yd2EtaW5mby4NCkkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIGluIGdvb2Qgc2hhcGUgYnV0 IHRoZXJlIGFyZSBhIGZldyBwb2ludHMgdGhhdCBzaG91bGQgYmUgY2xhcmlmaWVkIGZvciBiZXR0 ZXIgdW5kZXJzdGFuZGluZy4NCg0KTWFqb3IgSXNzdWVzOg0KDQpOb25lDQoNCk1pbm9yIElzc3Vl czoNCg0KTm9uZQ0KDQpOaXRzOg0KDQoxKSBJbiBzZWN0aW9uIDEuMiwgbGFiZWwgY29udGludWl0 eSBjb25zdHJhaW50IChlLmcuLCB3YXZlbGVuZ3RoIGNvbnRpbnVpdHkgaW4gV1NPTikgaXMgbWVu dGlvbmVkLiBIb3dldmVyLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgaW5mb3JtYXRpb24gZWxlbWVu dHMgZm9yIHdoaWNoIHRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGVuY29kaW5ncyBjYW4gZGVzY3Jp YmUgc3VjaCBjb25zdHJhaW50LiBNeSByZWFkaW5nIGlzIHRoYXQgaW5mb3JtYXRpb24gZWxlbWVu dCBzdWNoIGFzIFBvcnQgTGFiZWwgUmVzdHJpY3Rpb24gaXMgcmF0aGVyIGZvciBkZXNjcmliaW5n IHdhdmVsZW5ndGggdHVuaW5nIGNhcGFiaWxpdGllcy9yZXN0cmljdGlvbnMuDQoNCjIpIEluIHNl Y3Rpb24gMi4xLCBpdCBzYXlzICJ0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2ZSB0aGUgc2FtZSB7 c3JjIHBvcnQsIHNyYyBsYWJlbCwgZHN0IHBvcnQsIGRzdCBsYWJlbH0iLiBUbyBiZSBwcmVjaXNl LCBJIGd1ZXNzIHRoaXMgc2hvdWxkIGJlICJ0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2ZSB0aGUg c2FtZSB7c3JjIHBvcnQsIHNyYyBsYWJlbH0sIGFuZCB0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2 ZSB0aGUgc2FtZSB7ZHN0IHBvcnQsIGRzdCBsYWJlbH0iPw0KDQozKSBJbiBzZWN0aW9uIDIuMSwg aXQgc2F5cyAiVGhlIHZhbHVlIG9mIDB4RkYgaXMgcmVzZXJ2ZWQgZm9yIHVzZSB3aXRoIHBvcnQg d2F2ZWxlbmd0aCBjb25zdHJhaW50cyIuIEkgdGhpbmsgInBvcnQgd2F2ZWxlbmd0aCBjb25zdHJh aW50cyIgc2hvdWxkIGJlICJwb3J0IGxhYmVsIHJlc3RyaWN0aW9uIi4NCg0KNCkgSW4gc2VjdGlv biAyLjEsIGZvciBMaW5rIFNldCBBIGRpcj1iaWRpcmVjdGlvbmFsLCBMaW5rIFNldCBCIGRpcj1i aWRpcmVjdGlvbmFsLCBpZiBhbnkgc2lnbmFsIG9uIGFuIGlucHV0IGxpbmsgWCBpcyBvdXRwdXQg b24gYSBsaW5rIFksIHRoZW4gYW55IHNpZ25hbCBvbiBhbiBpbnB1dCBsaW5rIFkgaXMgb3V0cHV0 IG9uIGEgbGluayBYIChhZnRlciBjcm9zcy1jb25uZWN0KT8gT3IgYW55IGNvbnN0cmFpbnQgb24g c3VjaCBzaWduYWwgZmxvdyAoYWZ0ZXIgY3Jvc3MtY29ubmVjdCkgaXMgb3V0IG9mIHNjb3BlPw0K DQo1KSBJbiBzZWN0aW9uIDIuMi4xLCBpdCBzYXlzICJJbiB0aGlzIGNhc2UgdGhlIGFjY29tcGFu eWluZyBsYWJlbCBzZXQgaW5kaWNhdGVzIHRoZSBsYWJlbHMgcGVybWl0dGVkIG9uIHRoZSBwb3J0 LiIgSSB0aGluayAicG9ydCIgc2hvdWxkIGJlICJwb3J0L21hdHJpeCIuDQoNCjYpIEluIHNlY3Rp b24gMi4yLjIsIGl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgdHlwZSAoZS5nLiwg aW50ZWdlcikgZm9yIE1heE51bUNoYW5uZWxzLg0KVGhpcyBhbHNvIGFwcGxpZXMgZm9yIE1heExh YmVsUmFuZ2UgKGluIHNlY3Rpb24gMi4yLjMpIGFuZCBOdW0gTGFiZWxzIChpbiBzZWN0aW9uIDIu NikuDQoNCjcpIEluIHNlY3Rpb24gMi42LCBpdCBzYXlzICJMYWJlbCBTZXQgRmllbGQgaXMgdXNl ZCB3aXRoaW4gdGhlIDxBdmFpbGFibGVMYWJlbHM+IG9yIHRoZSA8U2hhcmVkQmFja3VwTGFiZWxz PiIuIEJ1dCBJIHRoaW5rIExhYmVsIFNldCBGaWVsZCBpcyBhbHNvIHVzZWQgd2l0aGluIFNJTVBM RV9MQUJFTCwgTEFCRUxfUkFOR0UgYW5kIFNJTVBMRV9MQUJFTCAmIENIQU5ORUxfQ09VTlQuDQoN Cg0KVGhhbmtzLA0KVG9tb25vcmkNCg== From nobody Sun Jan 18 09:52: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 E7D3B1ACDCD for ; Sun, 18 Jan 2015 09:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 38jY6Cztlw34 for ; Sun, 18 Jan 2015 09:52:22 -0800 (PST) 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 E68501ACD7E for ; Sun, 18 Jan 2015 09:52:21 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0IHqIai024839; Sun, 18 Jan 2015 17:52:18 GMT Received: from 950129200 (91-115-32-217.adsl.highway.telekom.at [91.115.32.217]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0IHqH3k024831 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 18 Jan 2015 17:52:18 GMT From: "Adrian Farrel" To: References: <20150117080822.9166.5118.idtracker@ietfa.amsl.com> In-Reply-To: <20150117080822.9166.5118.idtracker@ietfa.amsl.com> Date: Sun, 18 Jan 2015 17:52:17 -0000 Message-ID: <00b401d03347$80821e10$81865a30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLKticmOIMt6JpcscAvSTL/sxVA4ZrRIhMQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21262.001 X-TM-AS-Result: No--2.972-10.0-31-10 X-imss-scan-details: No--2.972-10.0-31-10 X-TMASE-MatchedRID: scwq2vQP8OG0m/IROg5s5VaOpp/sV5nVO1K5iM8Q6KBq1n9CrSmVbnmG gNmgsYEreoaxdWxonPT1fsx0fFEH/iWvhQBtQUwTu72KpAktHS8S12tj9Zvd8yxfh0kL+Aj+wua niM9QXy26jE2y8BwYNRBT3MyFfbSmHodpx3o6GrsXrP0cYcrA2+SBrGHYyfa6xe3blg14hRJ5tV 6mUTwAzW6mUHbiBraMpghVtWRmhpPDYChFZbR8qZ4CIKY/Hg3AcmfM3DjaQLHZs3HUcS/scCq2r l3dzGQ1gLFo9xFYYFiNy/tviA2yw5E28dVkPimEbJWWptElrxkn3/eRbcEmL6LXFQBcaQGNOvsE tqw1zsfzhJy6CHiRk8sIvLaAivo7Mnp7Jdy+vhOnyLbqIYI358P9zZjybGuKTVn51J26DC8gSRG ZYS1q0EMMprcbiest Archived-At: Cc: ccamp@ietf.org Subject: Re: [CCAMP] Last Call Expired: 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, 18 Jan 2015 17:52:24 -0000 Hi authors, You have received reviews from the Routing Directorate, Security = Directorate, and General Area Review Team. All indicated minor = editorials that seem easy to fix and benign. Could you please post a new revision addressing these points. Thanks for the work, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of DraftTracker = Mail System > Sent: 17 January 2015 08:08 > To: iesg@ietf.org; ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-general- > constraint-encode@tools.ietf.org > Cc: iesg-secretary@ietf.org > Subject: Last Call Expired: = >=20 >=20 > Please DO NOT reply to this email. >=20 > I-D: > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-ccamp-general- > constraint-encode/ >=20 > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. From nobody Mon Jan 19 10:36: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 CC9EA1B2BC7; Mon, 19 Jan 2015 10:36:19 -0800 (PST) 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 6V2ZBSMiJvGD; Mon, 19 Jan 2015 10:36:15 -0800 (PST) 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 B37681B2BAB; Mon, 19 Jan 2015 10:36:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOF02182; Mon, 19 Jan 2015 18:36:11 +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, 19 Jan 2015 18:36:10 +0000 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, 19 Jan 2015 10:36:03 -0800 From: Leeyoung To: "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt Thread-Index: AQHQNBbGbqO3+3fprEKLaLL/5Pq9nQ== Date: Mon, 19 Jan 2015 18:36:02 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C79E28@dfweml706-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'rtg-dir@ietf.org'" , "'ccamp@ietf.org'" , "draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext.all@tools.ietf.org" Subject: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.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, 19 Jan 2015 18:36:20 -0000 SGVsbG8sIA0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3Mg dG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBw YXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVz IG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92 aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIA0KDQpBbHRob3VnaCB0aGVz ZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywg aXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRo IGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQg c3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcg dGhlIGRyYWZ0LiANCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRw LW9hbS1leHQtMTUudHh0DQpSZXZpZXdlcjogWW91bmcgTGVlDQpSZXZpZXcgRGF0ZTogMTkgSmFu dWFyeSwgMjAxNQ0KSUVURiBMQyBFbmQgRGF0ZTogbm90IHN1cmUNCkludGVuZGVkIFN0YXR1czog U3RhbmRhcmRzIFRyYWNrDQoNClN1bW1hcnk6DQoNClRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9y IHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlv ciB0byBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6DQoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IHRoZSBjb25maWd1cmF0aW9uIG9mIHByb2FjdGl2ZSBNUExTLVRQIE9BTSBmdW5jdGlvbnMgY2Fy cmllZCBieSB0aGUgR01QTFMgUlNWUC1URSBwcm90b2NvbHMgYmFzZWQgb24gdGhlIE9BTSBDb25m aWd1cmF0aW9uIEZyYW1ld29yayBmb3IgR01QTFMgUlNWUC1URS4gVGhlIGRvY3VtZW50IGlzIGlu IGdvb2Qgc2hhcGUgYnV0IHRoZXJlIGFyZSBhIGZldyBwb2ludHMgdGhhdCBzaG91bGQgYmUgY2xh cmlmaWVkIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5LiANCg0KTWFqb3IgSXNzdWVzOg0KDQpO b25lDQoNCk1pbm9yIElzc3VlczoNCg0KTm9uZQ0KDQpOaXRzOg0KDQoxKSBJbiBBYnN0cmFjdCBh bmQgb3RoZXIgcGFydHMsIHNob3VsZCAncHJvLWFjdGl2ZScgYmUgcmVwbGFjZWQgd2l0aCAncHJv YWN0aXZlJz8gUGVyaGFwcywgdGhlcmUgbWF5IGJlIGEgcmVhc29uIGZvciB0aGUgaHlwaGVuLCBi dXQgSSB3YXMgbm90IHN1cmUuIA0KDQoyKSBJbiBJbnRyb2R1Y3Rpb24sIEkgd291bGQgc3VnZ2Vz dDoNCg0KT0xEOiBUaGUgdXNlIG9mIEdNUExTIFJTVlAtVEUgZm9yIHRoZSBjb25maWd1cmF0aW9u IG9mIE9BTQ0KICAgZnVuY3Rpb25zIGlzIGRlZmluZWQgaW4gYSB0ZWNobm9sb2d5IGFnbm9zdGlj IHdheSBpbiBbUkZDNzI2MF0uDQpORVc6IFtSRkM3MjYwXSBkZWZpbmVzIFRoZSB1c2Ugb2YgR01Q TFMgUlNWUC1URSBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gb2YgT0FNDQogICBmdW5jdGlvbnMgaXMg ZGVmaW5lZCBpbiBhIHRlY2hub2xvZ3kgYWdub3N0aWMgd2F5Lg0KDQozKSBJbiBJbnRyb2R1Y3Rp b24gKHRoZSBzZWNvbmQgcGFyYWdyYXBoKSwgSSBhbSBub3Qgc3VyZSBpZiB5b3UgbmVlZCwgJ3Ro ZSBUcmFuc3BvcnQgUHJvZmlsZSBvZiBNUExTJyBhZnRlciBNUExTLVRQLiANCg0KNCkgSW4gSW50 cm9kdWN0aW9uICh0aGUgZm91cnRoIHBhcmFncmFwaCksIGlzIHRoZXJlIGFueSByZWZlcmVuY2Ug Zm9yIHRoZSBsYXN0IHNlbnRlbmNlLCAiQWRkaXRpb25hbGx5LCB0aGVyZSBpcyBhIG51bWJlciBv ZiBGYXVsdCBNYW5hZ2VtZW50IFNpZ25hbHMgdGhhdCBjYW4gYmUgY29uZmlndXJlZC4iPyBBbHNv IHN1Z2dlc3Q6DQoNCk9MRDogQWRkaXRpb25hbGx5DQpOZXc6IEFkZGl0aW9uYWxseSwgDQoNCjUp IEluIFNlY3Rpb24gMy4xICh0aGUgc2Vjb25kIHBhcmFncmFwaCk6IFRoaXMgc3ViLVRMViBhcyBo YXMgdG8gYmUgZXhhbWluZWQuLi4gSSB3b3VsZCBzdWdnZXN0IHJlcGxhY2luZyAnaGFzIHRvIGJl JyB0byBlaXRoZXIgTVVTVCBvciBTSE9VTEQuIA0KDQo2KSBJbiBTZWN0aW9uIDMuMjogLSAiQkZE IENvbmZpZ3VyYXRpb24gc3ViLVRMViIsIHdoaWNoIE1VU1QgYmUgaW5jbHVkZWQgaWYgdGhlIEND DQogICAgICBhbmQvb3IgdGhlIENWIE9BTSBGdW5jdGlvbiBmbGFnIGlzIHNldC4gSXQgd2FzIG5v dCBjbGVhciB0byBtZSB3aGVyZSB0aGUgQ0MgYW5kL29yIENWIE9BTSBGdW5jdGlvbiBGbGFnIGlz IHNldC4gUmVmZXJlbmNlIHdvdWxkIGJlIGdvb2QuIEkgcHJlc3VtZSBpdCBpcyB0aGUgT0FNIENv bmZpZ3VyYXRpb24gVExWIGluIFtSRkM3MjYwXS4gDQoNCjcpIEkgaGF2ZSBzaW1pbGFyIGNvbW1l bnRzIGFzIDYpIHRocm91Z2hvdXQgdGhpcyBzZWN0aW9uIHdoZW4geW91IHJlZmVyIHRvICdOJyBm bGFnLCAnSScgZmxhZywgZXRjLiANCg0KOCkgSW4gU2VjdGlvbiAzLjI6DQoNCiBPTEQ6IC0gTVBM UyBPQU0gQ29uZmlndXJhdGlvbiBzdWItVExWIE1BWSBiZSBlbXB0eSwgaS5lLiBoYXZlIG5vIFZh bHVlLg0KICAgICAgVGhlbiBpdHMgTGVuZ3RoIE1VU1QgYmUgOC4gIFRoZW4gYWxsIE9BTSBmdW5j dGlvbnMgdGhhdCBoYXZlIHRoZWlyDQogICAgICBjb3JyZXNwb25kaW5nIGZsYWdzIHNldCBpbiB0 aGUgIk9BTSBGdW5jdGlvbiBGbGFncyBzdWItVExWIiBNVVNUDQogICAgICBiZSBhc3NpZ25lZCB0 aGVpciBkZWZhdWx0IHZhbHVlcyBvciBsZWZ0IGRpc2FibGVkLg0KDQogTkVXOiAtIElmIE1QTFMg T0FNIENvbmZpZ3VyYXRpb24gc3ViLVRMViBNQVkgYmUgZW1wdHksIGkuZS4gaGF2ZSBubyBWYWx1 ZSwNCiAgICAgIHRoZW4gaXRzIExlbmd0aCBNVVNUIGJlIDggYW5kIGFsbCBPQU0gZnVuY3Rpb25z IHRoYXQgaGF2ZSB0aGVpcg0KICAgICAgY29ycmVzcG9uZGluZyBmbGFncyBzZXQgaW4gdGhlICJP QU0gRnVuY3Rpb24gRmxhZ3Mgc3ViLVRMViIgTVVTVA0KICAgICAgYmUgYXNzaWduZWQgdGhlaXIg ZGVmYXVsdCB2YWx1ZXMgb3IgbGVmdCBkaXNhYmxlZC4NCg0KIE9MRDogLSBzdWItVExWIHRoYXQg ZG9lc24ndCBoYXZlIGNvcnJlc3BvbmRpbmcgZmxhZyBzZXQgTVVTVCBiZQ0KICAgICAgc2lsZW50 bHkgaWdub3JlZDsNCg0KIE5FVzogLSBTdWItVExWLi4uLiAoQ2FwaXRhbGl6ZSkgDQoNCiBPTEQ6 IC0gaWYgbXVsdGlwbGUgY29waWVzIG9mIGEgc3ViLVRMViBhcmUgcHJlc2VudCwgdGhlbiBvbmx5 IHRoZSBmaXJzdA0KICAgICAgc3ViLVRMViBNVVNUIGJlIHVzZWQgYW5kIHRoZSByZW1haW5pbmcg c3ViLVRMVnMgTVVTVCBiZSBzaWxlbnRseQ0KICAgICAgaWdub3JlZC4NCg0KIE5FVzogLSBJZiBt dWx0aXBsZS4uLi4gKENhcGl0YWxpemUpIA0KDQo5KSBTZWN0aW9uIDMuMi4xLCBpdCB3b3VsZCBi ZSBlYXNpZXIgdG8gdHJhY2UgaWYgeW91IHdvdWxkIHJlZmVyZW5jZSBmb3IgdGhlIGZpcnN0IHNl bnRlbmNlLCBzaW1pbGFyIHRvIGNvbW1lbnQgNCkuIA0KDQpUaGFua3MsDQpZb3VuZw0K From nobody Mon Jan 19 12:04: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 2AD5E1B2C30; Mon, 19 Jan 2015 12:04:31 -0800 (PST) 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 zalSO6xHcukc; Mon, 19 Jan 2015 12:04:29 -0800 (PST) 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 3FF601B2C76; Mon, 19 Jan 2015 12:04:28 -0800 (PST) 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 BRN07764; Mon, 19 Jan 2015 20:04:26 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 19 Jan 2015 20:04:25 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Mon, 19 Jan 2015 12:04:11 -0800 From: Leeyoung To: Leeyoung , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt Thread-Index: AQHQNCMXvrj5anlv+Uah41+rgGF9xQ== Date: Mon, 19 Jan 2015 20:04:11 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C79E93@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C79E28@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C79E28@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'rtg-dir@ietf.org'" , "'ccamp@ietf.org'" , "draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext.all@tools.ietf.org" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.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, 19 Jan 2015 20:04:31 -0000 SGksDQoNClNvcnJ5LCBvbmUgb2YgdGhlIG5pdHMgaGFkIGEgbml0OiBJIHNob3VsZCBiZToNCg0K T0xEOiBUaGUgdXNlIG9mIEdNUExTIFJTVlAtVEUgZm9yIHRoZSBjb25maWd1cmF0aW9uIG9mIE9B TQ0KICAgZnVuY3Rpb25zIGlzIGRlZmluZWQgaW4gYSB0ZWNobm9sb2d5IGFnbm9zdGljIHdheSBp biBbUkZDNzI2MF0uDQpORVc6IFtSRkM3MjYwXSBkZWZpbmVzIHVzZSBvZiBHTVBMUyBSU1ZQLVRF IGZvciB0aGUgY29uZmlndXJhdGlvbiBvZiBPQU0NCiAgIGZ1bmN0aW9ucyBpbiBhIHRlY2hub2xv Z3kgYWdub3N0aWMgd2F5Lg0KDQpUaGFua3MsDQpZb3VuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogcnRnLWRpciBbbWFpbHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIExlZXlvdW5nDQpTZW50OiBNb25kYXksIEphbnVhcnkgMTksIDIwMTUgMTI6 MzYgUE0NClRvOiBydGctYWRzQHRvb2xzLmlldGYub3JnDQpDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcn OyAnY2NhbXBAaWV0Zi5vcmcnOyBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0t ZXh0LmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6 IGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMTUudHh0DQoNCkhlbGxv LCANCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2 aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJl dmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0 aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBz cGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBh c3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg dGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciANCg0KQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdv dWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkg b3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4gDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0t ZXh0LTE1LnR4dA0KUmV2aWV3ZXI6IFlvdW5nIExlZQ0KUmV2aWV3IERhdGU6IDE5IEphbnVhcnks IDIwMTUNCklFVEYgTEMgRW5kIERhdGU6IG5vdCBzdXJlDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5k YXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KDQpUaGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJs aWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJpb3IgdG8g cHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUg Y29uZmlndXJhdGlvbiBvZiBwcm9hY3RpdmUgTVBMUy1UUCBPQU0gZnVuY3Rpb25zIGNhcnJpZWQg YnkgdGhlIEdNUExTIFJTVlAtVEUgcHJvdG9jb2xzIGJhc2VkIG9uIHRoZSBPQU0gQ29uZmlndXJh dGlvbiBGcmFtZXdvcmsgZm9yIEdNUExTIFJTVlAtVEUuIFRoZSBkb2N1bWVudCBpcyBpbiBnb29k IHNoYXBlIGJ1dCB0aGVyZSBhcmUgYSBmZXcgcG9pbnRzIHRoYXQgc2hvdWxkIGJlIGNsYXJpZmll ZCB0byBpbXByb3ZlIHRoZSByZWFkYWJpbGl0eS4gDQoNCk1ham9yIElzc3VlczoNCg0KTm9uZQ0K DQpNaW5vciBJc3N1ZXM6DQoNCk5vbmUNCg0KTml0czoNCg0KMSkgSW4gQWJzdHJhY3QgYW5kIG90 aGVyIHBhcnRzLCBzaG91bGQgJ3Byby1hY3RpdmUnIGJlIHJlcGxhY2VkIHdpdGggJ3Byb2FjdGl2 ZSc/IFBlcmhhcHMsIHRoZXJlIG1heSBiZSBhIHJlYXNvbiBmb3IgdGhlIGh5cGhlbiwgYnV0IEkg d2FzIG5vdCBzdXJlLiANCg0KMikgSW4gSW50cm9kdWN0aW9uLCBJIHdvdWxkIHN1Z2dlc3Q6DQoN Ck9MRDogVGhlIHVzZSBvZiBHTVBMUyBSU1ZQLVRFIGZvciB0aGUgY29uZmlndXJhdGlvbiBvZiBP QU0NCiAgIGZ1bmN0aW9ucyBpcyBkZWZpbmVkIGluIGEgdGVjaG5vbG9neSBhZ25vc3RpYyB3YXkg aW4gW1JGQzcyNjBdLg0KTkVXOiBbUkZDNzI2MF0gZGVmaW5lcyBUaGUgdXNlIG9mIEdNUExTIFJT VlAtVEUgZm9yIHRoZSBjb25maWd1cmF0aW9uIG9mIE9BTQ0KICAgZnVuY3Rpb25zIGlzIGRlZmlu ZWQgaW4gYSB0ZWNobm9sb2d5IGFnbm9zdGljIHdheS4NCg0KMykgSW4gSW50cm9kdWN0aW9uICh0 aGUgc2Vjb25kIHBhcmFncmFwaCksIEkgYW0gbm90IHN1cmUgaWYgeW91IG5lZWQsICd0aGUgVHJh bnNwb3J0IFByb2ZpbGUgb2YgTVBMUycgYWZ0ZXIgTVBMUy1UUC4gDQoNCjQpIEluIEludHJvZHVj dGlvbiAodGhlIGZvdXJ0aCBwYXJhZ3JhcGgpLCBpcyB0aGVyZSBhbnkgcmVmZXJlbmNlIGZvciB0 aGUgbGFzdCBzZW50ZW5jZSwgIkFkZGl0aW9uYWxseSwgdGhlcmUgaXMgYSBudW1iZXIgb2YgRmF1 bHQgTWFuYWdlbWVudCBTaWduYWxzIHRoYXQgY2FuIGJlIGNvbmZpZ3VyZWQuIj8gQWxzbyBzdWdn ZXN0Og0KDQpPTEQ6IEFkZGl0aW9uYWxseQ0KTmV3OiBBZGRpdGlvbmFsbHksIA0KDQo1KSBJbiBT ZWN0aW9uIDMuMSAodGhlIHNlY29uZCBwYXJhZ3JhcGgpOiBUaGlzIHN1Yi1UTFYgYXMgaGFzIHRv IGJlIGV4YW1pbmVkLi4uIEkgd291bGQgc3VnZ2VzdCByZXBsYWNpbmcgJ2hhcyB0byBiZScgdG8g ZWl0aGVyIE1VU1Qgb3IgU0hPVUxELiANCg0KNikgSW4gU2VjdGlvbiAzLjI6IC0gIkJGRCBDb25m aWd1cmF0aW9uIHN1Yi1UTFYiLCB3aGljaCBNVVNUIGJlIGluY2x1ZGVkIGlmIHRoZSBDQw0KICAg ICAgYW5kL29yIHRoZSBDViBPQU0gRnVuY3Rpb24gZmxhZyBpcyBzZXQuIEl0IHdhcyBub3QgY2xl YXIgdG8gbWUgd2hlcmUgdGhlIENDIGFuZC9vciBDViBPQU0gRnVuY3Rpb24gRmxhZyBpcyBzZXQu IFJlZmVyZW5jZSB3b3VsZCBiZSBnb29kLiBJIHByZXN1bWUgaXQgaXMgdGhlIE9BTSBDb25maWd1 cmF0aW9uIFRMViBpbiBbUkZDNzI2MF0uIA0KDQo3KSBJIGhhdmUgc2ltaWxhciBjb21tZW50cyBh cyA2KSB0aHJvdWdob3V0IHRoaXMgc2VjdGlvbiB3aGVuIHlvdSByZWZlciB0byAnTicgZmxhZywg J0knIGZsYWcsIGV0Yy4gDQoNCjgpIEluIFNlY3Rpb24gMy4yOg0KDQogT0xEOiAtIE1QTFMgT0FN IENvbmZpZ3VyYXRpb24gc3ViLVRMViBNQVkgYmUgZW1wdHksIGkuZS4gaGF2ZSBubyBWYWx1ZS4N CiAgICAgIFRoZW4gaXRzIExlbmd0aCBNVVNUIGJlIDguICBUaGVuIGFsbCBPQU0gZnVuY3Rpb25z IHRoYXQgaGF2ZSB0aGVpcg0KICAgICAgY29ycmVzcG9uZGluZyBmbGFncyBzZXQgaW4gdGhlICJP QU0gRnVuY3Rpb24gRmxhZ3Mgc3ViLVRMViIgTVVTVA0KICAgICAgYmUgYXNzaWduZWQgdGhlaXIg ZGVmYXVsdCB2YWx1ZXMgb3IgbGVmdCBkaXNhYmxlZC4NCg0KIE5FVzogLSBJZiBNUExTIE9BTSBD b25maWd1cmF0aW9uIHN1Yi1UTFYgTUFZIGJlIGVtcHR5LCBpLmUuIGhhdmUgbm8gVmFsdWUsDQog ICAgICB0aGVuIGl0cyBMZW5ndGggTVVTVCBiZSA4IGFuZCBhbGwgT0FNIGZ1bmN0aW9ucyB0aGF0 IGhhdmUgdGhlaXINCiAgICAgIGNvcnJlc3BvbmRpbmcgZmxhZ3Mgc2V0IGluIHRoZSAiT0FNIEZ1 bmN0aW9uIEZsYWdzIHN1Yi1UTFYiIE1VU1QNCiAgICAgIGJlIGFzc2lnbmVkIHRoZWlyIGRlZmF1 bHQgdmFsdWVzIG9yIGxlZnQgZGlzYWJsZWQuDQoNCiBPTEQ6IC0gc3ViLVRMViB0aGF0IGRvZXNu J3QgaGF2ZSBjb3JyZXNwb25kaW5nIGZsYWcgc2V0IE1VU1QgYmUNCiAgICAgIHNpbGVudGx5IGln bm9yZWQ7DQoNCiBORVc6IC0gU3ViLVRMVi4uLi4gKENhcGl0YWxpemUpIA0KDQogT0xEOiAtIGlm IG11bHRpcGxlIGNvcGllcyBvZiBhIHN1Yi1UTFYgYXJlIHByZXNlbnQsIHRoZW4gb25seSB0aGUg Zmlyc3QNCiAgICAgIHN1Yi1UTFYgTVVTVCBiZSB1c2VkIGFuZCB0aGUgcmVtYWluaW5nIHN1Yi1U TFZzIE1VU1QgYmUgc2lsZW50bHkNCiAgICAgIGlnbm9yZWQuDQoNCiBORVc6IC0gSWYgbXVsdGlw bGUuLi4uIChDYXBpdGFsaXplKSANCg0KOSkgU2VjdGlvbiAzLjIuMSwgaXQgd291bGQgYmUgZWFz aWVyIHRvIHRyYWNlIGlmIHlvdSB3b3VsZCByZWZlcmVuY2UgZm9yIHRoZSBmaXJzdCBzZW50ZW5j ZSwgc2ltaWxhciB0byBjb21tZW50IDQpLiANCg0KVGhhbmtzLA0KWW91bmcNCg== From nobody Mon Jan 19 14:54:42 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 2BB4A1B2D13; Mon, 19 Jan 2015 14:54:35 -0800 (PST) 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 YKCfPflU-jON; Mon, 19 Jan 2015 14:54:32 -0800 (PST) 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 011B31B2D0A; Mon, 19 Jan 2015 14:54:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRN15525; Mon, 19 Jan 2015 22:54:29 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 19 Jan 2015 22:54:28 +0000 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, 19 Jan 2015 14:54:19 -0800 From: Leeyoung To: Tomonori Takeda , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt Thread-Index: AdAyVmdKICzu0mt5SZ+spYC7d3T1cAB2eNGw Date: Mon, 19 Jan 2015 22:54:18 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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, 19 Jan 2015 22:54:35 -0000 SGkgVG9tb25vcmksDQoNClRoYW5rcyBmb3IgcHJvdmlkaW5nIGdvb2QgY29tbWVudHMuIEhlcmUn cyBteSByZXNwb25zZS4gUGxlYXNlIHNlZSBpbi1saW5lLg0KDQpSZWdhcmRzLA0KWW91bmcNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Zy1kaXIgW21haWx0bzpydGctZGly LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb21vbm9yaSBUYWtlZGENClNlbnQ6IFNh dHVyZGF5LCBKYW51YXJ5IDE3LCAyMDE1IDc6NTkgQU0NClRvOiBydGctYWRzQHRvb2xzLmlldGYu b3JnDQpDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNv bnN0cmFpbnQtZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZycNClN1 YmplY3Q6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwt Y29uc3RyYWludC1lbmNvZGUtMTYudHh0DQoNCkhlbGxvLCANCg0KSSBoYXZlIGJlZW4gc2VsZWN0 ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRo ZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0 aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFu ZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJw b3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5n IEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUs IHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93 aWtpL1J0Z0RpciANCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3Ig dGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNv dWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29t bWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3Vn aCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4gDQoNCkRvY3VtZW50OiBkcmFm dC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGUtMTYudHh0IA0KUmV2aWV3ZXI6 IFRvbW9ub3JpIFRha2VkYQ0KUmV2aWV3IERhdGU6IDE3IEphbnVhcnksIDIwMTUNCklFVEYgTEMg RW5kIERhdGU6IDE3IEphbnVhcnksIDIwMTUNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRy YWNrDQoNClN1bW1hcnk6DQoNClRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBw dWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJpb3Ig dG8gcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBw cm90b2NvbC1hZ25vc3RpYyBlbmNvZGluZ3MgZm9yIGdlbmVyYWwgaW5mb3JtYXRpb24gZWxlbWVu dHMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLWluZm8uDQpJIHRoaW5rIHRoZSBk b2N1bWVudCBpcyBpbiBnb29kIHNoYXBlIGJ1dCB0aGVyZSBhcmUgYSBmZXcgcG9pbnRzIHRoYXQg c2hvdWxkIGJlIGNsYXJpZmllZCBmb3IgYmV0dGVyIHVuZGVyc3RhbmRpbmcuDQoNCk1ham9yIElz c3VlczoNCg0KTm9uZQ0KDQpNaW5vciBJc3N1ZXM6DQoNCk5vbmUNCg0KTml0czoNCg0KMSkgSW4g c2VjdGlvbiAxLjIsIGxhYmVsIGNvbnRpbnVpdHkgY29uc3RyYWludCAoZS5nLiwgd2F2ZWxlbmd0 aCBjb250aW51aXR5IGluIFdTT04pIGlzIG1lbnRpb25lZC4gSG93ZXZlciwgSSBhbSBub3Qgc3Vy ZSB3aGV0aGVyIGluZm9ybWF0aW9uIGVsZW1lbnRzIGZvciB3aGljaCB0aGlzIGRvY3VtZW50IHNw ZWNpZmllcyBlbmNvZGluZ3MgY2FuIGRlc2NyaWJlIHN1Y2ggY29uc3RyYWludC4gTXkgcmVhZGlu ZyBpcyB0aGF0IGluZm9ybWF0aW9uIGVsZW1lbnQgc3VjaCBhcyBQb3J0IExhYmVsIFJlc3RyaWN0 aW9uIGlzIHJhdGhlciBmb3IgZGVzY3JpYmluZyB3YXZlbGVuZ3RoIHR1bmluZyBjYXBhYmlsaXRp ZXMvcmVzdHJpY3Rpb25zLg0KDQpZT1VORz4+IExhYmVsIGNvbnRpbnVpdHkgY29uc3RyYWludHMg Y2FuIGJlIGluZmVycmVkIGZyb20gdGhlIHR3byBwbGFjZXMgaW4gdGhlIGRyYWZ0OiAoaSkgUG9y dCBMYWJlbCBSZXN0cmljdGlvbiwgd2hpY2ggZ2l2ZXMgdGhlIHNldCBvZiBsYWJlbHMgKHdhdmVs ZW5ndGhzKSB0aGF0IG1heSBub3QgYmUgYXZhaWxhYmxlIG9uIGNlcnRhaW4gbGlua3MgaW5jbHVk aW5nIHR1bmluZyByYW5nZS9yZXN0cmljdGlvbjsgKGlpKSBBdmFpbGFibGUvU2hhcmVkIEJhY2t1 cCBMYWJlbCBGaWVsZHMgKHNlY3Rpb24gMi40ICYgc2VjdGlvbiAyLjUpLiBUaGVyZSBpcyBubyBl bmNvZGluZyBmb3IgbGFiZWwgY29udGludWl0eSBjb25zdHJhaW50IHBlciBzZS4gVGhlIGFmb3Jl bWVudGlvbmVkIGNvbnN0cmFpbnRzIGFyZSBlbmNvZGVkIHRvIGdpdmUgYSBub2RlIG9yIGEgUENF IHRvIGJlIGFibGUgdG8gY29tcHV0ZSBhIHBhdGggKGkuZS4sIHBhdGggd2l0aCB3YXZlbGVuZ3Ro IGNvbnRpbnVpdHkpIHN1YmplY3QgdG8gdGhlc2UgY29uc3RyYWludHMuIA0KDQoyKSBJbiBzZWN0 aW9uIDIuMSwgaXQgc2F5cyAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge3Ny YyBwb3J0LCBzcmMgbGFiZWwsIGRzdCBwb3J0LCBkc3QgbGFiZWx9Ii4gVG8gYmUgcHJlY2lzZSwg SSBndWVzcyB0aGlzIHNob3VsZCBiZSAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNh bWUge3NyYyBwb3J0LCBzcmMgbGFiZWx9LCBhbmQgdHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUg dGhlIHNhbWUge2RzdCBwb3J0LCBkc3QgbGFiZWx9Ij8NCg0KWU9VTkc+PiBJIHRoaW5rIHlvdXIg c3VnZ2VzdGlvbiBtYXkgYmUgdG9vIHJlc3RyaWN0aXZlLiBGb3IgaW5zdGFuY2UsIGlmIHdlIGhh dmUgb25lIHNvdXJjZSAocG9ydCAxKSBhbmQgb25lIGRlc3RpbmF0aW9uIChwb3J0IDIpIHdpdGgg dHdvIGxhYmVscyBlYWNoLiBUaGVuIHdlIHdvdWxkIGhhdmU6IHsoMSwxLDIsMSksICgxLDEsMiwy KSwgKDEsMiwyLDEpLCAoMSwyLDIsMil9IEkgdGhpbmsgd2l0aCB0aGUgY3VycmVudCBzdGF0ZW1l bnQsIHdlIGNhbiBzZW5kIHRoaXMgaW5mbyBpbiBhbnkgY29tYmluYXRpb24gb2YgbXVsdGlwbGUg bWF0cmljZXMsIHdoaWNoIEkgdGhpbmsgcGVyZmVjdGx5IGZpbmUuIFdpdGggeW91ciBzdWdnZXN0 aW9uLCBJIHdvdWxkIG5vdCBiZSBhYmxlIHNlbmQgKDEsMSwyLDEpIGFuZCAoMSwxLDIsMikgdG9n ZXRoZXIuIFdoeSB3b3VsZCB0aGlzIG5vdCBiZSBtYWRlIHBvc3NpYmxlPyBNeSB0YWtlIGlzIGFz IGxvbmcgYXMgZWFjaCBzdWJtYXRyaXggcmVwcmVzZW50cyBhIHNldCBvZiBkaXNqb2ludCBxdWFk cnVwbGVzLCB0aGF0IHNob3VsZCBiZSBhbGxvd2VkLiANCg0KMykgSW4gc2VjdGlvbiAyLjEsIGl0 IHNheXMgIlRoZSB2YWx1ZSBvZiAweEZGIGlzIHJlc2VydmVkIGZvciB1c2Ugd2l0aCBwb3J0IHdh dmVsZW5ndGggY29uc3RyYWludHMiLiBJIHRoaW5rICJwb3J0IHdhdmVsZW5ndGggY29uc3RyYWlu dHMiIHNob3VsZCBiZSAicG9ydCBsYWJlbCByZXN0cmljdGlvbiIuDQoNCllPVU5HPj4gWWVzLCB0 aGFua3MuIA0KDQo0KSBJbiBzZWN0aW9uIDIuMSwgZm9yIExpbmsgU2V0IEEgZGlyPWJpZGlyZWN0 aW9uYWwsIExpbmsgU2V0IEIgZGlyPWJpZGlyZWN0aW9uYWwsIGlmIGFueSBzaWduYWwgb24gYW4g aW5wdXQgbGluayBYIGlzIG91dHB1dCBvbiBhIGxpbmsgWSwgdGhlbiBhbnkgc2lnbmFsIG9uIGFu IGlucHV0IGxpbmsgWSBpcyBvdXRwdXQgb24gYSBsaW5rIFggKGFmdGVyIGNyb3NzLWNvbm5lY3Qp PyBPciBhbnkgY29uc3RyYWludCBvbiBzdWNoIHNpZ25hbCBmbG93IChhZnRlciBjcm9zcy1jb25u ZWN0KSBpcyBvdXQgb2Ygc2NvcGU/DQoNCllPVU5HPj4gSSBhbSBub3Qgc3VyZSB3aGF0ICJhZnRl ciBjcm9zcy1jb25uZWN0IiBpcyBtZWFudC4gDQoNCjUpIEluIHNlY3Rpb24gMi4yLjEsIGl0IHNh eXMgIkluIHRoaXMgY2FzZSB0aGUgYWNjb21wYW55aW5nIGxhYmVsIHNldCBpbmRpY2F0ZXMgdGhl IGxhYmVscyBwZXJtaXR0ZWQgb24gdGhlIHBvcnQuIiBJIHRoaW5rICJwb3J0IiBzaG91bGQgYmUg InBvcnQvbWF0cml4Ii4NCg0KWU9VTkc+PiBZZXMsIHRoYW5rcy4gDQoNCjYpIEluIHNlY3Rpb24g Mi4yLjIsIGl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgdHlwZSAoZS5nLiwgaW50 ZWdlcikgZm9yIE1heE51bUNoYW5uZWxzLg0KVGhpcyBhbHNvIGFwcGxpZXMgZm9yIE1heExhYmVs UmFuZ2UgKGluIHNlY3Rpb24gMi4yLjMpIGFuZCBOdW0gTGFiZWxzIChpbiBzZWN0aW9uIDIuNiku DQoNCllPVU5HPj4gT0suIA0KDQo3KSBJbiBzZWN0aW9uIDIuNiwgaXQgc2F5cyAiTGFiZWwgU2V0 IEZpZWxkIGlzIHVzZWQgd2l0aGluIHRoZSA8QXZhaWxhYmxlTGFiZWxzPiBvciB0aGUgPFNoYXJl ZEJhY2t1cExhYmVscz4iLiBCdXQgSSB0aGluayBMYWJlbCBTZXQgRmllbGQgaXMgYWxzbyB1c2Vk IHdpdGhpbiBTSU1QTEVfTEFCRUwsIExBQkVMX1JBTkdFIGFuZCBTSU1QTEVfTEFCRUwgJiBDSEFO TkVMX0NPVU5ULg0KDQpZT1VORz4+IFllcywgaXQgaXMgdXNlZCBpbiBtdWx0aXBsZSBwbGFjZXMu IA0KDQpIb3cgYWJvdXQ6DQpPTEQ6IExhYmVsIFNldCBGaWVsZCBpcyB1c2VkIHdpdGhpbiB0aGUg PEF2YWlsYWJsZUxhYmVscz4gb3IgdGhlDQogICA8U2hhcmVkQmFja3VwTGFiZWxzPiwgd2hpY2gg aXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIuNC4gYW5kIDIuNS4sDQogICByZXNwZWN0aXZlbHkuDQpO RVc6IExhYmVsIFNldCBGaWVsZCBpcyB1c2VkIHdpdGhpbiB0aGUgPEF2YWlsYWJsZUxhYmVscz4g b3IgdGhlDQogICA8U2hhcmVkQmFja3VwTGFiZWxzPiwgd2hpY2ggaXMgZGVmaW5lZCBpbiBTZWN0 aW9uIDIuNC4gYW5kIDIuNS4sDQogICByZXNwZWN0aXZlbHkuIEl0IGlzIGFsc28gdXNlZCB3aXRo aW4gdGhlIDxTSU1QTEVfTEFCRUw+LCANCiAgIDxMQUJFTF9SQU5HRT4sIDxTSU1QTEVfTEFCRUw+ IG9yIDxDSEFOTkVMX0NPVU5UPiwgd2hpY2ggaXMgZGVmaW5lZA0KICAgaW4gU2VjdGlvbnMgMi4x LjEgLSAyLjEuNCwgcmVzcGVjdGl2ZWx5LiANCg0KDQpUaGFua3MsDQpUb21vbm9yaQ0K From nobody Mon Jan 19 14:55: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 02AA21B2D18 for ; Mon, 19 Jan 2015 14:55:48 -0800 (PST) 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 ZUn7UpINJ97E for ; Mon, 19 Jan 2015 14:55:46 -0800 (PST) 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 CF2761B2D16 for ; Mon, 19 Jan 2015 14:55:45 -0800 (PST) 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 BRN15593; Mon, 19 Jan 2015 22:55:44 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 19 Jan 2015 22:55:43 +0000 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, 19 Jan 2015 14:55:39 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-general-constraint-encode@tools.ietf.org" Thread-Topic: [CCAMP] Last Call Expired: Thread-Index: AQHQMizdnp6AZJv8L0WFk0EHwWi1PZzGsMGAgAFgqZA= Date: Mon, 19 Jan 2015 22:55:38 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7B11F@dfweml706-chm> References: <20150117080822.9166.5118.idtracker@ietfa.amsl.com> <00b401d03347$80821e10$81865a30$@olddog.co.uk> In-Reply-To: <00b401d03347$80821e10$81865a30$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Last Call Expired: 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, 19 Jan 2015 22:55:48 -0000 Hi Adrian, Yes, it will be updated shortly. Regards, Young=20 -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, January 18, 2015 11:52 AM To: draft-ietf-ccamp-general-constraint-encode@tools.ietf.org Cc: ccamp@ietf.org Subject: Re: [CCAMP] Last Call Expired: Hi authors, You have received reviews from the Routing Directorate, Security Directorat= e, and General Area Review Team. All indicated minor editorials that seem e= asy to fix and benign. Could you please post a new revision addressing these points. Thanks for the work, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of DraftTracker Mail = System > Sent: 17 January 2015 08:08 > To: iesg@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-general- > constraint-encode@tools.ietf.org > Cc: iesg-secretary@ietf.org > Subject: Last Call Expired: >=20 >=20 > Please DO NOT reply to this email. >=20 > I-D: > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ccamp-general- > constraint-encode/ >=20 > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From nobody Mon Jan 19 18:08:39 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 995521A9080; Mon, 19 Jan 2015 18:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RLD_8QaLrO_V; Mon, 19 Jan 2015 18:08:27 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79441A9079; Mon, 19 Jan 2015 18:08:26 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-4d-54bd662196e6 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DE.20.03307.1266DB45; Mon, 19 Jan 2015 21:16:33 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 21:08:23 -0500 From: Gregory Mirsky To: Leeyoung , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt Thread-Index: AQHQNCMqXFKUqtcClk2QnwLL3lAFRZzIN3UA Date: Tue, 20 Jan 2015 02:08:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8E135C@eusaamb103.ericsson.se> References: <7AEB3D6833318045B4AE71C2C87E8E1729C79E28@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C79E93@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C79E93@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPiK5i2t4Qg23NxhZP5txgsZj6XtNi 2jxXi+dzZrJYLFjzlN2B1aPlyFtWjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr4++CY6wF bU4Vy69uZ2pgXOPQxcjJISFgIrH37To2CFtM4sK99UA2F4eQwBFGiVsPDrBCOMsZJfb+fcsK UsUmYCTxYmMPO4gtIhAuMeX+ERaQImaBy4wSy/9/ZARJCAMlDh9axwhRFCHR3vmaGcI2kvj3 YT1YnEVAVWLnjNtgcV4BX4kpx5azQ2zbxygxaVczWIJTwFXiw9N2sAZGoPu+n1rDBGIzC4hL 3HoynwnibgGJJXvOM0PYohIvH/9jhbAVJfb1TwcaygFUrymxfpc+RKuixJTuh+wQewUlTs58 wjKBUWwWkqmzEDpmIemYhaRjASPLKkaO0uLUstx0I4NNjMBYOibBpruDcc9Ly0OMAhyMSjy8 G5j2hAixJpYVV+YeYpTmYFES5215tz5ESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2NxuL3i rIS8tGNhkvZ/iuI3OOWyPOR5bl4s7sLIbpU5V7q6OnL9ulVTdA79jb3uz9u95UShgzX7KlM7 P7GUlGPOX8tF7ER/aLQo6a2y8e7Y/SRubudVeVtR9xzej3ktL9S+X5i/PrOR86BXwK+Fd1/d 5v6kuSiPJUNIUmsrO/eiQNV5TZ+vKrEUZyQaajEXFScCAMiL1HaGAgAA Archived-At: Cc: "'rtg-dir@ietf.org'" , "'ccamp@ietf.org'" , "draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext.all@tools.ietf.org" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.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: Tue, 20 Jan 2015 02:08:29 -0000 SGkgWW91bmcsDQp0aGFuayB5b3UgZm9yIHlvdXIgdGhyb3VnaCByZXZpZXcgYW5kIGNvbnNpZGVy YXRlIGNvbW1lbnRzLg0KUGxlYXNlIGZpbmQgbXkgYW5zd2VycyBpbi1saW5lIGFuZCB0YWdnZWQg R0lNPj4uDQpQbGVhc2UgbGV0IG1lIGtub3cgd2hldGhlciB3ZSBzaG91bGQgcHVibGlzaCB0aGUg bmV3IHZlcnNpb24gb3IgYWRkcmVzcyB0aGVzZSBjb21tZW50cyBhcyBwYXJ0IG9mIFJGQyBFZGl0 b3IgdXBkYXRlLg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXSANClNlbnQ6 IE1vbmRheSwgSmFudWFyeSAxOSwgMjAxNSAxMjowNCBQTQ0KVG86IExlZXlvdW5nOyBydGctYWRz QHRvb2xzLmlldGYub3JnDQpDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnY2NhbXBAaWV0Zi5vcmcn OyBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0LmFsbEB0b29scy5pZXRm Lm9yZw0KU3ViamVjdDogUkU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNj YW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0LTE1LnR4dA0KDQpIaSwNCg0KU29ycnksIG9uZSBv ZiB0aGUgbml0cyBoYWQgYSBuaXQ6IEkgc2hvdWxkIGJlOg0KDQpPTEQ6IFRoZSB1c2Ugb2YgR01Q TFMgUlNWUC1URSBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gb2YgT0FNDQogICBmdW5jdGlvbnMgaXMg ZGVmaW5lZCBpbiBhIHRlY2hub2xvZ3kgYWdub3N0aWMgd2F5IGluIFtSRkM3MjYwXS4NCk5FVzog W1JGQzcyNjBdIGRlZmluZXMgdXNlIG9mIEdNUExTIFJTVlAtVEUgZm9yIHRoZSBjb25maWd1cmF0 aW9uIG9mIE9BTQ0KICAgZnVuY3Rpb25zIGluIGEgdGVjaG5vbG9neSBhZ25vc3RpYyB3YXkuDQpH SU0+PiBBY2NlcHRlZCwgZG9uZS4NCg0KVGhhbmtzLA0KWW91bmcNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IHJ0Zy1kaXIgW21haWx0bzpydGctZGlyLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBMZWV5b3VuZw0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE5LCAyMDE1 IDEyOjM2IFBNDQpUbzogcnRnLWFkc0B0b29scy5pZXRmLm9yZw0KQ2M6ICdydGctZGlyQGlldGYu b3JnJzsgJ2NjYW1wQGlldGYub3JnJzsgZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAt b2FtLWV4dC5hbGxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFtSVEctRElSXSBSdGdEaXIgcmV2 aWV3OiBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0LTE1LnR4dA0KDQpI ZWxsbywgDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIgDQoNCkFsdGhvdWdoIHRoZXNl IGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBp dCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGgg YW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBz dHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0 aGUgZHJhZnQuIA0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAt b2FtLWV4dC0xNS50eHQNClJldmlld2VyOiBZb3VuZyBMZWUNClJldmlldyBEYXRlOiAxOSBKYW51 YXJ5LCAyMDE1DQpJRVRGIExDIEVuZCBEYXRlOiBub3Qgc3VyZQ0KSW50ZW5kZWQgU3RhdHVzOiBT dGFuZGFyZHMgVHJhY2sNCg0KU3VtbWFyeToNCg0KVGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3Ig cHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHByaW9y IHRvIHB1YmxpY2F0aW9uLg0KDQpDb21tZW50czoNCg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMg dGhlIGNvbmZpZ3VyYXRpb24gb2YgcHJvYWN0aXZlIE1QTFMtVFAgT0FNIGZ1bmN0aW9ucyBjYXJy aWVkIGJ5IHRoZSBHTVBMUyBSU1ZQLVRFIHByb3RvY29scyBiYXNlZCBvbiB0aGUgT0FNIENvbmZp Z3VyYXRpb24gRnJhbWV3b3JrIGZvciBHTVBMUyBSU1ZQLVRFLiBUaGUgZG9jdW1lbnQgaXMgaW4g Z29vZCBzaGFwZSBidXQgdGhlcmUgYXJlIGEgZmV3IHBvaW50cyB0aGF0IHNob3VsZCBiZSBjbGFy aWZpZWQgdG8gaW1wcm92ZSB0aGUgcmVhZGFiaWxpdHkuIA0KDQpNYWpvciBJc3N1ZXM6DQoNCk5v bmUNCkdJTT4+IFRoYW5rIHlvdQ0KDQpNaW5vciBJc3N1ZXM6DQoNCk5vbmUNCkdJTT4+IFRoYW5r IHlvdQ0KDQpOaXRzOg0KDQoxKSBJbiBBYnN0cmFjdCBhbmQgb3RoZXIgcGFydHMsIHNob3VsZCAn cHJvLWFjdGl2ZScgYmUgcmVwbGFjZWQgd2l0aCAncHJvYWN0aXZlJz8gUGVyaGFwcywgdGhlcmUg bWF5IGJlIGEgcmVhc29uIGZvciB0aGUgaHlwaGVuLCBidXQgSSB3YXMgbm90IHN1cmUuIA0KR0lN Pj4gSSBmaW5kIHRoYXQgJ3Byb2FjdGl2ZScgaXMgbW9yZSBjb21tb24gZm9ybS4gQWNjZXB0ZWQg YW5kIHVwZGF0ZWQuDQogDQoyKSBJbiBJbnRyb2R1Y3Rpb24sIEkgd291bGQgc3VnZ2VzdDoNCg0K T0xEOiBUaGUgdXNlIG9mIEdNUExTIFJTVlAtVEUgZm9yIHRoZSBjb25maWd1cmF0aW9uIG9mIE9B TQ0KICAgZnVuY3Rpb25zIGlzIGRlZmluZWQgaW4gYSB0ZWNobm9sb2d5IGFnbm9zdGljIHdheSBp biBbUkZDNzI2MF0uDQpORVc6IFtSRkM3MjYwXSBkZWZpbmVzIFRoZSB1c2Ugb2YgR01QTFMgUlNW UC1URSBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gb2YgT0FNDQogICBmdW5jdGlvbnMgaXMgZGVmaW5l ZCBpbiBhIHRlY2hub2xvZ3kgYWdub3N0aWMgd2F5Lg0KR0lNPj4gSSB0aGluayB0aGF0IHRoZSB2 ZXJ5IGZpcnN0IG5vdGUgYWRkcmVzc2VzIHRoaXMgY2hhbmdlIGFscmVhZHkuDQoNCjMpIEluIElu dHJvZHVjdGlvbiAodGhlIHNlY29uZCBwYXJhZ3JhcGgpLCBJIGFtIG5vdCBzdXJlIGlmIHlvdSBu ZWVkLCAndGhlIFRyYW5zcG9ydCBQcm9maWxlIG9mIE1QTFMnIGFmdGVyIE1QTFMtVFAuIA0KR0lN Pj4gSSB0aGluayBpdCBpcyBhY2NlcHRhYmxlLCBzb21ld2hhdCBjb252ZXJzYXRpb25hbCBmb3Jt Lg0KDQo0KSBJbiBJbnRyb2R1Y3Rpb24gKHRoZSBmb3VydGggcGFyYWdyYXBoKSwgaXMgdGhlcmUg YW55IHJlZmVyZW5jZSBmb3IgdGhlIGxhc3Qgc2VudGVuY2UsICJBZGRpdGlvbmFsbHksIHRoZXJl IGlzIGEgbnVtYmVyIG9mIEZhdWx0IE1hbmFnZW1lbnQgU2lnbmFscyB0aGF0IGNhbiBiZSBjb25m aWd1cmVkLiI/IEFsc28gc3VnZ2VzdDoNCkdJTT4+IEFkZGVkIHJlZmVyZW5jZSB0byBSRkMgIDY0 MjcuDQoNCk9MRDogQWRkaXRpb25hbGx5DQpOZXc6IEFkZGl0aW9uYWxseSwgDQpHSU0+PiBEb25l DQoNCjUpIEluIFNlY3Rpb24gMy4xICh0aGUgc2Vjb25kIHBhcmFncmFwaCk6IFRoaXMgc3ViLVRM ViBhcyBoYXMgdG8gYmUgZXhhbWluZWQuLi4gSSB3b3VsZCBzdWdnZXN0IHJlcGxhY2luZyAnaGFz IHRvIGJlJyB0byBlaXRoZXIgTVVTVCBvciBTSE9VTEQuIA0KR0lNPj4gVXBkYXRlZCAiIFRoaXMg c3ViLVRMViBNVVNUIGJlIGV4YW1pbmVkIGV2ZW4gYnkgaW50ZXJtZWRpYXRlIG5vZGVzIHRoYXQg c3VwcG9ydCB0aGVzZSBleHRlbnNpb25zIC4uLiINCg0KNikgSW4gU2VjdGlvbiAzLjI6IC0gIkJG RCBDb25maWd1cmF0aW9uIHN1Yi1UTFYiLCB3aGljaCBNVVNUIGJlIGluY2x1ZGVkIGlmIHRoZSBD Qw0KICAgICAgYW5kL29yIHRoZSBDViBPQU0gRnVuY3Rpb24gZmxhZyBpcyBzZXQuIEl0IHdhcyBu b3QgY2xlYXIgdG8gbWUgd2hlcmUgdGhlIENDIGFuZC9vciBDViBPQU0gRnVuY3Rpb24gRmxhZyBp cyBzZXQuIFJlZmVyZW5jZSB3b3VsZCBiZSBnb29kLiBJIHByZXN1bWUgaXQgaXMgdGhlIE9BTSBD b25maWd1cmF0aW9uIFRMViBpbiBbUkZDNzI2MF0uIA0KR0lNPj4gVXBkYXRlZCAiICJCRkQgQ29u ZmlndXJhdGlvbiBzdWItVExWIiwgd2hpY2ggTVVTVCBiZSBpbmNsdWRlZCBpZiBlaXRoZXIgdGhl IENDLCB0aGUgQ1Ygb3IgYm90aCBPQU0gRnVuY3Rpb24gZmxhZ3MgYmVpbmcgc2V0IGluIHRoZSBP QU0gRnVuY3Rpb24gRmxhZ3MgU3ViLVRMViBbUkZDNzI2MF0uIg0KDQo3KSBJIGhhdmUgc2ltaWxh ciBjb21tZW50cyBhcyA2KSB0aHJvdWdob3V0IHRoaXMgc2VjdGlvbiB3aGVuIHlvdSByZWZlciB0 byAnTicgZmxhZywgJ0knIGZsYWcsIGV0Yy4gDQpHSU0+PiBJcyB0aGlzIHRoZSBmb2xsb3dpbmc6 DQoiICJQZXJmb3JtYW5jZSBNb25pdG9yaW5nIHN1Yi1UTFYiLCB3aGljaCBNVVNUIGJlIGluY2x1 ZGVkIGlmIGFueSBvZiB0aGUgUE0vRGVsYXksIFBNL0xvc3Mgb3IgUE0vVGhyb3VnaHB1dCBmbGFn cyBhcmUgc2V0IGluIHRoZSAiT0FNIEZ1bmN0aW9uIEZsYWcgc3ViLVRMViBbUkZDNzI2MF0uIiAo cmVmZXJlbmNlIGFkZGVkKQ0KDQo4KSBJbiBTZWN0aW9uIDMuMjoNCg0KIE9MRDogLSBNUExTIE9B TSBDb25maWd1cmF0aW9uIHN1Yi1UTFYgTUFZIGJlIGVtcHR5LCBpLmUuIGhhdmUgbm8gVmFsdWUu DQogICAgICBUaGVuIGl0cyBMZW5ndGggTVVTVCBiZSA4LiAgVGhlbiBhbGwgT0FNIGZ1bmN0aW9u cyB0aGF0IGhhdmUgdGhlaXINCiAgICAgIGNvcnJlc3BvbmRpbmcgZmxhZ3Mgc2V0IGluIHRoZSAi T0FNIEZ1bmN0aW9uIEZsYWdzIHN1Yi1UTFYiIE1VU1QNCiAgICAgIGJlIGFzc2lnbmVkIHRoZWly IGRlZmF1bHQgdmFsdWVzIG9yIGxlZnQgZGlzYWJsZWQuDQoNCiBORVc6IC0gSWYgTVBMUyBPQU0g Q29uZmlndXJhdGlvbiBzdWItVExWIE1BWSBiZSBlbXB0eSwgaS5lLiBoYXZlIG5vIFZhbHVlLA0K ICAgICAgdGhlbiBpdHMgTGVuZ3RoIE1VU1QgYmUgOCBhbmQgYWxsIE9BTSBmdW5jdGlvbnMgdGhh dCBoYXZlIHRoZWlyDQogICAgICBjb3JyZXNwb25kaW5nIGZsYWdzIHNldCBpbiB0aGUgIk9BTSBG dW5jdGlvbiBGbGFncyBzdWItVExWIiBNVVNUDQogICAgICBiZSBhc3NpZ25lZCB0aGVpciBkZWZh dWx0IHZhbHVlcyBvciBsZWZ0IGRpc2FibGVkLg0KR0lNPj4gSSB0aGluayAiSWYiIGFuZCAiTUFZ IiBkb24ndCBtYXRjaCBpbiB0aGUgc2FtZSBzZW50ZW5jZS4gSSB0aGluayBpdCBpcyBvbmUgb3Ig YW5vdGhlci4gJ01BWScgYmVpbmcgbm9ybWF0aXZlIHNlZW1zIG1vcmUgc3VpdGFibGUuDQoNCiBP TEQ6IC0gc3ViLVRMViB0aGF0IGRvZXNuJ3QgaGF2ZSBjb3JyZXNwb25kaW5nIGZsYWcgc2V0IE1V U1QgYmUNCiAgICAgIHNpbGVudGx5IGlnbm9yZWQ7DQoNCiBORVc6IC0gU3ViLVRMVi4uLi4gKENh cGl0YWxpemUpIA0KR0lNPj4gRG9uZSBhbmQgcy87Ly4vIFRoZW4gY2FwaXRhbGl6ZWQgbmV4dCBs aW5lLCBzL2lmL0lmLyBhcyBzdWdnZXN0ZWQgYmVsb3cuDQoNCiBPTEQ6IC0gaWYgbXVsdGlwbGUg Y29waWVzIG9mIGEgc3ViLVRMViBhcmUgcHJlc2VudCwgdGhlbiBvbmx5IHRoZSBmaXJzdA0KICAg ICAgc3ViLVRMViBNVVNUIGJlIHVzZWQgYW5kIHRoZSByZW1haW5pbmcgc3ViLVRMVnMgTVVTVCBi ZSBzaWxlbnRseQ0KICAgICAgaWdub3JlZC4NCg0KIE5FVzogLSBJZiBtdWx0aXBsZS4uLi4gKENh cGl0YWxpemUpIA0KDQo5KSBTZWN0aW9uIDMuMi4xLCBpdCB3b3VsZCBiZSBlYXNpZXIgdG8gdHJh Y2UgaWYgeW91IHdvdWxkIHJlZmVyZW5jZSBmb3IgdGhlIGZpcnN0IHNlbnRlbmNlLCBzaW1pbGFy IHRvIGNvbW1lbnQgNCkuIA0KR0lNPj4gVXBkYXRlZCB0bzoNCiJJZiB0aGUgQ1YgZmxhZyBpcyBz ZXQgaW4gdGhlIE9BTSBGdW5jdGlvbiBGbGFncyBTdWItVExWIFtSRkM3MjYwXSwgdGhlbiAuLi4i DQoNClRoYW5rcywNCllvdW5nDQo= From nobody Tue Jan 20 08:30: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 6D58D1B29DD; Tue, 20 Jan 2015 08:30:47 -0800 (PST) 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 N9mfgYdNUDVB; Tue, 20 Jan 2015 08:30:44 -0800 (PST) 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 20EC31B29AD; Tue, 20 Jan 2015 08:30:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG01011; Tue, 20 Jan 2015 16:30:41 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 16:30:41 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Tue, 20 Jan 2015 08:30:38 -0800 From: Leeyoung To: Gregory Mirsky , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt Thread-Index: AQHQNCMXvrj5anlv+Uah41+rgGF9xZzIycWAgABqkIA= Date: Tue, 20 Jan 2015 16:30:38 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7B2AA@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C79E28@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C79E93@dfweml706-chm> <7347100B5761DC41A166AC17F22DF1121B8E135C@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8E135C@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'rtg-dir@ietf.org'" , "'ccamp@ietf.org'" , "draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext.all@tools.ietf.org" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.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: Tue, 20 Jan 2015 16:30:47 -0000 SGkgR3JlZywNCg0KVGhhbmtzLiBJIHRoaW5rIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHJl dmlzaW9uLiBObyBmdXJ0aGVyIGlzc3VlIGlzIHBlbmRpbmcgdG8gbWUuIA0KDQpSZWdhcmRzLA0K WW91bmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEdyZWdvcnkgTWlyc2t5 IFttYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tXSANClNlbnQ6IE1vbmRheSwgSmFu dWFyeSAxOSwgMjAxNSA4OjA4IFBNDQpUbzogTGVleW91bmc7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5v cmcNCkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZyc7IGRyYWZ0LWlldGYt Y2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQuYWxsQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0 OiBSRTogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1t cGxzLXRwLW9hbS1leHQtMTUudHh0DQoNCkhpIFlvdW5nLA0KdGhhbmsgeW91IGZvciB5b3VyIHRo cm91Z2ggcmV2aWV3IGFuZCBjb25zaWRlcmF0ZSBjb21tZW50cy4NClBsZWFzZSBmaW5kIG15IGFu c3dlcnMgaW4tbGluZSBhbmQgdGFnZ2VkIEdJTT4+Lg0KUGxlYXNlIGxldCBtZSBrbm93IHdoZXRo ZXIgd2Ugc2hvdWxkIHB1Ymxpc2ggdGhlIG5ldyB2ZXJzaW9uIG9yIGFkZHJlc3MgdGhlc2UgY29t bWVudHMgYXMgcGFydCBvZiBSRkMgRWRpdG9yIHVwZGF0ZS4NCg0KCVJlZ2FyZHMsDQoJCUdyZWcN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExlZXlvdW5nIFttYWlsdG86bGVl eW91bmdAaHVhd2VpLmNvbV0gDQpTZW50OiBNb25kYXksIEphbnVhcnkgMTksIDIwMTUgMTI6MDQg UE0NClRvOiBMZWV5b3VuZzsgcnRnLWFkc0B0b29scy5pZXRmLm9yZw0KQ2M6ICdydGctZGlyQGll dGYub3JnJzsgJ2NjYW1wQGlldGYub3JnJzsgZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMt dHAtb2FtLWV4dC5hbGxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbUlRHLURJUl0gUnRn RGlyIHJldmlldzogZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtb2FtLWV4dC0xNS50 eHQNCg0KSGksDQoNClNvcnJ5LCBvbmUgb2YgdGhlIG5pdHMgaGFkIGEgbml0OiBJIHNob3VsZCBi ZToNCg0KT0xEOiBUaGUgdXNlIG9mIEdNUExTIFJTVlAtVEUgZm9yIHRoZSBjb25maWd1cmF0aW9u IG9mIE9BTQ0KICAgZnVuY3Rpb25zIGlzIGRlZmluZWQgaW4gYSB0ZWNobm9sb2d5IGFnbm9zdGlj IHdheSBpbiBbUkZDNzI2MF0uDQpORVc6IFtSRkM3MjYwXSBkZWZpbmVzIHVzZSBvZiBHTVBMUyBS U1ZQLVRFIGZvciB0aGUgY29uZmlndXJhdGlvbiBvZiBPQU0NCiAgIGZ1bmN0aW9ucyBpbiBhIHRl Y2hub2xvZ3kgYWdub3N0aWMgd2F5Lg0KR0lNPj4gQWNjZXB0ZWQsIGRvbmUuDQoNClRoYW5rcywN CllvdW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBydGctZGlyIFttYWls dG86cnRnLWRpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVleW91bmcNClNlbnQ6 IE1vbmRheSwgSmFudWFyeSAxOSwgMjAxNSAxMjozNiBQTQ0KVG86IHJ0Zy1hZHNAdG9vbHMuaWV0 Zi5vcmcNCkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZyc7IGRyYWZ0LWll dGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQuYWxsQHRvb2xzLmlldGYub3JnDQpTdWJq ZWN0OiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLW1w bHMtdHAtb2FtLWV4dC0xNS50eHQNCg0KSGVsbG8sIA0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBh cyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJv dXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmct cmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElF U0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ug b2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURz LiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxl YXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kv UnRnRGlyIA0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUg dXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQg Y29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50 cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRp c2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0LiANCg0KRG9jdW1lbnQ6IGRyYWZ0LWll dGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMTUudHh0DQpSZXZpZXdlcjogWW91bmcg TGVlDQpSZXZpZXcgRGF0ZTogMTkgSmFudWFyeSwgMjAxNQ0KSUVURiBMQyBFbmQgRGF0ZTogbm90 IHN1cmUNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNClN1bW1hcnk6DQoNClRo aXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBz aG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6DQoN ClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBjb25maWd1cmF0aW9uIG9mIHByb2FjdGl2ZSBN UExTLVRQIE9BTSBmdW5jdGlvbnMgY2FycmllZCBieSB0aGUgR01QTFMgUlNWUC1URSBwcm90b2Nv bHMgYmFzZWQgb24gdGhlIE9BTSBDb25maWd1cmF0aW9uIEZyYW1ld29yayBmb3IgR01QTFMgUlNW UC1URS4gVGhlIGRvY3VtZW50IGlzIGluIGdvb2Qgc2hhcGUgYnV0IHRoZXJlIGFyZSBhIGZldyBw b2ludHMgdGhhdCBzaG91bGQgYmUgY2xhcmlmaWVkIHRvIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5 LiANCg0KTWFqb3IgSXNzdWVzOg0KDQpOb25lDQpHSU0+PiBUaGFuayB5b3UNCg0KTWlub3IgSXNz dWVzOg0KDQpOb25lDQpHSU0+PiBUaGFuayB5b3UNCg0KTml0czoNCg0KMSkgSW4gQWJzdHJhY3Qg YW5kIG90aGVyIHBhcnRzLCBzaG91bGQgJ3Byby1hY3RpdmUnIGJlIHJlcGxhY2VkIHdpdGggJ3By b2FjdGl2ZSc/IFBlcmhhcHMsIHRoZXJlIG1heSBiZSBhIHJlYXNvbiBmb3IgdGhlIGh5cGhlbiwg YnV0IEkgd2FzIG5vdCBzdXJlLiANCkdJTT4+IEkgZmluZCB0aGF0ICdwcm9hY3RpdmUnIGlzIG1v cmUgY29tbW9uIGZvcm0uIEFjY2VwdGVkIGFuZCB1cGRhdGVkLg0KIA0KMikgSW4gSW50cm9kdWN0 aW9uLCBJIHdvdWxkIHN1Z2dlc3Q6DQoNCk9MRDogVGhlIHVzZSBvZiBHTVBMUyBSU1ZQLVRFIGZv ciB0aGUgY29uZmlndXJhdGlvbiBvZiBPQU0NCiAgIGZ1bmN0aW9ucyBpcyBkZWZpbmVkIGluIGEg dGVjaG5vbG9neSBhZ25vc3RpYyB3YXkgaW4gW1JGQzcyNjBdLg0KTkVXOiBbUkZDNzI2MF0gZGVm aW5lcyBUaGUgdXNlIG9mIEdNUExTIFJTVlAtVEUgZm9yIHRoZSBjb25maWd1cmF0aW9uIG9mIE9B TQ0KICAgZnVuY3Rpb25zIGlzIGRlZmluZWQgaW4gYSB0ZWNobm9sb2d5IGFnbm9zdGljIHdheS4N CkdJTT4+IEkgdGhpbmsgdGhhdCB0aGUgdmVyeSBmaXJzdCBub3RlIGFkZHJlc3NlcyB0aGlzIGNo YW5nZSBhbHJlYWR5Lg0KDQozKSBJbiBJbnRyb2R1Y3Rpb24gKHRoZSBzZWNvbmQgcGFyYWdyYXBo KSwgSSBhbSBub3Qgc3VyZSBpZiB5b3UgbmVlZCwgJ3RoZSBUcmFuc3BvcnQgUHJvZmlsZSBvZiBN UExTJyBhZnRlciBNUExTLVRQLiANCkdJTT4+IEkgdGhpbmsgaXQgaXMgYWNjZXB0YWJsZSwgc29t ZXdoYXQgY29udmVyc2F0aW9uYWwgZm9ybS4NCg0KNCkgSW4gSW50cm9kdWN0aW9uICh0aGUgZm91 cnRoIHBhcmFncmFwaCksIGlzIHRoZXJlIGFueSByZWZlcmVuY2UgZm9yIHRoZSBsYXN0IHNlbnRl bmNlLCAiQWRkaXRpb25hbGx5LCB0aGVyZSBpcyBhIG51bWJlciBvZiBGYXVsdCBNYW5hZ2VtZW50 IFNpZ25hbHMgdGhhdCBjYW4gYmUgY29uZmlndXJlZC4iPyBBbHNvIHN1Z2dlc3Q6DQpHSU0+PiBB ZGRlZCByZWZlcmVuY2UgdG8gUkZDICA2NDI3Lg0KDQpPTEQ6IEFkZGl0aW9uYWxseQ0KTmV3OiBB ZGRpdGlvbmFsbHksIA0KR0lNPj4gRG9uZQ0KDQo1KSBJbiBTZWN0aW9uIDMuMSAodGhlIHNlY29u ZCBwYXJhZ3JhcGgpOiBUaGlzIHN1Yi1UTFYgYXMgaGFzIHRvIGJlIGV4YW1pbmVkLi4uIEkgd291 bGQgc3VnZ2VzdCByZXBsYWNpbmcgJ2hhcyB0byBiZScgdG8gZWl0aGVyIE1VU1Qgb3IgU0hPVUxE LiANCkdJTT4+IFVwZGF0ZWQgIiBUaGlzIHN1Yi1UTFYgTVVTVCBiZSBleGFtaW5lZCBldmVuIGJ5 IGludGVybWVkaWF0ZSBub2RlcyB0aGF0IHN1cHBvcnQgdGhlc2UgZXh0ZW5zaW9ucyAuLi4iDQoN CjYpIEluIFNlY3Rpb24gMy4yOiAtICJCRkQgQ29uZmlndXJhdGlvbiBzdWItVExWIiwgd2hpY2gg TVVTVCBiZSBpbmNsdWRlZCBpZiB0aGUgQ0MNCiAgICAgIGFuZC9vciB0aGUgQ1YgT0FNIEZ1bmN0 aW9uIGZsYWcgaXMgc2V0LiBJdCB3YXMgbm90IGNsZWFyIHRvIG1lIHdoZXJlIHRoZSBDQyBhbmQv b3IgQ1YgT0FNIEZ1bmN0aW9uIEZsYWcgaXMgc2V0LiBSZWZlcmVuY2Ugd291bGQgYmUgZ29vZC4g SSBwcmVzdW1lIGl0IGlzIHRoZSBPQU0gQ29uZmlndXJhdGlvbiBUTFYgaW4gW1JGQzcyNjBdLiAN CkdJTT4+IFVwZGF0ZWQgIiAiQkZEIENvbmZpZ3VyYXRpb24gc3ViLVRMViIsIHdoaWNoIE1VU1Qg YmUgaW5jbHVkZWQgaWYgZWl0aGVyIHRoZSBDQywgdGhlIENWIG9yIGJvdGggT0FNIEZ1bmN0aW9u IGZsYWdzIGJlaW5nIHNldCBpbiB0aGUgT0FNIEZ1bmN0aW9uIEZsYWdzIFN1Yi1UTFYgW1JGQzcy NjBdLiINCg0KNykgSSBoYXZlIHNpbWlsYXIgY29tbWVudHMgYXMgNikgdGhyb3VnaG91dCB0aGlz IHNlY3Rpb24gd2hlbiB5b3UgcmVmZXIgdG8gJ04nIGZsYWcsICdJJyBmbGFnLCBldGMuIA0KR0lN Pj4gSXMgdGhpcyB0aGUgZm9sbG93aW5nOg0KIiAiUGVyZm9ybWFuY2UgTW9uaXRvcmluZyBzdWIt VExWIiwgd2hpY2ggTVVTVCBiZSBpbmNsdWRlZCBpZiBhbnkgb2YgdGhlIFBNL0RlbGF5LCBQTS9M b3NzIG9yIFBNL1Rocm91Z2hwdXQgZmxhZ3MgYXJlIHNldCBpbiB0aGUgIk9BTSBGdW5jdGlvbiBG bGFnIHN1Yi1UTFYgW1JGQzcyNjBdLiIgKHJlZmVyZW5jZSBhZGRlZCkNCg0KOCkgSW4gU2VjdGlv biAzLjI6DQoNCiBPTEQ6IC0gTVBMUyBPQU0gQ29uZmlndXJhdGlvbiBzdWItVExWIE1BWSBiZSBl bXB0eSwgaS5lLiBoYXZlIG5vIFZhbHVlLg0KICAgICAgVGhlbiBpdHMgTGVuZ3RoIE1VU1QgYmUg OC4gIFRoZW4gYWxsIE9BTSBmdW5jdGlvbnMgdGhhdCBoYXZlIHRoZWlyDQogICAgICBjb3JyZXNw b25kaW5nIGZsYWdzIHNldCBpbiB0aGUgIk9BTSBGdW5jdGlvbiBGbGFncyBzdWItVExWIiBNVVNU DQogICAgICBiZSBhc3NpZ25lZCB0aGVpciBkZWZhdWx0IHZhbHVlcyBvciBsZWZ0IGRpc2FibGVk Lg0KDQogTkVXOiAtIElmIE1QTFMgT0FNIENvbmZpZ3VyYXRpb24gc3ViLVRMViBNQVkgYmUgZW1w dHksIGkuZS4gaGF2ZSBubyBWYWx1ZSwNCiAgICAgIHRoZW4gaXRzIExlbmd0aCBNVVNUIGJlIDgg YW5kIGFsbCBPQU0gZnVuY3Rpb25zIHRoYXQgaGF2ZSB0aGVpcg0KICAgICAgY29ycmVzcG9uZGlu ZyBmbGFncyBzZXQgaW4gdGhlICJPQU0gRnVuY3Rpb24gRmxhZ3Mgc3ViLVRMViIgTVVTVA0KICAg ICAgYmUgYXNzaWduZWQgdGhlaXIgZGVmYXVsdCB2YWx1ZXMgb3IgbGVmdCBkaXNhYmxlZC4NCkdJ TT4+IEkgdGhpbmsgIklmIiBhbmQgIk1BWSIgZG9uJ3QgbWF0Y2ggaW4gdGhlIHNhbWUgc2VudGVu Y2UuIEkgdGhpbmsgaXQgaXMgb25lIG9yIGFub3RoZXIuICdNQVknIGJlaW5nIG5vcm1hdGl2ZSBz ZWVtcyBtb3JlIHN1aXRhYmxlLg0KDQogT0xEOiAtIHN1Yi1UTFYgdGhhdCBkb2Vzbid0IGhhdmUg Y29ycmVzcG9uZGluZyBmbGFnIHNldCBNVVNUIGJlDQogICAgICBzaWxlbnRseSBpZ25vcmVkOw0K DQogTkVXOiAtIFN1Yi1UTFYuLi4uIChDYXBpdGFsaXplKSANCkdJTT4+IERvbmUgYW5kIHMvOy8u LyBUaGVuIGNhcGl0YWxpemVkIG5leHQgbGluZSwgcy9pZi9JZi8gYXMgc3VnZ2VzdGVkIGJlbG93 Lg0KDQogT0xEOiAtIGlmIG11bHRpcGxlIGNvcGllcyBvZiBhIHN1Yi1UTFYgYXJlIHByZXNlbnQs IHRoZW4gb25seSB0aGUgZmlyc3QNCiAgICAgIHN1Yi1UTFYgTVVTVCBiZSB1c2VkIGFuZCB0aGUg cmVtYWluaW5nIHN1Yi1UTFZzIE1VU1QgYmUgc2lsZW50bHkNCiAgICAgIGlnbm9yZWQuDQoNCiBO RVc6IC0gSWYgbXVsdGlwbGUuLi4uIChDYXBpdGFsaXplKSANCg0KOSkgU2VjdGlvbiAzLjIuMSwg aXQgd291bGQgYmUgZWFzaWVyIHRvIHRyYWNlIGlmIHlvdSB3b3VsZCByZWZlcmVuY2UgZm9yIHRo ZSBmaXJzdCBzZW50ZW5jZSwgc2ltaWxhciB0byBjb21tZW50IDQpLiANCkdJTT4+IFVwZGF0ZWQg dG86DQoiSWYgdGhlIENWIGZsYWcgaXMgc2V0IGluIHRoZSBPQU0gRnVuY3Rpb24gRmxhZ3MgU3Vi LVRMViBbUkZDNzI2MF0sIHRoZW4gLi4uIg0KDQpUaGFua3MsDQpZb3VuZw0K From nobody Tue Jan 20 09:06: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 5210C1B2AE1; Tue, 20 Jan 2015 09:06:07 -0800 (PST) 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 oqMaerLSgu-8; Tue, 20 Jan 2015 09:06:05 -0800 (PST) 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 23B131B2ADC; Tue, 20 Jan 2015 09:06:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG03607; Tue, 20 Jan 2015 17:06:02 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 20 Jan 2015 17:06:01 +0000 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; Tue, 20 Jan 2015 09:05:50 -0800 From: Leeyoung To: Leeyoung , Gregory Mirsky , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.txt Thread-Index: AQHQNCMXvrj5anlv+Uah41+rgGF9xZzIycWAgABqkICAAAnFgA== Date: Tue, 20 Jan 2015 17:05:50 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7B422@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C79E28@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C79E93@dfweml706-chm> <7347100B5761DC41A166AC17F22DF1121B8E135C@eusaamb103.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C7B2AA@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7B2AA@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'rtg-dir@ietf.org'" , "'ccamp@ietf.org'" , "draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext.all@tools.ietf.org" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-15.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: Tue, 20 Jan 2015 17:06:07 -0000 SGkgR3JlZywNCg0KV2hhdCBJIG1lYW50IHdhcyBhbGwgbXkgY29tbWVudHMgY2FuIGJlIGFkZHJl c3NlZCBhcyBwYXJ0IG9mIFJGQyBFZGl0b3IgdXBkYXRlLg0KDQpUaGFua3MsDQpZb3VuZw0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRnLWRpciBbbWFpbHRvOnJ0Zy1kaXIt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlZXlvdW5nDQpTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDIwLCAyMDE1IDEwOjMxIEFNDQpUbzogR3JlZ29yeSBNaXJza3k7IHJ0Zy1hZHNAdG9v bHMuaWV0Zi5vcmcNCkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZyc7IGRy YWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQuYWxsQHRvb2xzLmlldGYub3Jn DQpTdWJqZWN0OiBSZTogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtY2NhbXAt cnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMTUudHh0DQoNCkhpIEdyZWcsDQoNClRoYW5rcy4gSSB0 aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciByZXZpc2lvbi4gTm8gZnVydGhlciBpc3N1 ZSBpcyBwZW5kaW5nIHRvIG1lLiANCg0KUmVnYXJkcywNCllvdW5nDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBHcmVnb3J5IE1pcnNreSBbbWFpbHRvOmdyZWdvcnkubWlyc2t5 QGVyaWNzc29uLmNvbV0gDQpTZW50OiBNb25kYXksIEphbnVhcnkgMTksIDIwMTUgODowOCBQTQ0K VG86IExlZXlvdW5nOyBydGctYWRzQHRvb2xzLmlldGYub3JnDQpDYzogJ3J0Zy1kaXJAaWV0Zi5v cmcnOyAnY2NhbXBAaWV0Zi5vcmcnOyBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1v YW0tZXh0LmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFtSVEctRElSXSBSdGdEaXIg cmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0LTE1LnR4dA0K DQpIaSBZb3VuZywNCnRoYW5rIHlvdSBmb3IgeW91ciB0aHJvdWdoIHJldmlldyBhbmQgY29uc2lk ZXJhdGUgY29tbWVudHMuDQpQbGVhc2UgZmluZCBteSBhbnN3ZXJzIGluLWxpbmUgYW5kIHRhZ2dl ZCBHSU0+Pi4NClBsZWFzZSBsZXQgbWUga25vdyB3aGV0aGVyIHdlIHNob3VsZCBwdWJsaXNoIHRo ZSBuZXcgdmVyc2lvbiBvciBhZGRyZXNzIHRoZXNlIGNvbW1lbnRzIGFzIHBhcnQgb2YgUkZDIEVk aXRvciB1cGRhdGUuDQoNCglSZWdhcmRzLA0KCQlHcmVnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBMZWV5b3VuZyBbbWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb21dIA0KU2Vu dDogTW9uZGF5LCBKYW51YXJ5IDE5LCAyMDE1IDEyOjA0IFBNDQpUbzogTGVleW91bmc7IHJ0Zy1h ZHNAdG9vbHMuaWV0Zi5vcmcNCkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9y Zyc7IGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQuYWxsQHRvb2xzLmll dGYub3JnDQpTdWJqZWN0OiBSRTogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYt Y2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMTUudHh0DQoNCkhpLA0KDQpTb3JyeSwgb25l IG9mIHRoZSBuaXRzIGhhZCBhIG5pdDogSSBzaG91bGQgYmU6DQoNCk9MRDogVGhlIHVzZSBvZiBH TVBMUyBSU1ZQLVRFIGZvciB0aGUgY29uZmlndXJhdGlvbiBvZiBPQU0NCiAgIGZ1bmN0aW9ucyBp cyBkZWZpbmVkIGluIGEgdGVjaG5vbG9neSBhZ25vc3RpYyB3YXkgaW4gW1JGQzcyNjBdLg0KTkVX OiBbUkZDNzI2MF0gZGVmaW5lcyB1c2Ugb2YgR01QTFMgUlNWUC1URSBmb3IgdGhlIGNvbmZpZ3Vy YXRpb24gb2YgT0FNDQogICBmdW5jdGlvbnMgaW4gYSB0ZWNobm9sb2d5IGFnbm9zdGljIHdheS4N CkdJTT4+IEFjY2VwdGVkLCBkb25lLg0KDQpUaGFua3MsDQpZb3VuZw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRnLWRpciBbbWFpbHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIExlZXlvdW5nDQpTZW50OiBNb25kYXksIEphbnVhcnkgMTksIDIw MTUgMTI6MzYgUE0NClRvOiBydGctYWRzQHRvb2xzLmlldGYub3JnDQpDYzogJ3J0Zy1kaXJAaWV0 Zi5vcmcnOyAnY2NhbXBAaWV0Zi5vcmcnOyBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10 cC1vYW0tZXh0LmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogW1JURy1ESVJdIFJ0Z0RpciBy ZXZpZXc6IGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMTUudHh0DQoN CkhlbGxvLCANCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1l cyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJv dmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciANCg0KQWx0aG91Z2ggdGhl c2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMs IGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0 aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5k IHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5n IHRoZSBkcmFmdC4gDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10 cC1vYW0tZXh0LTE1LnR4dA0KUmV2aWV3ZXI6IFlvdW5nIExlZQ0KUmV2aWV3IERhdGU6IDE5IEph bnVhcnksIDIwMTUNCklFVEYgTEMgRW5kIERhdGU6IG5vdCBzdXJlDQpJbnRlbmRlZCBTdGF0dXM6 IFN0YW5kYXJkcyBUcmFjaw0KDQpTdW1tYXJ5Og0KDQpUaGlzIGRvY3VtZW50IGlzIHJlYWR5IGZv ciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJp b3IgdG8gcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmll cyB0aGUgY29uZmlndXJhdGlvbiBvZiBwcm9hY3RpdmUgTVBMUy1UUCBPQU0gZnVuY3Rpb25zIGNh cnJpZWQgYnkgdGhlIEdNUExTIFJTVlAtVEUgcHJvdG9jb2xzIGJhc2VkIG9uIHRoZSBPQU0gQ29u ZmlndXJhdGlvbiBGcmFtZXdvcmsgZm9yIEdNUExTIFJTVlAtVEUuIFRoZSBkb2N1bWVudCBpcyBp biBnb29kIHNoYXBlIGJ1dCB0aGVyZSBhcmUgYSBmZXcgcG9pbnRzIHRoYXQgc2hvdWxkIGJlIGNs YXJpZmllZCB0byBpbXByb3ZlIHRoZSByZWFkYWJpbGl0eS4gDQoNCk1ham9yIElzc3VlczoNCg0K Tm9uZQ0KR0lNPj4gVGhhbmsgeW91DQoNCk1pbm9yIElzc3VlczoNCg0KTm9uZQ0KR0lNPj4gVGhh bmsgeW91DQoNCk5pdHM6DQoNCjEpIEluIEFic3RyYWN0IGFuZCBvdGhlciBwYXJ0cywgc2hvdWxk ICdwcm8tYWN0aXZlJyBiZSByZXBsYWNlZCB3aXRoICdwcm9hY3RpdmUnPyBQZXJoYXBzLCB0aGVy ZSBtYXkgYmUgYSByZWFzb24gZm9yIHRoZSBoeXBoZW4sIGJ1dCBJIHdhcyBub3Qgc3VyZS4gDQpH SU0+PiBJIGZpbmQgdGhhdCAncHJvYWN0aXZlJyBpcyBtb3JlIGNvbW1vbiBmb3JtLiBBY2NlcHRl ZCBhbmQgdXBkYXRlZC4NCiANCjIpIEluIEludHJvZHVjdGlvbiwgSSB3b3VsZCBzdWdnZXN0Og0K DQpPTEQ6IFRoZSB1c2Ugb2YgR01QTFMgUlNWUC1URSBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gb2Yg T0FNDQogICBmdW5jdGlvbnMgaXMgZGVmaW5lZCBpbiBhIHRlY2hub2xvZ3kgYWdub3N0aWMgd2F5 IGluIFtSRkM3MjYwXS4NCk5FVzogW1JGQzcyNjBdIGRlZmluZXMgVGhlIHVzZSBvZiBHTVBMUyBS U1ZQLVRFIGZvciB0aGUgY29uZmlndXJhdGlvbiBvZiBPQU0NCiAgIGZ1bmN0aW9ucyBpcyBkZWZp bmVkIGluIGEgdGVjaG5vbG9neSBhZ25vc3RpYyB3YXkuDQpHSU0+PiBJIHRoaW5rIHRoYXQgdGhl IHZlcnkgZmlyc3Qgbm90ZSBhZGRyZXNzZXMgdGhpcyBjaGFuZ2UgYWxyZWFkeS4NCg0KMykgSW4g SW50cm9kdWN0aW9uICh0aGUgc2Vjb25kIHBhcmFncmFwaCksIEkgYW0gbm90IHN1cmUgaWYgeW91 IG5lZWQsICd0aGUgVHJhbnNwb3J0IFByb2ZpbGUgb2YgTVBMUycgYWZ0ZXIgTVBMUy1UUC4gDQpH SU0+PiBJIHRoaW5rIGl0IGlzIGFjY2VwdGFibGUsIHNvbWV3aGF0IGNvbnZlcnNhdGlvbmFsIGZv cm0uDQoNCjQpIEluIEludHJvZHVjdGlvbiAodGhlIGZvdXJ0aCBwYXJhZ3JhcGgpLCBpcyB0aGVy ZSBhbnkgcmVmZXJlbmNlIGZvciB0aGUgbGFzdCBzZW50ZW5jZSwgIkFkZGl0aW9uYWxseSwgdGhl cmUgaXMgYSBudW1iZXIgb2YgRmF1bHQgTWFuYWdlbWVudCBTaWduYWxzIHRoYXQgY2FuIGJlIGNv bmZpZ3VyZWQuIj8gQWxzbyBzdWdnZXN0Og0KR0lNPj4gQWRkZWQgcmVmZXJlbmNlIHRvIFJGQyAg NjQyNy4NCg0KT0xEOiBBZGRpdGlvbmFsbHkNCk5ldzogQWRkaXRpb25hbGx5LCANCkdJTT4+IERv bmUNCg0KNSkgSW4gU2VjdGlvbiAzLjEgKHRoZSBzZWNvbmQgcGFyYWdyYXBoKTogVGhpcyBzdWIt VExWIGFzIGhhcyB0byBiZSBleGFtaW5lZC4uLiBJIHdvdWxkIHN1Z2dlc3QgcmVwbGFjaW5nICdo YXMgdG8gYmUnIHRvIGVpdGhlciBNVVNUIG9yIFNIT1VMRC4gDQpHSU0+PiBVcGRhdGVkICIgVGhp cyBzdWItVExWIE1VU1QgYmUgZXhhbWluZWQgZXZlbiBieSBpbnRlcm1lZGlhdGUgbm9kZXMgdGhh dCBzdXBwb3J0IHRoZXNlIGV4dGVuc2lvbnMgLi4uIg0KDQo2KSBJbiBTZWN0aW9uIDMuMjogLSAi QkZEIENvbmZpZ3VyYXRpb24gc3ViLVRMViIsIHdoaWNoIE1VU1QgYmUgaW5jbHVkZWQgaWYgdGhl IENDDQogICAgICBhbmQvb3IgdGhlIENWIE9BTSBGdW5jdGlvbiBmbGFnIGlzIHNldC4gSXQgd2Fz IG5vdCBjbGVhciB0byBtZSB3aGVyZSB0aGUgQ0MgYW5kL29yIENWIE9BTSBGdW5jdGlvbiBGbGFn IGlzIHNldC4gUmVmZXJlbmNlIHdvdWxkIGJlIGdvb2QuIEkgcHJlc3VtZSBpdCBpcyB0aGUgT0FN IENvbmZpZ3VyYXRpb24gVExWIGluIFtSRkM3MjYwXS4gDQpHSU0+PiBVcGRhdGVkICIgIkJGRCBD b25maWd1cmF0aW9uIHN1Yi1UTFYiLCB3aGljaCBNVVNUIGJlIGluY2x1ZGVkIGlmIGVpdGhlciB0 aGUgQ0MsIHRoZSBDViBvciBib3RoIE9BTSBGdW5jdGlvbiBmbGFncyBiZWluZyBzZXQgaW4gdGhl IE9BTSBGdW5jdGlvbiBGbGFncyBTdWItVExWIFtSRkM3MjYwXS4iDQoNCjcpIEkgaGF2ZSBzaW1p bGFyIGNvbW1lbnRzIGFzIDYpIHRocm91Z2hvdXQgdGhpcyBzZWN0aW9uIHdoZW4geW91IHJlZmVy IHRvICdOJyBmbGFnLCAnSScgZmxhZywgZXRjLiANCkdJTT4+IElzIHRoaXMgdGhlIGZvbGxvd2lu ZzoNCiIgIlBlcmZvcm1hbmNlIE1vbml0b3Jpbmcgc3ViLVRMViIsIHdoaWNoIE1VU1QgYmUgaW5j bHVkZWQgaWYgYW55IG9mIHRoZSBQTS9EZWxheSwgUE0vTG9zcyBvciBQTS9UaHJvdWdocHV0IGZs YWdzIGFyZSBzZXQgaW4gdGhlICJPQU0gRnVuY3Rpb24gRmxhZyBzdWItVExWIFtSRkM3MjYwXS4i IChyZWZlcmVuY2UgYWRkZWQpDQoNCjgpIEluIFNlY3Rpb24gMy4yOg0KDQogT0xEOiAtIE1QTFMg T0FNIENvbmZpZ3VyYXRpb24gc3ViLVRMViBNQVkgYmUgZW1wdHksIGkuZS4gaGF2ZSBubyBWYWx1 ZS4NCiAgICAgIFRoZW4gaXRzIExlbmd0aCBNVVNUIGJlIDguICBUaGVuIGFsbCBPQU0gZnVuY3Rp b25zIHRoYXQgaGF2ZSB0aGVpcg0KICAgICAgY29ycmVzcG9uZGluZyBmbGFncyBzZXQgaW4gdGhl ICJPQU0gRnVuY3Rpb24gRmxhZ3Mgc3ViLVRMViIgTVVTVA0KICAgICAgYmUgYXNzaWduZWQgdGhl aXIgZGVmYXVsdCB2YWx1ZXMgb3IgbGVmdCBkaXNhYmxlZC4NCg0KIE5FVzogLSBJZiBNUExTIE9B TSBDb25maWd1cmF0aW9uIHN1Yi1UTFYgTUFZIGJlIGVtcHR5LCBpLmUuIGhhdmUgbm8gVmFsdWUs DQogICAgICB0aGVuIGl0cyBMZW5ndGggTVVTVCBiZSA4IGFuZCBhbGwgT0FNIGZ1bmN0aW9ucyB0 aGF0IGhhdmUgdGhlaXINCiAgICAgIGNvcnJlc3BvbmRpbmcgZmxhZ3Mgc2V0IGluIHRoZSAiT0FN IEZ1bmN0aW9uIEZsYWdzIHN1Yi1UTFYiIE1VU1QNCiAgICAgIGJlIGFzc2lnbmVkIHRoZWlyIGRl ZmF1bHQgdmFsdWVzIG9yIGxlZnQgZGlzYWJsZWQuDQpHSU0+PiBJIHRoaW5rICJJZiIgYW5kICJN QVkiIGRvbid0IG1hdGNoIGluIHRoZSBzYW1lIHNlbnRlbmNlLiBJIHRoaW5rIGl0IGlzIG9uZSBv ciBhbm90aGVyLiAnTUFZJyBiZWluZyBub3JtYXRpdmUgc2VlbXMgbW9yZSBzdWl0YWJsZS4NCg0K IE9MRDogLSBzdWItVExWIHRoYXQgZG9lc24ndCBoYXZlIGNvcnJlc3BvbmRpbmcgZmxhZyBzZXQg TVVTVCBiZQ0KICAgICAgc2lsZW50bHkgaWdub3JlZDsNCg0KIE5FVzogLSBTdWItVExWLi4uLiAo Q2FwaXRhbGl6ZSkgDQpHSU0+PiBEb25lIGFuZCBzLzsvLi8gVGhlbiBjYXBpdGFsaXplZCBuZXh0 IGxpbmUsIHMvaWYvSWYvIGFzIHN1Z2dlc3RlZCBiZWxvdy4NCg0KIE9MRDogLSBpZiBtdWx0aXBs ZSBjb3BpZXMgb2YgYSBzdWItVExWIGFyZSBwcmVzZW50LCB0aGVuIG9ubHkgdGhlIGZpcnN0DQog ICAgICBzdWItVExWIE1VU1QgYmUgdXNlZCBhbmQgdGhlIHJlbWFpbmluZyBzdWItVExWcyBNVVNU IGJlIHNpbGVudGx5DQogICAgICBpZ25vcmVkLg0KDQogTkVXOiAtIElmIG11bHRpcGxlLi4uLiAo Q2FwaXRhbGl6ZSkgDQoNCjkpIFNlY3Rpb24gMy4yLjEsIGl0IHdvdWxkIGJlIGVhc2llciB0byB0 cmFjZSBpZiB5b3Ugd291bGQgcmVmZXJlbmNlIGZvciB0aGUgZmlyc3Qgc2VudGVuY2UsIHNpbWls YXIgdG8gY29tbWVudCA0KS4gDQpHSU0+PiBVcGRhdGVkIHRvOg0KIklmIHRoZSBDViBmbGFnIGlz IHNldCBpbiB0aGUgT0FNIEZ1bmN0aW9uIEZsYWdzIFN1Yi1UTFYgW1JGQzcyNjBdLCB0aGVuIC4u LiINCg0KVGhhbmtzLA0KWW91bmcNCg== From nobody Tue Jan 20 14:54: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 42C2C1A0067; Tue, 20 Jan 2015 14:54:56 -0800 (PST) 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 qmPrdYiTPCJq; Tue, 20 Jan 2015 14:54:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 121261A0065; Tue, 20 Jan 2015 14:54:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150120225454.32469.84424.idtracker@ietfa.amsl.com> Date: Tue, 20 Jan 2015 14:54:54 -0800 Archived-At: Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-17.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, 20 Jan 2015 22:54:56 -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 : General Network Element Constraint Encoding for GMPLS Controlled Networks Authors : Greg M. Bernstein Young Lee Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-general-constraint-encode-17.txt Pages : 31 Date : 2015-01-20 Abstract: Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-general-constraint-encode-17 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 Jan 20 22:47: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 5FC701A0379; Tue, 20 Jan 2015 22:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lyk_OIGD3Cz8; Tue, 20 Jan 2015 22:47:51 -0800 (PST) Received: from mgw020.noc.ntt.com (mgw020.noc.ntt.com [210.160.55.2]) by ietfa.amsl.com (Postfix) with ESMTP id 85D631A0378; Tue, 20 Jan 2015 22:47:51 -0800 (PST) Received: from c0043i0.coe.ntt.com (c0043i0.nc.agilit-hosting.com [10.18.161.12]) by mgw020.noc.ntt.com (NTT Com MailSV) with ESMTP id 5880544600C4; Wed, 21 Jan 2015 15:47:50 +0900 (JST) Received: from C0039I0.coe.ntt.com (10.18.160.43) by c0043i0.coe.ntt.com (10.18.161.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 21 Jan 2015 15:47:48 +0900 Received: from C0010I0.coe.ntt.com ([169.254.2.243]) by C0039I0.coe.ntt.com ([10.18.160.43]) with mapi id 14.03.0181.006; Wed, 21 Jan 2015 15:47:49 +0900 From: Tomonori Takeda To: Leeyoung , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt Thread-Index: AQHQNDrfTzEBEMoZRkC5S21+tdrK7JzKHOCg Date: Wed, 21 Jan 2015 06:47:47 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: leeyoung@huawei.com, rtg-ads@tools.ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org, ccamp@ietf.org, tomonori.takeda@ntt.com x-originating-ip: [10.18.84.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" , Tomonori Takeda Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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: Wed, 21 Jan 2015 06:47:56 -0000 SGkgWW91bmcsDQoNClRoYW5rcy4NCg0KVHdvIGZvbGxvdy11cCBxdWVzdGlvbnMvY29tbWVudHMu DQooSSBhbSBmaW5lIHdpdGggb3RoZXIgcG9pbnRzLCB3aGljaCB5b3UgYWxyZWFkeSBhZGRyZXNz ZWQgaW4gdGhlIHVwZGF0ZWQgZHJhZnQuKQ0KDQo+IDIpIEluIHNlY3Rpb24gMi4xLCBpdCBzYXlz ICJ0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2ZSB0aGUgc2FtZSB7c3JjIHBvcnQsIHNyYyBsYWJl bCwgZHN0IHBvcnQsIGRzdCBsYWJlbH0iLiBUbyBiZSBwcmVjaXNlLCBJIGd1ZXNzIHRoaXMgc2hv dWxkIGJlID4gInR3byBtYXRyaWNlcyB3aWxsIG5vdCBoYXZlIHRoZSBzYW1lIHtzcmMgcG9ydCwg c3JjIGxhYmVsfSwgYW5kIHR3byBtYXRyaWNlcyB3aWxsIG5vdCBoYXZlIHRoZSBzYW1lIHtkc3Qg cG9ydCwgZHN0IGxhYmVsfSI/DQo+IA0KPiBZT1VORz4+IEkgdGhpbmsgeW91ciBzdWdnZXN0aW9u IG1heSBiZSB0b28gcmVzdHJpY3RpdmUuIEZvciBpbnN0YW5jZSwgaWYgd2UgaGF2ZSBvbmUgc291 cmNlIChwb3J0IDEpIGFuZCBvbmUgZGVzdGluYXRpb24gKHBvcnQgMikgd2l0aCB0d28gbGFiZWxz ID4gZWFjaC4gVGhlbiB3ZSB3b3VsZCBoYXZlOiB7KDEsMSwyLDEpLCAoMSwxLDIsMiksICgxLDIs MiwxKSwgKDEsMiwyLDIpfSBJIHRoaW5rIHdpdGggdGhlIGN1cnJlbnQgc3RhdGVtZW50LCB3ZSBj YW4gc2VuZCB0aGlzIGluZm8gaW4gYW55IGNvbWJpbmF0aW9uID4gb2YgbXVsdGlwbGUgbWF0cmlj ZXMsIHdoaWNoIEkgdGhpbmsgcGVyZmVjdGx5IGZpbmUuIFdpdGggeW91ciBzdWdnZXN0aW9uLCBJ IHdvdWxkIG5vdCBiZSBhYmxlIHNlbmQgKDEsMSwyLDEpIGFuZCAoMSwxLDIsMikgdG9nZXRoZXIu IFdoeSB3b3VsZCB0aGlzID4gbm90IGJlIG1hZGUgcG9zc2libGU/IE15IHRha2UgaXMgYXMgbG9u ZyBhcyBlYWNoIHN1Ym1hdHJpeCByZXByZXNlbnRzIGEgc2V0IG9mIGRpc2pvaW50IHF1YWRydXBs ZXMsIHRoYXQgc2hvdWxkIGJlIGFsbG93ZWQuDQoNCk15IHJlYWRpbmcgb2YgInR3byBtYXRyaWNl cyB3aWxsIG5vdCBoYXZlIHRoZSBzYW1lIHtzcmMgcG9ydCwgc3JjIGxhYmVsLCBkc3QgcG9ydCwg ZHN0IGxhYmVsfSIgaXMgYXMgZm9sbG93cy4NCg0KPEV4YW1wbGUgQT4NCg0KICBpbnB1dCBwb3J0 PTEgIC0tPiBTdWJtYXRyaXgjMSAtLT4gb3V0cHV0IHBvcnQ9Mg0KICBpbnB1dCBsYWJlbD0xICAg ICAgICAgICAgICAgICAgICAgb3V0cHV0IGxhYmVsPTENCg0KICBpbnB1dCBwb3J0PTEgIC0tPiBT dWJtYXRyaXgjMiAtLT4gb3V0cHV0IHBvcnQ9Mg0KICBpbnB1dCBsYWJlbD0xICAgICAgICAgICAg ICAgICAgICAgb3V0cHV0IGxhYmVsPTINCg0KICBUaGlzIGlzIGFsbG93ZWQuDQoNCjxFeGFtcGxl IEI+DQoNCiAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzEgLS0+IG91dHB1dCBwb3J0PTIN CiAgaW5wdXQgbGFiZWw9MSAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0xDQoNCiAg aW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzIgLS0+IG91dHB1dCBwb3J0PTINCiAgaW5wdXQg bGFiZWw9MSAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0xDQoNCiAgVGhpcyBpcyBu b3QgYWxsb3dlZC4NCg0KPEV4YW1wbGUgQz4NCg0KICBpbnB1dCBwb3J0PTEgIC0tPiBTdWJtYXRy aXgjMSAtLT4gb3V0cHV0IHBvcnQ9Mg0KICBpbnB1dCBsYWJlbD0xICAgICAgICAgICAgICAgICAg ICAgb3V0cHV0IGxhYmVsPTENCg0KICBpbnB1dCBwb3J0PTEgIC0tPiBTdWJtYXRyaXgjMiAtLT4g b3V0cHV0IHBvcnQ9Mg0KICBpbnB1dCBsYWJlbD0yICAgICAgICAgICAgICAgICAgICAgb3V0cHV0 IGxhYmVsPTINCg0KICBUaGlzIGlzIGFsbG93ZWQuDQoNCklzIGFib3ZlIHVuZGVyc3RhbmRpbmcg Y29ycmVjdD8NCklmIHNvLCBJIGFtIG5vdCBzdXJlIGhvdyBleGFtcGxlIEEgd29ya3MsIHNpbmNl IEkgYW0gbm90IHN1cmUgd2hhdCBpcyB0aGUgaW5kZW50aWZpZXIgdG8gZGlyZWN0IGZyb20gaW5w dXQgdG8gZWFjaCBzdWJtYXRyaXguDQoNCk1heWJlIEkgYW0gbWlzLXVuZGVyc3RhbmRpbmcgd2hh dCBzdWItbWF0cml4IGlzLiBJIHRob3VnaHQgc3ViLW1hdHJpeCBpcyBhIHNvcnQgb2YgdmlydHVh bCBub2RlLCBzcGxpdHRpbmcgdGhlIHNpbmdsZSBtYXRyaXggKG9yIHN3aXRjaCkgaW50byBzbWFs bGVyIHBpZWNlcy4NCg0KPiA0KSBJbiBzZWN0aW9uIDIuMSwgZm9yIExpbmsgU2V0IEEgZGlyPWJp ZGlyZWN0aW9uYWwsIExpbmsgU2V0IEIgZGlyPWJpZGlyZWN0aW9uYWwsIGlmIGFueSBzaWduYWwg b24gYW4gaW5wdXQgbGluayBYIGlzIG91dHB1dCBvbiBhIGxpbmsgWSwgdGhlbiBhbnkgPiBzaWdu YWwgb24gYW4gaW5wdXQgbGluayBZIGlzIG91dHB1dCBvbiBhIGxpbmsgWCAoYWZ0ZXIgY3Jvc3Mt Y29ubmVjdCk/IE9yIGFueSBjb25zdHJhaW50IG9uIHN1Y2ggc2lnbmFsIGZsb3cgKGFmdGVyIGNy b3NzLWNvbm5lY3QpIGlzIG91dCBvZiBzY29wZT8NCj4gDQo+IDxZT1VORz4+IEkgYW0gbm90IHN1 cmUgd2hhdCAiYWZ0ZXIgY3Jvc3MtY29ubmVjdCIgaXMgbWVhbnQuDQoNCjxFeGFtcGxlPg0KDQog IExpbmsgc2V0IEE6IGxpbmsjMSwgbGluayMyLCBsaW5rIzMNCiAgTGluayBzZXQgQjogbGluayM0 LCBsaW5rIzUsIGxpbmsjNg0KDQogIEJvdGggb2YgTGluayBzZXQgQSBhbmQgTGluayBzZXQgQiBh cmUgc3BlY2lmaWVkIGFzICJkaXIiLg0KDQogIEluIHRoaXMgY2FzZSwNCiAgLSBJcyBpdCBwb3Nz aWJsZSB0byBwcm9ibGVtIHRoZSBjcm9zcy1jb25uZWN0IGFzIGlucHV0PWxpbmsjMSwgb3V0cHV0 PWxpbmsjNA0KICAgICYgaW5wdXQ9bGluayM1LCBvdXRwdXQ9bGluayMxIHNpbXVsdGFuZW9sdXNs eT8NCiAgLSBPciBpcyBpdCBhdXRvbWF0aWNhbGx5IGFzc3VtZWQgaWYgaW5wdXQ9bGluayMxLCBv dXRwdXQ9bGluayM0LA0KICAgIHRoZW4gaW5wdXQ9bGluayM0LCBvdXRwdXQ9bGluayMxPw0KICAt IE9yIHRoaXMgc29ydCBvZiBjb25zdHJhaW50IGlzIG5vdCBzcGVjaWZpZWQgaW4gTGluayBTZXQg RmllbGQ/DQoNClRoZSB0ZXh0IHNlZW1zIGxpa2Ugc2F5aW5nIHRoZSBmaXJzdCBvcHRpb24sIGJ1 dCBJIGRvIG5vdCB0aGluayB0aGlzIGlzIGEgY29tbW9uIGVxdWlwbWVudCBpbXBsZW1lbnRhaW9u Lg0KDQpUaGFua3MsDQpUb21vbm9yaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMjAsIDIwMTUgNzo1NCBBTQ0KVG86IFRvbW9ub3JpIFRha2VkYe+8iOatpueUsOef peWFuO+8iTsgcnRnLWFkc0B0b29scy5pZXRmLm9yZw0KQ2M6ICdydGctZGlyQGlldGYub3JnJzsg J2RyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS5hbGxAdG9vbHMuaWV0 Zi5vcmcnOyAnY2NhbXBAaWV0Zi5vcmcnDQpTdWJqZWN0OiBSRTogW1JURy1ESVJdIFJ0Z0RpciBy ZXZpZXc6IGRyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS0xNi50eHQN Cg0KSGkgVG9tb25vcmksDQoNClRoYW5rcyBmb3IgcHJvdmlkaW5nIGdvb2QgY29tbWVudHMuIEhl cmUncyBteSByZXNwb25zZS4gUGxlYXNlIHNlZSBpbi1saW5lLg0KDQpSZWdhcmRzLA0KWW91bmcN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Zy1kaXIgW21haWx0bzpydGct ZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb21vbm9yaSBUYWtlZGENClNlbnQ6 IFNhdHVyZGF5LCBKYW51YXJ5IDE3LCAyMDE1IDc6NTkgQU0NClRvOiBydGctYWRzQHRvb2xzLmll dGYub3JnDQpDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFs LWNvbnN0cmFpbnQtZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZycN ClN1YmplY3Q6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVy YWwtY29uc3RyYWludC1lbmNvZGUtMTYudHh0DQoNCkhlbGxvLCANCg0KSSBoYXZlIGJlZW4gc2Vs ZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQu IFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciBy b3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxs IGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBw dXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0 aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJh Yy93aWtpL1J0Z0RpciANCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBm b3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91 IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwg Y29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhy b3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4gDQoNCkRvY3VtZW50OiBk cmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGUtMTYudHh0IA0KUmV2aWV3 ZXI6IFRvbW9ub3JpIFRha2VkYQ0KUmV2aWV3IERhdGU6IDE3IEphbnVhcnksIDIwMTUNCklFVEYg TEMgRW5kIERhdGU6IDE3IEphbnVhcnksIDIwMTUNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRz IFRyYWNrDQoNClN1bW1hcnk6DQoNClRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZv ciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJp b3IgdG8gcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmll cyBwcm90b2NvbC1hZ25vc3RpYyBlbmNvZGluZ3MgZm9yIGdlbmVyYWwgaW5mb3JtYXRpb24gZWxl bWVudHMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLWluZm8uDQpJIHRoaW5rIHRo ZSBkb2N1bWVudCBpcyBpbiBnb29kIHNoYXBlIGJ1dCB0aGVyZSBhcmUgYSBmZXcgcG9pbnRzIHRo YXQgc2hvdWxkIGJlIGNsYXJpZmllZCBmb3IgYmV0dGVyIHVuZGVyc3RhbmRpbmcuDQoNCk1ham9y IElzc3VlczoNCg0KTm9uZQ0KDQpNaW5vciBJc3N1ZXM6DQoNCk5vbmUNCg0KTml0czoNCg0KMSkg SW4gc2VjdGlvbiAxLjIsIGxhYmVsIGNvbnRpbnVpdHkgY29uc3RyYWludCAoZS5nLiwgd2F2ZWxl bmd0aCBjb250aW51aXR5IGluIFdTT04pIGlzIG1lbnRpb25lZC4gSG93ZXZlciwgSSBhbSBub3Qg c3VyZSB3aGV0aGVyIGluZm9ybWF0aW9uIGVsZW1lbnRzIGZvciB3aGljaCB0aGlzIGRvY3VtZW50 IHNwZWNpZmllcyBlbmNvZGluZ3MgY2FuIGRlc2NyaWJlIHN1Y2ggY29uc3RyYWludC4gTXkgcmVh ZGluZyBpcyB0aGF0IGluZm9ybWF0aW9uIGVsZW1lbnQgc3VjaCBhcyBQb3J0IExhYmVsIFJlc3Ry aWN0aW9uIGlzIHJhdGhlciBmb3IgZGVzY3JpYmluZyB3YXZlbGVuZ3RoIHR1bmluZyBjYXBhYmls aXRpZXMvcmVzdHJpY3Rpb25zLg0KDQpZT1VORz4+IExhYmVsIGNvbnRpbnVpdHkgY29uc3RyYWlu dHMgY2FuIGJlIGluZmVycmVkIGZyb20gdGhlIHR3byBwbGFjZXMgaW4gdGhlIGRyYWZ0OiAoaSkg UG9ydCBMYWJlbCBSZXN0cmljdGlvbiwgd2hpY2ggZ2l2ZXMgdGhlIHNldCBvZiBsYWJlbHMgKHdh dmVsZW5ndGhzKSB0aGF0IG1heSBub3QgYmUgYXZhaWxhYmxlIG9uIGNlcnRhaW4gbGlua3MgaW5j bHVkaW5nIHR1bmluZyByYW5nZS9yZXN0cmljdGlvbjsgKGlpKSBBdmFpbGFibGUvU2hhcmVkIEJh Y2t1cCBMYWJlbCBGaWVsZHMgKHNlY3Rpb24gMi40ICYgc2VjdGlvbiAyLjUpLiBUaGVyZSBpcyBu byBlbmNvZGluZyBmb3IgbGFiZWwgY29udGludWl0eSBjb25zdHJhaW50IHBlciBzZS4gVGhlIGFm b3JlbWVudGlvbmVkIGNvbnN0cmFpbnRzIGFyZSBlbmNvZGVkIHRvIGdpdmUgYSBub2RlIG9yIGEg UENFIHRvIGJlIGFibGUgdG8gY29tcHV0ZSBhIHBhdGggKGkuZS4sIHBhdGggd2l0aCB3YXZlbGVu Z3RoIGNvbnRpbnVpdHkpIHN1YmplY3QgdG8gdGhlc2UgY29uc3RyYWludHMuIA0KDQoyKSBJbiBz ZWN0aW9uIDIuMSwgaXQgc2F5cyAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUg e3NyYyBwb3J0LCBzcmMgbGFiZWwsIGRzdCBwb3J0LCBkc3QgbGFiZWx9Ii4gVG8gYmUgcHJlY2lz ZSwgSSBndWVzcyB0aGlzIHNob3VsZCBiZSAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhl IHNhbWUge3NyYyBwb3J0LCBzcmMgbGFiZWx9LCBhbmQgdHdvIG1hdHJpY2VzIHdpbGwgbm90IGhh dmUgdGhlIHNhbWUge2RzdCBwb3J0LCBkc3QgbGFiZWx9Ij8NCg0KWU9VTkc+PiBJIHRoaW5rIHlv dXIgc3VnZ2VzdGlvbiBtYXkgYmUgdG9vIHJlc3RyaWN0aXZlLiBGb3IgaW5zdGFuY2UsIGlmIHdl IGhhdmUgb25lIHNvdXJjZSAocG9ydCAxKSBhbmQgb25lIGRlc3RpbmF0aW9uIChwb3J0IDIpIHdp dGggdHdvIGxhYmVscyBlYWNoLiBUaGVuIHdlIHdvdWxkIGhhdmU6IHsoMSwxLDIsMSksICgxLDEs MiwyKSwgKDEsMiwyLDEpLCAoMSwyLDIsMil9IEkgdGhpbmsgd2l0aCB0aGUgY3VycmVudCBzdGF0 ZW1lbnQsIHdlIGNhbiBzZW5kIHRoaXMgaW5mbyBpbiBhbnkgY29tYmluYXRpb24gb2YgbXVsdGlw bGUgbWF0cmljZXMsIHdoaWNoIEkgdGhpbmsgcGVyZmVjdGx5IGZpbmUuIFdpdGggeW91ciBzdWdn ZXN0aW9uLCBJIHdvdWxkIG5vdCBiZSBhYmxlIHNlbmQgKDEsMSwyLDEpIGFuZCAoMSwxLDIsMikg dG9nZXRoZXIuIFdoeSB3b3VsZCB0aGlzIG5vdCBiZSBtYWRlIHBvc3NpYmxlPyBNeSB0YWtlIGlz IGFzIGxvbmcgYXMgZWFjaCBzdWJtYXRyaXggcmVwcmVzZW50cyBhIHNldCBvZiBkaXNqb2ludCBx dWFkcnVwbGVzLCB0aGF0IHNob3VsZCBiZSBhbGxvd2VkLiANCg0KMykgSW4gc2VjdGlvbiAyLjEs IGl0IHNheXMgIlRoZSB2YWx1ZSBvZiAweEZGIGlzIHJlc2VydmVkIGZvciB1c2Ugd2l0aCBwb3J0 IHdhdmVsZW5ndGggY29uc3RyYWludHMiLiBJIHRoaW5rICJwb3J0IHdhdmVsZW5ndGggY29uc3Ry YWludHMiIHNob3VsZCBiZSAicG9ydCBsYWJlbCByZXN0cmljdGlvbiIuDQoNCllPVU5HPj4gWWVz LCB0aGFua3MuIA0KDQo0KSBJbiBzZWN0aW9uIDIuMSwgZm9yIExpbmsgU2V0IEEgZGlyPWJpZGly ZWN0aW9uYWwsIExpbmsgU2V0IEIgZGlyPWJpZGlyZWN0aW9uYWwsIGlmIGFueSBzaWduYWwgb24g YW4gaW5wdXQgbGluayBYIGlzIG91dHB1dCBvbiBhIGxpbmsgWSwgdGhlbiBhbnkgc2lnbmFsIG9u IGFuIGlucHV0IGxpbmsgWSBpcyBvdXRwdXQgb24gYSBsaW5rIFggKGFmdGVyIGNyb3NzLWNvbm5l Y3QpPyBPciBhbnkgY29uc3RyYWludCBvbiBzdWNoIHNpZ25hbCBmbG93IChhZnRlciBjcm9zcy1j b25uZWN0KSBpcyBvdXQgb2Ygc2NvcGU/DQoNCllPVU5HPj4gSSBhbSBub3Qgc3VyZSB3aGF0ICJh ZnRlciBjcm9zcy1jb25uZWN0IiBpcyBtZWFudC4gDQoNCjUpIEluIHNlY3Rpb24gMi4yLjEsIGl0 IHNheXMgIkluIHRoaXMgY2FzZSB0aGUgYWNjb21wYW55aW5nIGxhYmVsIHNldCBpbmRpY2F0ZXMg dGhlIGxhYmVscyBwZXJtaXR0ZWQgb24gdGhlIHBvcnQuIiBJIHRoaW5rICJwb3J0IiBzaG91bGQg YmUgInBvcnQvbWF0cml4Ii4NCg0KWU9VTkc+PiBZZXMsIHRoYW5rcy4gDQoNCjYpIEluIHNlY3Rp b24gMi4yLjIsIGl0IHdvdWxkIGJlIGJldHRlciB0byBkZXNjcmliZSB0aGUgdHlwZSAoZS5nLiwg aW50ZWdlcikgZm9yIE1heE51bUNoYW5uZWxzLg0KVGhpcyBhbHNvIGFwcGxpZXMgZm9yIE1heExh YmVsUmFuZ2UgKGluIHNlY3Rpb24gMi4yLjMpIGFuZCBOdW0gTGFiZWxzIChpbiBzZWN0aW9uIDIu NikuDQoNCllPVU5HPj4gT0suIA0KDQo3KSBJbiBzZWN0aW9uIDIuNiwgaXQgc2F5cyAiTGFiZWwg U2V0IEZpZWxkIGlzIHVzZWQgd2l0aGluIHRoZSA8QXZhaWxhYmxlTGFiZWxzPiBvciB0aGUgPFNo YXJlZEJhY2t1cExhYmVscz4iLiBCdXQgSSB0aGluayBMYWJlbCBTZXQgRmllbGQgaXMgYWxzbyB1 c2VkIHdpdGhpbiBTSU1QTEVfTEFCRUwsIExBQkVMX1JBTkdFIGFuZCBTSU1QTEVfTEFCRUwgJiBD SEFOTkVMX0NPVU5ULg0KDQpZT1VORz4+IFllcywgaXQgaXMgdXNlZCBpbiBtdWx0aXBsZSBwbGFj ZXMuIA0KDQpIb3cgYWJvdXQ6DQpPTEQ6IExhYmVsIFNldCBGaWVsZCBpcyB1c2VkIHdpdGhpbiB0 aGUgPEF2YWlsYWJsZUxhYmVscz4gb3IgdGhlDQogICA8U2hhcmVkQmFja3VwTGFiZWxzPiwgd2hp Y2ggaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIuNC4gYW5kIDIuNS4sDQogICByZXNwZWN0aXZlbHku DQpORVc6IExhYmVsIFNldCBGaWVsZCBpcyB1c2VkIHdpdGhpbiB0aGUgPEF2YWlsYWJsZUxhYmVs cz4gb3IgdGhlDQogICA8U2hhcmVkQmFja3VwTGFiZWxzPiwgd2hpY2ggaXMgZGVmaW5lZCBpbiBT ZWN0aW9uIDIuNC4gYW5kIDIuNS4sDQogICByZXNwZWN0aXZlbHkuIEl0IGlzIGFsc28gdXNlZCB3 aXRoaW4gdGhlIDxTSU1QTEVfTEFCRUw+LCANCiAgIDxMQUJFTF9SQU5HRT4sIDxTSU1QTEVfTEFC RUw+IG9yIDxDSEFOTkVMX0NPVU5UPiwgd2hpY2ggaXMgZGVmaW5lZA0KICAgaW4gU2VjdGlvbnMg Mi4xLjEgLSAyLjEuNCwgcmVzcGVjdGl2ZWx5LiANCg0KDQpUaGFua3MsDQpUb21vbm9yaQ0K From nobody Wed Jan 21 03:57: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 442E11A1A22; Wed, 21 Jan 2015 03:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 KjYjmYEmkMbF; Wed, 21 Jan 2015 03:57:43 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58411A1A1E; Wed, 21 Jan 2015 03:57:42 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LBveuw013271; Wed, 21 Jan 2015 11:57:40 GMT Received: from 950129200 (089144210022.atnat0019.highway.a1.net [89.144.210.22]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LBvb84013235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 11:57:38 GMT From: "Adrian Farrel" To: "'Cyril Margaria'" , References: <012001d0274b$d25f3630$771da290$@olddog.co.uk> In-Reply-To: Date: Wed, 21 Jan 2015 11:57:37 -0000 Message-ID: <011b01d03571$7526d480$5f747d80$@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: AQJNJKbqcA8ICrxY/nQ0vdspVCXFtAG4lZZam8LQ7AA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21270.001 X-TM-AS-Result: No--22.294-10.0-31-10 X-imss-scan-details: No--22.294-10.0-31-10 X-TMASE-MatchedRID: Ync95tbzDRmnykMun0J1wtxajlW+zwxCC/ExpXrHizwJW4Re2U2py+50 k+nSYSmWO4Z0ZkXCjJsUPsM54RzshHYIQoHEix+qdrpCZsJVIIUpWss5kPUFdGu9/l5WAy7sbOh vQwxZCUumUhnCmPhVLUlKUqmaZWPdzsxad8fKloYzSlmIs9AhOtEA4SsNDgaiXudxyY/AL0eXNa gpKKGTEzmrSBe3bBipItB1q1kmkIKbdVs/uMg2/8H0JgP/bKWSQa2sDHLkQ040QmmUihPzrJ8zj Z45FG+UwOalMNNoWHYYkIWWLQ+ruev/j3sV8W9mW7gz/Gbgpl4/W/kEeVcLFGjSAumzejoRDgvn ApkxBAVSRo6Tk1CHbLtnawFLb7obvYmC3IHzHcj/VoEOchXiKVXKDhjPZTukMKZRiezcUtMgRPl rGC5FrzzIYciYTdEA3KCE1AIrmzWH6FJxCilEmWbzlCg24oq+h+w9Wz/xXDprEoFtNYg0C4ARql 3UMZ6bVgi2vEnHdgKGDG1lR3xKVq+2LFpqaFp51yMJs9mBCcUvfgjwim9BwsUdzAovpQT/eu5z4 syzGYYu6BdQaUaE9nkNrWD+KBWtoayr11+eKrlRKfej56hSbJsqkCVjbLpJAuVirUrNCL+g0ehM cZ850tJpCbWqQKk2C1MkYihD/gEKT+RHLhCkHMqXjImgj58becvjbu/xDjr3qGsw1oZ+zxwz72z DzvkOCMe3Br715Je4Clh+0goxykq+i9GrWzgshsE+u3nnCfAk227IvqakhftHa1P9/19Uo8WMkQ Wv6iXhWDPiI8D3842j49Ftap9EkGUtrowrXLg= Archived-At: Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org, ccamp@ietf.org, draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, draft-ietf-ccamp-wson-signaling@tools.ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-teas-lsp-attribute-ro 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: Wed, 21 Jan 2015 11:57:46 -0000 Hi Cyril, Thanks for engaging. [CCAMP - note just one point wrt draft-ietf-ccamp-wson-signaling] > >Section 2.3 needs to describe the processing when an ERO Hop = Attributes > >subobject is encountered after a loose hop subobject or a strict hop > >that is an abstract node? > > > >- Is it valid? > >- Is it assumed to apply to all hops in that loose hop or abstract = node? > >- Or in the case of a loose hop, does it just apply to the named hop > > itself? > >- What about if the preceding subobject is an interface identifier or = a > > label? > > > >I wonder whether reference to 4990 would help at all. >=20 > Following RFC4990, it depends. > In the context of draft-ietf-teas-rsvp-te-li-lb, a loopback after a = loose > hop, could be rejected. This should not apply to a label or interface > In the context of draft-ietf-ccamp-wson-signaling-09, a = ResourceBlockInfo > should target an explicit Hop, but the WavelengthSelection could = appear > after an abstract node or loose hop. >=20 > Future Attributes TLV may apply to interfaces or labels. I think its = up to > the document defining the TLV to scope it. > For instance the following text could address that: > Depending on the scope of thea specific Hop attribute TLV, the = defining > document SHOULD describe after which kind of hop they are valid, for > instance by describing rules similar to [RFC4990] section 6.1. OK. This is clear. Thanks. I think *this* I-D needs to make it clear what the expectations are: 1. The sub-object is allowed at any point in the ERO 2. The document that specifies a TLV for the sub-object must make it clear where in an ERO a sub-object containing that TLV is allowed and not allowed. That should be an easy edit for you. > For draft-ietf-teas-rsvp-te-li-lb this could be (restricting the TLV = to > explicit nodes, precluding link ids): > The Attribute Flags TLV with Loopback Attribute Flag set MUST be = present > after an explicit Hop addressing an TE Router ID identifying a = specific > node or a Link ID identifying an incoming TE link. it MUST NOT be = present > after a loose, abstract node, Link ID identifying an outgoing TE = link, > Component Interface ID or Label. Ah, joy! Yes. This needs another fix to draft-ietf-teas-rsvp-te-li-lb. I've made a note in the data tracker and marked that I-D as needing a = new revision. > For draft-ietf-ccamp-wson-signaling-09, this could be (restricting the > ResourceBlockInfo to explicit nodes): >=20 > The WSON Processing HOP Attribute TLV with ResourceBlockInfo MUST be > present after an explicit Hop addressing an TE Router ID identifying a > specific node or a Link ID identifying an incoming TE link. it MUST = NOT be > present after a loose, abstract node, Link ID identifying an outgoing = TE > link, Component Interface ID or Label. >=20 > The WSON Processing HOP Attribute TLV with WavelengthSelection only = MUST > be present after an explicit Hop addressing an TE Router ID = identifying a > specific node, a Link ID identifying an incoming TE link, loose hop, > abstract node, Link ID identifying an outgoing TE lin or Component > Interface ID. it MUST NOT be present after a Label. >=20 > The WavelengthSelection may apply starting at an abstract node, but = not > after a label (as no selection is possible) Phew, this I-D is still pending my review. I'll capture that as I process it. Thanks for doing the work of crafting text. [I added CCAMP to the recipients of this email so they can see this = point] =20 > >3.2.1 has > > > > All such > > subobjects MUST be forwarded unmodified by transit LSRs. > > > >That is, of course, the general rule, but I assume that there are > >exceptions. > > > >For example, an ASBR may choose to prune the information that is > >forwarded in an RRO. Similarly, the UNI-N may strip information. > > > >I think the point would be that "If a node forwards an RRO subobject > >for a specific hop, it MUST forward any associated HOP Attributes > >subobjects." > > > >But even this may be too restrictive for a border node that wants to > >report the chosen path but not expose how the internals of its = network > >are operated. In this case it may want to strip HOP Attributes > >subobjects from the RRO or even modify them to mask information. > > > >Can you add some clarification about all of this? >=20 > Absolutely, for instance changing the MUST in SHOULD, and adding the > following text: >=20 > "It is noted that a node (e.g. a domain edge node) may edit the RRO to > prune/modify the RRO, including the RRO Hop Attribute subobject before > forwarding due to confidentiality policy or other reasons (for = instance > RRO size reduction)." Perfect. =20 > >I think section 5 is a little optimistic. You are introducing a new > >mechanism for the control of the behavior on certain nodes on the = path > >of the LSP. Since the control of those nodes may impact the behavior = of > >other LSPs passing the node, some care is needed. For example, = setting > >optical power levels for one lambda can interfere with the signals on > >other lambdas. Thus, and in general, you have a mechanism that takes > >control away from the node itself and puts it in the hand of the node > >that signaled the LSP. This opens up three security possibilities: > >1. Simple errors in the attributes of an LSP may inadvertently impact > > existing LSPs while still allowing this LSP to be set up. > >2. A malign ingress may signal an LSP down a path and with attributes > > chosen to damage other LSPs from other ingresses. > >3. An attacked Path message may result in damage to other LSPs. > > > >The third of these is mitigated somewhat by existing RSVP-TE security > >mechanisms. The first two (and the third in the case of a subverted > >node) can only be mitigated by allowing policy to be applied at a = node > >that implements the HOP Attributes it receives in an ERO. A node must = be > >allowed to determine that satisfy the attributes would be inadvisable = or > >against local policy even if practically possible. In these cases the > >node has a choice to either reject the Path message (but a new error > >code might be helpful) or to modify the requested attribute (but in = this > >case it might be required to report exactly what it has done, = presumably > >in the RRO). >=20 > I agree in general, the existing text refer to the hop attributes as > =B3functional preferences=B2, as any other RSVP object, this is to be > considered as =B3external input=B2, so subject to policy and sanity = check. > The document does not define how the TLV have to be applied (Just that = the > content must be processed). The aspect of targetting other LSP is, I > think, especially valid for WSON, but less applicable for MPLS-TP. > The same consideration also apply for explicit label control. >=20 > OLD: > "As any RSVP-TE signaling request, the procedures defined in this > document permit the transfer and reporting of functional = preferences > on specific node.=B2 >=20 > NEW: > "As any RSVP-TE signaling request, the procedures defined in this > document permit the transfer and reporting of functional = preferences > on specific node. > The mechanism added in this document does allow more control of LSP > attributes at a given node. As other inputs, a node should check the = Hop > Attributes against his policies and admission procedures. > A node may reject the message using existing RSVP error code like = "Policy > Control Failure" or "Admission Control Failure". The node may also, > depending on the specific TLV procedures, modify the requested = attribute. > " Perfect. > I think that Attribute modification is TLV-dependant and should be > specified in the defining documents. You should probably also include a statement of this so that people are = reminded to do exactly that. > >3.2.3 has some SHOULDs and SHOULD NOTs. This always makes me wonder > > what the exception cases are: under what circumstances MAY an > > implementation vary from these rules? >=20 > If a specific attribute/document allows it. Wouldn=B9t a MUST in that = case > be too restrictive for those documents? >=20 > Would the following text clarify in which case this may be allowed? >=20 > A node MAY use the RRO Hop Attribute to report a LSP Attribute > signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES only if the > following conditions are met : >=20 > Rhe Attribute and its corresponding flag is allowed on both the > LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and LSP Hop Attributes > subobject. >=20 > The document defining this Attribute specify this specific > behavior. Like it. s/Rhe/The/ Thanks, Please post the updated version. Adrian From nobody Wed Jan 21 09:43: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 8AD531A1B46; Wed, 21 Jan 2015 09:43:52 -0800 (PST) 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 qPQTeOKsFoKn; Wed, 21 Jan 2015 09:43:49 -0800 (PST) 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 C66981A1B3E; Wed, 21 Jan 2015 09:43:47 -0800 (PST) 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 BRP16799; Wed, 21 Jan 2015 17:43:46 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 21 Jan 2015 17:43:45 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 21 Jan 2015 09:43:34 -0800 From: Leeyoung To: Tomonori Takeda , Leeyoung , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt Thread-Index: AdAyVmdKICzu0mt5SZ+spYC7d3T1cAB2eNGwAFY7goAAAxCE8A== Date: Wed, 21 Jan 2015 17:43:34 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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: Wed, 21 Jan 2015 17:43:52 -0000 SGkgVG9tb25vcmksDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50LiBQbGVhc2Ugc2VlIGluLWxp bmUgZm9yIG15IHJlc3BvbnNlLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhlIHJlc3BvbnNlIHdv dWxkIHNhdGlzZnkgeW91LiANCg0KQmVzdCByZWdhcmRzLA0KWW91bmcNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IFRvbW9ub3JpIFRha2VkYSBbbWFpbHRvOnRvbW9ub3JpLnRh a2VkYUBudHQuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMSwgMjAxNSAxMjo0OCBB TQ0KVG86IExlZXlvdW5nOyBydGctYWRzQHRvb2xzLmlldGYub3JnDQpDYzogJ3J0Zy1kaXJAaWV0 Zi5vcmcnOyAnZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLmFsbEB0 b29scy5pZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZyc7IFRvbW9ub3JpIFRha2VkYQ0KU3ViamVj dDogUkU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwt Y29uc3RyYWludC1lbmNvZGUtMTYudHh0DQoNCkhpIFlvdW5nLA0KDQpUaGFua3MuDQoNClR3byBm b2xsb3ctdXAgcXVlc3Rpb25zL2NvbW1lbnRzLg0KKEkgYW0gZmluZSB3aXRoIG90aGVyIHBvaW50 cywgd2hpY2ggeW91IGFscmVhZHkgYWRkcmVzc2VkIGluIHRoZSB1cGRhdGVkIGRyYWZ0LikNCg0K PiAyKSBJbiBzZWN0aW9uIDIuMSwgaXQgc2F5cyAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUg dGhlIHNhbWUge3NyYyBwb3J0LCBzcmMgbGFiZWwsIGRzdCBwb3J0LCBkc3QgbGFiZWx9Ii4gVG8g YmUgcHJlY2lzZSwgSSBndWVzcyB0aGlzIHNob3VsZCBiZSA+ICJ0d28gbWF0cmljZXMgd2lsbCBu b3QgaGF2ZSB0aGUgc2FtZSB7c3JjIHBvcnQsIHNyYyBsYWJlbH0sIGFuZCB0d28gbWF0cmljZXMg d2lsbCBub3QgaGF2ZSB0aGUgc2FtZSB7ZHN0IHBvcnQsIGRzdCBsYWJlbH0iPw0KPiANCj4gWU9V Tkc+PiBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlvbiBtYXkgYmUgdG9vIHJlc3RyaWN0aXZlLiBGb3Ig aW5zdGFuY2UsIGlmIHdlIGhhdmUgb25lIHNvdXJjZSAocG9ydCAxKSBhbmQgb25lIGRlc3RpbmF0 aW9uIChwb3J0IDIpIHdpdGggdHdvIGxhYmVscyA+IGVhY2guIFRoZW4gd2Ugd291bGQgaGF2ZTog eygxLDEsMiwxKSwgKDEsMSwyLDIpLCAoMSwyLDIsMSksICgxLDIsMiwyKX0gSSB0aGluayB3aXRo IHRoZSBjdXJyZW50IHN0YXRlbWVudCwgd2UgY2FuIHNlbmQgdGhpcyBpbmZvIGluIGFueSBjb21i aW5hdGlvbiA+IG9mIG11bHRpcGxlIG1hdHJpY2VzLCB3aGljaCBJIHRoaW5rIHBlcmZlY3RseSBm aW5lLiBXaXRoIHlvdXIgc3VnZ2VzdGlvbiwgSSB3b3VsZCBub3QgYmUgYWJsZSBzZW5kICgxLDEs MiwxKSBhbmQgKDEsMSwyLDIpIHRvZ2V0aGVyLiBXaHkgd291bGQgdGhpcyA+IG5vdCBiZSBtYWRl IHBvc3NpYmxlPyBNeSB0YWtlIGlzIGFzIGxvbmcgYXMgZWFjaCBzdWJtYXRyaXggcmVwcmVzZW50 cyBhIHNldCBvZiBkaXNqb2ludCBxdWFkcnVwbGVzLCB0aGF0IHNob3VsZCBiZSBhbGxvd2VkLg0K DQpNeSByZWFkaW5nIG9mICJ0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2ZSB0aGUgc2FtZSB7c3Jj IHBvcnQsIHNyYyBsYWJlbCwgZHN0IHBvcnQsIGRzdCBsYWJlbH0iIGlzIGFzIGZvbGxvd3MuDQoN CjxFeGFtcGxlIEE+DQoNCiAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzEgLS0+IG91dHB1 dCBwb3J0PTINCiAgaW5wdXQgbGFiZWw9MSAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJl bD0xDQoNCiAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzIgLS0+IG91dHB1dCBwb3J0PTIN CiAgaW5wdXQgbGFiZWw9MSAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0yDQoNCiAg VGhpcyBpcyBhbGxvd2VkLg0KDQo8RXhhbXBsZSBCPg0KDQogIGlucHV0IHBvcnQ9MSAgLS0+IFN1 Ym1hdHJpeCMxIC0tPiBvdXRwdXQgcG9ydD0yDQogIGlucHV0IGxhYmVsPTEgICAgICAgICAgICAg ICAgICAgICBvdXRwdXQgbGFiZWw9MQ0KDQogIGlucHV0IHBvcnQ9MSAgLS0+IFN1Ym1hdHJpeCMy IC0tPiBvdXRwdXQgcG9ydD0yDQogIGlucHV0IGxhYmVsPTEgICAgICAgICAgICAgICAgICAgICBv dXRwdXQgbGFiZWw9MQ0KDQogIFRoaXMgaXMgbm90IGFsbG93ZWQuDQoNCjxFeGFtcGxlIEM+DQoN CiAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzEgLS0+IG91dHB1dCBwb3J0PTINCiAgaW5w dXQgbGFiZWw9MSAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0xDQoNCiAgaW5wdXQg cG9ydD0xICAtLT4gU3VibWF0cml4IzIgLS0+IG91dHB1dCBwb3J0PTINCiAgaW5wdXQgbGFiZWw9 MiAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0yDQoNCiAgVGhpcyBpcyBhbGxvd2Vk Lg0KDQpJcyBhYm92ZSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQpJZiBzbywgSSBhbSBub3Qgc3Vy ZSBob3cgZXhhbXBsZSBBIHdvcmtzLCBzaW5jZSBJIGFtIG5vdCBzdXJlIHdoYXQgaXMgdGhlIGlu ZGVudGlmaWVyIHRvIGRpcmVjdCBmcm9tIGlucHV0IHRvIGVhY2ggc3VibWF0cml4Lg0KDQpNYXli ZSBJIGFtIG1pcy11bmRlcnN0YW5kaW5nIHdoYXQgc3ViLW1hdHJpeCBpcy4gSSB0aG91Z2h0IHN1 Yi1tYXRyaXggaXMgYSBzb3J0IG9mIHZpcnR1YWwgbm9kZSwgc3BsaXR0aW5nIHRoZSBzaW5nbGUg bWF0cml4IChvciBzd2l0Y2gpIGludG8gc21hbGxlciBwaWVjZXMuDQoNCllPVU5HPj4gT0ssIEkg dGhpbmsgdGhlIGRlZmluaXRpb24gb2Ygc3VibWF0cml4IHdhcyBub3QgY2xlYXIuIEl0IGlzIHNp bXBseSBkaXZpZGluZyB1cCBhIG1hdHJpeCBpbnRvIHNldmVyYWwgcGllY2VzIGluIGNhc2UgdGhl IHNpemUgb2YgdGhlIG1hdHJpeCBiZWNvbWVzIHRvbyBiaWcgb3IgYSB3YXkgdG8gYWR2ZXJ0aXpl IHRoZSBjaGFuZ2VkIHBvcnQvbGFiZWwgc2V0IGluIG9uZSBwbGFjZSAoc3ViLW1hdHJpeCkgdGhl biBvdGhlciB1bmNoYW5nZWQgcG9ydC9sYWJlbCBzZXQgaW4gb3RoZXIgcGxhY2UgKGRpZmZlcmVu dCBzdWItbWF0cml4KS4gVGhlIGlkZW50aWZpZXIgZm9yIGVhY2ggc3ViLW1hdHJpeCBpcyB0aGUg TUFUUklYIElELiBUaGVyZSBpcyBub3Qgc2VwYXJhdGUgaWRlbnRpZmllciB0byBkaXJlY3QgZnJv bSBpbnB1dC4gVGhlIGlucHV0IGlzIGEgcGFydCBvZiB0aGUgc3ViLW1hdHJpeC4gU2F5IGlmIHdl IGhhdmUgTipNIG1hdHJpeCB0aGF0IGRlc2NyaWJlcyBhbGwgaW5wdXQgYW5kIG91dHB1dCBwb3J0 L2xhYmVsLiBXZSBtaWdodCBkaXZpZGUgdXAgaW50byBOKihNLUwpIGFuZCBOKkwgb3IgYW55IG90 aGVyIGNvbWJpbmF0aW9ucyBhcyBmYXIgYXMgdGhleSBhcmUgYWxsIGRpc2pvaW50IGZyb20gZWFj aCBvdGhlci4gDQoNCj4gNCkgSW4gc2VjdGlvbiAyLjEsIGZvciBMaW5rIFNldCBBIGRpcj1iaWRp cmVjdGlvbmFsLCBMaW5rIFNldCBCIGRpcj1iaWRpcmVjdGlvbmFsLCBpZiBhbnkgc2lnbmFsIG9u IGFuIGlucHV0IGxpbmsgWCBpcyBvdXRwdXQgb24gYSBsaW5rIFksIHRoZW4gYW55ID4gc2lnbmFs IG9uIGFuIGlucHV0IGxpbmsgWSBpcyBvdXRwdXQgb24gYSBsaW5rIFggKGFmdGVyIGNyb3NzLWNv bm5lY3QpPyBPciBhbnkgY29uc3RyYWludCBvbiBzdWNoIHNpZ25hbCBmbG93IChhZnRlciBjcm9z cy1jb25uZWN0KSBpcyBvdXQgb2Ygc2NvcGU/DQo+IA0KPiA8WU9VTkc+PiBJIGFtIG5vdCBzdXJl IHdoYXQgImFmdGVyIGNyb3NzLWNvbm5lY3QiIGlzIG1lYW50Lg0KDQo8RXhhbXBsZT4NCg0KICBM aW5rIHNldCBBOiBsaW5rIzEsIGxpbmsjMiwgbGluayMzDQogIExpbmsgc2V0IEI6IGxpbmsjNCwg bGluayM1LCBsaW5rIzYNCg0KICBCb3RoIG9mIExpbmsgc2V0IEEgYW5kIExpbmsgc2V0IEIgYXJl IHNwZWNpZmllZCBhcyAiZGlyIi4NCg0KICBJbiB0aGlzIGNhc2UsDQogIC0gSXMgaXQgcG9zc2li bGUgdG8gcHJvYmxlbSB0aGUgY3Jvc3MtY29ubmVjdCBhcyBpbnB1dD1saW5rIzEsIG91dHB1dD1s aW5rIzQNCiAgICAmIGlucHV0PWxpbmsjNSwgb3V0cHV0PWxpbmsjMSBzaW11bHRhbmVvbHVzbHk/ DQogIC0gT3IgaXMgaXQgYXV0b21hdGljYWxseSBhc3N1bWVkIGlmIGlucHV0PWxpbmsjMSwgb3V0 cHV0PWxpbmsjNCwNCiAgICB0aGVuIGlucHV0PWxpbmsjNCwgb3V0cHV0PWxpbmsjMT8NCiAgLSBP ciB0aGlzIHNvcnQgb2YgY29uc3RyYWludCBpcyBub3Qgc3BlY2lmaWVkIGluIExpbmsgU2V0IEZp ZWxkPw0KDQpUaGUgdGV4dCBzZWVtcyBsaWtlIHNheWluZyB0aGUgZmlyc3Qgb3B0aW9uLCBidXQg SSBkbyBub3QgdGhpbmsgdGhpcyBpcyBhIGNvbW1vbiBlcXVpcG1lbnQgaW1wbGVtZW50YWlvbi4N Cg0KWU9VR04+PiBPSy4gSSB0aGluayBJIHVuZGVyc3RhbmQgeW91IG1vcmUgY2xlYXJseS4gRm9y IHRoaXMgY2FzZSAoYmlkaXJlY3Rpb25hbCBsaW5rIHNldHMpLCB0aGUgZmlyc3QgY2FzZSBpcyBk ZWZpbml0ZWx5IG5vdCB0aGUgaW50ZW50aW9uLiBUaGUgc2Vjb25kIGNhc2UgaXMgYXNzdW1lZC4g DQoNClRoYW5rcywNClRvbW9ub3JpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBMZWV5b3VuZyBbbWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb21dIA0KU2VudDogVHVlc2RheSwg SmFudWFyeSAyMCwgMjAxNSA3OjU0IEFNDQpUbzogVG9tb25vcmkgVGFrZWRh77yI5q2m55Sw55+l 5YW477yJOyBydGctYWRzQHRvb2xzLmlldGYub3JnDQpDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAn ZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLmFsbEB0b29scy5pZXRm Lm9yZyc7ICdjY2FtcEBpZXRmLm9yZycNClN1YmplY3Q6IFJFOiBbUlRHLURJUl0gUnRnRGlyIHJl dmlldzogZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLTE2LnR4dA0K DQpIaSBUb21vbm9yaSwNCg0KVGhhbmtzIGZvciBwcm92aWRpbmcgZ29vZCBjb21tZW50cy4gSGVy ZSdzIG15IHJlc3BvbnNlLiBQbGVhc2Ugc2VlIGluLWxpbmUuDQoNClJlZ2FyZHMsDQpZb3VuZw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRnLWRpciBbbWFpbHRvOnJ0Zy1k aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbW9ub3JpIFRha2VkYQ0KU2VudDog U2F0dXJkYXksIEphbnVhcnkgMTcsIDIwMTUgNzo1OSBBTQ0KVG86IHJ0Zy1hZHNAdG9vbHMuaWV0 Zi5vcmcNCkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwt Y29uc3RyYWludC1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnJzsgJ2NjYW1wQGlldGYub3JnJw0K U3ViamVjdDogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtY2NhbXAtZ2VuZXJh bC1jb25zdHJhaW50LWVuY29kZS0xNi50eHQNCg0KSGVsbG8sIA0KDQpJIGhhdmUgYmVlbiBzZWxl Y3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4g VGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJv dXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwg YW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1 cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRp bmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFj L3dpa2kvUnRnRGlyIA0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3Ug Y291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBj b21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJv dWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0LiANCg0KRG9jdW1lbnQ6IGRy YWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS0xNi50eHQgDQpSZXZpZXdl cjogVG9tb25vcmkgVGFrZWRhDQpSZXZpZXcgRGF0ZTogMTcgSmFudWFyeSwgMjAxNQ0KSUVURiBM QyBFbmQgRGF0ZTogMTcgSmFudWFyeSwgMjAxNQ0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMg VHJhY2sNCg0KU3VtbWFyeToNCg0KVGhpcyBkb2N1bWVudCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9y IHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlv ciB0byBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6DQoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IHByb3RvY29sLWFnbm9zdGljIGVuY29kaW5ncyBmb3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiBlbGVt ZW50cyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2EtaW5mby4NCkkgdGhpbmsgdGhl IGRvY3VtZW50IGlzIGluIGdvb2Qgc2hhcGUgYnV0IHRoZXJlIGFyZSBhIGZldyBwb2ludHMgdGhh dCBzaG91bGQgYmUgY2xhcmlmaWVkIGZvciBiZXR0ZXIgdW5kZXJzdGFuZGluZy4NCg0KTWFqb3Ig SXNzdWVzOg0KDQpOb25lDQoNCk1pbm9yIElzc3VlczoNCg0KTm9uZQ0KDQpOaXRzOg0KDQoxKSBJ biBzZWN0aW9uIDEuMiwgbGFiZWwgY29udGludWl0eSBjb25zdHJhaW50IChlLmcuLCB3YXZlbGVu Z3RoIGNvbnRpbnVpdHkgaW4gV1NPTikgaXMgbWVudGlvbmVkLiBIb3dldmVyLCBJIGFtIG5vdCBz dXJlIHdoZXRoZXIgaW5mb3JtYXRpb24gZWxlbWVudHMgZm9yIHdoaWNoIHRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIGVuY29kaW5ncyBjYW4gZGVzY3JpYmUgc3VjaCBjb25zdHJhaW50LiBNeSByZWFk aW5nIGlzIHRoYXQgaW5mb3JtYXRpb24gZWxlbWVudCBzdWNoIGFzIFBvcnQgTGFiZWwgUmVzdHJp Y3Rpb24gaXMgcmF0aGVyIGZvciBkZXNjcmliaW5nIHdhdmVsZW5ndGggdHVuaW5nIGNhcGFiaWxp dGllcy9yZXN0cmljdGlvbnMuDQoNCllPVU5HPj4gTGFiZWwgY29udGludWl0eSBjb25zdHJhaW50 cyBjYW4gYmUgaW5mZXJyZWQgZnJvbSB0aGUgdHdvIHBsYWNlcyBpbiB0aGUgZHJhZnQ6IChpKSBQ b3J0IExhYmVsIFJlc3RyaWN0aW9uLCB3aGljaCBnaXZlcyB0aGUgc2V0IG9mIGxhYmVscyAod2F2 ZWxlbmd0aHMpIHRoYXQgbWF5IG5vdCBiZSBhdmFpbGFibGUgb24gY2VydGFpbiBsaW5rcyBpbmNs dWRpbmcgdHVuaW5nIHJhbmdlL3Jlc3RyaWN0aW9uOyAoaWkpIEF2YWlsYWJsZS9TaGFyZWQgQmFj a3VwIExhYmVsIEZpZWxkcyAoc2VjdGlvbiAyLjQgJiBzZWN0aW9uIDIuNSkuIFRoZXJlIGlzIG5v IGVuY29kaW5nIGZvciBsYWJlbCBjb250aW51aXR5IGNvbnN0cmFpbnQgcGVyIHNlLiBUaGUgYWZv cmVtZW50aW9uZWQgY29uc3RyYWludHMgYXJlIGVuY29kZWQgdG8gZ2l2ZSBhIG5vZGUgb3IgYSBQ Q0UgdG8gYmUgYWJsZSB0byBjb21wdXRlIGEgcGF0aCAoaS5lLiwgcGF0aCB3aXRoIHdhdmVsZW5n dGggY29udGludWl0eSkgc3ViamVjdCB0byB0aGVzZSBjb25zdHJhaW50cy4gDQoNCjIpIEluIHNl Y3Rpb24gMi4xLCBpdCBzYXlzICJ0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2ZSB0aGUgc2FtZSB7 c3JjIHBvcnQsIHNyYyBsYWJlbCwgZHN0IHBvcnQsIGRzdCBsYWJlbH0iLiBUbyBiZSBwcmVjaXNl LCBJIGd1ZXNzIHRoaXMgc2hvdWxkIGJlICJ0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2ZSB0aGUg c2FtZSB7c3JjIHBvcnQsIHNyYyBsYWJlbH0sIGFuZCB0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2 ZSB0aGUgc2FtZSB7ZHN0IHBvcnQsIGRzdCBsYWJlbH0iPw0KDQpZT1VORz4+IEkgdGhpbmsgeW91 ciBzdWdnZXN0aW9uIG1heSBiZSB0b28gcmVzdHJpY3RpdmUuIEZvciBpbnN0YW5jZSwgaWYgd2Ug aGF2ZSBvbmUgc291cmNlIChwb3J0IDEpIGFuZCBvbmUgZGVzdGluYXRpb24gKHBvcnQgMikgd2l0 aCB0d28gbGFiZWxzIGVhY2guIFRoZW4gd2Ugd291bGQgaGF2ZTogeygxLDEsMiwxKSwgKDEsMSwy LDIpLCAoMSwyLDIsMSksICgxLDIsMiwyKX0gSSB0aGluayB3aXRoIHRoZSBjdXJyZW50IHN0YXRl bWVudCwgd2UgY2FuIHNlbmQgdGhpcyBpbmZvIGluIGFueSBjb21iaW5hdGlvbiBvZiBtdWx0aXBs ZSBtYXRyaWNlcywgd2hpY2ggSSB0aGluayBwZXJmZWN0bHkgZmluZS4gV2l0aCB5b3VyIHN1Z2dl c3Rpb24sIEkgd291bGQgbm90IGJlIGFibGUgc2VuZCAoMSwxLDIsMSkgYW5kICgxLDEsMiwyKSB0 b2dldGhlci4gV2h5IHdvdWxkIHRoaXMgbm90IGJlIG1hZGUgcG9zc2libGU/IE15IHRha2UgaXMg YXMgbG9uZyBhcyBlYWNoIHN1Ym1hdHJpeCByZXByZXNlbnRzIGEgc2V0IG9mIGRpc2pvaW50IHF1 YWRydXBsZXMsIHRoYXQgc2hvdWxkIGJlIGFsbG93ZWQuIA0KDQozKSBJbiBzZWN0aW9uIDIuMSwg aXQgc2F5cyAiVGhlIHZhbHVlIG9mIDB4RkYgaXMgcmVzZXJ2ZWQgZm9yIHVzZSB3aXRoIHBvcnQg d2F2ZWxlbmd0aCBjb25zdHJhaW50cyIuIEkgdGhpbmsgInBvcnQgd2F2ZWxlbmd0aCBjb25zdHJh aW50cyIgc2hvdWxkIGJlICJwb3J0IGxhYmVsIHJlc3RyaWN0aW9uIi4NCg0KWU9VTkc+PiBZZXMs IHRoYW5rcy4gDQoNCjQpIEluIHNlY3Rpb24gMi4xLCBmb3IgTGluayBTZXQgQSBkaXI9YmlkaXJl Y3Rpb25hbCwgTGluayBTZXQgQiBkaXI9YmlkaXJlY3Rpb25hbCwgaWYgYW55IHNpZ25hbCBvbiBh biBpbnB1dCBsaW5rIFggaXMgb3V0cHV0IG9uIGEgbGluayBZLCB0aGVuIGFueSBzaWduYWwgb24g YW4gaW5wdXQgbGluayBZIGlzIG91dHB1dCBvbiBhIGxpbmsgWCAoYWZ0ZXIgY3Jvc3MtY29ubmVj dCk/IE9yIGFueSBjb25zdHJhaW50IG9uIHN1Y2ggc2lnbmFsIGZsb3cgKGFmdGVyIGNyb3NzLWNv bm5lY3QpIGlzIG91dCBvZiBzY29wZT8NCg0KWU9VTkc+PiBJIGFtIG5vdCBzdXJlIHdoYXQgImFm dGVyIGNyb3NzLWNvbm5lY3QiIGlzIG1lYW50LiANCg0KNSkgSW4gc2VjdGlvbiAyLjIuMSwgaXQg c2F5cyAiSW4gdGhpcyBjYXNlIHRoZSBhY2NvbXBhbnlpbmcgbGFiZWwgc2V0IGluZGljYXRlcyB0 aGUgbGFiZWxzIHBlcm1pdHRlZCBvbiB0aGUgcG9ydC4iIEkgdGhpbmsgInBvcnQiIHNob3VsZCBi ZSAicG9ydC9tYXRyaXgiLg0KDQpZT1VORz4+IFllcywgdGhhbmtzLiANCg0KNikgSW4gc2VjdGlv biAyLjIuMiwgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlc2NyaWJlIHRoZSB0eXBlIChlLmcuLCBp bnRlZ2VyKSBmb3IgTWF4TnVtQ2hhbm5lbHMuDQpUaGlzIGFsc28gYXBwbGllcyBmb3IgTWF4TGFi ZWxSYW5nZSAoaW4gc2VjdGlvbiAyLjIuMykgYW5kIE51bSBMYWJlbHMgKGluIHNlY3Rpb24gMi42 KS4NCg0KWU9VTkc+PiBPSy4gDQoNCjcpIEluIHNlY3Rpb24gMi42LCBpdCBzYXlzICJMYWJlbCBT ZXQgRmllbGQgaXMgdXNlZCB3aXRoaW4gdGhlIDxBdmFpbGFibGVMYWJlbHM+IG9yIHRoZSA8U2hh cmVkQmFja3VwTGFiZWxzPiIuIEJ1dCBJIHRoaW5rIExhYmVsIFNldCBGaWVsZCBpcyBhbHNvIHVz ZWQgd2l0aGluIFNJTVBMRV9MQUJFTCwgTEFCRUxfUkFOR0UgYW5kIFNJTVBMRV9MQUJFTCAmIENI QU5ORUxfQ09VTlQuDQoNCllPVU5HPj4gWWVzLCBpdCBpcyB1c2VkIGluIG11bHRpcGxlIHBsYWNl cy4gDQoNCkhvdyBhYm91dDoNCk9MRDogTGFiZWwgU2V0IEZpZWxkIGlzIHVzZWQgd2l0aGluIHRo ZSA8QXZhaWxhYmxlTGFiZWxzPiBvciB0aGUNCiAgIDxTaGFyZWRCYWNrdXBMYWJlbHM+LCB3aGlj aCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMi40LiBhbmQgMi41LiwNCiAgIHJlc3BlY3RpdmVseS4N Ck5FVzogTGFiZWwgU2V0IEZpZWxkIGlzIHVzZWQgd2l0aGluIHRoZSA8QXZhaWxhYmxlTGFiZWxz PiBvciB0aGUNCiAgIDxTaGFyZWRCYWNrdXBMYWJlbHM+LCB3aGljaCBpcyBkZWZpbmVkIGluIFNl Y3Rpb24gMi40LiBhbmQgMi41LiwNCiAgIHJlc3BlY3RpdmVseS4gSXQgaXMgYWxzbyB1c2VkIHdp dGhpbiB0aGUgPFNJTVBMRV9MQUJFTD4sIA0KICAgPExBQkVMX1JBTkdFPiwgPFNJTVBMRV9MQUJF TD4gb3IgPENIQU5ORUxfQ09VTlQ+LCB3aGljaCBpcyBkZWZpbmVkDQogICBpbiBTZWN0aW9ucyAy LjEuMSAtIDIuMS40LCByZXNwZWN0aXZlbHkuIA0KDQoNClRoYW5rcywNClRvbW9ub3JpDQo= From nobody Wed Jan 21 12:59:05 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 D216A1A8839 for ; Wed, 21 Jan 2015 12:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.978 X-Spam-Level: X-Spam-Status: No, score=-97.978 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_SLUT=2.522, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 B0zmVQecSIYO for ; Wed, 21 Jan 2015 12:58:59 -0800 (PST) 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 E79F31A8830 for ; Wed, 21 Jan 2015 12:58:58 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LKvxn7002976; Wed, 21 Jan 2015 20:58:00 GMT Received: from 950129200 (089144198240.atnat0007.highway.a1.net [89.144.198.240]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LKvvEH002967 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 20:57:58 GMT From: "Adrian Farrel" To: "'Leeyoung'" , References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> Date: Wed, 21 Jan 2015 20:57:56 -0000 Message-ID: <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQJ3wIujnPuGDVA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21272.002 X-TM-AS-Result: No--15.477-10.0-31-10 X-imss-scan-details: No--15.477-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wrmR+C0l9vjV8GRhP/nTHNbYWrp179pohj0J SifQ1MZ5roveI71hB0Qjk/kPI8DPx05GqmwdJt7C6vGX8vR+hqjiXOoSlo9AtYJMlS+kMGbc0xj TQ8V5r3Fs9C4m/Ueo/d+Jza/a9teag+QbvWfvu8i8coKUcaOOve8lj2kHOCDUidYwmfMI8uBBD+ z28Qkmd+17CrIRoHb2BupkzfMOQXS/JxRBHWTApiArD+K6XhnH9xIiieITJaiynk7TnYzMuvJvf lJl1oGsw/UdL9EcJmaOVKjw5IrenybZZYAQu9H5y7TSWcbz49b4uJ1REX4MHX3hz57t9YhwAy7F ge6wFlu91njNIDBTO5LC6W0yRmUXw96zDQifY+gIVoCLGbl5T0GtrAxy5ENO9WxlDvtT3Nz+1Hn niUzVLbe0s3JW76HN8TxBP2FxIFbcx97ZZVZcMuLdprnA5EQR2LfeG0uDflTNpr24oOS4xpYnOA NpMjh38bJb0aNG//+3LXha6kS5H3LoyH4Gm9PGACs2C3nGlBh+K68qL2G5phxUkJPe1WBq4vbk6 0X83gCCpWo1JYSZWlmEt4PHleWrtSRDUDvza5OQTsyupo9izR6InYiNINGdBoA1fKObuhMcaYAs 8/F61zt5/UisYj5O7QHRY5U6Rkdu6WKkJ3C7LDLRY601LrakY9JlLwL1dg3a+IH8mvgPVJvgUg7 gsdlOjFXb0YkfwXv4lJQPIqA7oMPXVOccBDU9iFoorQjboWnGdQx1K0CtmVmmz7LVVfOpGfrX8m YF7oeOr9X/y8WA5URZ83DrGmyHKEVn4TCGPMCeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtwcipXRZMawu5a5XvBUru6kEtJLs9rWW9/f0lFVz5KSJwxxkR8eEZ9g== Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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: Wed, 21 Jan 2015 20:59:03 -0000 Hi, Thanks for the response. Many of the points you said "YES" and I have edit them out. You can fold the changes into a new revision. Further discussion below. > My comment for general vs. WSON-specific issue is that the design philosophy > of general encoding was to generalize a common element that can be applied > to different technologies. For instance, connectivity matrix definitely can be > applied to WSON, OTN and other Switching technology as one encoding can > fit to all. You seemed to desire a sharing of the same encoding to describe > different entities where possible. This is fine for label vs. wavelength as there > is one-to-one mapping for this. However, Resource Block encoding cannot > properly share with the connectivity matrix encoding with two reasons: > > 1. They refer to different elements in the node. > 2. They require different sets of fields with different number of fields. > > Please also see my comment in-line for details. > >> I've now done my AD review of this document. I am rather regretting >> starting the IETF last call for draft-ietf-ccamp-general-constraint- >> encode on which this document depends because it seems that this >> document introduces WSON-specific encodings (all of those before >> Section 4) that should/could have been made generic. In fact, I >> thought the point of the general encodings document was to produce >> protocol objects that could be used by technology-specific documents >> like this one. >> =========== >> > Section 2.1 seems somewhere between a copy of and a modification of > the Link Set Field in 2.3 of [Gen-Encode]. > > Some clarification would be useful. If this is different, why is it not > using one of the generic encodings applied in a specific way? If it is > the same, you should probably just reference the encoding in > [Gen-Encode] and describe here how the fields are used, but if you > insist in re-drawing the figure it should be aligned with the figure in > [Gen-Encode]. > > [YOUNG] not quite. Link Set and Label Set are two different things with different > fields. > Link Set has directionality and identifier format while Label Set does not have > these fields but has connectivity field. > Not sure how we can point to each other. First, I'm not sure why you bring label set in here since 2.1 is about "resource block set". This sent me back to rwa-info to see what the definition of a resource block is. Since resources tend to be packaged together in blocks of similar devices, e.g., on line cards or other types of modules, the fundamental unit of identifiable resource in this document is the "resource block". A resource block may contain one or more resources. A resource is the smallest identifiable unit of processing allocation. One can group together resources into blocks if they have similar characteristics relevant to the optical system being modeled, e.g., processing properties, accessibility, etc. Hmmm, now I spot another issue with this I-D. If a resource block is the fundamental unit of identifiable resource, how come it contains smaller identifiable units (i.e. resources)? That is a bit confusing. Sigh. Anyway, in section 2.1 of this document you define the RB set to be a collection of Resource Block identifiers. Maybe it would have helped me understand had you said (somewhere) specifically what a resource is in the RWA/WSON context. rwa-info suggests "resources such as regenerators or wavelength converters" and I am unclear whether this is exactly what you mean in every further use of "resource". And the concept of a resource block is also poorly introduced. If it is merely a collection of resources, that would be good to say. And if the resource block identifier is an arbitrary identifier assigned to this collection of resources with no more than a local semantics, then you could say so (and possibly explain how advertising resource block identifiers can be of any use to anyone else because they won't know what the resource block represents - I don't see any advertisement of "this resource block contains the following resources"). I think what you are saying by mentioning "label set" in your reply is that a resource block is a set of things that can be labeled. That is certainly how I interpreted it. And I thought - surely you can label things in any technology, so there ought to be a general encoding for a resource block. Of course, there is label set and link set in general-constraint-encode. But neither looks much like the RB set in this document. You're probably right that link set would be the wrong thing for RB set to try to look like (although links are switchable/labelled quantities, too), but label set doesn't look like the RB set you have here. Which brings me back to my main question.... What is it about a WSON RB set that makes it something that is not generalised? I don't see anything in the description of RB set or RBs themselves that makes them specific to WSON (possibly because there is so little description of a resource or a resource block in any of the documents!). >> Section 2.1 >> >> The RB identifier represents the ID of the resource block which is a >> 32 bit integer. >> >> You might note that the scope of the RB identifier is local to the node >> on which it is applied although that node may choose to use a globally >> known encoding such as from RFC 6205. >> >> I assume that flexi-grid is out of scope for WSON. If it is not, then >> you need to think further about your 32 bit identifiers. > > [YOUNG] Flex-grid is out of scope here. OK > In addition, RB identifier is a resource > block ID Which is different from wavelength identifier. I am sure how a globally > known encoding for Wavelength id can be used for RB identifier. They seemed > to refer two different entities. OK. I now understand that a resource block is NOT the fundamental unit of resource that rwa-info claims it to be. So a resource block is a collection of one or more wavelengths (resources) and the resource block identifier is an arbitrary identifier for that block of resources. As I asked above, when you advertise RB ID 1 to me, how do I know which resources you are referring to? >> Section 3.1 >> >> Why isn't the Resource Accessibility Field expressed in terms of the >> use of a generic Connectivity Matrix Field from section 2.1 of >> [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive >> application agnostic encodings that could be used without modification >> (but with applicability notes) by specific technologies. > > [YOUNG] Not quite. Connectivity Matrix encoding cannot be used for Resource > Accessibility Field as the latter > has additional entity (namely, RB set field) to describe. We generalized a single- > stage connectivity matrix in [Gen-Encode] that can > be applicable to any switching technology. Here in WSON, we have a need to > model RB constraints (for the pool of Wavelength Converters) > from/to input/output link sets. Putting two different entities into one coding was > not the choice of the authors. I don't understand. You say that the generalized single-stage connectivity matrix can be applicable to any switching technology and then you don't use it for WSON saying that you need other constraints as well. Are you, in fact, saying that the generalized single-stage connectivity matrix is not applicable to WSON? >> Section 3.2 >> >> I looked for the equivalent of the Resource Wavelength Constraints >> Field in [Gen-Encode]. I understand that Input Wavelength Constraints >> Field and Output Wavelength Constraints Field are encoded using the >> generic Label Set of [Gen-Encode], but I thought that the whole concept >> of Resource Constraints would be generic. > > [YOUNG] Again, I think the design of generalization is not intended to > share the same encoding to describe two different entities. Besides, I do > not see the need to generalize encoding of an entity that has no particular > use in other technologies than WSON. I think the point of generalization is to come up with an encoding that can be re-used in different witching environments. Obviously, the only environment with wavelength is WSON. But all switching environments have labels that are switched, and have constraints applicable to those labels and to the ability to switch the labels. Suppose I wrote: Resources, such as switches and filters, may have limited input or output label ranges. Additionally, due to the structure of the switches not all labels can necessarily reach or leave all the resources. These properties are described by using one or more resource restrictions fields as defined below: That is just a rewrite of 3.2 in general terms and seems to not be a problem. Indeed, if general-constraint-encode had had... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|O|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RB Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Label Constraints | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Label Constraints | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...then I would have thought it a perfect fit. > Section 3.3 > > As with the previous section I don't see anything that is WSON-specific > in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field > and I wondered why [Gen-Encode] doesn't have anything to cover this. > > [YOUNG] RB is wavelength converters, which is a unique WSON element. No! You might as well say that a lambda is a unique WSON concept and so cannot re-use the generic concept of the LABEL object. Isn't a "wavelength converter" just a special case of a label switch? That is certainly how I read RFC 6163 Wavelength converters take an input optical signal at one wavelength and emit an equivalent content optical signal at another wavelength on output. I think you are just not stepping back far enough to see the concept of "generalization." >> Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? > > [YOUNG] I think the reason for B bit is not included in Section 3.4 is the context > where it won't be very useful (even if we have a B bit) as input wavelengths > available will hardly match with output wavelength available in most cases. > Compared to this, wavelength constraints can more often be same for input and > output. This isn't very convincing. "in most cases" suggests sometimes it will. Are you saying the use of one extra bit outweighs the saving in encoding in the rare cases where that bit could be used? You didn't comment about section 4. >> Section 4 >> >> How do I know the length of the ResourceBlockInfo field? I need to know >> this to decide whether to try to parse the next bytes as another >> Optional subfield. I *do* when I reach the end of one Optional subfield, >> but I don't know whether another follows. >> >> Possibly you intend the object that includes a ResourceBlockInfo field >> to provide the length information, but other fields defined in this >> document do include lengths or enough information to deduce the lengths. > > [YOUNG] Yes, you're right. It is not completely consistent. How about the > following > Encoding: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I|O| Reserved | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set Field | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional subfield 1 | > : ... : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : : > : : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional subfield N | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OK, that would be effective. How does that fit with your implementation? And is this a big enough change to require returning to the working group? >> Section 4.1 >> How do I interpret a Vendor-Specific Application Code? Is there an OUI >> I'm missing? > > [YOUNG] Not sure if I understood this question. What is "OUI"? http://en.wikipedia.org/wiki/Organizationally_unique_identifier http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802 -numbers-2 Or perhaps an Enterprise Number http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers The question is: You have sections 4.1.1 through 4.1.4 to tell me how to interpret the Optical Interface Class field when it contains an ITU-T Application Mapping. When I received s=0 and OI=1 it means that the Optical Interface Class contains a "Vendor Specific Optical Interface Class". How do I interpret that Optical Interface Class? Which vendor does it apply to? Is there some information elsewhere that gives me a clue as to which vendor has encoded the information? Or is the information supposed to be encoded in the Optical Interface Class, perhaps as the first 48 bits? Or am I supposed to know by context? >> I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and >> have asked the chairs to send a liaison to ITU-T Q6/15 asking them to >> cast an eye over the text of these sections. > > [YOUNG] Thanks. It is a good idea to send a liaison to Q6/15. Great. That has now been sent and we'll see what happens. >> 4.1.1 and 4.1.2 >> >> An Optional F can be added indicating a FEC Encoding. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |B| D |S| c | W | y | t | z | v | F | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> F (suffix): = 0 reserved, = 1 Fec Encoding >> >> Values not mentioned here are not allowed in this application >> code >> >> If F is optional but only one value is allowed (viz. 1) how do I opt to >> not indicate a FEC Encoding? > > [YOUNG] I guess 0 will do it. But I can't set zero because it is reserved. Thanks, Adrian From nobody Wed Jan 21 13:22:05 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 33EC81A887E for ; Wed, 21 Jan 2015 13:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 PbaSezX1fAfs for ; Wed, 21 Jan 2015 13:22:01 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D1B1A887A for ; Wed, 21 Jan 2015 13:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2039; q=dns/txt; s=iport; t=1421875321; x=1423084921; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c0y5nWqg7ua3jSjz/kKan0ONhcEWq6U6tERe7YbXBgs=; b=by4FWfZ8Gh7IO/kEBHipa3WVNI0Qs/znoeSyLePjRMbfO3xJGhlGjhxE Ahi6D/WOnVdMmmSe2Gfv4zoj9zfCuRq9voQOmdUYPILDHV8Z62TpiyS2B DCqv4zeSrBCByQ50eLLjwoHr1YCiY0c/dXRYuOhFSm5RsamyIqjsCRKIj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFAJYXwFStJV2Z/2dsb2JhbABbgwZSWAEDw3aCJ4VvAoEoQwEBAQEBfYQNAQEEeRACAQhGMiUCBA4FCYgjDdJwAQEBAQEBAQEBAQEBAQEBAQEBARmPRjMHgxaBEwWOWYNHhVCSKiKDbm8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,444,1418083200"; d="scan'208";a="116121342" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 21 Jan 2015 21:22:00 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0LLM0C6027683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 21:22:00 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 15:22:00 -0600 From: "Giovanni Martinelli (giomarti)" To: "adrian@olddog.co.uk" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQJ3wIujnPuGDVCAAJV6gA== Date: Wed, 21 Jan 2015 21:21:59 +0000 Message-ID: <4B704AAD-ED2D-4688-9283-F2ACBFB27554@cisco.com> References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> In-Reply-To: <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.213.6] Content-Type: text/plain; charset="Windows-1252" Content-ID: <832149BD647D8D43A8B5650ACFE40AD5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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, 21 Jan 2015 21:22:03 -0000 Specifically to the Interface class here below=85=20 In the initial draft merged to this one there was the usage of OUI however = (I guess after chatting with Lou) we decided to remove any encoding when th= e Interface class is not standard.=20 In term of semantic the protcol does not need to decode the Interface class= since it only assess the interface compatibility if two interfaces has a c= lass value that match two interfaces cann be connected. =20 Having saying that I don=92t have strong opinion in adding the OUI or leavi= ng room for maybe future public interfaces database. For sure there=92s a n= eed to leave room for specific compatibility assesment since there optical = multivendor compatibility has been already demonstrated.=20 hope this help =85 Cheers G On 21 Jan 2015, at 21:57, Adrian Farrel wrote: >>>=20 >>> Section 4.1 >>> How do I interpret a Vendor-Specific Application Code? Is there an OUI >>> I'm missing? >>=20 >> [YOUNG] Not sure if I understood this question. What is "OUI"? >=20 > http://en.wikipedia.org/wiki/Organizationally_unique_identifier > http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#i= eee-802 > -numbers-2 >=20 > Or perhaps an Enterprise Number > http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers >=20 > The question is: >=20 > You have sections 4.1.1 through 4.1.4 to tell me how to interpret the Opt= ical > Interface Class field when it contains an ITU-T Application Mapping. > When I received s=3D0 and OI=3D1 it means that the Optical Interface Clas= s contains > a "Vendor Specific Optical Interface Class". > How do I interpret that Optical Interface Class? > Which vendor does it apply to? > Is there some information elsewhere that gives me a clue as to which vend= or has > encoded the information? > Or is the information supposed to be encoded in the Optical Interface Cla= ss, > perhaps as the first 48 bits? > Or am I supposed to know by context? From nobody Wed Jan 21 13:55:39 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 0FC421A0041 for ; Wed, 21 Jan 2015 13:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 dxWu78hXVQp7 for ; Wed, 21 Jan 2015 13:55:31 -0800 (PST) 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 DA3C11A0026 for ; Wed, 21 Jan 2015 13:55:30 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LLtKcw028631; Wed, 21 Jan 2015 21:55:20 GMT Received: from 950129200 (089144198240.atnat0007.highway.a1.net [89.144.198.240]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0LLtHEX028620 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 21:55:19 GMT From: "Adrian Farrel" To: "'Giovanni Martinelli \(giomarti\)'" References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> <4B704AAD-ED2D-4688-9283-F2ACBFB27554@cisco.com> In-Reply-To: <4B704AAD-ED2D-4688-9283-F2ACBFB27554@cisco.com> Date: Wed, 21 Jan 2015 21:55:16 -0000 Message-ID: <033301d035c4$f2717b90$d75472b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQJ3wIujAyk0V7MB8PVN4ZzS7emQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21272.003 X-TM-AS-Result: No--22.979-10.0-31-10 X-imss-scan-details: No--22.979-10.0-31-10 X-TMASE-MatchedRID: byfwvk+IcRmwzFuyya2WsEKcYi5Qw/RVlnrMq7Sriu3E3grQNcpLWNoz beODnXpl5HnfFFKR5dwGRoT1tahRf7SHbPtwt+RfSDkh6bW+bccmln3AceenB9p1biJhIyNRXa2 +zE1cP+VSXntx713VaDpBc5uTSHW+Y+VfsshMgK30hv/rD7WVZA/LU+XiHL1tD4y1CC6G7fjUdt HM7EKWR/prHKq2ATP4CjTy2qbL4Du5HsA8a/n6iKMVgdN9w+TCj/xLIaDSshEjJTYshMkID9Uwy rj5CivytOixgOjnHf1nklUsX189YkLMcWGLKmhWaK+MsTwM+1me7AJyCqdN8FUSdDbvVFxS0TD6 UetkoeX1x6IKVdulMwA1CHMkDy6fYqmUd3tOErWeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47gYq/Q JOAA07Y2j49Ftap9EkGUtrowrXLg= Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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: Wed, 21 Jan 2015 21:55:35 -0000 Hi, Well, you seem to have a half-way house. You have specified the existence of a thing, but not how to read it. If you wanted to make a statement that this object will only be used when it is known that all systems in a network come from the same vendor and/or have the same understanding of the encoding, that might be OK (although how you would ascertain this might also need to be described). Or you could entirely remove the vendor-specific option. Or you could put in an OUI / enterprise number followed by transparent bytes. Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 21 January 2015 21:22 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > Specifically to the Interface class here below. > > In the initial draft merged to this one there was the usage of OUI however (I > guess after chatting with Lou) we decided to remove any encoding when the > Interface class is not standard. > In term of semantic the protcol does not need to decode the Interface class since > it only assess the interface compatibility if two interfaces has a class value that > match two interfaces cann be connected. > > Having saying that I don't have strong opinion in adding the OUI or leaving room > for maybe future public interfaces database. For sure there's a need to leave > room for specific compatibility assesment since there optical multivendor > compatibility has been already demonstrated. > > hope this help . > > Cheers > G > > > On 21 Jan 2015, at 21:57, Adrian Farrel wrote: > > >>> > >>> Section 4.1 > >>> How do I interpret a Vendor-Specific Application Code? Is there an OUI > >>> I'm missing? > >> > >> [YOUNG] Not sure if I understood this question. What is "OUI"? > > > > http://en.wikipedia.org/wiki/Organizationally_unique_identifier > > http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > numbers.xhtml#ieee-802 > > -numbers-2 > > > > Or perhaps an Enterprise Number > > http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers > > > > The question is: > > > > You have sections 4.1.1 through 4.1.4 to tell me how to interpret the Optical > > Interface Class field when it contains an ITU-T Application Mapping. > > When I received s=0 and OI=1 it means that the Optical Interface Class contains > > a "Vendor Specific Optical Interface Class". > > How do I interpret that Optical Interface Class? > > Which vendor does it apply to? > > Is there some information elsewhere that gives me a clue as to which vendor > has > > encoded the information? > > Or is the information supposed to be encoded in the Optical Interface Class, > > perhaps as the first 48 bits? > > Or am I supposed to know by context? From nobody Wed Jan 21 14:58: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 3A2471A1A14 for ; Wed, 21 Jan 2015 14:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_SLUT=2.522, 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=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 uWbjgF_gcvZf for ; Wed, 21 Jan 2015 14:58:20 -0800 (PST) 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 7A48B1A0025 for ; Wed, 21 Jan 2015 14:58:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOH25097; Wed, 21 Jan 2015 22:58:17 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 21 Jan 2015 22:58:16 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 21 Jan 2015 14:58:03 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Thread-Index: AdAmyKqM3E2i5eP+S/KXayUoWZed4QFfHtywAm61lQAAEBoNkA== Date: Wed, 21 Jan 2015 22:58:02 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7DA1A@dfweml706-chm> References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> In-Reply-To: <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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, 21 Jan 2015 22:58:25 -0000 Hi Adrian, Thanks for your thorough comment here.=20 I am not sure if my response would satisfy all your concerns/questions, esp= ecially the discussion on generalized vs. WSON-specific issues. But I belie= ve there was some misunderstanding as to the definition of Resource Blocks = and how to identify them in the advertisement.=20 Please see inline for my comment.=20 Regards, Young=20 -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Wednesday, January 21, 2015 2:58 PM To: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Hi, Thanks for the response. Many of the points you said "YES" and I have edit them out. You can fold th= e changes into a new revision. YOUNG>> OK.=20 Further discussion below. > My comment for general vs. WSON-specific issue is that the design philos= ophy > of general encoding was to generalize a common element that can be applie= d > to different technologies. For instance, connectivity matrix definitely c= an be > applied to WSON, OTN and other Switching technology as one encoding can > fit to all. You seemed to desire a sharing of the same encoding to descri= be > different entities where possible. This is fine for label vs. wavelength = as there > is one-to-one mapping for this. However, Resource Block encoding cannot > properly share with the connectivity matrix encoding with two reasons: >=20 > 1. They refer to different elements in the node. > 2. They require different sets of fields with different number of fields. >=20 > Please also see my comment in-line for details. >=20 >> I've now done my AD review of this document. I am rather regretting >> starting the IETF last call for draft-ietf-ccamp-general-constraint- >> encode on which this document depends because it seems that this >> document introduces WSON-specific encodings (all of those before >> Section 4) that should/could have been made generic. In fact, I >> thought the point of the general encodings document was to produce >> protocol objects that could be used by technology-specific documents >> like this one. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 > Section 2.1 seems somewhere between a copy of and a modification of > the Link Set Field in 2.3 of [Gen-Encode]. >=20 > Some clarification would be useful. If this is different, why is it not > using one of the generic encodings applied in a specific way? If it is > the same, you should probably just reference the encoding in > [Gen-Encode] and describe here how the fields are used, but if you > insist in re-drawing the figure it should be aligned with the figure in > [Gen-Encode]. >=20 > [YOUNG] not quite. Link Set and Label Set are two different things with different > fields. > Link Set has directionality and identifier format while Label Set does no= t have > these fields but has connectivity field. > Not sure how we can point to each other. First, I'm not sure why you bring label set in here since 2.1 is about "res= ource block set". YOUNG>> My bad. I think I was mixed up. My point probably was comparing RB = Set Field with Link Set Field with different fields --- It would be hard to= have one encoding to describe two different elements. =20 This sent me back to rwa-info to see what the definition of a resource bloc= k is. Since resources tend to be packaged together in blocks of similar devices, e.g., on line cards or other types of modules, the fundamental unit of identifiable resource in this document is the "resource block". A resource block may contain one or more resources. A resource is the smallest identifiable unit of processing allocation. One can group together resources into blocks if they have similar characteristics relevant to the optical system being modeled, e.g., processing properties, accessibility, etc. Hmmm, now I spot another issue with this I-D. If a resource block is the fundamental unit of identifiable resource, how c= ome it contains smaller identifiable units (i.e. resources)? That is a bit confusing. Sigh. Anyway, in section 2.1 of this document you define the RB set to be a colle= ction of Resource Block identifiers. Maybe it would have helped me understand had= you said (somewhere) specifically what a resource is in the RWA/WSON context. rwa-info suggests "resources such as regenerators or wavelength converters"= and I am unclear whether this is exactly what you mean in every further use of "resource". YOUNG>> Yes, resources meant regenerators/wavelength converters.=20 And the concept of a resource block is also poorly introduced. If it is mer= ely a collection of resources, that would be good to say. And if the resource blo= ck identifier is an arbitrary identifier assigned to this collection of resour= ces with no more than a local semantics, then you could say so (and possibly ex= plain how advertising resource block identifiers can be of any use to anyone else because they won't know what the resource block represents - I don't see an= y advertisement of "this resource block contains the following resources"). I think what you are saying by mentioning "label set" in your reply is that= a resource block is a set of things that can be labeled. That is certainly ho= w I interpreted it. And I thought - surely you can label things in any technolo= gy, so there ought to be a general encoding for a resource block. Of course, there is label set and link set in general-constraint-encode. Bu= t neither looks much like the RB set in this document. You're probably right = that link set would be the wrong thing for RB set to try to look like (although = links are switchable/labelled quantities, too), but label set doesn't look like t= he RB set you have here. Which brings me back to my main question.... What is it about a WSON RB set that makes it something that is not generali= sed? I don't see anything in the description of RB set or RBs themselves that ma= kes them specific to WSON (possibly because there is so little description of a resource or a resource block in any of the documents!). YOUNG>> How about the figure 1 in Appendix A.1, I think it should have been= labeled as "RB Pool" instead of WC Pool. I will change "WC" to "RB" and po= int to this figure from Section 2.1 and Section 3.2 where RB Set is explain= ed in the context of Resource Pool.=20 >> Section 2.1 >>=20 >> The RB identifier represents the ID of the resource block which is a >> 32 bit integer. >>=20 >> You might note that the scope of the RB identifier is local to the node >> on which it is applied although that node may choose to use a globally >> known encoding such as from RFC 6205. >>=20 >> I assume that flexi-grid is out of scope for WSON. If it is not, then >> you need to think further about your 32 bit identifiers. >=20 > [YOUNG] Flex-grid is out of scope here. OK > In addition, RB identifier is a resource > block ID Which is different from wavelength identifier. I am sure how a globally > known encoding for Wavelength id can be used for RB identifier. They seem= ed > to refer two different entities. OK. I now understand that a resource block is NOT the fundamental unit of resource that rwa-info claims it to be. So a resource block is a collection= of one or more wavelengths (resources) and the resource block identifier is an arbitrary identifier for that block of resources. As I asked above, when you advertise RB ID 1 to me, how do I know which resources you are referring to? YOUNG>> In Section 3.1 Resource Accessibility Field is defined and encoded = as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Reserved(8bits)|C| Reserved (23 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Link Set Field A #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RB Set Field A #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Link set and RB set pairs as needed to | : specify PoolInputMatrix : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Link Set Field B #1 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RB Set B Field #1 (for output connectivity) | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Link Set and RB set pairs as needed to | : specify PoolOutputMatrix : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RB Set Field defines the RD ID's and Input/Output Link Sets are associated = with RB ID's.=20 See Appendix A.1, Figure 1 which explains the association of Link Sets with= RB blocks including RB ID's.=20 +-----+ +-----+ | 1 1 | | 1 0 | WI =3D| |, WE =3D| | | 1 1 | | 0 1 | +-----+ +-----+ +-----------+ +------+ | |--------------------->| | | |--------------------->| C | /| | |--------------------->| o | /D+--->| |--------------------->| m | + e+--->| | | b |=3D=3D=3D=3D= =3D=3D=3D> =3D=3D=3D=3D=3D=3D=3D=3D>| M| | Optical | +-----------+ | i= | Port O1 Port I1 + u+--->| Switch | | WC Pool | | n | \x+--->| | | +-----+ | | e | \| | +----+->|WC #1|--+---->| r | | | | +-----+ | +------+ | | | | +------+ /| | | | +-----+ | | | /D+--->| +----+->|WC #2|--+---->| C | + e+--->| | | +-----+ | | o | =3D=3D=3D=3D=3D=3D=3D=3D>| M| | | +-----------+ | m= |=3D=3D=3D=3D=3D=3D=3D> Port I2 + u+--->| | | b | Port O2 \x+--->| |--------------------->| i | \| | |--------------------->| n | | |--------------------->| e | | |--------------------->| r | +-----------+ +------+ Figure 1 An optical switch featuring a shared per fiber wavelength converter pool architecture. >> Section 3.1 >>=20 >> Why isn't the Resource Accessibility Field expressed in terms of the >> use of a generic Connectivity Matrix Field from section 2.1 of >> [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive >> application agnostic encodings that could be used without modification >> (but with applicability notes) by specific technologies. >=20 > [YOUNG] Not quite. Connectivity Matrix encoding cannot be used for Resour= ce > Accessibility Field as the latter > has additional entity (namely, RB set field) to describe. We generalized = a single- > stage connectivity matrix in [Gen-Encode] that can > be applicable to any switching technology. Here in WSON, we have a need t= o > model RB constraints (for the pool of Wavelength Converters) > from/to input/output link sets. Putting two different entities into one c= oding was > not the choice of the authors. I don't understand. You say that the generalized single-stage connectivity matrix can be applic= able to any switching technology and then you don't use it for WSON saying that = you need other constraints as well. Are you, in fact, saying that the generalized single-stage connectivity mat= rix is not applicable to WSON? YOUNG>> No that is not what I am saying. WSON uses both the connectivity ma= trix and the RB. The RB is only unique for WSON element.=20 >> Section 3.2 >>=20 >> I looked for the equivalent of the Resource Wavelength Constraints >> Field in [Gen-Encode]. I understand that Input Wavelength Constraints >> Field and Output Wavelength Constraints Field are encoded using the >> generic Label Set of [Gen-Encode], but I thought that the whole concept >> of Resource Constraints would be generic. >=20 > [YOUNG] Again, I think the design of generalization is not intended to > share the same encoding to describe two different entities. Besides, I do > not see the need to generalize encoding of an entity that has no particul= ar > use in other technologies than WSON. I think the point of generalization is to come up with an encoding that can= be re-used in different witching environments. Obviously, the only environment with wavelength is WSON. But all switching environments have labels that are switched, and have constraints applicable= to those labels and to the ability to switch the labels. Suppose I wrote: Resources, such as switches and filters, may have limited input or output label ranges. Additionally, due to the structure of the switches not all labels can necessarily reach or leave all the resources. These properties are described by using one or more resource restrictions fields as defined below: That is just a rewrite of 3.2 in general terms and seems to not be a proble= m. Indeed, if general-constraint-encode had had... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|O|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | RB Set Field | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Label Constraints | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Label Constraints | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...then I would have thought it a perfect fit. > Section 3.3 >=20 > As with the previous section I don't see anything that is WSON-specific > in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field > and I wondered why [Gen-Encode] doesn't have anything to cover this. >=20 > [YOUNG] RB is wavelength converters, which is a unique WSON element. No! You might as well say that a lambda is a unique WSON concept and so cannot re-use the generic concept of the LABEL object. Isn't a "wavelength converter" just a special case of a label switch? That = is certainly how I read RFC 6163 Wavelength converters take an input optical signal at one wavelength and emit an equivalent content optical signal at another wavelength on output. I think you are just not stepping back far enough to see the concept of "generalization." YOUNG>> As the figure 1 from Appendix A, WC's are additional element on top= of a label switch. I still think it is a unique WSON element which may not= be relevant to Generic label switch paradigm. =20 >> Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? >=20 > [YOUNG] I think the reason for B bit is not included in Section 3.4 is th= e context > where it won't be very useful (even if we have a B bit) as input waveleng= ths > available will hardly match with output wavelength available in most case= s. > Compared to this, wavelength constraints can more often be same for input= and > output. This isn't very convincing. "in most cases" suggests sometimes it will. Are you saying the use of one extra bit outweighs the saving in encoding in= the rare cases where that bit could be used? YOUNG>> I can add B bit if you think it must be there in Sections 3.4 and 4= .=20 You didn't comment about section 4. >> Section 4 >>=20 >> How do I know the length of the ResourceBlockInfo field? I need to know >> this to decide whether to try to parse the next bytes as another >> Optional subfield. I *do* when I reach the end of one Optional subfield, >> but I don't know whether another follows. >>=20 >> Possibly you intend the object that includes a ResourceBlockInfo field >> to provide the length information, but other fields defined in this >> document do include lengths or enough information to deduce the lengths. >=20 > [YOUNG] Yes, you're right. It is not completely consistent. How about the > following > Encoding: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I|O| Reserved | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set Field | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional subfield 1 | > : ... : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : : > : : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional subfield N | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OK, that would be effective. How does that fit with your implementation? And is this a big enough change to require returning to the working group? YOUNG>> The object that includes a ResourceBlockInfo field provides the len= gth info.=20 I grant however there is inconsistency here. Not sure what is the best. Per= haps, effectiveness may be sacrificed unless things are broken.=20 >> Section 4.1 >> How do I interpret a Vendor-Specific Application Code? Is there an OUI >> I'm missing? >=20 > [YOUNG] Not sure if I understood this question. What is "OUI"? http://en.wikipedia.org/wiki/Organizationally_unique_identifier http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#iee= e-802 -numbers-2 Or perhaps an Enterprise Number http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers The question is: You have sections 4.1.1 through 4.1.4 to tell me how to interpret the Optic= al Interface Class field when it contains an ITU-T Application Mapping. When I received s=3D0 and OI=3D1 it means that the Optical Interface Class = contains a "Vendor Specific Optical Interface Class". How do I interpret that Optical Interface Class? Which vendor does it apply to? Is there some information elsewhere that gives me a clue as to which vendor= has encoded the information? Or is the information supposed to be encoded in the Optical Interface Class= , perhaps as the first 48 bits? Or am I supposed to know by context? YOUNG>> See Giovanni's email. =20 >> I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and >> have asked the chairs to send a liaison to ITU-T Q6/15 asking them to >> cast an eye over the text of these sections. >=20 > [YOUNG] Thanks. It is a good idea to send a liaison to Q6/15. Great. That has now been sent and we'll see what happens. >> 4.1.1 and 4.1.2 >>=20 >> An Optional F can be added indicating a FEC Encoding. >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |B| D |S| c | W | y | t | z | v | F | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> F (suffix): =3D 0 reserved, =3D 1 Fec Encoding >>=20 >> Values not mentioned here are not allowed in this application >> code >>=20 >> If F is optional but only one value is allowed (viz. 1) how do I opt to >> not indicate a FEC Encoding? >=20 > [YOUNG] I guess 0 will do it. But I can't set zero because it is reserved. [YOUNG] I can add "F bit not equal 1" implies a FEC Encoding is not include= d.=20 Thanks, Adrian From nobody Thu Jan 22 00:42: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 37D691A044D for ; Thu, 22 Jan 2015 00:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 vnu7SzV9jRHO for ; Thu, 22 Jan 2015 00:42:41 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6231E1A0545 for ; Thu, 22 Jan 2015 00:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4001; q=dns/txt; s=iport; t=1421916161; x=1423125761; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kNNve+RAjrjSGM0hNpIBNR8mAJq2lTfBDRxSFbVDKI8=; b=luXMkx9xV1WtspXgSgjW1OQprkWAMvQ3wkAKMn+WMjddhQWv2LaoFxVw rOoFB8JKddd3Pj/nnYcIGPF12rnCQswq9TviFHyCn7W7hZBb2I4SL3sku BDm8GGLeHS9sgeK2QdIuYT+2kELqWUAW4nFmVgvb95woD6xH6uvDUHzEy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsFALW2wFStJV2b/2dsb2JhbABagwZSWATEGoIlhXECgSFDAQEBAQF9hAwBAQEDAXkFBwQCAQgRBAEBAScHMhQJCAIEDgUJEogJCA3SGwEBAQEBAQEBAQEBAQEBAQEBAQEBARePRjMHBoMQgRMFjl2DR4VPgRSFP4teIoF/H4FQbwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,447,1418083200"; d="scan'208";a="389765004" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 22 Jan 2015 08:42:40 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t0M8gefV006711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Jan 2015 08:42:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 02:42:40 -0600 From: "Giovanni Martinelli (giomarti)" To: "adrian@olddog.co.uk" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQJ3wIujnPuGDVCAAJV6gIAACUwAgAC044A= Date: Thu, 22 Jan 2015 08:42:39 +0000 Message-ID: <4676494F-5FC1-4053-B9A7-0C665B6429CB@cisco.com> References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> <4B704AAD-ED2D-4688-9283-F2ACBFB27554@cisco.com> <033301d035c4$f2717b90$d75472b0$@olddog.co.uk> In-Reply-To: <033301d035c4$f2717b90$d75472b0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.212.153] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1B110BEDCF3A6C42BAC55ACB804F18AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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, 22 Jan 2015 08:42:43 -0000 Hi Adrian, On 21 Jan 2015, at 22:55, Adrian Farrel wrote: > Hi, >=20 > Well, you seem to have a half-way house. >=20 > You have specified the existence of a thing, but not how to read it. >=20 > If you wanted to make a statement that this object will only be used when= it is > known that all systems in a network come from the same vendor and/or have= the > same understanding of the encoding, that might be OK (although how you wo= uld > ascertain this might also need to be described). >=20 The statement is to ensure the interface compatibility without encoding all= the possible details and parameter that define an interface (e.g. modulati= on format, forward error correction etc.). This was the initial solution in= the draft then replaced by the interface class concept. The WSON (RWA-on= ly) has the requirement is to make sure two interface are compatible. This = requirement, imho, can be satisfy by a simple comparison which has a boolea= n result.=20 We end up then in the ITU application codes for the =93certified=94 (we=92= ll this is my term not 100% sure is the best one) compatibility where prope= r encoding is provided.=20 > Or you could entirely remove the vendor-specific option. >=20 > Or you could put in an OUI / enterprise number followed by transparent by= tes. >=20 To me I=92m perfectly fine with the second option.=20 Cheers G > Adrian >=20 >> -----Original Message----- >> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] >> Sent: 21 January 2015 21:22 >> To: adrian@olddog.co.uk >> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; >> ccamp@ietf.org; ccamp-chairs@tools.ietf.org >> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode >>=20 >> Specifically to the Interface class here below. >>=20 >> In the initial draft merged to this one there was the usage of OUI howev= er (I >> guess after chatting with Lou) we decided to remove any encoding when th= e >> Interface class is not standard. >> In term of semantic the protcol does not need to decode the Interface cl= ass > since >> it only assess the interface compatibility if two interfaces has a class= value > that >> match two interfaces cann be connected. >>=20 >> Having saying that I don't have strong opinion in adding the OUI or leav= ing > room >> for maybe future public interfaces database. For sure there's a need to = leave >> room for specific compatibility assesment since there optical multivendo= r >> compatibility has been already demonstrated. >>=20 >> hope this help . >>=20 >> Cheers >> G >>=20 >>=20 >> On 21 Jan 2015, at 21:57, Adrian Farrel wrote: >>=20 >>>>>=20 >>>>> Section 4.1 >>>>> How do I interpret a Vendor-Specific Application Code? Is there an OU= I >>>>> I'm missing? >>>>=20 >>>> [YOUNG] Not sure if I understood this question. What is "OUI"? >>>=20 >>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier >>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- >> numbers.xhtml#ieee-802 >>> -numbers-2 >>>=20 >>> Or perhaps an Enterprise Number >>> http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers >>>=20 >>> The question is: >>>=20 >>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret the > Optical >>> Interface Class field when it contains an ITU-T Application Mapping. >>> When I received s=3D0 and OI=3D1 it means that the Optical Interface Cl= ass > contains >>> a "Vendor Specific Optical Interface Class". >>> How do I interpret that Optical Interface Class? >>> Which vendor does it apply to? >>> Is there some information elsewhere that gives me a clue as to which ve= ndor >> has >>> encoded the information? >>> Or is the information supposed to be encoded in the Optical Interface C= lass, >>> perhaps as the first 48 bits? >>> Or am I supposed to know by context? >=20 From nobody Fri Jan 23 00:01: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 B94A71A8F50; Fri, 23 Jan 2015 00:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9MmizH-bVc4O; Fri, 23 Jan 2015 00:01:37 -0800 (PST) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id 61BB31A9007; Fri, 23 Jan 2015 00:01:34 -0800 (PST) Received: from c0042i0.coe.ntt.com (c0042i0.nc.agilit-hosting.com [10.18.161.11]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id 8C2CC1C5809C; Fri, 23 Jan 2015 17:01:33 +0900 (JST) Received: from C0040I0.coe.ntt.com (10.18.160.44) by c0042i0.coe.ntt.com (10.18.161.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 23 Jan 2015 17:01:27 +0900 Received: from C0010I0.coe.ntt.com ([169.254.2.243]) by C0040I0.coe.ntt.com ([10.18.160.44]) with mapi id 14.03.0181.006; Fri, 23 Jan 2015 17:01:32 +0900 From: Tomonori Takeda To: Leeyoung , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt Thread-Index: AQHQNDrfTzEBEMoZRkC5S21+tdrK7JzKHOCggAAnWACAAxi0wA== Date: Fri, 23 Jan 2015 08:01:32 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: leeyoung@huawei.com, rtg-ads@tools.ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org, ccamp@ietf.org, tomonori.takeda@ntt.com x-originating-ip: [10.18.84.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" , Tomonori Takeda Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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: Fri, 23 Jan 2015 08:01:42 -0000 SGkgWW91bmcsDQoNCk9LLCB0aGFua3MsDQoNClRvbW9ub3JpDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBMZWV5b3VuZyBbbWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb21dIA0K U2VudDogVGh1cnNkYXksIEphbnVhcnkgMjIsIDIwMTUgMjo0NCBBTQ0KVG86IFRvbW9ub3JpIFRh a2VkYe+8iOatpueUsOefpeWFuO+8iTsgTGVleW91bmc7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcN CkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3Ry YWludC1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnJzsgJ2NjYW1wQGlldGYub3JnJw0KU3ViamVj dDogUkU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwt Y29uc3RyYWludC1lbmNvZGUtMTYudHh0DQoNCkhpIFRvbW9ub3JpLA0KDQpUaGFua3MgZm9yIHlv dXIgY29tbWVudC4gUGxlYXNlIHNlZSBpbi1saW5lIGZvciBteSByZXNwb25zZS4gUGxlYXNlIGxl dCBtZSBrbm93IGlmIHRoZSByZXNwb25zZSB3b3VsZCBzYXRpc2Z5IHlvdS4gDQoNCkJlc3QgcmVn YXJkcywNCllvdW5nDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUb21vbm9y aSBUYWtlZGEgW21haWx0bzp0b21vbm9yaS50YWtlZGFAbnR0LmNvbV0gDQpTZW50OiBXZWRuZXNk YXksIEphbnVhcnkgMjEsIDIwMTUgMTI6NDggQU0NClRvOiBMZWV5b3VuZzsgcnRnLWFkc0B0b29s cy5pZXRmLm9yZw0KQ2M6ICdydGctZGlyQGlldGYub3JnJzsgJ2RyYWZ0LWlldGYtY2NhbXAtZ2Vu ZXJhbC1jb25zdHJhaW50LWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcnOyAnY2NhbXBAaWV0Zi5v cmcnOyBUb21vbm9yaSBUYWtlZGENClN1YmplY3Q6IFJFOiBbUlRHLURJUl0gUnRnRGlyIHJldmll dzogZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLTE2LnR4dA0KDQpI aSBZb3VuZywNCg0KVGhhbmtzLg0KDQpUd28gZm9sbG93LXVwIHF1ZXN0aW9ucy9jb21tZW50cy4N CihJIGFtIGZpbmUgd2l0aCBvdGhlciBwb2ludHMsIHdoaWNoIHlvdSBhbHJlYWR5IGFkZHJlc3Nl ZCBpbiB0aGUgdXBkYXRlZCBkcmFmdC4pDQoNCj4gMikgSW4gc2VjdGlvbiAyLjEsIGl0IHNheXMg InR3byBtYXRyaWNlcyB3aWxsIG5vdCBoYXZlIHRoZSBzYW1lIHtzcmMgcG9ydCwgc3JjIGxhYmVs LCBkc3QgcG9ydCwgZHN0IGxhYmVsfSIuIFRvIGJlIHByZWNpc2UsIEkgZ3Vlc3MgdGhpcyBzaG91 bGQgYmUgPiAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge3NyYyBwb3J0LCBz cmMgbGFiZWx9LCBhbmQgdHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge2RzdCBw b3J0LCBkc3QgbGFiZWx9Ij8NCj4gDQo+IFlPVU5HPj4gSSB0aGluayB5b3VyIHN1Z2dlc3Rpb24g bWF5IGJlIHRvbyByZXN0cmljdGl2ZS4gRm9yIGluc3RhbmNlLCBpZiB3ZSBoYXZlIG9uZSBzb3Vy Y2UgKHBvcnQgMSkgYW5kIG9uZSBkZXN0aW5hdGlvbiAocG9ydCAyKSB3aXRoIHR3byBsYWJlbHMg PiBlYWNoLiBUaGVuIHdlIHdvdWxkIGhhdmU6IHsoMSwxLDIsMSksICgxLDEsMiwyKSwgKDEsMiwy LDEpLCAoMSwyLDIsMil9IEkgdGhpbmsgd2l0aCB0aGUgY3VycmVudCBzdGF0ZW1lbnQsIHdlIGNh biBzZW5kIHRoaXMgaW5mbyBpbiBhbnkgY29tYmluYXRpb24gPiBvZiBtdWx0aXBsZSBtYXRyaWNl cywgd2hpY2ggSSB0aGluayBwZXJmZWN0bHkgZmluZS4gV2l0aCB5b3VyIHN1Z2dlc3Rpb24sIEkg d291bGQgbm90IGJlIGFibGUgc2VuZCAoMSwxLDIsMSkgYW5kICgxLDEsMiwyKSB0b2dldGhlci4g V2h5IHdvdWxkIHRoaXMgPiBub3QgYmUgbWFkZSBwb3NzaWJsZT8gTXkgdGFrZSBpcyBhcyBsb25n IGFzIGVhY2ggc3VibWF0cml4IHJlcHJlc2VudHMgYSBzZXQgb2YgZGlzam9pbnQgcXVhZHJ1cGxl cywgdGhhdCBzaG91bGQgYmUgYWxsb3dlZC4NCg0KTXkgcmVhZGluZyBvZiAidHdvIG1hdHJpY2Vz IHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge3NyYyBwb3J0LCBzcmMgbGFiZWwsIGRzdCBwb3J0LCBk c3QgbGFiZWx9IiBpcyBhcyBmb2xsb3dzLg0KDQo8RXhhbXBsZSBBPg0KDQogIGlucHV0IHBvcnQ9 MSAgLS0+IFN1Ym1hdHJpeCMxIC0tPiBvdXRwdXQgcG9ydD0yDQogIGlucHV0IGxhYmVsPTEgICAg ICAgICAgICAgICAgICAgICBvdXRwdXQgbGFiZWw9MQ0KDQogIGlucHV0IHBvcnQ9MSAgLS0+IFN1 Ym1hdHJpeCMyIC0tPiBvdXRwdXQgcG9ydD0yDQogIGlucHV0IGxhYmVsPTEgICAgICAgICAgICAg ICAgICAgICBvdXRwdXQgbGFiZWw9Mg0KDQogIFRoaXMgaXMgYWxsb3dlZC4NCg0KPEV4YW1wbGUg Qj4NCg0KICBpbnB1dCBwb3J0PTEgIC0tPiBTdWJtYXRyaXgjMSAtLT4gb3V0cHV0IHBvcnQ9Mg0K ICBpbnB1dCBsYWJlbD0xICAgICAgICAgICAgICAgICAgICAgb3V0cHV0IGxhYmVsPTENCg0KICBp bnB1dCBwb3J0PTEgIC0tPiBTdWJtYXRyaXgjMiAtLT4gb3V0cHV0IHBvcnQ9Mg0KICBpbnB1dCBs YWJlbD0xICAgICAgICAgICAgICAgICAgICAgb3V0cHV0IGxhYmVsPTENCg0KICBUaGlzIGlzIG5v dCBhbGxvd2VkLg0KDQo8RXhhbXBsZSBDPg0KDQogIGlucHV0IHBvcnQ9MSAgLS0+IFN1Ym1hdHJp eCMxIC0tPiBvdXRwdXQgcG9ydD0yDQogIGlucHV0IGxhYmVsPTEgICAgICAgICAgICAgICAgICAg ICBvdXRwdXQgbGFiZWw9MQ0KDQogIGlucHV0IHBvcnQ9MSAgLS0+IFN1Ym1hdHJpeCMyIC0tPiBv dXRwdXQgcG9ydD0yDQogIGlucHV0IGxhYmVsPTIgICAgICAgICAgICAgICAgICAgICBvdXRwdXQg bGFiZWw9Mg0KDQogIFRoaXMgaXMgYWxsb3dlZC4NCg0KSXMgYWJvdmUgdW5kZXJzdGFuZGluZyBj b3JyZWN0Pw0KSWYgc28sIEkgYW0gbm90IHN1cmUgaG93IGV4YW1wbGUgQSB3b3Jrcywgc2luY2Ug SSBhbSBub3Qgc3VyZSB3aGF0IGlzIHRoZSBpbmRlbnRpZmllciB0byBkaXJlY3QgZnJvbSBpbnB1 dCB0byBlYWNoIHN1Ym1hdHJpeC4NCg0KTWF5YmUgSSBhbSBtaXMtdW5kZXJzdGFuZGluZyB3aGF0 IHN1Yi1tYXRyaXggaXMuIEkgdGhvdWdodCBzdWItbWF0cml4IGlzIGEgc29ydCBvZiB2aXJ0dWFs IG5vZGUsIHNwbGl0dGluZyB0aGUgc2luZ2xlIG1hdHJpeCAob3Igc3dpdGNoKSBpbnRvIHNtYWxs ZXIgcGllY2VzLg0KDQpZT1VORz4+IE9LLCBJIHRoaW5rIHRoZSBkZWZpbml0aW9uIG9mIHN1Ym1h dHJpeCB3YXMgbm90IGNsZWFyLiBJdCBpcyBzaW1wbHkgZGl2aWRpbmcgdXAgYSBtYXRyaXggaW50 byBzZXZlcmFsIHBpZWNlcyBpbiBjYXNlIHRoZSBzaXplIG9mIHRoZSBtYXRyaXggYmVjb21lcyB0 b28gYmlnIG9yIGEgd2F5IHRvIGFkdmVydGl6ZSB0aGUgY2hhbmdlZCBwb3J0L2xhYmVsIHNldCBp biBvbmUgcGxhY2UgKHN1Yi1tYXRyaXgpIHRoZW4gb3RoZXIgdW5jaGFuZ2VkIHBvcnQvbGFiZWwg c2V0IGluIG90aGVyIHBsYWNlIChkaWZmZXJlbnQgc3ViLW1hdHJpeCkuIFRoZSBpZGVudGlmaWVy IGZvciBlYWNoIHN1Yi1tYXRyaXggaXMgdGhlIE1BVFJJWCBJRC4gVGhlcmUgaXMgbm90IHNlcGFy YXRlIGlkZW50aWZpZXIgdG8gZGlyZWN0IGZyb20gaW5wdXQuIFRoZSBpbnB1dCBpcyBhIHBhcnQg b2YgdGhlIHN1Yi1tYXRyaXguIFNheSBpZiB3ZSBoYXZlIE4qTSBtYXRyaXggdGhhdCBkZXNjcmli ZXMgYWxsIGlucHV0IGFuZCBvdXRwdXQgcG9ydC9sYWJlbC4gV2UgbWlnaHQgZGl2aWRlIHVwIGlu dG8gTiooTS1MKSBhbmQgTipMIG9yIGFueSBvdGhlciBjb21iaW5hdGlvbnMgYXMgZmFyIGFzIHRo ZXkgYXJlIGFsbCBkaXNqb2ludCBmcm9tIGVhY2ggb3RoZXIuIA0KDQo+IDQpIEluIHNlY3Rpb24g Mi4xLCBmb3IgTGluayBTZXQgQSBkaXI9YmlkaXJlY3Rpb25hbCwgTGluayBTZXQgQiBkaXI9Ymlk aXJlY3Rpb25hbCwgaWYgYW55IHNpZ25hbCBvbiBhbiBpbnB1dCBsaW5rIFggaXMgb3V0cHV0IG9u IGEgbGluayBZLCB0aGVuIGFueSA+IHNpZ25hbCBvbiBhbiBpbnB1dCBsaW5rIFkgaXMgb3V0cHV0 IG9uIGEgbGluayBYIChhZnRlciBjcm9zcy1jb25uZWN0KT8gT3IgYW55IGNvbnN0cmFpbnQgb24g c3VjaCBzaWduYWwgZmxvdyAoYWZ0ZXIgY3Jvc3MtY29ubmVjdCkgaXMgb3V0IG9mIHNjb3BlPw0K PiANCj4gPFlPVU5HPj4gSSBhbSBub3Qgc3VyZSB3aGF0ICJhZnRlciBjcm9zcy1jb25uZWN0IiBp cyBtZWFudC4NCg0KPEV4YW1wbGU+DQoNCiAgTGluayBzZXQgQTogbGluayMxLCBsaW5rIzIsIGxp bmsjMw0KICBMaW5rIHNldCBCOiBsaW5rIzQsIGxpbmsjNSwgbGluayM2DQoNCiAgQm90aCBvZiBM aW5rIHNldCBBIGFuZCBMaW5rIHNldCBCIGFyZSBzcGVjaWZpZWQgYXMgImRpciIuDQoNCiAgSW4g dGhpcyBjYXNlLA0KICAtIElzIGl0IHBvc3NpYmxlIHRvIHByb2JsZW0gdGhlIGNyb3NzLWNvbm5l Y3QgYXMgaW5wdXQ9bGluayMxLCBvdXRwdXQ9bGluayM0DQogICAgJiBpbnB1dD1saW5rIzUsIG91 dHB1dD1saW5rIzEgc2ltdWx0YW5lb2x1c2x5Pw0KICAtIE9yIGlzIGl0IGF1dG9tYXRpY2FsbHkg YXNzdW1lZCBpZiBpbnB1dD1saW5rIzEsIG91dHB1dD1saW5rIzQsDQogICAgdGhlbiBpbnB1dD1s aW5rIzQsIG91dHB1dD1saW5rIzE/DQogIC0gT3IgdGhpcyBzb3J0IG9mIGNvbnN0cmFpbnQgaXMg bm90IHNwZWNpZmllZCBpbiBMaW5rIFNldCBGaWVsZD8NCg0KVGhlIHRleHQgc2VlbXMgbGlrZSBz YXlpbmcgdGhlIGZpcnN0IG9wdGlvbiwgYnV0IEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgYSBjb21t b24gZXF1aXBtZW50IGltcGxlbWVudGFpb24uDQoNCllPVUdOPj4gT0suIEkgdGhpbmsgSSB1bmRl cnN0YW5kIHlvdSBtb3JlIGNsZWFybHkuIEZvciB0aGlzIGNhc2UgKGJpZGlyZWN0aW9uYWwgbGlu ayBzZXRzKSwgdGhlIGZpcnN0IGNhc2UgaXMgZGVmaW5pdGVseSBub3QgdGhlIGludGVudGlvbi4g VGhlIHNlY29uZCBjYXNlIGlzIGFzc3VtZWQuIA0KDQpUaGFua3MsDQpUb21vbm9yaQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0Bo dWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjAsIDIwMTUgNzo1NCBBTQ0KVG86 IFRvbW9ub3JpIFRha2VkYe+8iOatpueUsOefpeWFuO+8iTsgcnRnLWFkc0B0b29scy5pZXRmLm9y Zw0KQ2M6ICdydGctZGlyQGlldGYub3JnJzsgJ2RyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25z dHJhaW50LWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcnOyAnY2NhbXBAaWV0Zi5vcmcnDQpTdWJq ZWN0OiBSRTogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtY2NhbXAtZ2VuZXJh bC1jb25zdHJhaW50LWVuY29kZS0xNi50eHQNCg0KSGkgVG9tb25vcmksDQoNClRoYW5rcyBmb3Ig cHJvdmlkaW5nIGdvb2QgY29tbWVudHMuIEhlcmUncyBteSByZXNwb25zZS4gUGxlYXNlIHNlZSBp bi1saW5lLg0KDQpSZWdhcmRzLA0KWW91bmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHJ0Zy1kaXIgW21haWx0bzpydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBUb21vbm9yaSBUYWtlZGENClNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDE3LCAyMDE1IDc6 NTkgQU0NClRvOiBydGctYWRzQHRvb2xzLmlldGYub3JnDQpDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcn OyAnZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLmFsbEB0b29scy5p ZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZycNClN1YmplY3Q6IFtSVEctRElSXSBSdGdEaXIgcmV2 aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGUtMTYudHh0DQoN CkhlbGxvLCANCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1l cyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJv dmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciANCg0KQWx0aG91Z2ggdGhl c2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMs IGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0 aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5k IHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5n IHRoZSBkcmFmdC4gDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3Ry YWludC1lbmNvZGUtMTYudHh0IA0KUmV2aWV3ZXI6IFRvbW9ub3JpIFRha2VkYQ0KUmV2aWV3IERh dGU6IDE3IEphbnVhcnksIDIwMTUNCklFVEYgTEMgRW5kIERhdGU6IDE3IEphbnVhcnksIDIwMTUN CkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNClN1bW1hcnk6DQoNClRoaXMgZG9j dW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRo YXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJpb3IgdG8gcHVibGljYXRpb24uDQoNCkNvbW1lbnRz Og0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBwcm90b2NvbC1hZ25vc3RpYyBlbmNvZGluZ3Mg Zm9yIGdlbmVyYWwgaW5mb3JtYXRpb24gZWxlbWVudHMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYt Y2NhbXAtcndhLWluZm8uDQpJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBpbiBnb29kIHNoYXBlIGJ1 dCB0aGVyZSBhcmUgYSBmZXcgcG9pbnRzIHRoYXQgc2hvdWxkIGJlIGNsYXJpZmllZCBmb3IgYmV0 dGVyIHVuZGVyc3RhbmRpbmcuDQoNCk1ham9yIElzc3VlczoNCg0KTm9uZQ0KDQpNaW5vciBJc3N1 ZXM6DQoNCk5vbmUNCg0KTml0czoNCg0KMSkgSW4gc2VjdGlvbiAxLjIsIGxhYmVsIGNvbnRpbnVp dHkgY29uc3RyYWludCAoZS5nLiwgd2F2ZWxlbmd0aCBjb250aW51aXR5IGluIFdTT04pIGlzIG1l bnRpb25lZC4gSG93ZXZlciwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIGluZm9ybWF0aW9uIGVsZW1l bnRzIGZvciB3aGljaCB0aGlzIGRvY3VtZW50IHNwZWNpZmllcyBlbmNvZGluZ3MgY2FuIGRlc2Ny aWJlIHN1Y2ggY29uc3RyYWludC4gTXkgcmVhZGluZyBpcyB0aGF0IGluZm9ybWF0aW9uIGVsZW1l bnQgc3VjaCBhcyBQb3J0IExhYmVsIFJlc3RyaWN0aW9uIGlzIHJhdGhlciBmb3IgZGVzY3JpYmlu ZyB3YXZlbGVuZ3RoIHR1bmluZyBjYXBhYmlsaXRpZXMvcmVzdHJpY3Rpb25zLg0KDQpZT1VORz4+ IExhYmVsIGNvbnRpbnVpdHkgY29uc3RyYWludHMgY2FuIGJlIGluZmVycmVkIGZyb20gdGhlIHR3 byBwbGFjZXMgaW4gdGhlIGRyYWZ0OiAoaSkgUG9ydCBMYWJlbCBSZXN0cmljdGlvbiwgd2hpY2gg Z2l2ZXMgdGhlIHNldCBvZiBsYWJlbHMgKHdhdmVsZW5ndGhzKSB0aGF0IG1heSBub3QgYmUgYXZh aWxhYmxlIG9uIGNlcnRhaW4gbGlua3MgaW5jbHVkaW5nIHR1bmluZyByYW5nZS9yZXN0cmljdGlv bjsgKGlpKSBBdmFpbGFibGUvU2hhcmVkIEJhY2t1cCBMYWJlbCBGaWVsZHMgKHNlY3Rpb24gMi40 ICYgc2VjdGlvbiAyLjUpLiBUaGVyZSBpcyBubyBlbmNvZGluZyBmb3IgbGFiZWwgY29udGludWl0 eSBjb25zdHJhaW50IHBlciBzZS4gVGhlIGFmb3JlbWVudGlvbmVkIGNvbnN0cmFpbnRzIGFyZSBl bmNvZGVkIHRvIGdpdmUgYSBub2RlIG9yIGEgUENFIHRvIGJlIGFibGUgdG8gY29tcHV0ZSBhIHBh dGggKGkuZS4sIHBhdGggd2l0aCB3YXZlbGVuZ3RoIGNvbnRpbnVpdHkpIHN1YmplY3QgdG8gdGhl c2UgY29uc3RyYWludHMuIA0KDQoyKSBJbiBzZWN0aW9uIDIuMSwgaXQgc2F5cyAidHdvIG1hdHJp Y2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge3NyYyBwb3J0LCBzcmMgbGFiZWwsIGRzdCBwb3J0 LCBkc3QgbGFiZWx9Ii4gVG8gYmUgcHJlY2lzZSwgSSBndWVzcyB0aGlzIHNob3VsZCBiZSAidHdv IG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge3NyYyBwb3J0LCBzcmMgbGFiZWx9LCBh bmQgdHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge2RzdCBwb3J0LCBkc3QgbGFi ZWx9Ij8NCg0KWU9VTkc+PiBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlvbiBtYXkgYmUgdG9vIHJlc3Ry aWN0aXZlLiBGb3IgaW5zdGFuY2UsIGlmIHdlIGhhdmUgb25lIHNvdXJjZSAocG9ydCAxKSBhbmQg b25lIGRlc3RpbmF0aW9uIChwb3J0IDIpIHdpdGggdHdvIGxhYmVscyBlYWNoLiBUaGVuIHdlIHdv dWxkIGhhdmU6IHsoMSwxLDIsMSksICgxLDEsMiwyKSwgKDEsMiwyLDEpLCAoMSwyLDIsMil9IEkg dGhpbmsgd2l0aCB0aGUgY3VycmVudCBzdGF0ZW1lbnQsIHdlIGNhbiBzZW5kIHRoaXMgaW5mbyBp biBhbnkgY29tYmluYXRpb24gb2YgbXVsdGlwbGUgbWF0cmljZXMsIHdoaWNoIEkgdGhpbmsgcGVy ZmVjdGx5IGZpbmUuIFdpdGggeW91ciBzdWdnZXN0aW9uLCBJIHdvdWxkIG5vdCBiZSBhYmxlIHNl bmQgKDEsMSwyLDEpIGFuZCAoMSwxLDIsMikgdG9nZXRoZXIuIFdoeSB3b3VsZCB0aGlzIG5vdCBi ZSBtYWRlIHBvc3NpYmxlPyBNeSB0YWtlIGlzIGFzIGxvbmcgYXMgZWFjaCBzdWJtYXRyaXggcmVw cmVzZW50cyBhIHNldCBvZiBkaXNqb2ludCBxdWFkcnVwbGVzLCB0aGF0IHNob3VsZCBiZSBhbGxv d2VkLiANCg0KMykgSW4gc2VjdGlvbiAyLjEsIGl0IHNheXMgIlRoZSB2YWx1ZSBvZiAweEZGIGlz IHJlc2VydmVkIGZvciB1c2Ugd2l0aCBwb3J0IHdhdmVsZW5ndGggY29uc3RyYWludHMiLiBJIHRo aW5rICJwb3J0IHdhdmVsZW5ndGggY29uc3RyYWludHMiIHNob3VsZCBiZSAicG9ydCBsYWJlbCBy ZXN0cmljdGlvbiIuDQoNCllPVU5HPj4gWWVzLCB0aGFua3MuIA0KDQo0KSBJbiBzZWN0aW9uIDIu MSwgZm9yIExpbmsgU2V0IEEgZGlyPWJpZGlyZWN0aW9uYWwsIExpbmsgU2V0IEIgZGlyPWJpZGly ZWN0aW9uYWwsIGlmIGFueSBzaWduYWwgb24gYW4gaW5wdXQgbGluayBYIGlzIG91dHB1dCBvbiBh IGxpbmsgWSwgdGhlbiBhbnkgc2lnbmFsIG9uIGFuIGlucHV0IGxpbmsgWSBpcyBvdXRwdXQgb24g YSBsaW5rIFggKGFmdGVyIGNyb3NzLWNvbm5lY3QpPyBPciBhbnkgY29uc3RyYWludCBvbiBzdWNo IHNpZ25hbCBmbG93IChhZnRlciBjcm9zcy1jb25uZWN0KSBpcyBvdXQgb2Ygc2NvcGU/DQoNCllP VU5HPj4gSSBhbSBub3Qgc3VyZSB3aGF0ICJhZnRlciBjcm9zcy1jb25uZWN0IiBpcyBtZWFudC4g DQoNCjUpIEluIHNlY3Rpb24gMi4yLjEsIGl0IHNheXMgIkluIHRoaXMgY2FzZSB0aGUgYWNjb21w YW55aW5nIGxhYmVsIHNldCBpbmRpY2F0ZXMgdGhlIGxhYmVscyBwZXJtaXR0ZWQgb24gdGhlIHBv cnQuIiBJIHRoaW5rICJwb3J0IiBzaG91bGQgYmUgInBvcnQvbWF0cml4Ii4NCg0KWU9VTkc+PiBZ ZXMsIHRoYW5rcy4gDQoNCjYpIEluIHNlY3Rpb24gMi4yLjIsIGl0IHdvdWxkIGJlIGJldHRlciB0 byBkZXNjcmliZSB0aGUgdHlwZSAoZS5nLiwgaW50ZWdlcikgZm9yIE1heE51bUNoYW5uZWxzLg0K VGhpcyBhbHNvIGFwcGxpZXMgZm9yIE1heExhYmVsUmFuZ2UgKGluIHNlY3Rpb24gMi4yLjMpIGFu ZCBOdW0gTGFiZWxzIChpbiBzZWN0aW9uIDIuNikuDQoNCllPVU5HPj4gT0suIA0KDQo3KSBJbiBz ZWN0aW9uIDIuNiwgaXQgc2F5cyAiTGFiZWwgU2V0IEZpZWxkIGlzIHVzZWQgd2l0aGluIHRoZSA8 QXZhaWxhYmxlTGFiZWxzPiBvciB0aGUgPFNoYXJlZEJhY2t1cExhYmVscz4iLiBCdXQgSSB0aGlu ayBMYWJlbCBTZXQgRmllbGQgaXMgYWxzbyB1c2VkIHdpdGhpbiBTSU1QTEVfTEFCRUwsIExBQkVM X1JBTkdFIGFuZCBTSU1QTEVfTEFCRUwgJiBDSEFOTkVMX0NPVU5ULg0KDQpZT1VORz4+IFllcywg aXQgaXMgdXNlZCBpbiBtdWx0aXBsZSBwbGFjZXMuIA0KDQpIb3cgYWJvdXQ6DQpPTEQ6IExhYmVs IFNldCBGaWVsZCBpcyB1c2VkIHdpdGhpbiB0aGUgPEF2YWlsYWJsZUxhYmVscz4gb3IgdGhlDQog ICA8U2hhcmVkQmFja3VwTGFiZWxzPiwgd2hpY2ggaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIuNC4g YW5kIDIuNS4sDQogICByZXNwZWN0aXZlbHkuDQpORVc6IExhYmVsIFNldCBGaWVsZCBpcyB1c2Vk IHdpdGhpbiB0aGUgPEF2YWlsYWJsZUxhYmVscz4gb3IgdGhlDQogICA8U2hhcmVkQmFja3VwTGFi ZWxzPiwgd2hpY2ggaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIuNC4gYW5kIDIuNS4sDQogICByZXNw ZWN0aXZlbHkuIEl0IGlzIGFsc28gdXNlZCB3aXRoaW4gdGhlIDxTSU1QTEVfTEFCRUw+LCANCiAg IDxMQUJFTF9SQU5HRT4sIDxTSU1QTEVfTEFCRUw+IG9yIDxDSEFOTkVMX0NPVU5UPiwgd2hpY2gg aXMgZGVmaW5lZA0KICAgaW4gU2VjdGlvbnMgMi4xLjEgLSAyLjEuNCwgcmVzcGVjdGl2ZWx5LiAN Cg0KDQpUaGFua3MsDQpUb21vbm9yaQ0K From nobody Fri Jan 23 05:49:45 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 6773C1A90C9 for ; Fri, 23 Jan 2015 05:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 KQyX5cLfLpCy for ; Fri, 23 Jan 2015 05:49:41 -0800 (PST) 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 4E2F41A90C8 for ; Fri, 23 Jan 2015 05:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4446; q=dns/txt; s=iport; t=1422020982; x=1423230582; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WISniFY0QffA8+nfgeb8m8l4W/hE5ajWcqYqkHT8wus=; b=A0ycL/yA2wknpEBKNIs0MO8dTQ6dOf1c2VKfm2wzycdYxVi2xynI420E Gsu2O7iNS6GveOUN0by/JddRKZC4EYjlCwg2JbyZiBxKwMKxkPVKxA9+r 2laAOwm4RG+5uNyzWCVxh8ntvMzZ/CWiaYSCKo5OPWqNbKtZxGYV62S0Y g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkFAKpQwlStJV2T/2dsb2JhbABagwZSWATEJ4IlhXECgRRDAQEBAQF9hAwBAQEDAXkFBwQCAQgRBAEBAScHMhQJCAIEDgUJEogJCA3SQAEBAQEBAQEBAQEBAQEBAQEBAQEBARePRTMHBoMQgRMFjmaDSoVPgRSFP4tiIoF/H4FQbwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,453,1418083200"; d="scan'208";a="390192628" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jan 2015 13:49:41 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t0NDnenK011594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 13:49:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 07:49:39 -0600 From: "Giovanni Martinelli (giomarti)" To: "adrian@olddog.co.uk" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQJ3wIujnPuGDVCAAJV6gIAACUwAgAC044CAAegbgA== Date: Fri, 23 Jan 2015 13:49:39 +0000 Message-ID: <7FC25DD1-41D5-4800-92E3-B682B38D2F2B@cisco.com> References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> <4B704AAD-ED2D-4688-9283-F2ACBFB27554@cisco.com> <033301d035c4$f2717b90$d75472b0$@olddog.co.uk> <4676494F-5FC1-4053-B9A7-0C665B6429CB@cisco.com> In-Reply-To: <4676494F-5FC1-4053-B9A7-0C665B6429CB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.213.69] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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, 23 Jan 2015 13:49:43 -0000 One additional comment (hoping not additional confusion).=20 The idea about Optical Interface Class was taken from SRLG. Good or bad is = a plain number and you do simple operations on it.=20 Cheers G On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) wrote: > Hi Adrian, >=20 > On 21 Jan 2015, at 22:55, Adrian Farrel wrote: >=20 >> Hi, >>=20 >> Well, you seem to have a half-way house. >>=20 >> You have specified the existence of a thing, but not how to read it. >>=20 >> If you wanted to make a statement that this object will only be used whe= n it is >> known that all systems in a network come from the same vendor and/or hav= e the >> same understanding of the encoding, that might be OK (although how you w= ould >> ascertain this might also need to be described). >>=20 >=20 > The statement is to ensure the interface compatibility without encoding a= ll the possible details and parameter that define an interface (e.g. modula= tion format, forward error correction etc.). This was the initial solution = in the draft then replaced by the interface class concept. The WSON (RWA-= only) has the requirement is to make sure two interface are compatible. Thi= s requirement, imho, can be satisfy by a simple comparison which has a bool= ean result.=20 >=20 > We end up then in the ITU application codes for the =93certified=94 (we= =92ll this is my term not 100% sure is the best one) compatibility where pr= oper encoding is provided.=20 >=20 >=20 >> Or you could entirely remove the vendor-specific option. >>=20 >> Or you could put in an OUI / enterprise number followed by transparent b= ytes. >>=20 >=20 > To me I=92m perfectly fine with the second option.=20 >=20 > Cheers > G >=20 >=20 >> Adrian >>=20 >>> -----Original Message----- >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] >>> Sent: 21 January 2015 21:22 >>> To: adrian@olddog.co.uk >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode >>>=20 >>> Specifically to the Interface class here below. >>>=20 >>> In the initial draft merged to this one there was the usage of OUI howe= ver (I >>> guess after chatting with Lou) we decided to remove any encoding when t= he >>> Interface class is not standard. >>> In term of semantic the protcol does not need to decode the Interface c= lass >> since >>> it only assess the interface compatibility if two interfaces has a clas= s value >> that >>> match two interfaces cann be connected. >>>=20 >>> Having saying that I don't have strong opinion in adding the OUI or lea= ving >> room >>> for maybe future public interfaces database. For sure there's a need to= leave >>> room for specific compatibility assesment since there optical multivend= or >>> compatibility has been already demonstrated. >>>=20 >>> hope this help . >>>=20 >>> Cheers >>> G >>>=20 >>>=20 >>> On 21 Jan 2015, at 21:57, Adrian Farrel wrote: >>>=20 >>>>>>=20 >>>>>> Section 4.1 >>>>>> How do I interpret a Vendor-Specific Application Code? Is there an O= UI >>>>>> I'm missing? >>>>>=20 >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? >>>>=20 >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- >>> numbers.xhtml#ieee-802 >>>> -numbers-2 >>>>=20 >>>> Or perhaps an Enterprise Number >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers >>>>=20 >>>> The question is: >>>>=20 >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret the >> Optical >>>> Interface Class field when it contains an ITU-T Application Mapping. >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface C= lass >> contains >>>> a "Vendor Specific Optical Interface Class". >>>> How do I interpret that Optical Interface Class? >>>> Which vendor does it apply to? >>>> Is there some information elsewhere that gives me a clue as to which v= endor >>> has >>>> encoded the information? >>>> Or is the information supposed to be encoded in the Optical Interface = Class, >>>> perhaps as the first 48 bits? >>>> Or am I supposed to know by context? >>=20 >=20 From nobody Fri Jan 23 06:41: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 1EF091A90C8 for ; Fri, 23 Jan 2015 06:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RCGQbmukkZyv for ; Fri, 23 Jan 2015 06:41:17 -0800 (PST) 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 3E52B1A90BA for ; Fri, 23 Jan 2015 06:41:17 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NEf6Wf032241; Fri, 23 Jan 2015 14:41:06 GMT Received: from 950129200 (089144224197.atnat0033.highway.a1.net [89.144.224.197]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NEeuPo032118 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 14:41:04 GMT From: "Adrian Farrel" To: "'Giovanni Martinelli \(giomarti\)'" Date: Fri, 23 Jan 2015 14:40:50 -0000 Message-ID: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA3F39rUe0sT3nBRieZEz+A1ksBgQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21276.004 X-TM-AS-Result: No--31.626-10.0-31-10 X-imss-scan-details: No--31.626-10.0-31-10 X-TMASE-MatchedRID: Qy8IQnwT72Q/FLJq3yHG9WzBijri5+RVJNroBaGZ+LW9K1jOJyKSa/U7 2nYVxvYN1eyLpsu4p9K3ISeKj4IBIP2TaclfE10aM0pZiLPQITpu/Xr6CKXiN3H+NJSyqjxjbyq cWT4FZRczkTO9kPlpFpPrkLG7Agm3ZF6ysdFjt0rx5KZMlKYS/VHewY36PuY0B6d3D+KIwZDxy/ H5BGyr4qpoI0gyGMJQ9AaJ/rCyiU1CzHFhiypoVppWgCLYjjT9Q95F2IiVUkT1bGUO+1Pc3KkLY bIpdhDAHIHA2mx0ec9Fcy9Xm9K+Vev0250SgRWKJMk7xo92oCX4uJ1REX4MHY/ysyGl2pMecQ2N 8UBEvedi4EZZUzX5yFpPtNJoAeE25lAcvk44nZXoe5XUFQlg8x7aUJN4PKIOfeHPnu31iHAEhlb ld58ez/Kw46gg+NH67QcXuKn618HpzoZfJABOunH7HV/mO4UTaBTWjXFXXd9Ev26FkhjLXcrpBM uiQ/7mrDHUBm6rZ1QhIMlpP/jXw2uCdtCAow1/71Wx2uUbPLdBldmDYjwlpqFSh25xC7TpBixx3 lAro9f8bQRM2WaSHJGTpe1iiCJqtD9qpBlNF8o/vucGn10dpvoA9r2LThYYKrauXd3MZDUD/dHy T/Xh7Q== Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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: Fri, 23 Jan 2015 14:41:20 -0000 Hi, I appreciate this discussion, but I am not seeing a specific conclusion from it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable. I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the document. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or bad is a > plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be used when it is > >> known that all systems in a network come from the same vendor and/or have > the > >> same understanding of the encoding, that might be OK (although how you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without encoding all the > possible details and parameter that define an interface (e.g. modulation format, > forward error correction etc.). This was the initial solution in the draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This requirement, > imho, can be satisfy by a simple comparison which has a boolean result. > > > > We end up then in the ITU application codes for the "certified" (we'll this is my > term not 100% sure is the best one) compatibility where proper encoding is > provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI however (I > >>> guess after chatting with Lou) we decided to remove any encoding when the > >>> Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a need to leave > >>> room for specific compatibility assesment since there optical multivendor > >>> compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there an OUI > >>>>>> I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=0 and OI=1 it means that the Optical Interface Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > From nobody Fri Jan 23 07:27:39 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 81FEC1A914E for ; Fri, 23 Jan 2015 07:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 6ttM5f2ZRduX for ; Fri, 23 Jan 2015 07:27:35 -0800 (PST) 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 EFDBB1A90BA for ; Fri, 23 Jan 2015 07:27:34 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NFRGc3006450; Fri, 23 Jan 2015 15:27:17 GMT Received: from 950129200 (089144224197.atnat0033.highway.a1.net [89.144.224.197]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NFRERO006327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 15:27:15 GMT From: "Adrian Farrel" To: "'Leeyoung'" , Date: Fri, 23 Jan 2015 15:27:10 -0000 Message-ID: <006a01d03721$11490170$33db0450$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA3HZjonkvmk8bgRpWytOzEjnSVrw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21278.000 X-TM-AS-Result: No--14.837-10.0-31-10 X-imss-scan-details: No--14.837-10.0-31-10 X-TMASE-MatchedRID: V7+YOFQa11Eol39hmeEcd4zb2GR6Ttd3bayJNjpJvsazU0R+5DbDbKGM dMUDv3NC7Z2Ub9WArt0IThkg+gnWEO26dmaIobujSDkh6bW+bcdYfDj3hIJgka+WgCcaviqGIZn pVU5Vh5YIl5LoEUEJGtJOk2AbaE/FqW0LH7DLBaXK09/T6AzbVkyQ5fRSh265CVuEXtlNqcshuv 9XGd2ScmZskvJo0aBBTpApQ5mX86rODBDKbmK9pcWUKBjERoYTWwKGivsEuI2e8oYCLa7A46MOK npzjnVIVH9uf5GqbbIQbg/yAcf3PtOlZ6Jznao8hrs6JAEL1u44WsSNiH/UXkhkYHhloziiK5/V s9QmFLCTEmvX2xcMHinx5D0LD290QdZuZ42vrpHMrZu+Xb3+2Z6KYa03LCO2myiLZetSf8nJ4y0 wP1A6AMaUO+wtQNbajoczmuoPCq0G3jDd1UNPMHVlxHCgLB+noVceYt5Zmq1Z/RKsbmMCsnQJru 67Hfym Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org Subject: [CCAMP] Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info 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: Fri, 23 Jan 2015 15:27:37 -0000 Hello, Continuing this discussion, I think we are getting closer. > > My comment for general vs. WSON-specific issue is that the design philosophy > > of general encoding was to generalize a common element that can be applied > > to different technologies. For instance, connectivity matrix definitely can be > > applied to WSON, OTN and other Switching technology as one encoding can > > fit to all. You seemed to desire a sharing of the same encoding to describe > > different entities where possible. This is fine for label vs. wavelength as > > there is one-to-one mapping for this. However, Resource Block encoding > > cannot properly share with the connectivity matrix encoding with two > > reasons: > > > > 1. They refer to different elements in the node. > > 2. They require different sets of fields with different number of fields. OK, what we really seem to be running into is some rather vague definitions of "resource" and "resource block". Do you think we could spend some time nailing those down. Then we'll work out where to put them (possibly in rwa-info). The question is not about the protocol element "resource block" but is about what it represents. So, as a starter, what is a Resource in a WSON system? You have said (lower down this email) that " resources meant regenerators/wavelength converters". I can live with this (although it is a long way from the term "resource" used in 3473 etc. where it is taken to mean buffers, bandwidth, memory, labels, lambdas,... That difference in interpretation is sufficiently large that it needs to be brought out and made very clear. You need something like: In this document the term "Resource" is used to refer to a physical component of a WSON node such as a regenerator or a wavelength converter. Multiple instances of such components are often present within a single WSON node. This term is not to be confused with the concept of forwarding or switching resources such as bandwidth or lambdas. Then you can answer what is a Resource Block in a WSON system? >From what I think I now understand, a resource block is simply a collection of resources on a WSON network node that behave in the same way. This allows easier description in the protocol encoding, but has no other meaning. So you could say: A Resource Block is a collection of Resources from the same WSON node that are grouped together for administrative reasons and for ease of encoding in the protocols. All Resources in the same Resource Block behave in the same way and have similar characteristics relevant to the optical system, e.g., processing properties, accessibility, etc. Then comes, what is a Resource Pool? Actually, this is only implicitly defined in draft-ietf-ccamp-rwa-info and so we have quite a gap. It looks like you might say: A Resource Pool is a collection of Resource Blocks for the purpose of representing throughput or cross-connect capabilities in a WSON node. A Resource Pool associates input ports or links on the node with output ports or links and is used to indicate how signals may be passed from an input port or link to an output port or link by way of a Resource Block (in other words, by way of a Resource). A Resource Pool may, therefore, be modelled as a matrix. A Resource Block may be present in multiple Resource Pools. And finally, we have Resource Block Set. What is that? I *think* it is just the encoding concept for a Resource Block Pool. You have (in 2.1) In a WSON node that includes resource blocks (RB), denoting subsets of these blocks allows one to efficiently describe common properties of the blocks and to describe the structure and characteristics, if non-trivial, of the resource pool. *Now* I see that your "subsets" should actually be "sets" and that will make more sense. But do you need the two terms "Resource Block Pool" and "Resource Block Set"? Are they the same or different? When I read 3.2 it looks like the Resource Block Pool is a collection of Resource Block Sets. Have I finally got this right? If so, then can we agree precise text and where to put it? Thanks for your patience. Adrian From nobody Fri Jan 23 07:57: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 33B041A9121 for ; Fri, 23 Jan 2015 07:57:29 -0800 (PST) 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 a996vs2_x_n8 for ; Fri, 23 Jan 2015 07:57:24 -0800 (PST) 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 A9F7E1A9115 for ; Fri, 23 Jan 2015 07:57:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOI99633; Fri, 23 Jan 2015 15:57:20 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 15:57:20 +0000 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; Fri, 23 Jan 2015 07:57:16 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Thread-Topic: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info Thread-Index: AdA3HZjonkvmk8bgRpWytOzEjnSVrwABW8lg Date: Fri, 23 Jan 2015 15:57:15 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7E013@dfweml706-chm> References: <006a01d03721$11490170$33db0450$@olddog.co.uk> In-Reply-To: <006a01d03721$11490170$33db0450$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info 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, 23 Jan 2015 15:57:30 -0000 Hi Adrian, I think we are on the same page. Please see inline for specific comment.=20 Best regards, Young -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, January 23, 2015 9:27 AM To: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org Subject: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rw= a-wson-encode and draft-ietf-ccamp-rwa-info Hello, Continuing this discussion, I think we are getting closer. > > My comment for general vs. WSON-specific issue is that the design philosophy > > of general encoding was to generalize a common element that can be appl= ied > > to different technologies. For instance, connectivity matrix definitely= can be > > applied to WSON, OTN and other Switching technology as one encoding can > > fit to all. You seemed to desire a sharing of the same encoding to desc= ribe > > different entities where possible. This is fine for label vs. wavelengt= h as > > there is one-to-one mapping for this. However, Resource Block encoding > > cannot properly share with the connectivity matrix encoding with two > > reasons: > > > > 1. They refer to different elements in the node. > > 2. They require different sets of fields with different number of field= s. OK, what we really seem to be running into is some rather vague definitions= of "resource" and "resource block". Do you think we could spend some time nailing those down. Then we'll work o= ut where to put them (possibly in rwa-info). YOUNG>> Yes, I have just noticed that you held rwa-info and I hope you can = suggest some clarifying text into that draft, which I see below.=20 The question is not about the protocol element "resource block" but is abou= t what it represents. So, as a starter, what is a Resource in a WSON system? You have said (lower down this email) that " resources meant regenerators/wavelength converters". I can live with this (although it is a long way from the term "resource" us= ed in 3473 etc. where it is taken to mean buffers, bandwidth, memory, labels, lambdas,... That difference in interpretation is sufficiently large that it needs to be brought out and made very clear. You need something like: In this document the term "Resource" is used to refer to a physical component of a WSON node such as a regenerator or a wavelength converter. Multiple instances of such components are often present within a single WSON node. This term is not to be confused with the concept of forwarding or switching resources such as bandwidth or lambdas. YOUNG>> Great suggestion. Yes, that is what is Resource is. The part of the= problem has been that the term 'resource' was picked when the WG asked us = to generalize Regenerators/wavelength converters. This term 'resource' may = have not been perfect, but it was chosen as such to have its meaning in a s= pecific context.=20 Then you can answer what is a Resource Block in a WSON system? >From what I think I now understand, a resource block is simply a collection= of resources on a WSON network node that behave in the same way. This allows e= asier description in the protocol encoding, but has no other meaning. So you coul= d say: A Resource Block is a collection of Resources from the same WSON node that are grouped together for administrative reasons and for ease of encoding in the protocols. All Resources in the same Resource Block behave in the same way and have similar characteristics relevant to the optical system, e.g., processing properties, accessibility, etc.=20 YOUNG>> Yes, it is correct. Then comes, what is a Resource Pool? Actually, this is only implicitly defi= ned in draft-ietf-ccamp-rwa-info and so we have quite a gap. It looks like you = might say: A Resource Pool is a collection of Resource Blocks for the purpose of representing throughput or cross-connect capabilities in a WSON node. A Resource Pool associates input ports or links on the node with output ports or links and is used to indicate how signals may be passed from an input port or link to an output port or link by way of a Resource Block (in other words, by way of a Resource). A Resource Pool may, therefore, be modelled as a matrix. =20 A Resource Block may be present in multiple Resource Pools. YOUNG>> Yes. And finally, we have Resource Block Set. What is that? I *think* it is just the encoding concept for a Resource Block Pool. You have (in 2.1) In a WSON node that includes resource blocks (RB), denoting subsets of these blocks allows one to efficiently describe common properties of the blocks and to describe the structure and characteristics, if non-trivial, of the resource pool. *Now* I see that your "subsets" should actually be "sets" and that will mak= e more sense. YOUNG>> Yes, "sets" make it clearer. But do you need the two terms "Resource Block Pool" and "Resource Block Set= "? Are they the same or different? When I read 3.2 it looks like the Resource = Block Pool is a collection of Resource Block Sets. YOUNG>> They are different. Resource Block Pool is sitting above the RB Set= s. There may be multiple RB Sets in a node that behave differently, e.g., d= ifferent input/output constraints on the access/egress to the Pool.=20 Have I finally got this right? YOUNG>> Yes, I think so.=20 If so, then can we agree precise text and where to put it? YOUNG>> Yes.=20 Thanks for your patience. Adrian From nobody Fri Jan 23 08:03: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 C997D1A9115 for ; Fri, 23 Jan 2015 08:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 fxBkV_-vSGYO for ; Fri, 23 Jan 2015 08:02:57 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3E61A8AE7 for ; Fri, 23 Jan 2015 08:02:56 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 1DB81F2ECB9BF; Fri, 23 Jan 2015 16:02:49 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t0NG2pBW022580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 11:02:51 -0500 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.168]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 11:02:51 -0500 From: "Lam, Hing-Kam (Kam)" To: "adrian@olddog.co.uk" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AdA3F39rUe0sT3nBRieZEz+A1ksBgQAC7Nvw Date: Fri, 23 Jan 2015 16:02:50 +0000 Message-ID: <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> In-Reply-To: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_8DBC3FDAC14BE441AED9C5939C77758509EE3A6CUS70TWXCHMBA12z_" MIME-Version: 1.0 Archived-At: Cc: "Doolan, Paul \(Coriant - US/Irving\)" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 23 Jan 2015 16:03:03 -0000 --_000_8DBC3FDAC14BE441AED9C5939C77758509EE3A6CUS70TWXCHMBA12z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.8= 74.1 to amend the specification of ApplicationIdentifier with the following= additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString = represents a standard application code as defined in the ITU-T Recommendati= ons. If the ApplicationIdentifierType is PROPRIETARY, the first six charact= ers of the PrintableString must contain the Hexadecimal representation of a= n OUI assigned to the vendor whose implementation generated the Application= Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietar= y-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools= .ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-w= son-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel > wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a bool= ean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel > wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_8DBC3FDAC14BE441AED9C5939C77758509EE3A6CUS70TWXCHMBA12z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

For your information. In the last SG15 meeting, Q= 14/15 agreed to update G.874.1 to amend the specification of ApplicationIde= ntifier with the following additional text:

 

If the ApplicationIden= tifierType is STANDARD, the value of PrintableString represents a standard = application code as defined in the ITU-T Recommendations. If the Applicatio= nIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal r= epresentation of an OUI assigned to the vendor whose implementation generat= ed the Application Identifier; the remaining octets of the PrintableString = are unspecified.

 

Paul Doolan had an I-D "https://tools.ietf.org/h= tml/draft-doolan-proprietary-ac-00" to the last IETF meeting with = the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM=

To: 'Giovanni Martinelli (giomarti)'

Cc: ccamp@ietf.= org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

Subject: [CCAMP] Vendor-Specific Application Code= in draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am not seeing= a specific conclusion from it.

 

The current I-D makes (IMHO) the Vendor-Specific = Application Code unusable. I offered three options:

 

1 This value is only to be used when it is known = that all devices

   participating in a network have the = same understanding of

   the content of the Vendor-Speci= fic Application Code field.

   How this knowledge is achieved is ou= tside the scope of this

   document

 

2 When this value is set, the first 32 (or 48) bi= ts of the Vendor-

  Specific Application Code field contain an= Enterprise Number

  (or OUI) that defines the context in which= the remainder of

  that field is interpreted.

 

3 Remove the option to include a Vendor-Specific = Application

   Code field.

 

If the WG could please pick one of these and help= Young to update the document.

 

Thanks,

Adrian

 

> -----Original Message-----

> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 13:50

> To: a= drian@olddog.co.uk

> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> ccamp@ietf= .org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of draft-ietf= -ccamp-rwa-wson-encode

>

> One additional comment (hoping not additiona= l confusion).

>

> The idea about Optical Interface Class was t= aken from SRLG. Good or

> bad is a plain number and you do simple oper= ations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, Giovanni Martinell= i (giomarti)

> <gi= omarti@cisco.com>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel= <adrian@olddog.co.uk> wro= te:

> >

> >> Hi,

> >>

> >> Well, you seem to have a half-way h= ouse.

> >>

> >> You have specified the existence of= a thing, but not how to read it.

> >>

> >> If you wanted to make a statement t= hat this object will only be

> >> used when

it is

> >> known that all systems in a network= come from the same vendor

> >> and/or have

> the

> >> same understanding of the encoding,= that might be OK (although how

> >> you

> would

> >> ascertain this might also need to b= e described).

> >>

> >

> > The statement is to ensure the interfac= e compatibility without

> > encoding all

the

> possible details and parameter that define a= n interface (e.g.

> modulation

format,

> forward error correction etc.). This was the= initial solution in the

> draft

then

> replaced by the interface class concept.&nbs= p;  The WSON (RWA-only) has the

> requirement is to make sure two interface ar= e compatible. This

> requirement, imho, can be satisfy by a simpl= e comparison which has a boolean result.

> >

> > We end up then in  the ITU applica= tion codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatib= ility where proper

> encoding is provided.

> >

> >

> >> Or you could entirely remove the ve= ndor-specific option.

> >>

> >> Or you could put in an OUI / enterp= rise number followed by

> >> transparent

> bytes.

> >>

> >

> > To me I'm perfectly fine with the secon= d option.

> >

> > Cheers

> > G

> >

> >

> >> Adrian

> >>

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

> >>> From: Giovanni Martinelli (giom= arti) [mailto:giomarti@cisco.com]=

> >>> Sent: 21 January 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>

> >>> Subject: Re: [CCAMP] AD review = of draft-ietf-ccamp-rwa-wson-encode

> >>>

> >>> Specifically to the Interface c= lass here below.

> >>>

> >>> In the initial draft merged to = this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) = we decided to remove any encoding

> >>> when the Interface class is not= standard.

> >>> In term of semantic the protcol= does not need to decode the

> >>> Interface

class

> >> since

> >>> it only assess the interface co= mpatibility if two interfaces has a

> >>> class

value

> >> that

> >>> match two interfaces cann be co= nnected.

> >>>

> >>> Having saying that I don't have= strong opinion in adding the OUI

> >>> or

leaving

> >> room

> >>> for maybe future public interfa= ces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility= assesment since there optical

> >>> multivendor compatibility has b= een already demonstrated.

> >>>

> >>> hope this help .

> >>>

> >>> Cheers

> >>> G

> >>>

> >>>

> >>> On 21 Jan 2015, at 21:57, Adria= n Farrel <adrian@olddog.co.uk= > wrote:

> >>>

> >>>>>>

> >>>>>> Section 4.1

> >>>>>> How do I interpret = a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?=

> >>>>>

> >>>>> [YOUNG] Not sure if I u= nderstood this question. What is "OUI"?

> >>>>

> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier

> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> numbers.xhtml#ieee-802

> >>>> -numbers-2

> >>>>

> >>>> Or perhaps an Enterprise Nu= mber

> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> >>>>

> >>>> The question is:=

> >>>>

> >>>> You have sections 4.1.1 thr= ough 4.1.4 to tell me how to interpret

> >>>> the

> >> Optical

> >>>> Interface Class field when = it contains an ITU-T Application Mapping.

> >>>> When I received s=3D0 and O= I=3D1 it means that the Optical Interface

> >>>> Class

> >> contains

> >>>> a "Vendor Specific Opt= ical Interface Class".

> >>>> How do I interpret that Opt= ical Interface Class?

> >>>> Which vendor does it apply = to?

> >>>> Is there some information e= lsewhere that gives me a clue as to

> >>>> which

> vendor

> >>> has

> >>>> encoded the information?

> >>>> Or is the information suppo= sed to be encoded in the Optical

> >>>> Interface

Class,

> >>>> perhaps as the first 48 bit= s?

> >>>> Or am I supposed to know by= context?

> >>

> >

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/ccamp

--_000_8DBC3FDAC14BE441AED9C5939C77758509EE3A6CUS70TWXCHMBA12z_-- From nobody Fri Jan 23 08:42:41 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 21CB41A9115 for ; Fri, 23 Jan 2015 08:42:40 -0800 (PST) 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 1P85bDpwLjC5 for ; Fri, 23 Jan 2015 08:42:37 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id B1A311A1AD8 for ; Fri, 23 Jan 2015 08:42:37 -0800 (PST) Received: (qmail 6975 invoked by uid 0); 23 Jan 2015 16:42:33 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 23 Jan 2015 16:42:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id jUiS1p00c2SSUrH01UiVUs; Fri, 23 Jan 2015 09:42:33 -0700 X-Authority-Analysis: v=2.1 cv=VqmwXYGn c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=hUXq7yzdp1YA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=YNv0rlydsVwA:10 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=CyRW7yT0AAAA:8 a=19k2qleqZTZaPkeqpiQA:9 a=2zux7P-dHdzaz_NP:21 a=XMUnZPsMoyRhUg4U:21 a=dRX7tCC7aNy5OXLD:21 a=QEXdDO2ut3YA: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=DSJIvSrhUhac56kfd0ydqnjXUSzXKvmwFiYh/E5rIeg=; b=hgSCcvtwnklX0CmtycvrMk16NPWrS6Uc3/UwAwQUR768DkklurlVjOLrxJjKg3h40M1ebiY7BFdsnoioPCt1ecODXeYuBjQfCP2m58DSPMEWwJ/UJf1UJbetutGiledg; Received: from box313.bluehost.com ([69.89.31.113]:38088 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YEhJS-0003Mr-R3; Fri, 23 Jan 2015 09:42:26 -0700 Message-ID: <54C279EE.3070200@labn.net> Date: Fri, 23 Jan 2015 11:42:22 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tomonori Takeda , Leeyoung , "rtg-ads@tools.ietf.org" References: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> In-Reply-To: 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: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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: Fri, 23 Jan 2015 16:42:40 -0000 Young, Can you review any changes planned as a result of the rtg-dir review? Please also include any specific language changes, that you may have already identified. Thanks, Lou (as doc Shepherd) On 01/23/2015 03:01 AM, Tomonori Takeda wrote: > Hi Young, > > OK, thanks, > > Tomonori > > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: Thursday, January 22, 2015 2:44 AM > To: Tomonori Takeda锛堟鐢扮煡鍏革級; Leeyoung; rtg-ads@tools.ietf.org > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org' > Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt > > Hi Tomonori, > > Thanks for your comment. Please see in-line for my response. Please let me know if the response would satisfy you. > > Best regards, > Young > > -----Original Message----- > From: Tomonori Takeda [mailto:tomonori.takeda@ntt.com] > Sent: Wednesday, January 21, 2015 12:48 AM > To: Leeyoung; rtg-ads@tools.ietf.org > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org'; Tomonori Takeda > Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt > > Hi Young, > > Thanks. > > Two follow-up questions/comments. > (I am fine with other points, which you already addressed in the updated draft.) > >> 2) In section 2.1, it says "two matrices will not have the same {src port, src label, dst port, dst label}". To be precise, I guess this should be > "two matrices will not have the same {src port, src label}, and two matrices will not have the same {dst port, dst label}"? >> >> YOUNG>> I think your suggestion may be too restrictive. For instance, if we have one source (port 1) and one destination (port 2) with two labels > each. Then we would have: {(1,1,2,1), (1,1,2,2), (1,2,2,1), (1,2,2,2)} I think with the current statement, we can send this info in any combination > of multiple matrices, which I think perfectly fine. With your suggestion, I would not be able send (1,1,2,1) and (1,1,2,2) together. Why would this > not be made possible? My take is as long as each submatrix represents a set of disjoint quadruples, that should be allowed. > > My reading of "two matrices will not have the same {src port, src label, dst port, dst label}" is as follows. > > > > input port=1 --> Submatrix#1 --> output port=2 > input label=1 output label=1 > > input port=1 --> Submatrix#2 --> output port=2 > input label=1 output label=2 > > This is allowed. > > > > input port=1 --> Submatrix#1 --> output port=2 > input label=1 output label=1 > > input port=1 --> Submatrix#2 --> output port=2 > input label=1 output label=1 > > This is not allowed. > > > > input port=1 --> Submatrix#1 --> output port=2 > input label=1 output label=1 > > input port=1 --> Submatrix#2 --> output port=2 > input label=2 output label=2 > > This is allowed. > > Is above understanding correct? > If so, I am not sure how example A works, since I am not sure what is the indentifier to direct from input to each submatrix. > > Maybe I am mis-understanding what sub-matrix is. I thought sub-matrix is a sort of virtual node, splitting the single matrix (or switch) into smaller pieces. > > YOUNG>> OK, I think the definition of submatrix was not clear. It is simply dividing up a matrix into several pieces in case the size of the matrix becomes too big or a way to advertize the changed port/label set in one place (sub-matrix) then other unchanged port/label set in other place (different sub-matrix). The identifier for each sub-matrix is the MATRIX ID. There is not separate identifier to direct from input. The input is a part of the sub-matrix. Say if we have N*M matrix that describes all input and output port/label. We might divide up into N*(M-L) and N*L or any other combinations as far as they are all disjoint from each other. > >> 4) In section 2.1, for Link Set A dir=bidirectional, Link Set B dir=bidirectional, if any signal on an input link X is output on a link Y, then any > signal on an input link Y is output on a link X (after cross-connect)? Or any constraint on such signal flow (after cross-connect) is out of scope? >> >> > I am not sure what "after cross-connect" is meant. > > > > Link set A: link#1, link#2, link#3 > Link set B: link#4, link#5, link#6 > > Both of Link set A and Link set B are specified as "dir". > > In this case, > - Is it possible to problem the cross-connect as input=link#1, output=link#4 > & input=link#5, output=link#1 simultaneolusly? > - Or is it automatically assumed if input=link#1, output=link#4, > then input=link#4, output=link#1? > - Or this sort of constraint is not specified in Link Set Field? > > The text seems like saying the first option, but I do not think this is a common equipment implementaion. > > YOUGN>> OK. I think I understand you more clearly. For this case (bidirectional link sets), the first case is definitely not the intention. The second case is assumed. > > Thanks, > Tomonori > > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: Tuesday, January 20, 2015 7:54 AM > To: Tomonori Takeda锛堟鐢扮煡鍏革級; rtg-ads@tools.ietf.org > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org' > Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt > > Hi Tomonori, > > Thanks for providing good comments. Here's my response. Please see in-line. > > Regards, > Young > > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Tomonori Takeda > Sent: Saturday, January 17, 2015 7:59 AM > To: rtg-ads@tools.ietf.org > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org' > Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see 鈥媓ttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. > > Document: draft-ietf-ccamp-general-constraint-encode-16.txt > Reviewer: Tomonori Takeda > Review Date: 17 January, 2015 > IETF LC End Date: 17 January, 2015 > Intended Status: Standards Track > > Summary: > > This document is basically ready for publication, but has nits that should be considered prior to publication. > > Comments: > > This document specifies protocol-agnostic encodings for general information elements described in draft-ietf-ccamp-rwa-info. > I think the document is in good shape but there are a few points that should be clarified for better understanding. > > Major Issues: > > None > > Minor Issues: > > None > > Nits: > > 1) In section 1.2, label continuity constraint (e.g., wavelength continuity in WSON) is mentioned. However, I am not sure whether information elements for which this document specifies encodings can describe such constraint. My reading is that information element such as Port Label Restriction is rather for describing wavelength tuning capabilities/restrictions. > > YOUNG>> Label continuity constraints can be inferred from the two places in the draft: (i) Port Label Restriction, which gives the set of labels (wavelengths) that may not be available on certain links including tuning range/restriction; (ii) Available/Shared Backup Label Fields (section 2.4 & section 2.5). There is no encoding for label continuity constraint per se. The aforementioned constraints are encoded to give a node or a PCE to be able to compute a path (i.e., path with wavelength continuity) subject to these constraints. > > 2) In section 2.1, it says "two matrices will not have the same {src port, src label, dst port, dst label}". To be precise, I guess this should be "two matrices will not have the same {src port, src label}, and two matrices will not have the same {dst port, dst label}"? > > YOUNG>> I think your suggestion may be too restrictive. For instance, if we have one source (port 1) and one destination (port 2) with two labels each. Then we would have: {(1,1,2,1), (1,1,2,2), (1,2,2,1), (1,2,2,2)} I think with the current statement, we can send this info in any combination of multiple matrices, which I think perfectly fine. With your suggestion, I would not be able send (1,1,2,1) and (1,1,2,2) together. Why would this not be made possible? My take is as long as each submatrix represents a set of disjoint quadruples, that should be allowed. > > 3) In section 2.1, it says "The value of 0xFF is reserved for use with port wavelength constraints". I think "port wavelength constraints" should be "port label restriction". > > YOUNG>> Yes, thanks. > > 4) In section 2.1, for Link Set A dir=bidirectional, Link Set B dir=bidirectional, if any signal on an input link X is output on a link Y, then any signal on an input link Y is output on a link X (after cross-connect)? Or any constraint on such signal flow (after cross-connect) is out of scope? > > YOUNG>> I am not sure what "after cross-connect" is meant. > > 5) In section 2.2.1, it says "In this case the accompanying label set indicates the labels permitted on the port." I think "port" should be "port/matrix". > > YOUNG>> Yes, thanks. > > 6) In section 2.2.2, it would be better to describe the type (e.g., integer) for MaxNumChannels. > This also applies for MaxLabelRange (in section 2.2.3) and Num Labels (in section 2.6). > > YOUNG>> OK. > > 7) In section 2.6, it says "Label Set Field is used within the or the ". But I think Label Set Field is also used within SIMPLE_LABEL, LABEL_RANGE and SIMPLE_LABEL & CHANNEL_COUNT. > > YOUNG>> Yes, it is used in multiple places. > > How about: > OLD: Label Set Field is used within the or the > , which is defined in Section 2.4. and 2.5., > respectively. > NEW: Label Set Field is used within the or the > , which is defined in Section 2.4. and 2.5., > respectively. It is also used within the , > , or , which is defined > in Sections 2.1.1 - 2.1.4, respectively. > > > Thanks, > Tomonori > From nobody Fri Jan 23 08:49: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 472591A87AC for ; Fri, 23 Jan 2015 08:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 pn0dYO-j7pbf for ; Fri, 23 Jan 2015 08:49:05 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1473B1A1AD8 for ; Fri, 23 Jan 2015 08:49:05 -0800 (PST) Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 23 Jan 2015 16:49:03 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.136]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.136]) with mapi id 15.01.0065.013; Fri, 23 Jan 2015 16:49:03 +0000 From: Gert Grammel To: "Lam, Hing-Kam (Kam)" , "adrian@olddog.co.uk" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyYVlxw97EbEt0aRBiXb7/iXxZzN6Tng Date: Fri, 23 Jan 2015 16:49:03 +0000 Message-ID: References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.55.14] authentication-results: alcatel-lucent.com; dkim=none (message not signed) header.d=none;alcatel-lucent.com; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR05MB041; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB041; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51704005)(13464003)(164054003)(24454002)(2950100001)(2900100001)(19300405004)(19625215002)(102836002)(15975445007)(76176999)(19609705001)(50986999)(54356999)(54606007)(33656002)(19580395003)(561944003)(19580405001)(86362001)(46102003)(92566002)(99286002)(106116001)(54206007)(230783001)(2656002)(87936001)(2501002)(16236675004)(40100003)(77156002)(62966003)(76576001)(66066001)(74316001)(122556002)(19617315012); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB041; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR05MB0411009341243A4FCC26E64CE360BN1PR05MB041namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 16:49:03.3096 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB041 Archived-At: Cc: "Doolan, Paul \(Coriant - US/Irving\)" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 23 Jan 2015 16:49:09 -0000 --_000_BN1PR05MB0411009341243A4FCC26E64CE360BN1PR05MB041namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kam, Is SG15 considering to host a registry for the vendor specific application = code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.= ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.8= 74.1 to amend the specification of ApplicationIdentifier with the following= additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString = represents a standard application code as defined in the ITU-T Recommendati= ons. If the ApplicationIdentifierType is PROPRIETARY, the first six charact= ers of the PrintableString must contain the Hexadecimal representation of a= n OUI assigned to the vendor whose implementation generated the Application= Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietar= y-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools= .ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-w= son-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel > wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a bool= ean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel > wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_BN1PR05MB0411009341243A4FCC26E64CE360BN1PR05MB041namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kam,

 

Is SG15 considering to= host a registry for the vendor specific application code or is the IETF re= gistry supposed to be used?

 

Thanks

 

Gert=

 

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs= @tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 meeting, Q= 14/15 agreed to update G.874.1 to amend the specification of ApplicationIde= ntifier with the following additional text:

 

If the ApplicationId= entifierType is STANDARD, the value of PrintableString represents a standar= d application code as defined in the ITU-T Recommendations. If the Applicat= ionIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal r= epresentation of an OUI assigned to the vendor whose implementation generat= ed the Application Identifier; the remaining octets of the PrintableString = are unspecified.

 

Paul Doolan had an I-D "https://tools.ietf.org/h= tml/draft-doolan-proprietary-ac-00" to the last IETF meeting with = the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM=

To: 'Giovanni Martinelli (giomarti)'

Cc: ccamp@ietf.= org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

Subject: [CCAMP] Vendor-Specific Application Code= in draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am not seeing= a specific conclusion from it.

 

The current I-D makes (IMHO) the Vendor-Specific = Application Code unusable. I offered three options:

 

1 This value is only to be used when it is known = that all devices

   participating in a network have the = same understanding of

   the content of the Vendor-Speci= fic Application Code field.

   How this knowledge is achieved is ou= tside the scope of this

   document

 

2 When this value is set, the first 32 (or 48) bi= ts of the Vendor-

  Specific Application Code field contain an= Enterprise Number

  (or OUI) that defines the context in which= the remainder of

  that field is interpreted.

 

3 Remove the option to include a Vendor-Specific = Application

   Code field.

 

If the WG could please pick one of these and help= Young to update the document.

 

Thanks,

Adrian

 

> -----Original Message-----

> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 13:50

> To: a= drian@olddog.co.uk

> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> ccamp@ietf= .org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of draft-ietf= -ccamp-rwa-wson-encode

>

> One additional comment (hoping not additiona= l confusion).

>

> The idea about Optical Interface Class was t= aken from SRLG. Good or

> bad is a plain number and you do simple oper= ations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, Giovanni Martinell= i (giomarti)

> <gi= omarti@cisco.com>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel= <adrian@olddog.co.uk> wro= te:

> >

> >> Hi,

> >>

> >> Well, you seem to have a half-way h= ouse.

> >>

> >> You have specified the existence of= a thing, but not how to read it.

> >>

> >> If you wanted to make a statement t= hat this object will only be

> >> used when

it is

> >> known that all systems in a network= come from the same vendor

> >> and/or have

> the

> >> same understanding of the encoding,= that might be OK (although how

> >> you

> would

> >> ascertain this might also need to b= e described).

> >>

> >

> > The statement is to ensure the interfac= e compatibility without

> > encoding all

the

> possible details and parameter that define a= n interface (e.g.

> modulation

format,

> forward error correction etc.). This was the= initial solution in the

> draft

then

> replaced by the interface class concept.&nbs= p;  The WSON (RWA-only) has the

> requirement is to make sure two interface ar= e compatible. This

> requirement, imho, can be satisfy by a simpl= e comparison which has a boolean result.

> >

> > We end up then in  the ITU applica= tion codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatib= ility where proper

> encoding is provided.

> >

> >

> >> Or you could entirely remove the ve= ndor-specific option.

> >>

> >> Or you could put in an OUI / enterp= rise number followed by

> >> transparent

> bytes.

> >>

> >

> > To me I'm perfectly fine with the secon= d option.

> >

> > Cheers

> > G

> >

> >

> >> Adrian

> >>

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

> >>> From: Giovanni Martinelli (giom= arti) [mailto:giomarti@cisco.com]=

> >>> Sent: 21 January 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>

> >>> Subject: Re: [CCAMP] AD review = of draft-ietf-ccamp-rwa-wson-encode

> >>>

> >>> Specifically to the Interface c= lass here below.

> >>>

> >>> In the initial draft merged to = this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) = we decided to remove any encoding

> >>> when the Interface class is not= standard.

> >>> In term of semantic the protcol= does not need to decode the

> >>> Interface

class

> >> since

> >>> it only assess the interface co= mpatibility if two interfaces has a

> >>> class

value

> >> that

> >>> match two interfaces cann be co= nnected.

> >>>

> >>> Having saying that I don't have= strong opinion in adding the OUI

> >>> or

leaving

> >> room

> >>> for maybe future public interfa= ces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility= assesment since there optical

> >>> multivendor compatibility has b= een already demonstrated.

> >>>

> >>> hope this help .

> >>>

> >>> Cheers

> >>> G

> >>>

> >>>

> >>> On 21 Jan 2015, at 21:57, Adria= n Farrel <adrian@olddog.co.uk= > wrote:

> >>>

> >>>>>>

> >>>>>> Section 4.1

> >>>>>> How do I interpret = a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?=

> >>>>>

> >>>>> [YOUNG] Not sure if I u= nderstood this question. What is "OUI"?

> >>>>

> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier

> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> numbers.xhtml#ieee-802

> >>>> -numbers-2

> >>>>

> >>>> Or perhaps an Enterprise Nu= mber

> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> >>>>

> >>>> The question is:=

> >>>>

> >>>> You have sections 4.1.1 thr= ough 4.1.4 to tell me how to interpret

> >>>> the

> >> Optical

> >>>> Interface Class field when = it contains an ITU-T Application Mapping.

> >>>> When I received s=3D0 and O= I=3D1 it means that the Optical Interface

> >>>> Class

> >> contains

> >>>> a "Vendor Specific Opt= ical Interface Class".

> >>>> How do I interpret that Opt= ical Interface Class?

> >>>> Which vendor does it apply = to?

> >>>> Is there some information e= lsewhere that gives me a clue as to

> >>>> which

> vendor

> >>> has

> >>>> encoded the information?

> >>>> Or is the information suppo= sed to be encoded in the Optical

> >>>> Interface

Class,

> >>>> perhaps as the first 48 bit= s?

> >>>> Or am I supposed to know by= context?

> >>

> >

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/ccamp

--_000_BN1PR05MB0411009341243A4FCC26E64CE360BN1PR05MB041namprd_-- From nobody Fri Jan 23 08:51: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 1B15B1A87AC; Fri, 23 Jan 2015 08:51:55 -0800 (PST) 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 dE995EGUf3jK; Fri, 23 Jan 2015 08:51:52 -0800 (PST) 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 A7E761A1AD0; Fri, 23 Jan 2015 08:51:50 -0800 (PST) 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 BOJ03384; Fri, 23 Jan 2015 16:51:49 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 16:51:48 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 08:51:43 -0800 From: Leeyoung To: Lou Berger , Tomonori Takeda , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt Thread-Index: AQHQNyua4bPWa0fjYUSk1DJvggIdkZzN6UpA Date: Fri, 23 Jan 2015 16:51:43 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7E063@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> <54C279EE.3070200@labn.net> In-Reply-To: <54C279EE.3070200@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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: Fri, 23 Jan 2015 16:51:55 -0000 SGkgTG91LA0KDQpBcmUgeW91IHJlZmVycmluZyAnYW55IHNwZWNpZmljIGxhbmd1YWdlIGNoYW5n ZXMnIHRvIEFkcmlhbidzICdSZXNvdXJjZScgbGFuZ3VhZ2U/IElmIHNvLCB5ZXMsIEkgZXhwZWN0 IEFkcmlhbidzIGlucHV0IG9uIHdoZXJlIHRvIHBsYWNlIGFueSBjaGFuZ2VzIGluIHRoZSBkcmFm dC4gT3RoZXIgdGhhbiB0aGF0IEkgYmVsaWV2ZSB0aGUgdmVyc2lvbiAxNyAod2hpY2ggd2FzIHB1 Ymxpc2hlZCkgcmVmbGVjdHMgVG9tb25vcmkncyBydGctZGlyIHJldmlldy4gTGV0IG1lIGtub3cg aWYgeW91IGJlbGlldmUgYW55IG90aGVyIGFzcGVjdCAob3RoZXIgdGhhbiAncmVzb3VyY2UnIGxh bmd1YWdlKSBzaG91bGQgYmUgdXBkYXRlZCBpbiB0aGUgdXBjb21pbmcgdmVyc2lvbiAxOC4NCg0K VGhhbmtzLA0KWW91bmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBC ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANClNlbnQ6IEZyaWRheSwgSmFudWFyeSAy MywgMjAxNSAxMDo0MiBBTQ0KVG86IFRvbW9ub3JpIFRha2VkYTsgTGVleW91bmc7IHJ0Zy1hZHNA dG9vbHMuaWV0Zi5vcmcNCkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdkcmFmdC1pZXRmLWNjYW1w LWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnJzsgJ2NjYW1wQGll dGYub3JnJw0KU3ViamVjdDogUmU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRm LWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGUtMTYudHh0DQoNCllvdW5nLA0KCUNhbiB5 b3UgcmV2aWV3IGFueSBjaGFuZ2VzIHBsYW5uZWQgYXMgYSByZXN1bHQgb2YgdGhlIHJ0Zy1kaXIg cmV2aWV3Pw0KUGxlYXNlIGFsc28gaW5jbHVkZSBhbnkgc3BlY2lmaWMgbGFuZ3VhZ2UgY2hhbmdl cywgdGhhdCB5b3UgbWF5IGhhdmUNCmFscmVhZHkgaWRlbnRpZmllZC4NCg0KVGhhbmtzLA0KTG91 IChhcyBkb2MgU2hlcGhlcmQpDQoNCk9uIDAxLzIzLzIwMTUgMDM6MDEgQU0sIFRvbW9ub3JpIFRh a2VkYSB3cm90ZToNCj4gSGkgWW91bmcsDQo+IA0KPiBPSywgdGhhbmtzLA0KPiANCj4gVG9tb25v cmkNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExlZXlvdW5nIFtt YWlsdG86bGVleW91bmdAaHVhd2VpLmNvbV0gDQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDIy LCAyMDE1IDI6NDQgQU0NCj4gVG86IFRvbW9ub3JpIFRha2VkYe+8iOatpueUsOefpeWFuO+8iTsg TGVleW91bmc7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6ICdydGctZGlyQGlldGYub3Jn JzsgJ2RyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS5hbGxAdG9vbHMu aWV0Zi5vcmcnOyAnY2NhbXBAaWV0Zi5vcmcnDQo+IFN1YmplY3Q6IFJFOiBbUlRHLURJUl0gUnRn RGlyIHJldmlldzogZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLTE2 LnR4dA0KPiANCj4gSGkgVG9tb25vcmksDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudC4g UGxlYXNlIHNlZSBpbi1saW5lIGZvciBteSByZXNwb25zZS4gUGxlYXNlIGxldCBtZSBrbm93IGlm IHRoZSByZXNwb25zZSB3b3VsZCBzYXRpc2Z5IHlvdS4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+ IFlvdW5nDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUb21vbm9y aSBUYWtlZGEgW21haWx0bzp0b21vbm9yaS50YWtlZGFAbnR0LmNvbV0gDQo+IFNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAyMSwgMjAxNSAxMjo0OCBBTQ0KPiBUbzogTGVleW91bmc7IHJ0Zy1hZHNA dG9vbHMuaWV0Zi5vcmcNCj4gQ2M6ICdydGctZGlyQGlldGYub3JnJzsgJ2RyYWZ0LWlldGYtY2Nh bXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcnOyAnY2NhbXBA aWV0Zi5vcmcnOyBUb21vbm9yaSBUYWtlZGENCj4gU3ViamVjdDogUkU6IFtSVEctRElSXSBSdGdE aXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGUtMTYu dHh0DQo+IA0KPiBIaSBZb3VuZywNCj4gDQo+IFRoYW5rcy4NCj4gDQo+IFR3byBmb2xsb3ctdXAg cXVlc3Rpb25zL2NvbW1lbnRzLg0KPiAoSSBhbSBmaW5lIHdpdGggb3RoZXIgcG9pbnRzLCB3aGlj aCB5b3UgYWxyZWFkeSBhZGRyZXNzZWQgaW4gdGhlIHVwZGF0ZWQgZHJhZnQuKQ0KPiANCj4+IDIp IEluIHNlY3Rpb24gMi4xLCBpdCBzYXlzICJ0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2ZSB0aGUg c2FtZSB7c3JjIHBvcnQsIHNyYyBsYWJlbCwgZHN0IHBvcnQsIGRzdCBsYWJlbH0iLiBUbyBiZSBw cmVjaXNlLCBJIGd1ZXNzIHRoaXMgc2hvdWxkIGJlID4gInR3byBtYXRyaWNlcyB3aWxsIG5vdCBo YXZlIHRoZSBzYW1lIHtzcmMgcG9ydCwgc3JjIGxhYmVsfSwgYW5kIHR3byBtYXRyaWNlcyB3aWxs IG5vdCBoYXZlIHRoZSBzYW1lIHtkc3QgcG9ydCwgZHN0IGxhYmVsfSI/DQo+Pg0KPj4gWU9VTkc+ PiBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlvbiBtYXkgYmUgdG9vIHJlc3RyaWN0aXZlLiBGb3IgaW5z dGFuY2UsIGlmIHdlIGhhdmUgb25lIHNvdXJjZSAocG9ydCAxKSBhbmQgb25lIGRlc3RpbmF0aW9u IChwb3J0IDIpIHdpdGggdHdvIGxhYmVscyA+IGVhY2guIFRoZW4gd2Ugd291bGQgaGF2ZTogeygx LDEsMiwxKSwgKDEsMSwyLDIpLCAoMSwyLDIsMSksICgxLDIsMiwyKX0gSSB0aGluayB3aXRoIHRo ZSBjdXJyZW50IHN0YXRlbWVudCwgd2UgY2FuIHNlbmQgdGhpcyBpbmZvIGluIGFueSBjb21iaW5h dGlvbiA+IG9mIG11bHRpcGxlIG1hdHJpY2VzLCB3aGljaCBJIHRoaW5rIHBlcmZlY3RseSBmaW5l LiBXaXRoIHlvdXIgc3VnZ2VzdGlvbiwgSSB3b3VsZCBub3QgYmUgYWJsZSBzZW5kICgxLDEsMiwx KSBhbmQgKDEsMSwyLDIpIHRvZ2V0aGVyLiBXaHkgd291bGQgdGhpcyA+IG5vdCBiZSBtYWRlIHBv c3NpYmxlPyBNeSB0YWtlIGlzIGFzIGxvbmcgYXMgZWFjaCBzdWJtYXRyaXggcmVwcmVzZW50cyBh IHNldCBvZiBkaXNqb2ludCBxdWFkcnVwbGVzLCB0aGF0IHNob3VsZCBiZSBhbGxvd2VkLg0KPiAN Cj4gTXkgcmVhZGluZyBvZiAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge3Ny YyBwb3J0LCBzcmMgbGFiZWwsIGRzdCBwb3J0LCBkc3QgbGFiZWx9IiBpcyBhcyBmb2xsb3dzLg0K PiANCj4gPEV4YW1wbGUgQT4NCj4gDQo+ICAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzEg LS0+IG91dHB1dCBwb3J0PTINCj4gICBpbnB1dCBsYWJlbD0xICAgICAgICAgICAgICAgICAgICAg b3V0cHV0IGxhYmVsPTENCj4gDQo+ICAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzIgLS0+ IG91dHB1dCBwb3J0PTINCj4gICBpbnB1dCBsYWJlbD0xICAgICAgICAgICAgICAgICAgICAgb3V0 cHV0IGxhYmVsPTINCj4gDQo+ICAgVGhpcyBpcyBhbGxvd2VkLg0KPiANCj4gPEV4YW1wbGUgQj4N Cj4gDQo+ICAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzEgLS0+IG91dHB1dCBwb3J0PTIN Cj4gICBpbnB1dCBsYWJlbD0xICAgICAgICAgICAgICAgICAgICAgb3V0cHV0IGxhYmVsPTENCj4g DQo+ICAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzIgLS0+IG91dHB1dCBwb3J0PTINCj4g ICBpbnB1dCBsYWJlbD0xICAgICAgICAgICAgICAgICAgICAgb3V0cHV0IGxhYmVsPTENCj4gDQo+ ICAgVGhpcyBpcyBub3QgYWxsb3dlZC4NCj4gDQo+IDxFeGFtcGxlIEM+DQo+IA0KPiAgIGlucHV0 IHBvcnQ9MSAgLS0+IFN1Ym1hdHJpeCMxIC0tPiBvdXRwdXQgcG9ydD0yDQo+ICAgaW5wdXQgbGFi ZWw9MSAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0xDQo+IA0KPiAgIGlucHV0IHBv cnQ9MSAgLS0+IFN1Ym1hdHJpeCMyIC0tPiBvdXRwdXQgcG9ydD0yDQo+ICAgaW5wdXQgbGFiZWw9 MiAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0yDQo+IA0KPiAgIFRoaXMgaXMgYWxs b3dlZC4NCj4gDQo+IElzIGFib3ZlIHVuZGVyc3RhbmRpbmcgY29ycmVjdD8NCj4gSWYgc28sIEkg YW0gbm90IHN1cmUgaG93IGV4YW1wbGUgQSB3b3Jrcywgc2luY2UgSSBhbSBub3Qgc3VyZSB3aGF0 IGlzIHRoZSBpbmRlbnRpZmllciB0byBkaXJlY3QgZnJvbSBpbnB1dCB0byBlYWNoIHN1Ym1hdHJp eC4NCj4gDQo+IE1heWJlIEkgYW0gbWlzLXVuZGVyc3RhbmRpbmcgd2hhdCBzdWItbWF0cml4IGlz LiBJIHRob3VnaHQgc3ViLW1hdHJpeCBpcyBhIHNvcnQgb2YgdmlydHVhbCBub2RlLCBzcGxpdHRp bmcgdGhlIHNpbmdsZSBtYXRyaXggKG9yIHN3aXRjaCkgaW50byBzbWFsbGVyIHBpZWNlcy4NCj4g DQo+IFlPVU5HPj4gT0ssIEkgdGhpbmsgdGhlIGRlZmluaXRpb24gb2Ygc3VibWF0cml4IHdhcyBu b3QgY2xlYXIuIEl0IGlzIHNpbXBseSBkaXZpZGluZyB1cCBhIG1hdHJpeCBpbnRvIHNldmVyYWwg cGllY2VzIGluIGNhc2UgdGhlIHNpemUgb2YgdGhlIG1hdHJpeCBiZWNvbWVzIHRvbyBiaWcgb3Ig YSB3YXkgdG8gYWR2ZXJ0aXplIHRoZSBjaGFuZ2VkIHBvcnQvbGFiZWwgc2V0IGluIG9uZSBwbGFj ZSAoc3ViLW1hdHJpeCkgdGhlbiBvdGhlciB1bmNoYW5nZWQgcG9ydC9sYWJlbCBzZXQgaW4gb3Ro ZXIgcGxhY2UgKGRpZmZlcmVudCBzdWItbWF0cml4KS4gVGhlIGlkZW50aWZpZXIgZm9yIGVhY2gg c3ViLW1hdHJpeCBpcyB0aGUgTUFUUklYIElELiBUaGVyZSBpcyBub3Qgc2VwYXJhdGUgaWRlbnRp ZmllciB0byBkaXJlY3QgZnJvbSBpbnB1dC4gVGhlIGlucHV0IGlzIGEgcGFydCBvZiB0aGUgc3Vi LW1hdHJpeC4gU2F5IGlmIHdlIGhhdmUgTipNIG1hdHJpeCB0aGF0IGRlc2NyaWJlcyBhbGwgaW5w dXQgYW5kIG91dHB1dCBwb3J0L2xhYmVsLiBXZSBtaWdodCBkaXZpZGUgdXAgaW50byBOKihNLUwp IGFuZCBOKkwgb3IgYW55IG90aGVyIGNvbWJpbmF0aW9ucyBhcyBmYXIgYXMgdGhleSBhcmUgYWxs IGRpc2pvaW50IGZyb20gZWFjaCBvdGhlci4gDQo+IA0KPj4gNCkgSW4gc2VjdGlvbiAyLjEsIGZv ciBMaW5rIFNldCBBIGRpcj1iaWRpcmVjdGlvbmFsLCBMaW5rIFNldCBCIGRpcj1iaWRpcmVjdGlv bmFsLCBpZiBhbnkgc2lnbmFsIG9uIGFuIGlucHV0IGxpbmsgWCBpcyBvdXRwdXQgb24gYSBsaW5r IFksIHRoZW4gYW55ID4gc2lnbmFsIG9uIGFuIGlucHV0IGxpbmsgWSBpcyBvdXRwdXQgb24gYSBs aW5rIFggKGFmdGVyIGNyb3NzLWNvbm5lY3QpPyBPciBhbnkgY29uc3RyYWludCBvbiBzdWNoIHNp Z25hbCBmbG93IChhZnRlciBjcm9zcy1jb25uZWN0KSBpcyBvdXQgb2Ygc2NvcGU/DQo+Pg0KPj4g PFlPVU5HPj4gSSBhbSBub3Qgc3VyZSB3aGF0ICJhZnRlciBjcm9zcy1jb25uZWN0IiBpcyBtZWFu dC4NCj4gDQo+IDxFeGFtcGxlPg0KPiANCj4gICBMaW5rIHNldCBBOiBsaW5rIzEsIGxpbmsjMiwg bGluayMzDQo+ICAgTGluayBzZXQgQjogbGluayM0LCBsaW5rIzUsIGxpbmsjNg0KPiANCj4gICBC b3RoIG9mIExpbmsgc2V0IEEgYW5kIExpbmsgc2V0IEIgYXJlIHNwZWNpZmllZCBhcyAiZGlyIi4N Cj4gDQo+ICAgSW4gdGhpcyBjYXNlLA0KPiAgIC0gSXMgaXQgcG9zc2libGUgdG8gcHJvYmxlbSB0 aGUgY3Jvc3MtY29ubmVjdCBhcyBpbnB1dD1saW5rIzEsIG91dHB1dD1saW5rIzQNCj4gICAgICYg aW5wdXQ9bGluayM1LCBvdXRwdXQ9bGluayMxIHNpbXVsdGFuZW9sdXNseT8NCj4gICAtIE9yIGlz IGl0IGF1dG9tYXRpY2FsbHkgYXNzdW1lZCBpZiBpbnB1dD1saW5rIzEsIG91dHB1dD1saW5rIzQs DQo+ICAgICB0aGVuIGlucHV0PWxpbmsjNCwgb3V0cHV0PWxpbmsjMT8NCj4gICAtIE9yIHRoaXMg c29ydCBvZiBjb25zdHJhaW50IGlzIG5vdCBzcGVjaWZpZWQgaW4gTGluayBTZXQgRmllbGQ/DQo+ IA0KPiBUaGUgdGV4dCBzZWVtcyBsaWtlIHNheWluZyB0aGUgZmlyc3Qgb3B0aW9uLCBidXQgSSBk byBub3QgdGhpbmsgdGhpcyBpcyBhIGNvbW1vbiBlcXVpcG1lbnQgaW1wbGVtZW50YWlvbi4NCj4g DQo+IFlPVUdOPj4gT0suIEkgdGhpbmsgSSB1bmRlcnN0YW5kIHlvdSBtb3JlIGNsZWFybHkuIEZv ciB0aGlzIGNhc2UgKGJpZGlyZWN0aW9uYWwgbGluayBzZXRzKSwgdGhlIGZpcnN0IGNhc2UgaXMg ZGVmaW5pdGVseSBub3QgdGhlIGludGVudGlvbi4gVGhlIHNlY29uZCBjYXNlIGlzIGFzc3VtZWQu IA0KPiANCj4gVGhhbmtzLA0KPiBUb21vbm9yaQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXSANCj4g U2VudDogVHVlc2RheSwgSmFudWFyeSAyMCwgMjAxNSA3OjU0IEFNDQo+IFRvOiBUb21vbm9yaSBU YWtlZGHvvIjmrabnlLDnn6XlhbjvvIk7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6ICdy dGctZGlyQGlldGYub3JnJzsgJ2RyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVu Y29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcnOyAnY2NhbXBAaWV0Zi5vcmcnDQo+IFN1YmplY3Q6IFJF OiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0 cmFpbnQtZW5jb2RlLTE2LnR4dA0KPiANCj4gSGkgVG9tb25vcmksDQo+IA0KPiBUaGFua3MgZm9y IHByb3ZpZGluZyBnb29kIGNvbW1lbnRzLiBIZXJlJ3MgbXkgcmVzcG9uc2UuIFBsZWFzZSBzZWUg aW4tbGluZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IFlvdW5nDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBydGctZGlyIFttYWlsdG86cnRnLWRpci1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgVG9tb25vcmkgVGFrZWRhDQo+IFNlbnQ6IFNhdHVyZGF5LCBKYW51 YXJ5IDE3LCAyMDE1IDc6NTkgQU0NCj4gVG86IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6 ICdydGctZGlyQGlldGYub3JnJzsgJ2RyYWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50 LWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcnOyAnY2NhbXBAaWV0Zi5vcmcnDQo+IFN1YmplY3Q6 IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3Ry YWludC1lbmNvZGUtMTYudHh0DQo+IA0KPiBIZWxsbywgDQo+IA0KPiBJIGhhdmUgYmVlbiBzZWxl Y3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4g VGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJv dXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwg YW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1 cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRp bmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFj L3dpa2kvUnRnRGlyIA0KPiANCj4gQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmls eSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYg eW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENh bGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0g dGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4gDQo+IA0KPiBEb2N1 bWVudDogZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLTE2LnR4dCAN Cj4gUmV2aWV3ZXI6IFRvbW9ub3JpIFRha2VkYQ0KPiBSZXZpZXcgRGF0ZTogMTcgSmFudWFyeSwg MjAxNQ0KPiBJRVRGIExDIEVuZCBEYXRlOiAxNyBKYW51YXJ5LCAyMDE1DQo+IEludGVuZGVkIFN0 YXR1czogU3RhbmRhcmRzIFRyYWNrDQo+IA0KPiBTdW1tYXJ5Og0KPiANCj4gVGhpcyBkb2N1bWVu dCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBz aG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBwdWJsaWNhdGlvbi4NCj4gDQo+IENvbW1lbnRz Og0KPiANCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgcHJvdG9jb2wtYWdub3N0aWMgZW5jb2Rp bmdzIGZvciBnZW5lcmFsIGluZm9ybWF0aW9uIGVsZW1lbnRzIGRlc2NyaWJlZCBpbiBkcmFmdC1p ZXRmLWNjYW1wLXJ3YS1pbmZvLg0KPiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBpbiBnb29kIHNo YXBlIGJ1dCB0aGVyZSBhcmUgYSBmZXcgcG9pbnRzIHRoYXQgc2hvdWxkIGJlIGNsYXJpZmllZCBm b3IgYmV0dGVyIHVuZGVyc3RhbmRpbmcuDQo+IA0KPiBNYWpvciBJc3N1ZXM6DQo+IA0KPiBOb25l DQo+IA0KPiBNaW5vciBJc3N1ZXM6DQo+IA0KPiBOb25lDQo+IA0KPiBOaXRzOg0KPiANCj4gMSkg SW4gc2VjdGlvbiAxLjIsIGxhYmVsIGNvbnRpbnVpdHkgY29uc3RyYWludCAoZS5nLiwgd2F2ZWxl bmd0aCBjb250aW51aXR5IGluIFdTT04pIGlzIG1lbnRpb25lZC4gSG93ZXZlciwgSSBhbSBub3Qg c3VyZSB3aGV0aGVyIGluZm9ybWF0aW9uIGVsZW1lbnRzIGZvciB3aGljaCB0aGlzIGRvY3VtZW50 IHNwZWNpZmllcyBlbmNvZGluZ3MgY2FuIGRlc2NyaWJlIHN1Y2ggY29uc3RyYWludC4gTXkgcmVh ZGluZyBpcyB0aGF0IGluZm9ybWF0aW9uIGVsZW1lbnQgc3VjaCBhcyBQb3J0IExhYmVsIFJlc3Ry aWN0aW9uIGlzIHJhdGhlciBmb3IgZGVzY3JpYmluZyB3YXZlbGVuZ3RoIHR1bmluZyBjYXBhYmls aXRpZXMvcmVzdHJpY3Rpb25zLg0KPiANCj4gWU9VTkc+PiBMYWJlbCBjb250aW51aXR5IGNvbnN0 cmFpbnRzIGNhbiBiZSBpbmZlcnJlZCBmcm9tIHRoZSB0d28gcGxhY2VzIGluIHRoZSBkcmFmdDog KGkpIFBvcnQgTGFiZWwgUmVzdHJpY3Rpb24sIHdoaWNoIGdpdmVzIHRoZSBzZXQgb2YgbGFiZWxz ICh3YXZlbGVuZ3RocykgdGhhdCBtYXkgbm90IGJlIGF2YWlsYWJsZSBvbiBjZXJ0YWluIGxpbmtz IGluY2x1ZGluZyB0dW5pbmcgcmFuZ2UvcmVzdHJpY3Rpb247IChpaSkgQXZhaWxhYmxlL1NoYXJl ZCBCYWNrdXAgTGFiZWwgRmllbGRzIChzZWN0aW9uIDIuNCAmIHNlY3Rpb24gMi41KS4gVGhlcmUg aXMgbm8gZW5jb2RpbmcgZm9yIGxhYmVsIGNvbnRpbnVpdHkgY29uc3RyYWludCBwZXIgc2UuIFRo ZSBhZm9yZW1lbnRpb25lZCBjb25zdHJhaW50cyBhcmUgZW5jb2RlZCB0byBnaXZlIGEgbm9kZSBv ciBhIFBDRSB0byBiZSBhYmxlIHRvIGNvbXB1dGUgYSBwYXRoIChpLmUuLCBwYXRoIHdpdGggd2F2 ZWxlbmd0aCBjb250aW51aXR5KSBzdWJqZWN0IHRvIHRoZXNlIGNvbnN0cmFpbnRzLiANCj4gDQo+ IDIpIEluIHNlY3Rpb24gMi4xLCBpdCBzYXlzICJ0d28gbWF0cmljZXMgd2lsbCBub3QgaGF2ZSB0 aGUgc2FtZSB7c3JjIHBvcnQsIHNyYyBsYWJlbCwgZHN0IHBvcnQsIGRzdCBsYWJlbH0iLiBUbyBi ZSBwcmVjaXNlLCBJIGd1ZXNzIHRoaXMgc2hvdWxkIGJlICJ0d28gbWF0cmljZXMgd2lsbCBub3Qg aGF2ZSB0aGUgc2FtZSB7c3JjIHBvcnQsIHNyYyBsYWJlbH0sIGFuZCB0d28gbWF0cmljZXMgd2ls bCBub3QgaGF2ZSB0aGUgc2FtZSB7ZHN0IHBvcnQsIGRzdCBsYWJlbH0iPw0KPiANCj4gWU9VTkc+ PiBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlvbiBtYXkgYmUgdG9vIHJlc3RyaWN0aXZlLiBGb3IgaW5z dGFuY2UsIGlmIHdlIGhhdmUgb25lIHNvdXJjZSAocG9ydCAxKSBhbmQgb25lIGRlc3RpbmF0aW9u IChwb3J0IDIpIHdpdGggdHdvIGxhYmVscyBlYWNoLiBUaGVuIHdlIHdvdWxkIGhhdmU6IHsoMSwx LDIsMSksICgxLDEsMiwyKSwgKDEsMiwyLDEpLCAoMSwyLDIsMil9IEkgdGhpbmsgd2l0aCB0aGUg Y3VycmVudCBzdGF0ZW1lbnQsIHdlIGNhbiBzZW5kIHRoaXMgaW5mbyBpbiBhbnkgY29tYmluYXRp b24gb2YgbXVsdGlwbGUgbWF0cmljZXMsIHdoaWNoIEkgdGhpbmsgcGVyZmVjdGx5IGZpbmUuIFdp dGggeW91ciBzdWdnZXN0aW9uLCBJIHdvdWxkIG5vdCBiZSBhYmxlIHNlbmQgKDEsMSwyLDEpIGFu ZCAoMSwxLDIsMikgdG9nZXRoZXIuIFdoeSB3b3VsZCB0aGlzIG5vdCBiZSBtYWRlIHBvc3NpYmxl PyBNeSB0YWtlIGlzIGFzIGxvbmcgYXMgZWFjaCBzdWJtYXRyaXggcmVwcmVzZW50cyBhIHNldCBv ZiBkaXNqb2ludCBxdWFkcnVwbGVzLCB0aGF0IHNob3VsZCBiZSBhbGxvd2VkLiANCj4gDQo+IDMp IEluIHNlY3Rpb24gMi4xLCBpdCBzYXlzICJUaGUgdmFsdWUgb2YgMHhGRiBpcyByZXNlcnZlZCBm b3IgdXNlIHdpdGggcG9ydCB3YXZlbGVuZ3RoIGNvbnN0cmFpbnRzIi4gSSB0aGluayAicG9ydCB3 YXZlbGVuZ3RoIGNvbnN0cmFpbnRzIiBzaG91bGQgYmUgInBvcnQgbGFiZWwgcmVzdHJpY3Rpb24i Lg0KPiANCj4gWU9VTkc+PiBZZXMsIHRoYW5rcy4gDQo+IA0KPiA0KSBJbiBzZWN0aW9uIDIuMSwg Zm9yIExpbmsgU2V0IEEgZGlyPWJpZGlyZWN0aW9uYWwsIExpbmsgU2V0IEIgZGlyPWJpZGlyZWN0 aW9uYWwsIGlmIGFueSBzaWduYWwgb24gYW4gaW5wdXQgbGluayBYIGlzIG91dHB1dCBvbiBhIGxp bmsgWSwgdGhlbiBhbnkgc2lnbmFsIG9uIGFuIGlucHV0IGxpbmsgWSBpcyBvdXRwdXQgb24gYSBs aW5rIFggKGFmdGVyIGNyb3NzLWNvbm5lY3QpPyBPciBhbnkgY29uc3RyYWludCBvbiBzdWNoIHNp Z25hbCBmbG93IChhZnRlciBjcm9zcy1jb25uZWN0KSBpcyBvdXQgb2Ygc2NvcGU/DQo+IA0KPiBZ T1VORz4+IEkgYW0gbm90IHN1cmUgd2hhdCAiYWZ0ZXIgY3Jvc3MtY29ubmVjdCIgaXMgbWVhbnQu IA0KPiANCj4gNSkgSW4gc2VjdGlvbiAyLjIuMSwgaXQgc2F5cyAiSW4gdGhpcyBjYXNlIHRoZSBh Y2NvbXBhbnlpbmcgbGFiZWwgc2V0IGluZGljYXRlcyB0aGUgbGFiZWxzIHBlcm1pdHRlZCBvbiB0 aGUgcG9ydC4iIEkgdGhpbmsgInBvcnQiIHNob3VsZCBiZSAicG9ydC9tYXRyaXgiLg0KPiANCj4g WU9VTkc+PiBZZXMsIHRoYW5rcy4gDQo+IA0KPiA2KSBJbiBzZWN0aW9uIDIuMi4yLCBpdCB3b3Vs ZCBiZSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIHR5cGUgKGUuZy4sIGludGVnZXIpIGZvciBNYXhO dW1DaGFubmVscy4NCj4gVGhpcyBhbHNvIGFwcGxpZXMgZm9yIE1heExhYmVsUmFuZ2UgKGluIHNl Y3Rpb24gMi4yLjMpIGFuZCBOdW0gTGFiZWxzIChpbiBzZWN0aW9uIDIuNikuDQo+IA0KPiBZT1VO Rz4+IE9LLiANCj4gDQo+IDcpIEluIHNlY3Rpb24gMi42LCBpdCBzYXlzICJMYWJlbCBTZXQgRmll bGQgaXMgdXNlZCB3aXRoaW4gdGhlIDxBdmFpbGFibGVMYWJlbHM+IG9yIHRoZSA8U2hhcmVkQmFj a3VwTGFiZWxzPiIuIEJ1dCBJIHRoaW5rIExhYmVsIFNldCBGaWVsZCBpcyBhbHNvIHVzZWQgd2l0 aGluIFNJTVBMRV9MQUJFTCwgTEFCRUxfUkFOR0UgYW5kIFNJTVBMRV9MQUJFTCAmIENIQU5ORUxf Q09VTlQuDQo+IA0KPiBZT1VORz4+IFllcywgaXQgaXMgdXNlZCBpbiBtdWx0aXBsZSBwbGFjZXMu IA0KPiANCj4gSG93IGFib3V0Og0KPiBPTEQ6IExhYmVsIFNldCBGaWVsZCBpcyB1c2VkIHdpdGhp biB0aGUgPEF2YWlsYWJsZUxhYmVscz4gb3IgdGhlDQo+ICAgIDxTaGFyZWRCYWNrdXBMYWJlbHM+ LCB3aGljaCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMi40LiBhbmQgMi41LiwNCj4gICAgcmVzcGVj dGl2ZWx5Lg0KPiBORVc6IExhYmVsIFNldCBGaWVsZCBpcyB1c2VkIHdpdGhpbiB0aGUgPEF2YWls YWJsZUxhYmVscz4gb3IgdGhlDQo+ICAgIDxTaGFyZWRCYWNrdXBMYWJlbHM+LCB3aGljaCBpcyBk ZWZpbmVkIGluIFNlY3Rpb24gMi40LiBhbmQgMi41LiwNCj4gICAgcmVzcGVjdGl2ZWx5LiBJdCBp cyBhbHNvIHVzZWQgd2l0aGluIHRoZSA8U0lNUExFX0xBQkVMPiwgDQo+ICAgIDxMQUJFTF9SQU5H RT4sIDxTSU1QTEVfTEFCRUw+IG9yIDxDSEFOTkVMX0NPVU5UPiwgd2hpY2ggaXMgZGVmaW5lZA0K PiAgICBpbiBTZWN0aW9ucyAyLjEuMSAtIDIuMS40LCByZXNwZWN0aXZlbHkuIA0KPiANCj4gDQo+ IFRoYW5rcywNCj4gVG9tb25vcmkNCj4gDQoNCg== From nobody Fri Jan 23 09:09: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 16A9F1A8BC2 for ; Fri, 23 Jan 2015 09:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 F6Wnkk_nWwqZ for ; Fri, 23 Jan 2015 09:09:41 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FAA1A1ADB for ; Fri, 23 Jan 2015 09:09:39 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 3110DF77A8B36; Fri, 23 Jan 2015 17:09:33 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t0NH9YrI006912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 12:09:34 -0500 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.168]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 12:09:34 -0500 From: "Lam, Hing-Kam (Kam)" To: Gert Grammel , "adrian@olddog.co.uk" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyAQjVyuIZDVkicZ67yfGpHF5zN7BoA Date: Fri, 23 Jan 2015 17:09:33 +0000 Message-ID: <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_8DBC3FDAC14BE441AED9C5939C77758509EE3B48US70TWXCHMBA12z_" MIME-Version: 1.0 Archived-At: Cc: "Doolan, Paul \(Coriant - US/Irving\)" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 23 Jan 2015 17:09:48 -0000 --_000_8DBC3FDAC14BE441AED9C5939C77758509EE3B48US70TWXCHMBA12z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gert, A vendor can purchase an OUI (Organizationally Unique Identifier) from the = IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific applic= ation identifiers under its own OUI. SG15 doesn't need to host any registry for this purpose. Regards, Kam From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Giovanni Martinelli (giomart= i)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.= ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Kam, Is SG15 considering to host a registry for the vendor specific application = code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (= giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.8= 74.1 to amend the specification of ApplicationIdentifier with the following= additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString = represents a standard application code as defined in the ITU-T Recommendati= ons. If the ApplicationIdentifierType is PROPRIETARY, the first six charact= ers of the PrintableString must contain the Hexadecimal representation of a= n OUI assigned to the vendor whose implementation generated the Application= Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietar= y-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools= .ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-w= son-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel > wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a bool= ean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel > wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_8DBC3FDAC14BE441AED9C5939C77758509EE3B48US70TWXCHMBA12z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gert,

 

A vendor can purchase = an OUI (Organizationally Unique Identifier) from the IEEE Registration Auth= ority.

Once a vendor has its = OUI, the vendor can manage its vendor-specific application identifiers unde= r its own OUI.

SG15 doesn’t nee= d to host any registry for this purpose.

 

Regards,

Kam<= /p>

 

From: Gert Gra= mmel [mailto:ggrammel@juniper.net]
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Giovanni Martinelli (= giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs= @tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Kam,

 

Is SG15 considering to= host a registry for the vendor specific application code or is the IETF re= gistry supposed to be used?

 

Thanks

 

Gert=

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: adrian@olddog.co.uk; = 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 meeting, Q= 14/15 agreed to update G.874.1 to amend the specification of ApplicationIde= ntifier with the following additional text:

 

If the ApplicationIden= tifierType is STANDARD, the value of PrintableString represents a standard = application code as defined in the ITU-T Recommendations. If the Applicatio= nIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal r= epresentation of an OUI assigned to the vendor whose implementation generat= ed the Application Identifier; the remaining octets of the PrintableString = are unspecified.

 

Paul Doolan had an I-D "https://tools.ietf.org/h= tml/draft-doolan-proprietary-ac-00" to the last IETF meeting with = the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM=

To: 'Giovanni Martinelli (giomarti)'

Cc: ccamp@ietf.= org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

Subject: [CCAMP] Vendor-Specific Application Code= in draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am not seeing= a specific conclusion from it.

 

The current I-D makes (IMHO) the Vendor-Specific = Application Code unusable. I offered three options:

 

1 This value is only to be used when it is known = that all devices

   participating in a network have the = same understanding of

   the content of the Vendor-Speci= fic Application Code field.

   How this knowledge is achieved is ou= tside the scope of this

   document

 

2 When this value is set, the first 32 (or 48) bi= ts of the Vendor-

  Specific Application Code field contain an= Enterprise Number

  (or OUI) that defines the context in which= the remainder of

  that field is interpreted.

 

3 Remove the option to include a Vendor-Specific = Application

   Code field.

 

If the WG could please pick one of these and help= Young to update the document.

 

Thanks,

Adrian

 

> -----Original Message-----

> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 13:50

> To: a= drian@olddog.co.uk

> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> ccamp@ietf= .org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of draft-ietf= -ccamp-rwa-wson-encode

>

> One additional comment (hoping not additiona= l confusion).

>

> The idea about Optical Interface Class was t= aken from SRLG. Good or

> bad is a plain number and you do simple oper= ations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, Giovanni Martinell= i (giomarti)

> <gi= omarti@cisco.com>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel= <adrian@olddog.co.uk> wro= te:

> >

> >> Hi,

> >>

> >> Well, you seem to have a half-way h= ouse.

> >>

> >> You have specified the existence of= a thing, but not how to read it.

> >>

> >> If you wanted to make a statement t= hat this object will only be

> >> used when

it is

> >> known that all systems in a network= come from the same vendor

> >> and/or have

> the

> >> same understanding of the encoding,= that might be OK (although how

> >> you

> would

> >> ascertain this might also need to b= e described).

> >>

> >

> > The statement is to ensure the interfac= e compatibility without

> > encoding all

the

> possible details and parameter that define a= n interface (e.g.

> modulation

format,

> forward error correction etc.). This was the= initial solution in the

> draft

then

> replaced by the interface class concept.&nbs= p;  The WSON (RWA-only) has the

> requirement is to make sure two interface ar= e compatible. This

> requirement, imho, can be satisfy by a simpl= e comparison which has a boolean result.

> >

> > We end up then in  the ITU applica= tion codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatib= ility where proper

> encoding is provided.

> >

> >

> >> Or you could entirely remove the ve= ndor-specific option.

> >>

> >> Or you could put in an OUI / enterp= rise number followed by

> >> transparent

> bytes.

> >>

> >

> > To me I'm perfectly fine with the secon= d option.

> >

> > Cheers

> > G

> >

> >

> >> Adrian

> >>

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

> >>> From: Giovanni Martinelli (giom= arti) [mailto:giomarti@cisco.com]=

> >>> Sent: 21 January 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>

> >>> Subject: Re: [CCAMP] AD review = of draft-ietf-ccamp-rwa-wson-encode

> >>>

> >>> Specifically to the Interface c= lass here below.

> >>>

> >>> In the initial draft merged to = this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) = we decided to remove any encoding

> >>> when the Interface class is not= standard.

> >>> In term of semantic the protcol= does not need to decode the

> >>> Interface

class

> >> since

> >>> it only assess the interface co= mpatibility if two interfaces has a

> >>> class

value

> >> that

> >>> match two interfaces cann be co= nnected.

> >>>

> >>> Having saying that I don't have= strong opinion in adding the OUI

> >>> or

leaving

> >> room

> >>> for maybe future public interfa= ces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility= assesment since there optical

> >>> multivendor compatibility has b= een already demonstrated.

> >>>

> >>> hope this help .

> >>>

> >>> Cheers

> >>> G

> >>>

> >>>

> >>> On 21 Jan 2015, at 21:57, Adria= n Farrel <adrian@olddog.co.uk= > wrote:

> >>>

> >>>>>>

> >>>>>> Section 4.1

> >>>>>> How do I interpret = a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?=

> >>>>>

> >>>>> [YOUNG] Not sure if I u= nderstood this question. What is "OUI"?

> >>>>

> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier

> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> numbers.xhtml#ieee-802

> >>>> -numbers-2

> >>>>

> >>>> Or perhaps an Enterprise Nu= mber

> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> >>>>

> >>>> The question is:=

> >>>>

> >>>> You have sections 4.1.1 thr= ough 4.1.4 to tell me how to interpret

> >>>> the

> >> Optical

> >>>> Interface Class field when = it contains an ITU-T Application Mapping.

> >>>> When I received s=3D0 and O= I=3D1 it means that the Optical Interface

> >>>> Class

> >> contains

> >>>> a "Vendor Specific Opt= ical Interface Class".

> >>>> How do I interpret that Opt= ical Interface Class?

> >>>> Which vendor does it apply = to?

> >>>> Is there some information e= lsewhere that gives me a clue as to

> >>>> which

> vendor

> >>> has

> >>>> encoded the information?

> >>>> Or is the information suppo= sed to be encoded in the Optical

> >>>> Interface

Class,

> >>>> perhaps as the first 48 bit= s?

> >>>> Or am I supposed to know by= context?

> >>

> >

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/ccamp

--_000_8DBC3FDAC14BE441AED9C5939C77758509EE3B48US70TWXCHMBA12z_-- From nobody Fri Jan 23 09:17:45 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 7CEBF1A883E for ; Fri, 23 Jan 2015 09:17:43 -0800 (PST) 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 UQCSx4Q8vuBn for ; Fri, 23 Jan 2015 09:17:41 -0800 (PST) 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 D2D3E1A1B06 for ; Fri, 23 Jan 2015 09:17:40 -0800 (PST) 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 BRR16587; Fri, 23 Jan 2015 17:17:39 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 17:17:38 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 09:17:36 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AdA3F39rUe0sT3nBRieZEz+A1ksBgQAGKR1A Date: Fri, 23 Jan 2015 17:17:35 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm> References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> In-Reply-To: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 23 Jan 2015 17:17:43 -0000 Hi, Thanks Adrian for taking this on.=20 My preference is Option 1. It would be hard to catch moving target around t= his area if we were to take Option 2.=20 Thanks, Young -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, January 23, 2015 8:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; ccamp@ie= tf.org; ccamp-chairs@tools.ietf.org Subject: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-enco= de Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of=20 the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode >=20 > One additional comment (hoping not additional confusion). >=20 > The idea about Optical Interface Class was taken from SRLG. Good or bad i= s a > plain number and you do simple operations on it. >=20 > Cheers > G >=20 > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > wrote: >=20 > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be used w= hen it is > >> known that all systems in a network come from the same vendor and/or h= ave > the > >> same understanding of the encoding, that might be OK (although how you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without encoding= all the > possible details and parameter that define an interface (e.g. modulation format, > forward error correction etc.). This was the initial solution in the draf= t then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This requiremen= t, > imho, can be satisfy by a simple comparison which has a boolean result. > > > > We end up then in the ITU application codes for the "certified" (we'll= this is my > term not 100% sure is the best one) compatibility where proper encoding i= s > provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI ho= wever (I > >>> guess after chatting with Lou) we decided to remove any encoding when= the > >>> Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a cl= ass value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a need = to leave > >>> room for specific compatibility assesment since there optical multive= ndor > >>> compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there an= OUI > >>>>>> I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret th= e > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface= Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical Interfac= e Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > From nobody Fri Jan 23 09:22:45 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 CF3001A8872 for ; Fri, 23 Jan 2015 09:22:42 -0800 (PST) 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 37WF7IsDBK9j for ; Fri, 23 Jan 2015 09:22:39 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id D327C1A8854 for ; Fri, 23 Jan 2015 09:22:31 -0800 (PST) Received: (qmail 15853 invoked by uid 0); 23 Jan 2015 17:22:31 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 23 Jan 2015 17:22:31 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id jVNH1p0192SSUrH01VNLcw; Fri, 23 Jan 2015 10:22:31 -0700 X-Authority-Analysis: v=2.1 cv=fJeqg/qe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=Vhvw94NMJWsA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=YNv0rlydsVwA:10 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=CyRW7yT0AAAA:8 a=dbgrvOMAyegXwSuFqbEA:9 a=fwd1uAYG5I1ZeS8x:21 a=yZD3P3FQdbicexAI:21 a=j8l58Ci2Z__Aiqu1:21 a=QEXdDO2ut3YA: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=0ZE1Q8aIfnaHvOSJSSoeKDS6fx5lXmMv/ejqhhJbpQE=; b=wVjx2HrvZTn01QhzGcy4C9VyLkkkXMM3c0kqlPr4B1pA6XefoiziG0QEGV7Y+MgragPJcc1QZQ71+natNh/+YZK4ZueKtHm6IuZLM8lcRggf6sfqKfA81HP3Q7OIwaXj; Received: from box313.bluehost.com ([69.89.31.113]:40480 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YEhw1-00027D-7g; Fri, 23 Jan 2015 10:22:17 -0700 Message-ID: <54C28342.8040606@labn.net> Date: Fri, 23 Jan 2015 12:22:10 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Leeyoung , Tomonori Takeda , "rtg-ads@tools.ietf.org" References: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> <54C279EE.3070200@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C7E063@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7E063@dfweml706-chm> 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: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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: Fri, 23 Jan 2015 17:22:43 -0000 Young, On 1/23/2015 11:51 AM, Leeyoung wrote: > Hi Lou, > > Are you referring 'any specific language changes' to Adrian's 'Resource' language? Actually, no. > If so, yes, I expect Adrian's input on where to place any changes in the draft. Other than that I believe the version 17 (which was published) reflects Tomonori's rtg-dir review. Let me know if you believe any other aspect (other than 'resource' language) should be updated in the upcoming version 18. I may have misunderstood the thread below, but I read it as there are two areas in -17 that should be clarified. Thanks, Lou > Thanks, > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, January 23, 2015 10:42 AM > To: Tomonori Takeda; Leeyoung; rtg-ads@tools.ietf.org > Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org' > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt > > Young, > Can you review any changes planned as a result of the rtg-dir review? > Please also include any specific language changes, that you may have > already identified. > > Thanks, > Lou (as doc Shepherd) > > On 01/23/2015 03:01 AM, Tomonori Takeda wrote: >> Hi Young, >> >> OK, thanks, >> >> Tomonori >> >> -----Original Message----- >> From: Leeyoung [mailto:leeyoung@huawei.com] >> Sent: Thursday, January 22, 2015 2:44 AM >> To: Tomonori Takeda锛堟鐢扮煡鍏革級; Leeyoung; rtg-ads@tools.ietf.org >> Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org' >> Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt >> >> Hi Tomonori, >> >> Thanks for your comment. Please see in-line for my response. Please let me know if the response would satisfy you. >> >> Best regards, >> Young >> >> -----Original Message----- >> From: Tomonori Takeda [mailto:tomonori.takeda@ntt.com] >> Sent: Wednesday, January 21, 2015 12:48 AM >> To: Leeyoung; rtg-ads@tools.ietf.org >> Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org'; Tomonori Takeda >> Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt >> >> Hi Young, >> >> Thanks. >> >> Two follow-up questions/comments. >> (I am fine with other points, which you already addressed in the updated draft.) >> >>> 2) In section 2.1, it says "two matrices will not have the same {src port, src label, dst port, dst label}". To be precise, I guess this should be > "two matrices will not have the same {src port, src label}, and two matrices will not have the same {dst port, dst label}"? >>> >>> YOUNG>> I think your suggestion may be too restrictive. For instance, if we have one source (port 1) and one destination (port 2) with two labels > each. Then we would have: {(1,1,2,1), (1,1,2,2), (1,2,2,1), (1,2,2,2)} I think with the current statement, we can send this info in any combination > of multiple matrices, which I think perfectly fine. With your suggestion, I would not be able send (1,1,2,1) and (1,1,2,2) together. Why would this > not be made possible? My take is as long as each submatrix represents a set of disjoint quadruples, that should be allowed. >> My reading of "two matrices will not have the same {src port, src label, dst port, dst label}" is as follows. >> >> >> >> input port=1 --> Submatrix#1 --> output port=2 >> input label=1 output label=1 >> >> input port=1 --> Submatrix#2 --> output port=2 >> input label=1 output label=2 >> >> This is allowed. >> >> >> >> input port=1 --> Submatrix#1 --> output port=2 >> input label=1 output label=1 >> >> input port=1 --> Submatrix#2 --> output port=2 >> input label=1 output label=1 >> >> This is not allowed. >> >> >> >> input port=1 --> Submatrix#1 --> output port=2 >> input label=1 output label=1 >> >> input port=1 --> Submatrix#2 --> output port=2 >> input label=2 output label=2 >> >> This is allowed. >> >> Is above understanding correct? >> If so, I am not sure how example A works, since I am not sure what is the indentifier to direct from input to each submatrix. >> >> Maybe I am mis-understanding what sub-matrix is. I thought sub-matrix is a sort of virtual node, splitting the single matrix (or switch) into smaller pieces. >> >> YOUNG>> OK, I think the definition of submatrix was not clear. It is simply dividing up a matrix into several pieces in case the size of the matrix becomes too big or a way to advertize the changed port/label set in one place (sub-matrix) then other unchanged port/label set in other place (different sub-matrix). The identifier for each sub-matrix is the MATRIX ID. There is not separate identifier to direct from input. The input is a part of the sub-matrix. Say if we have N*M matrix that describes all input and output port/label. We might divide up into N*(M-L) and N*L or any other combinations as far as they are all disjoint from each other. >> >>> 4) In section 2.1, for Link Set A dir=bidirectional, Link Set B dir=bidirectional, if any signal on an input link X is output on a link Y, then any > signal on an input link Y is output on a link X (after cross-connect)? Or any constraint on such signal flow (after cross-connect) is out of scope? >>> >>> > I am not sure what "after cross-connect" is meant. >> >> >> Link set A: link#1, link#2, link#3 >> Link set B: link#4, link#5, link#6 >> >> Both of Link set A and Link set B are specified as "dir". >> >> In this case, >> - Is it possible to problem the cross-connect as input=link#1, output=link#4 >> & input=link#5, output=link#1 simultaneolusly? >> - Or is it automatically assumed if input=link#1, output=link#4, >> then input=link#4, output=link#1? >> - Or this sort of constraint is not specified in Link Set Field? >> >> The text seems like saying the first option, but I do not think this is a common equipment implementaion. >> >> YOUGN>> OK. I think I understand you more clearly. For this case (bidirectional link sets), the first case is definitely not the intention. The second case is assumed. >> >> Thanks, >> Tomonori >> >> -----Original Message----- >> From: Leeyoung [mailto:leeyoung@huawei.com] >> Sent: Tuesday, January 20, 2015 7:54 AM >> To: Tomonori Takeda锛堟鐢扮煡鍏革級; rtg-ads@tools.ietf.org >> Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org' >> Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt >> >> Hi Tomonori, >> >> Thanks for providing good comments. Here's my response. Please see in-line. >> >> Regards, >> Young >> >> -----Original Message----- >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Tomonori Takeda >> Sent: Saturday, January 17, 2015 7:59 AM >> To: rtg-ads@tools.ietf.org >> Cc: 'rtg-dir@ietf.org'; 'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'; 'ccamp@ietf.org' >> Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see 鈥媓ttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. >> >> Document: draft-ietf-ccamp-general-constraint-encode-16.txt >> Reviewer: Tomonori Takeda >> Review Date: 17 January, 2015 >> IETF LC End Date: 17 January, 2015 >> Intended Status: Standards Track >> >> Summary: >> >> This document is basically ready for publication, but has nits that should be considered prior to publication. >> >> Comments: >> >> This document specifies protocol-agnostic encodings for general information elements described in draft-ietf-ccamp-rwa-info. >> I think the document is in good shape but there are a few points that should be clarified for better understanding. >> >> Major Issues: >> >> None >> >> Minor Issues: >> >> None >> >> Nits: >> >> 1) In section 1.2, label continuity constraint (e.g., wavelength continuity in WSON) is mentioned. However, I am not sure whether information elements for which this document specifies encodings can describe such constraint. My reading is that information element such as Port Label Restriction is rather for describing wavelength tuning capabilities/restrictions. >> >> YOUNG>> Label continuity constraints can be inferred from the two places in the draft: (i) Port Label Restriction, which gives the set of labels (wavelengths) that may not be available on certain links including tuning range/restriction; (ii) Available/Shared Backup Label Fields (section 2.4 & section 2.5). There is no encoding for label continuity constraint per se. The aforementioned constraints are encoded to give a node or a PCE to be able to compute a path (i.e., path with wavelength continuity) subject to these constraints. >> >> 2) In section 2.1, it says "two matrices will not have the same {src port, src label, dst port, dst label}". To be precise, I guess this should be "two matrices will not have the same {src port, src label}, and two matrices will not have the same {dst port, dst label}"? >> >> YOUNG>> I think your suggestion may be too restrictive. For instance, if we have one source (port 1) and one destination (port 2) with two labels each. Then we would have: {(1,1,2,1), (1,1,2,2), (1,2,2,1), (1,2,2,2)} I think with the current statement, we can send this info in any combination of multiple matrices, which I think perfectly fine. With your suggestion, I would not be able send (1,1,2,1) and (1,1,2,2) together. Why would this not be made possible? My take is as long as each submatrix represents a set of disjoint quadruples, that should be allowed. >> >> 3) In section 2.1, it says "The value of 0xFF is reserved for use with port wavelength constraints". I think "port wavelength constraints" should be "port label restriction". >> >> YOUNG>> Yes, thanks. >> >> 4) In section 2.1, for Link Set A dir=bidirectional, Link Set B dir=bidirectional, if any signal on an input link X is output on a link Y, then any signal on an input link Y is output on a link X (after cross-connect)? Or any constraint on such signal flow (after cross-connect) is out of scope? >> >> YOUNG>> I am not sure what "after cross-connect" is meant. >> >> 5) In section 2.2.1, it says "In this case the accompanying label set indicates the labels permitted on the port." I think "port" should be "port/matrix". >> >> YOUNG>> Yes, thanks. >> >> 6) In section 2.2.2, it would be better to describe the type (e.g., integer) for MaxNumChannels. >> This also applies for MaxLabelRange (in section 2.2.3) and Num Labels (in section 2.6). >> >> YOUNG>> OK. >> >> 7) In section 2.6, it says "Label Set Field is used within the or the ". But I think Label Set Field is also used within SIMPLE_LABEL, LABEL_RANGE and SIMPLE_LABEL & CHANNEL_COUNT. >> >> YOUNG>> Yes, it is used in multiple places. >> >> How about: >> OLD: Label Set Field is used within the or the >> , which is defined in Section 2.4. and 2.5., >> respectively. >> NEW: Label Set Field is used within the or the >> , which is defined in Section 2.4. and 2.5., >> respectively. It is also used within the , >> , or , which is defined >> in Sections 2.1.1 - 2.1.4, respectively. >> >> >> Thanks, >> Tomonori >> From nobody Fri Jan 23 09:24: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 DADF11ABD36 for ; Fri, 23 Jan 2015 09:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] 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 XuquAFnSdtUQ for ; Fri, 23 Jan 2015 09:24:45 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5881A886D for ; Fri, 23 Jan 2015 09:24:35 -0800 (PST) Received: from localhost ([::1]:38918) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YEhyE-0005Li-3J; Fri, 23 Jan 2015 20:24:34 +0300 Message-ID: <54C283CD.7030003@labn.net> Date: Fri, 23 Jan 2015 12:24:29 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Leeyoung , "adrian@olddog.co.uk" , "'Giovanni Martinelli (giomarti)'" References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 23 Jan 2015 17:24:48 -0000 On 1/23/2015 12:17 PM, Leeyoung wrote: > Hi, > > Thanks Adrian for taking this on. > > My preference is Option 1. Thanks Young. My memory is that this was the intent of the WG at the time this point was discussed. So, I also prefer/support option 1. Lou > It would be hard to catch moving target around this area if we were to take Option 2. > > Thanks, > Young > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, January 23, 2015 8:41 AM > To: 'Giovanni Martinelli (giomarti)' > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode > > Hi, > > I appreciate this discussion, but I am not seeing a specific conclusion from it. > > The current I-D makes (IMHO) the Vendor-Specific Application Code unusable. I > offered three options: > > 1 This value is only to be used when it is known that all devices > participating in a network have the same understanding of > the content of the Vendor-Specific Application Code field. > How this knowledge is achieved is outside the scope of this > document > > 2 When this value is set, the first 32 (or 48) bits of the Vendor- > Specific Application Code field contain an Enterprise Number > (or OUI) that defines the context in which the remainder of > that field is interpreted. > > 3 Remove the option to include a Vendor-Specific Application > Code field. > > If the WG could please pick one of these and help Young to update the document. > > Thanks, > Adrian > >> -----Original Message----- >> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] >> Sent: 23 January 2015 13:50 >> To: adrian@olddog.co.uk >> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; >> ccamp@ietf.org; ccamp-chairs@tools.ietf.org >> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode >> >> One additional comment (hoping not additional confusion). >> >> The idea about Optical Interface Class was taken from SRLG. Good or bad is a >> plain number and you do simple operations on it. >> >> Cheers >> G >> >> On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) >> wrote: >> >>> Hi Adrian, >>> >>> On 21 Jan 2015, at 22:55, Adrian Farrel wrote: >>> >>>> Hi, >>>> >>>> Well, you seem to have a half-way house. >>>> >>>> You have specified the existence of a thing, but not how to read it. >>>> >>>> If you wanted to make a statement that this object will only be used when > it is >>>> known that all systems in a network come from the same vendor and/or have >> the >>>> same understanding of the encoding, that might be OK (although how you >> would >>>> ascertain this might also need to be described). >>>> >>> The statement is to ensure the interface compatibility without encoding all > the >> possible details and parameter that define an interface (e.g. modulation > format, >> forward error correction etc.). This was the initial solution in the draft > then >> replaced by the interface class concept. The WSON (RWA-only) has the >> requirement is to make sure two interface are compatible. This requirement, >> imho, can be satisfy by a simple comparison which has a boolean result. >>> We end up then in the ITU application codes for the "certified" (we'll this > is my >> term not 100% sure is the best one) compatibility where proper encoding is >> provided. >>> >>>> Or you could entirely remove the vendor-specific option. >>>> >>>> Or you could put in an OUI / enterprise number followed by transparent >> bytes. >>> To me I'm perfectly fine with the second option. >>> >>> Cheers >>> G >>> >>> >>>> Adrian >>>> >>>>> -----Original Message----- >>>>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] >>>>> Sent: 21 January 2015 21:22 >>>>> To: adrian@olddog.co.uk >>>>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; >>>>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org >>>>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode >>>>> >>>>> Specifically to the Interface class here below. >>>>> >>>>> In the initial draft merged to this one there was the usage of OUI however > (I >>>>> guess after chatting with Lou) we decided to remove any encoding when the >>>>> Interface class is not standard. >>>>> In term of semantic the protcol does not need to decode the Interface > class >>>> since >>>>> it only assess the interface compatibility if two interfaces has a class > value >>>> that >>>>> match two interfaces cann be connected. >>>>> >>>>> Having saying that I don't have strong opinion in adding the OUI or > leaving >>>> room >>>>> for maybe future public interfaces database. For sure there's a need to > leave >>>>> room for specific compatibility assesment since there optical multivendor >>>>> compatibility has been already demonstrated. >>>>> >>>>> hope this help . >>>>> >>>>> Cheers >>>>> G >>>>> >>>>> >>>>> On 21 Jan 2015, at 21:57, Adrian Farrel wrote: >>>>> >>>>>>>> Section 4.1 >>>>>>>> How do I interpret a Vendor-Specific Application Code? Is there an OUI >>>>>>>> I'm missing? >>>>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? >>>>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier >>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- >>>>> numbers.xhtml#ieee-802 >>>>>> -numbers-2 >>>>>> >>>>>> Or perhaps an Enterprise Number >>>>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- >> numbers >>>>>> The question is: >>>>>> >>>>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret the >>>> Optical >>>>>> Interface Class field when it contains an ITU-T Application Mapping. >>>>>> When I received s=0 and OI=1 it means that the Optical Interface Class >>>> contains >>>>>> a "Vendor Specific Optical Interface Class". >>>>>> How do I interpret that Optical Interface Class? >>>>>> Which vendor does it apply to? >>>>>> Is there some information elsewhere that gives me a clue as to which >> vendor >>>>> has >>>>>> encoded the information? >>>>>> Or is the information supposed to be encoded in the Optical Interface > Class, >>>>>> perhaps as the first 48 bits? >>>>>> Or am I supposed to know by context? > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From nobody Fri Jan 23 09:25: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 EF0101ABD3B; Fri, 23 Jan 2015 09:25:47 -0800 (PST) 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 hP5uHzhTktVT; Fri, 23 Jan 2015 09:25:44 -0800 (PST) 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 4BFB21AC399; Fri, 23 Jan 2015 09:25:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRR16953; Fri, 23 Jan 2015 17:25:03 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 17:25:01 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 09:24:59 -0800 From: Leeyoung To: Lou Berger , Tomonori Takeda , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.txt Thread-Index: AQHQNyua4bPWa0fjYUSk1DJvggIdkZzN6UpAgACQuAD//3pWcA== Date: Fri, 23 Jan 2015 17:24:58 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7E0BA@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C7B111@dfweml706-chm> <7AEB3D6833318045B4AE71C2C87E8E1729C7C7D3@dfweml706-chm> <54C279EE.3070200@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729C7E063@dfweml706-chm> <54C28342.8040606@labn.net> In-Reply-To: <54C28342.8040606@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org'" , "'ccamp@ietf.org'" Subject: Re: [CCAMP] [RTG-DIR] RtgDir review: draft-ietf-ccamp-general-constraint-encode-16.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: Fri, 23 Jan 2015 17:25:48 -0000 TG91LA0KDQpJIGNhbiBhZGQgc29tZSBjbGFyaWZ5aW5nIHRleHQgaW4gdGhlIG5leHQgcmV2aXNp b24uIA0KDQpUaGFua3MsDQpZb3VuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KU2VudDogRnJpZGF5LCBK YW51YXJ5IDIzLCAyMDE1IDExOjIyIEFNDQpUbzogTGVleW91bmc7IFRvbW9ub3JpIFRha2VkYTsg cnRnLWFkc0B0b29scy5pZXRmLm9yZw0KQ2M6ICdydGctZGlyQGlldGYub3JnJzsgJ2RyYWZ0LWll dGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcnOyAn Y2NhbXBAaWV0Zi5vcmcnDQpTdWJqZWN0OiBSZTogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRy YWZ0LWlldGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS0xNi50eHQNCg0KWW91bmcs DQoNCk9uIDEvMjMvMjAxNSAxMTo1MSBBTSwgTGVleW91bmcgd3JvdGU6DQo+IEhpIExvdSwNCj4N Cj4gQXJlIHlvdSByZWZlcnJpbmcgJ2FueSBzcGVjaWZpYyBsYW5ndWFnZSBjaGFuZ2VzJyB0byBB ZHJpYW4ncyAnUmVzb3VyY2UnIGxhbmd1YWdlPyANCkFjdHVhbGx5LCBuby4NCj4gSWYgc28sIHll cywgSSBleHBlY3QgQWRyaWFuJ3MgaW5wdXQgb24gd2hlcmUgdG8gcGxhY2UgYW55IGNoYW5nZXMg aW4gdGhlIGRyYWZ0LiBPdGhlciB0aGFuIHRoYXQgSSBiZWxpZXZlIHRoZSB2ZXJzaW9uIDE3ICh3 aGljaCB3YXMgcHVibGlzaGVkKSByZWZsZWN0cyBUb21vbm9yaSdzIHJ0Zy1kaXIgcmV2aWV3LiBM ZXQgbWUga25vdyBpZiB5b3UgYmVsaWV2ZSBhbnkgb3RoZXIgYXNwZWN0IChvdGhlciB0aGFuICdy ZXNvdXJjZScgbGFuZ3VhZ2UpIHNob3VsZCBiZSB1cGRhdGVkIGluIHRoZSB1cGNvbWluZyB2ZXJz aW9uIDE4Lg0KDQpJIG1heSBoYXZlIG1pc3VuZGVyc3Rvb2QgdGhlIHRocmVhZCBiZWxvdywgYnV0 IEkgcmVhZCBpdCBhcyB0aGVyZSBhcmUNCnR3byBhcmVhcyBpbiAtMTcgdGhhdCBzaG91bGQgYmUg IGNsYXJpZmllZC4NCg0KVGhhbmtzLA0KTG91DQoNCj4gVGhhbmtzLA0KPiBZb3VuZw0KPg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJl cmdlckBsYWJuLm5ldF0gDQo+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAyMywgMjAxNSAxMDo0MiBB TQ0KPiBUbzogVG9tb25vcmkgVGFrZWRhOyBMZWV5b3VuZzsgcnRnLWFkc0B0b29scy5pZXRmLm9y Zw0KPiBDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNv bnN0cmFpbnQtZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZycNCj4g U3ViamVjdDogUmU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdl bmVyYWwtY29uc3RyYWludC1lbmNvZGUtMTYudHh0DQo+DQo+IFlvdW5nLA0KPiAJQ2FuIHlvdSBy ZXZpZXcgYW55IGNoYW5nZXMgcGxhbm5lZCBhcyBhIHJlc3VsdCBvZiB0aGUgcnRnLWRpciByZXZp ZXc/DQo+IFBsZWFzZSBhbHNvIGluY2x1ZGUgYW55IHNwZWNpZmljIGxhbmd1YWdlIGNoYW5nZXMs IHRoYXQgeW91IG1heSBoYXZlDQo+IGFscmVhZHkgaWRlbnRpZmllZC4NCj4NCj4gVGhhbmtzLA0K PiBMb3UgKGFzIGRvYyBTaGVwaGVyZCkNCj4NCj4gT24gMDEvMjMvMjAxNSAwMzowMSBBTSwgVG9t b25vcmkgVGFrZWRhIHdyb3RlOg0KPj4gSGkgWW91bmcsDQo+Pg0KPj4gT0ssIHRoYW5rcywNCj4+ DQo+PiBUb21vbm9yaQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBMZWV5b3VuZyBbbWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb21dIA0KPj4gU2VudDogVGh1cnNk YXksIEphbnVhcnkgMjIsIDIwMTUgMjo0NCBBTQ0KPj4gVG86IFRvbW9ub3JpIFRha2VkYe+8iOat pueUsOefpeWFuO+8iTsgTGVleW91bmc7IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4+IENjOiAn cnRnLWRpckBpZXRmLm9yZyc7ICdkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1l bmNvZGUuYWxsQHRvb2xzLmlldGYub3JnJzsgJ2NjYW1wQGlldGYub3JnJw0KPj4gU3ViamVjdDog UkU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVyYWwtY29u c3RyYWludC1lbmNvZGUtMTYudHh0DQo+Pg0KPj4gSGkgVG9tb25vcmksDQo+Pg0KPj4gVGhhbmtz IGZvciB5b3VyIGNvbW1lbnQuIFBsZWFzZSBzZWUgaW4tbGluZSBmb3IgbXkgcmVzcG9uc2UuIFBs ZWFzZSBsZXQgbWUga25vdyBpZiB0aGUgcmVzcG9uc2Ugd291bGQgc2F0aXNmeSB5b3UuIA0KPj4N Cj4+IEJlc3QgcmVnYXJkcywNCj4+IFlvdW5nDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IFRvbW9ub3JpIFRha2VkYSBbbWFpbHRvOnRvbW9ub3JpLnRha2VkYUBu dHQuY29tXSANCj4+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMSwgMjAxNSAxMjo0OCBBTQ0K Pj4gVG86IExlZXlvdW5nOyBydGctYWRzQHRvb2xzLmlldGYub3JnDQo+PiBDYzogJ3J0Zy1kaXJA aWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLmFs bEB0b29scy5pZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZyc7IFRvbW9ub3JpIFRha2VkYQ0KPj4g U3ViamVjdDogUkU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWNjYW1wLWdl bmVyYWwtY29uc3RyYWludC1lbmNvZGUtMTYudHh0DQo+Pg0KPj4gSGkgWW91bmcsDQo+Pg0KPj4g VGhhbmtzLg0KPj4NCj4+IFR3byBmb2xsb3ctdXAgcXVlc3Rpb25zL2NvbW1lbnRzLg0KPj4gKEkg YW0gZmluZSB3aXRoIG90aGVyIHBvaW50cywgd2hpY2ggeW91IGFscmVhZHkgYWRkcmVzc2VkIGlu IHRoZSB1cGRhdGVkIGRyYWZ0LikNCj4+DQo+Pj4gMikgSW4gc2VjdGlvbiAyLjEsIGl0IHNheXMg InR3byBtYXRyaWNlcyB3aWxsIG5vdCBoYXZlIHRoZSBzYW1lIHtzcmMgcG9ydCwgc3JjIGxhYmVs LCBkc3QgcG9ydCwgZHN0IGxhYmVsfSIuIFRvIGJlIHByZWNpc2UsIEkgZ3Vlc3MgdGhpcyBzaG91 bGQgYmUgPiAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge3NyYyBwb3J0LCBz cmMgbGFiZWx9LCBhbmQgdHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge2RzdCBw b3J0LCBkc3QgbGFiZWx9Ij8NCj4+Pg0KPj4+IFlPVU5HPj4gSSB0aGluayB5b3VyIHN1Z2dlc3Rp b24gbWF5IGJlIHRvbyByZXN0cmljdGl2ZS4gRm9yIGluc3RhbmNlLCBpZiB3ZSBoYXZlIG9uZSBz b3VyY2UgKHBvcnQgMSkgYW5kIG9uZSBkZXN0aW5hdGlvbiAocG9ydCAyKSB3aXRoIHR3byBsYWJl bHMgPiBlYWNoLiBUaGVuIHdlIHdvdWxkIGhhdmU6IHsoMSwxLDIsMSksICgxLDEsMiwyKSwgKDEs MiwyLDEpLCAoMSwyLDIsMil9IEkgdGhpbmsgd2l0aCB0aGUgY3VycmVudCBzdGF0ZW1lbnQsIHdl IGNhbiBzZW5kIHRoaXMgaW5mbyBpbiBhbnkgY29tYmluYXRpb24gPiBvZiBtdWx0aXBsZSBtYXRy aWNlcywgd2hpY2ggSSB0aGluayBwZXJmZWN0bHkgZmluZS4gV2l0aCB5b3VyIHN1Z2dlc3Rpb24s IEkgd291bGQgbm90IGJlIGFibGUgc2VuZCAoMSwxLDIsMSkgYW5kICgxLDEsMiwyKSB0b2dldGhl ci4gV2h5IHdvdWxkIHRoaXMgPiBub3QgYmUgbWFkZSBwb3NzaWJsZT8gTXkgdGFrZSBpcyBhcyBs b25nIGFzIGVhY2ggc3VibWF0cml4IHJlcHJlc2VudHMgYSBzZXQgb2YgZGlzam9pbnQgcXVhZHJ1 cGxlcywgdGhhdCBzaG91bGQgYmUgYWxsb3dlZC4NCj4+IE15IHJlYWRpbmcgb2YgInR3byBtYXRy aWNlcyB3aWxsIG5vdCBoYXZlIHRoZSBzYW1lIHtzcmMgcG9ydCwgc3JjIGxhYmVsLCBkc3QgcG9y dCwgZHN0IGxhYmVsfSIgaXMgYXMgZm9sbG93cy4NCj4+DQo+PiA8RXhhbXBsZSBBPg0KPj4NCj4+ ICAgaW5wdXQgcG9ydD0xICAtLT4gU3VibWF0cml4IzEgLS0+IG91dHB1dCBwb3J0PTINCj4+ICAg aW5wdXQgbGFiZWw9MSAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0xDQo+Pg0KPj4g ICBpbnB1dCBwb3J0PTEgIC0tPiBTdWJtYXRyaXgjMiAtLT4gb3V0cHV0IHBvcnQ9Mg0KPj4gICBp bnB1dCBsYWJlbD0xICAgICAgICAgICAgICAgICAgICAgb3V0cHV0IGxhYmVsPTINCj4+DQo+PiAg IFRoaXMgaXMgYWxsb3dlZC4NCj4+DQo+PiA8RXhhbXBsZSBCPg0KPj4NCj4+ICAgaW5wdXQgcG9y dD0xICAtLT4gU3VibWF0cml4IzEgLS0+IG91dHB1dCBwb3J0PTINCj4+ICAgaW5wdXQgbGFiZWw9 MSAgICAgICAgICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0xDQo+Pg0KPj4gICBpbnB1dCBwb3J0 PTEgIC0tPiBTdWJtYXRyaXgjMiAtLT4gb3V0cHV0IHBvcnQ9Mg0KPj4gICBpbnB1dCBsYWJlbD0x ICAgICAgICAgICAgICAgICAgICAgb3V0cHV0IGxhYmVsPTENCj4+DQo+PiAgIFRoaXMgaXMgbm90 IGFsbG93ZWQuDQo+Pg0KPj4gPEV4YW1wbGUgQz4NCj4+DQo+PiAgIGlucHV0IHBvcnQ9MSAgLS0+ IFN1Ym1hdHJpeCMxIC0tPiBvdXRwdXQgcG9ydD0yDQo+PiAgIGlucHV0IGxhYmVsPTEgICAgICAg ICAgICAgICAgICAgICBvdXRwdXQgbGFiZWw9MQ0KPj4NCj4+ICAgaW5wdXQgcG9ydD0xICAtLT4g U3VibWF0cml4IzIgLS0+IG91dHB1dCBwb3J0PTINCj4+ICAgaW5wdXQgbGFiZWw9MiAgICAgICAg ICAgICAgICAgICAgIG91dHB1dCBsYWJlbD0yDQo+Pg0KPj4gICBUaGlzIGlzIGFsbG93ZWQuDQo+ Pg0KPj4gSXMgYWJvdmUgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KPj4gSWYgc28sIEkgYW0gbm90 IHN1cmUgaG93IGV4YW1wbGUgQSB3b3Jrcywgc2luY2UgSSBhbSBub3Qgc3VyZSB3aGF0IGlzIHRo ZSBpbmRlbnRpZmllciB0byBkaXJlY3QgZnJvbSBpbnB1dCB0byBlYWNoIHN1Ym1hdHJpeC4NCj4+ DQo+PiBNYXliZSBJIGFtIG1pcy11bmRlcnN0YW5kaW5nIHdoYXQgc3ViLW1hdHJpeCBpcy4gSSB0 aG91Z2h0IHN1Yi1tYXRyaXggaXMgYSBzb3J0IG9mIHZpcnR1YWwgbm9kZSwgc3BsaXR0aW5nIHRo ZSBzaW5nbGUgbWF0cml4IChvciBzd2l0Y2gpIGludG8gc21hbGxlciBwaWVjZXMuDQo+Pg0KPj4g WU9VTkc+PiBPSywgSSB0aGluayB0aGUgZGVmaW5pdGlvbiBvZiBzdWJtYXRyaXggd2FzIG5vdCBj bGVhci4gSXQgaXMgc2ltcGx5IGRpdmlkaW5nIHVwIGEgbWF0cml4IGludG8gc2V2ZXJhbCBwaWVj ZXMgaW4gY2FzZSB0aGUgc2l6ZSBvZiB0aGUgbWF0cml4IGJlY29tZXMgdG9vIGJpZyBvciBhIHdh eSB0byBhZHZlcnRpemUgdGhlIGNoYW5nZWQgcG9ydC9sYWJlbCBzZXQgaW4gb25lIHBsYWNlIChz dWItbWF0cml4KSB0aGVuIG90aGVyIHVuY2hhbmdlZCBwb3J0L2xhYmVsIHNldCBpbiBvdGhlciBw bGFjZSAoZGlmZmVyZW50IHN1Yi1tYXRyaXgpLiBUaGUgaWRlbnRpZmllciBmb3IgZWFjaCBzdWIt bWF0cml4IGlzIHRoZSBNQVRSSVggSUQuIFRoZXJlIGlzIG5vdCBzZXBhcmF0ZSBpZGVudGlmaWVy IHRvIGRpcmVjdCBmcm9tIGlucHV0LiBUaGUgaW5wdXQgaXMgYSBwYXJ0IG9mIHRoZSBzdWItbWF0 cml4LiBTYXkgaWYgd2UgaGF2ZSBOKk0gbWF0cml4IHRoYXQgZGVzY3JpYmVzIGFsbCBpbnB1dCBh bmQgb3V0cHV0IHBvcnQvbGFiZWwuIFdlIG1pZ2h0IGRpdmlkZSB1cCBpbnRvIE4qKE0tTCkgYW5k IE4qTCBvciBhbnkgb3RoZXIgY29tYmluYXRpb25zIGFzIGZhciBhcyB0aGV5IGFyZSBhbGwgZGlz am9pbnQgZnJvbSBlYWNoIG90aGVyLiANCj4+DQo+Pj4gNCkgSW4gc2VjdGlvbiAyLjEsIGZvciBM aW5rIFNldCBBIGRpcj1iaWRpcmVjdGlvbmFsLCBMaW5rIFNldCBCIGRpcj1iaWRpcmVjdGlvbmFs LCBpZiBhbnkgc2lnbmFsIG9uIGFuIGlucHV0IGxpbmsgWCBpcyBvdXRwdXQgb24gYSBsaW5rIFks IHRoZW4gYW55ID4gc2lnbmFsIG9uIGFuIGlucHV0IGxpbmsgWSBpcyBvdXRwdXQgb24gYSBsaW5r IFggKGFmdGVyIGNyb3NzLWNvbm5lY3QpPyBPciBhbnkgY29uc3RyYWludCBvbiBzdWNoIHNpZ25h bCBmbG93IChhZnRlciBjcm9zcy1jb25uZWN0KSBpcyBvdXQgb2Ygc2NvcGU/DQo+Pj4NCj4+PiA8 WU9VTkc+PiBJIGFtIG5vdCBzdXJlIHdoYXQgImFmdGVyIGNyb3NzLWNvbm5lY3QiIGlzIG1lYW50 Lg0KPj4gPEV4YW1wbGU+DQo+Pg0KPj4gICBMaW5rIHNldCBBOiBsaW5rIzEsIGxpbmsjMiwgbGlu ayMzDQo+PiAgIExpbmsgc2V0IEI6IGxpbmsjNCwgbGluayM1LCBsaW5rIzYNCj4+DQo+PiAgIEJv dGggb2YgTGluayBzZXQgQSBhbmQgTGluayBzZXQgQiBhcmUgc3BlY2lmaWVkIGFzICJkaXIiLg0K Pj4NCj4+ICAgSW4gdGhpcyBjYXNlLA0KPj4gICAtIElzIGl0IHBvc3NpYmxlIHRvIHByb2JsZW0g dGhlIGNyb3NzLWNvbm5lY3QgYXMgaW5wdXQ9bGluayMxLCBvdXRwdXQ9bGluayM0DQo+PiAgICAg JiBpbnB1dD1saW5rIzUsIG91dHB1dD1saW5rIzEgc2ltdWx0YW5lb2x1c2x5Pw0KPj4gICAtIE9y IGlzIGl0IGF1dG9tYXRpY2FsbHkgYXNzdW1lZCBpZiBpbnB1dD1saW5rIzEsIG91dHB1dD1saW5r IzQsDQo+PiAgICAgdGhlbiBpbnB1dD1saW5rIzQsIG91dHB1dD1saW5rIzE/DQo+PiAgIC0gT3Ig dGhpcyBzb3J0IG9mIGNvbnN0cmFpbnQgaXMgbm90IHNwZWNpZmllZCBpbiBMaW5rIFNldCBGaWVs ZD8NCj4+DQo+PiBUaGUgdGV4dCBzZWVtcyBsaWtlIHNheWluZyB0aGUgZmlyc3Qgb3B0aW9uLCBi dXQgSSBkbyBub3QgdGhpbmsgdGhpcyBpcyBhIGNvbW1vbiBlcXVpcG1lbnQgaW1wbGVtZW50YWlv bi4NCj4+DQo+PiBZT1VHTj4+IE9LLiBJIHRoaW5rIEkgdW5kZXJzdGFuZCB5b3UgbW9yZSBjbGVh cmx5LiBGb3IgdGhpcyBjYXNlIChiaWRpcmVjdGlvbmFsIGxpbmsgc2V0cyksIHRoZSBmaXJzdCBj YXNlIGlzIGRlZmluaXRlbHkgbm90IHRoZSBpbnRlbnRpb24uIFRoZSBzZWNvbmQgY2FzZSBpcyBh c3N1bWVkLiANCj4+DQo+PiBUaGFua3MsDQo+PiBUb21vbm9yaQ0KPj4NCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBMZWV5b3VuZyBbbWFpbHRvOmxlZXlvdW5nQGh1YXdl aS5jb21dIA0KPj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyMCwgMjAxNSA3OjU0IEFNDQo+PiBU bzogVG9tb25vcmkgVGFrZWRh77yI5q2m55Sw55+l5YW477yJOyBydGctYWRzQHRvb2xzLmlldGYu b3JnDQo+PiBDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1jY2FtcC1nZW5lcmFs LWNvbnN0cmFpbnQtZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyc7ICdjY2FtcEBpZXRmLm9yZycN Cj4+IFN1YmplY3Q6IFJFOiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1jY2Ft cC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLTE2LnR4dA0KPj4NCj4+IEhpIFRvbW9ub3JpLA0K Pj4NCj4+IFRoYW5rcyBmb3IgcHJvdmlkaW5nIGdvb2QgY29tbWVudHMuIEhlcmUncyBteSByZXNw b25zZS4gUGxlYXNlIHNlZSBpbi1saW5lLg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBZb3VuZw0KPj4N Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBydGctZGlyIFttYWlsdG86 cnRnLWRpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9tb25vcmkgVGFrZWRhDQo+ PiBTZW50OiBTYXR1cmRheSwgSmFudWFyeSAxNywgMjAxNSA3OjU5IEFNDQo+PiBUbzogcnRnLWFk c0B0b29scy5pZXRmLm9yZw0KPj4gQ2M6ICdydGctZGlyQGlldGYub3JnJzsgJ2RyYWZ0LWlldGYt Y2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcnOyAnY2Nh bXBAaWV0Zi5vcmcnDQo+PiBTdWJqZWN0OiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQt aWV0Zi1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnQtZW5jb2RlLTE2LnR4dA0KPj4NCj4+IEhlbGxv LCANCj4+DQo+PiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3Mg dG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBw YXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVz IG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92 aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIA0KPj4NCj4+IEFsdGhvdWdo IHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcg QURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25n IHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUs IGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRh dGluZyB0aGUgZHJhZnQuIA0KPj4NCj4+IERvY3VtZW50OiBkcmFmdC1pZXRmLWNjYW1wLWdlbmVy YWwtY29uc3RyYWludC1lbmNvZGUtMTYudHh0IA0KPj4gUmV2aWV3ZXI6IFRvbW9ub3JpIFRha2Vk YQ0KPj4gUmV2aWV3IERhdGU6IDE3IEphbnVhcnksIDIwMTUNCj4+IElFVEYgTEMgRW5kIERhdGU6 IDE3IEphbnVhcnksIDIwMTUNCj4+IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQo+ Pg0KPj4gU3VtbWFyeToNCj4+DQo+PiBUaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFkeSBm b3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHBy aW9yIHRvIHB1YmxpY2F0aW9uLg0KPj4NCj4+IENvbW1lbnRzOg0KPj4NCj4+IFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIHByb3RvY29sLWFnbm9zdGljIGVuY29kaW5ncyBmb3IgZ2VuZXJhbCBpbmZv cm1hdGlvbiBlbGVtZW50cyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2EtaW5mby4N Cj4+IEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIGluIGdvb2Qgc2hhcGUgYnV0IHRoZXJlIGFyZSBh IGZldyBwb2ludHMgdGhhdCBzaG91bGQgYmUgY2xhcmlmaWVkIGZvciBiZXR0ZXIgdW5kZXJzdGFu ZGluZy4NCj4+DQo+PiBNYWpvciBJc3N1ZXM6DQo+Pg0KPj4gTm9uZQ0KPj4NCj4+IE1pbm9yIElz c3VlczoNCj4+DQo+PiBOb25lDQo+Pg0KPj4gTml0czoNCj4+DQo+PiAxKSBJbiBzZWN0aW9uIDEu MiwgbGFiZWwgY29udGludWl0eSBjb25zdHJhaW50IChlLmcuLCB3YXZlbGVuZ3RoIGNvbnRpbnVp dHkgaW4gV1NPTikgaXMgbWVudGlvbmVkLiBIb3dldmVyLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIg aW5mb3JtYXRpb24gZWxlbWVudHMgZm9yIHdoaWNoIHRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGVu Y29kaW5ncyBjYW4gZGVzY3JpYmUgc3VjaCBjb25zdHJhaW50LiBNeSByZWFkaW5nIGlzIHRoYXQg aW5mb3JtYXRpb24gZWxlbWVudCBzdWNoIGFzIFBvcnQgTGFiZWwgUmVzdHJpY3Rpb24gaXMgcmF0 aGVyIGZvciBkZXNjcmliaW5nIHdhdmVsZW5ndGggdHVuaW5nIGNhcGFiaWxpdGllcy9yZXN0cmlj dGlvbnMuDQo+Pg0KPj4gWU9VTkc+PiBMYWJlbCBjb250aW51aXR5IGNvbnN0cmFpbnRzIGNhbiBi ZSBpbmZlcnJlZCBmcm9tIHRoZSB0d28gcGxhY2VzIGluIHRoZSBkcmFmdDogKGkpIFBvcnQgTGFi ZWwgUmVzdHJpY3Rpb24sIHdoaWNoIGdpdmVzIHRoZSBzZXQgb2YgbGFiZWxzICh3YXZlbGVuZ3Ro cykgdGhhdCBtYXkgbm90IGJlIGF2YWlsYWJsZSBvbiBjZXJ0YWluIGxpbmtzIGluY2x1ZGluZyB0 dW5pbmcgcmFuZ2UvcmVzdHJpY3Rpb247IChpaSkgQXZhaWxhYmxlL1NoYXJlZCBCYWNrdXAgTGFi ZWwgRmllbGRzIChzZWN0aW9uIDIuNCAmIHNlY3Rpb24gMi41KS4gVGhlcmUgaXMgbm8gZW5jb2Rp bmcgZm9yIGxhYmVsIGNvbnRpbnVpdHkgY29uc3RyYWludCBwZXIgc2UuIFRoZSBhZm9yZW1lbnRp b25lZCBjb25zdHJhaW50cyBhcmUgZW5jb2RlZCB0byBnaXZlIGEgbm9kZSBvciBhIFBDRSB0byBi ZSBhYmxlIHRvIGNvbXB1dGUgYSBwYXRoIChpLmUuLCBwYXRoIHdpdGggd2F2ZWxlbmd0aCBjb250 aW51aXR5KSBzdWJqZWN0IHRvIHRoZXNlIGNvbnN0cmFpbnRzLiANCj4+DQo+PiAyKSBJbiBzZWN0 aW9uIDIuMSwgaXQgc2F5cyAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNhbWUge3Ny YyBwb3J0LCBzcmMgbGFiZWwsIGRzdCBwb3J0LCBkc3QgbGFiZWx9Ii4gVG8gYmUgcHJlY2lzZSwg SSBndWVzcyB0aGlzIHNob3VsZCBiZSAidHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUgdGhlIHNh bWUge3NyYyBwb3J0LCBzcmMgbGFiZWx9LCBhbmQgdHdvIG1hdHJpY2VzIHdpbGwgbm90IGhhdmUg dGhlIHNhbWUge2RzdCBwb3J0LCBkc3QgbGFiZWx9Ij8NCj4+DQo+PiBZT1VORz4+IEkgdGhpbmsg eW91ciBzdWdnZXN0aW9uIG1heSBiZSB0b28gcmVzdHJpY3RpdmUuIEZvciBpbnN0YW5jZSwgaWYg d2UgaGF2ZSBvbmUgc291cmNlIChwb3J0IDEpIGFuZCBvbmUgZGVzdGluYXRpb24gKHBvcnQgMikg d2l0aCB0d28gbGFiZWxzIGVhY2guIFRoZW4gd2Ugd291bGQgaGF2ZTogeygxLDEsMiwxKSwgKDEs MSwyLDIpLCAoMSwyLDIsMSksICgxLDIsMiwyKX0gSSB0aGluayB3aXRoIHRoZSBjdXJyZW50IHN0 YXRlbWVudCwgd2UgY2FuIHNlbmQgdGhpcyBpbmZvIGluIGFueSBjb21iaW5hdGlvbiBvZiBtdWx0 aXBsZSBtYXRyaWNlcywgd2hpY2ggSSB0aGluayBwZXJmZWN0bHkgZmluZS4gV2l0aCB5b3VyIHN1 Z2dlc3Rpb24sIEkgd291bGQgbm90IGJlIGFibGUgc2VuZCAoMSwxLDIsMSkgYW5kICgxLDEsMiwy KSB0b2dldGhlci4gV2h5IHdvdWxkIHRoaXMgbm90IGJlIG1hZGUgcG9zc2libGU/IE15IHRha2Ug aXMgYXMgbG9uZyBhcyBlYWNoIHN1Ym1hdHJpeCByZXByZXNlbnRzIGEgc2V0IG9mIGRpc2pvaW50 IHF1YWRydXBsZXMsIHRoYXQgc2hvdWxkIGJlIGFsbG93ZWQuIA0KPj4NCj4+IDMpIEluIHNlY3Rp b24gMi4xLCBpdCBzYXlzICJUaGUgdmFsdWUgb2YgMHhGRiBpcyByZXNlcnZlZCBmb3IgdXNlIHdp dGggcG9ydCB3YXZlbGVuZ3RoIGNvbnN0cmFpbnRzIi4gSSB0aGluayAicG9ydCB3YXZlbGVuZ3Ro IGNvbnN0cmFpbnRzIiBzaG91bGQgYmUgInBvcnQgbGFiZWwgcmVzdHJpY3Rpb24iLg0KPj4NCj4+ IFlPVU5HPj4gWWVzLCB0aGFua3MuIA0KPj4NCj4+IDQpIEluIHNlY3Rpb24gMi4xLCBmb3IgTGlu ayBTZXQgQSBkaXI9YmlkaXJlY3Rpb25hbCwgTGluayBTZXQgQiBkaXI9YmlkaXJlY3Rpb25hbCwg aWYgYW55IHNpZ25hbCBvbiBhbiBpbnB1dCBsaW5rIFggaXMgb3V0cHV0IG9uIGEgbGluayBZLCB0 aGVuIGFueSBzaWduYWwgb24gYW4gaW5wdXQgbGluayBZIGlzIG91dHB1dCBvbiBhIGxpbmsgWCAo YWZ0ZXIgY3Jvc3MtY29ubmVjdCk/IE9yIGFueSBjb25zdHJhaW50IG9uIHN1Y2ggc2lnbmFsIGZs b3cgKGFmdGVyIGNyb3NzLWNvbm5lY3QpIGlzIG91dCBvZiBzY29wZT8NCj4+DQo+PiBZT1VORz4+ IEkgYW0gbm90IHN1cmUgd2hhdCAiYWZ0ZXIgY3Jvc3MtY29ubmVjdCIgaXMgbWVhbnQuIA0KPj4N Cj4+IDUpIEluIHNlY3Rpb24gMi4yLjEsIGl0IHNheXMgIkluIHRoaXMgY2FzZSB0aGUgYWNjb21w YW55aW5nIGxhYmVsIHNldCBpbmRpY2F0ZXMgdGhlIGxhYmVscyBwZXJtaXR0ZWQgb24gdGhlIHBv cnQuIiBJIHRoaW5rICJwb3J0IiBzaG91bGQgYmUgInBvcnQvbWF0cml4Ii4NCj4+DQo+PiBZT1VO Rz4+IFllcywgdGhhbmtzLiANCj4+DQo+PiA2KSBJbiBzZWN0aW9uIDIuMi4yLCBpdCB3b3VsZCBi ZSBiZXR0ZXIgdG8gZGVzY3JpYmUgdGhlIHR5cGUgKGUuZy4sIGludGVnZXIpIGZvciBNYXhOdW1D aGFubmVscy4NCj4+IFRoaXMgYWxzbyBhcHBsaWVzIGZvciBNYXhMYWJlbFJhbmdlIChpbiBzZWN0 aW9uIDIuMi4zKSBhbmQgTnVtIExhYmVscyAoaW4gc2VjdGlvbiAyLjYpLg0KPj4NCj4+IFlPVU5H Pj4gT0suIA0KPj4NCj4+IDcpIEluIHNlY3Rpb24gMi42LCBpdCBzYXlzICJMYWJlbCBTZXQgRmll bGQgaXMgdXNlZCB3aXRoaW4gdGhlIDxBdmFpbGFibGVMYWJlbHM+IG9yIHRoZSA8U2hhcmVkQmFj a3VwTGFiZWxzPiIuIEJ1dCBJIHRoaW5rIExhYmVsIFNldCBGaWVsZCBpcyBhbHNvIHVzZWQgd2l0 aGluIFNJTVBMRV9MQUJFTCwgTEFCRUxfUkFOR0UgYW5kIFNJTVBMRV9MQUJFTCAmIENIQU5ORUxf Q09VTlQuDQo+Pg0KPj4gWU9VTkc+PiBZZXMsIGl0IGlzIHVzZWQgaW4gbXVsdGlwbGUgcGxhY2Vz LiANCj4+DQo+PiBIb3cgYWJvdXQ6DQo+PiBPTEQ6IExhYmVsIFNldCBGaWVsZCBpcyB1c2VkIHdp dGhpbiB0aGUgPEF2YWlsYWJsZUxhYmVscz4gb3IgdGhlDQo+PiAgICA8U2hhcmVkQmFja3VwTGFi ZWxzPiwgd2hpY2ggaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIuNC4gYW5kIDIuNS4sDQo+PiAgICBy ZXNwZWN0aXZlbHkuDQo+PiBORVc6IExhYmVsIFNldCBGaWVsZCBpcyB1c2VkIHdpdGhpbiB0aGUg PEF2YWlsYWJsZUxhYmVscz4gb3IgdGhlDQo+PiAgICA8U2hhcmVkQmFja3VwTGFiZWxzPiwgd2hp Y2ggaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIuNC4gYW5kIDIuNS4sDQo+PiAgICByZXNwZWN0aXZl bHkuIEl0IGlzIGFsc28gdXNlZCB3aXRoaW4gdGhlIDxTSU1QTEVfTEFCRUw+LCANCj4+ICAgIDxM QUJFTF9SQU5HRT4sIDxTSU1QTEVfTEFCRUw+IG9yIDxDSEFOTkVMX0NPVU5UPiwgd2hpY2ggaXMg ZGVmaW5lZA0KPj4gICAgaW4gU2VjdGlvbnMgMi4xLjEgLSAyLjEuNCwgcmVzcGVjdGl2ZWx5LiAN Cj4+DQo+Pg0KPj4gVGhhbmtzLA0KPj4gVG9tb25vcmkNCj4+DQoNCg== From nobody Fri Jan 23 10:34: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 839E21ACDD3 for ; Fri, 23 Jan 2015 10:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.378 X-Spam-Level: X-Spam-Status: No, score=-99.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_SLUT=2.522, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 G2GUE-Fk-Aph for ; Fri, 23 Jan 2015 10:34:25 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED011ACDCF for ; Fri, 23 Jan 2015 10:34:24 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIYIOU003130; Fri, 23 Jan 2015 18:34:18 GMT Received: from 950129200 (089144209017.atnat0018.highway.a1.net [89.144.209.17]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIYBkn003043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 18:34:17 GMT From: "Adrian Farrel" To: "'Leeyoung'" , References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7DA1A@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7DA1A@dfweml706-chm> Date: Fri, 23 Jan 2015 18:34:11 -0000 Message-ID: <009801d0373b$32210f90$96632eb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQJ3wIujAyk0V7MCCvPLSJzU0GSw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21278.002 X-TM-AS-Result: No--25.945-10.0-31-10 X-imss-scan-details: No--25.945-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtHoItLliax8Q7Gj3LN0+Ey9H9w9ONeWwHKqvcIF1TcLYKmw 5s23nMRbg1Z+dMbI6xQ6c6vDFSAdOBikjLq23VARlTsGW3DmpUsxmbT6wQT2ayP8GBeiiqDDJz/ Fli73wMiS/tZ2a/cX4+DFtzSqSPhRfF2w37ROyLM5yOdvO+rz33nL427v8Q46mBadosOIaCE+xn rY8SIOUh+33+vWXrpPW1TaGz/XYhSBupdkaEeObs1GzI6JnJjKH181YDtIVaqL+72Niu/rKbt+i +Gg5iN89fAy5OzP/1Mlqegxl8Tt3mlaYefQTGcyMtFjrTUutqR+Mk6ACsw4Jh9W4auM/sn0zVfj PwElWIrfw0uruGlfw5kLx6fQB6+1QpfQxLB50m0gKw/iul4Zx35Lmbb/xUuaYgFKBJUH5aO0nj9 xfM4ElGUPU2xFnfcx/HUNnzD9of40nllLIxRZ5obBPrt55wnwKVrLOZD1BXTE3grQNcpLWL4OWM 8hMbOS1jTArul9RVP3CbhR1iOkb3XHdWrIeHKU2OSj4qJA9QYHSA1qABZYHsI9dI7bfY/vlVRTv f2hoTyMEUuvpm4xfCOqG1yPKER2ahqNaxEQeGh7k1ZHmKLF7Vt06oMfzUpKeNDQ2odiEiGBuLDz zkmS1/EdLUjZYlvwteD6gJDksuS26aZT+DLr1IvtmwtVGLEkMJebi1vXnNOp7t/yrVnxkBZaDvo iUT/M5oP7fDAckCqun8wjeYlO709iedN46vv1SEQN/D/3cG5Cs7hdHoFFA2M+uU0H6Ayr33pzMs MDyh/Bu0rxt7xJrbGjgTsA6f3+e4eN1GlxwYeeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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: Fri, 23 Jan 2015 18:34:28 -0000 Hi, Picking up the remaining comments that I haven't cut out into separate threads. > YOUNG>> How about the figure 1 in Appendix A.1, I think it should have been > labeled as "RB Pool" instead of WC Pool. I will change "WC" to "RB" and point to > this figure from Section 2.1 and Section 3.2 where RB Set is explained in the > context of Resource Pool. I don't think you should point to the Appendix to achieve explanation in your text. You should explain the terms more clearly as in my other thread. That said, figure 1 *is* very helpful. I don't think you should change the labelling in the figure. The thing it shows is a pool of wavelength converters. That's good. Perhaps you could add a note as: OLD This wavelength converter pool can be encoded as follows: NEW The wavelength converters are resource blocks and the wavelength converter pool is a resource block pool. This can be encoded as follows: END > >> Section 2.1 > >> > >> The RB identifier represents the ID of the resource block which is a > >> 32 bit integer. [snip] > As I asked above, when you advertise RB ID 1 to me, how do I know which > resources you are referring to? > > YOUNG>> In Section 3.1 Resource Accessibility Field is defined and encoded as > below: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Reserved(8bits)|C| Reserved (23 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Link Set Field A #1 | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set Field A #1 | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Additional Link set and RB set pairs as needed to | > : specify PoolInputMatrix : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Link Set Field B #1 | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set B Field #1 (for output connectivity) | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Additional Link Set and RB set pairs as needed to | > : specify PoolOutputMatrix : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > RB Set Field defines the RD ID's and Input/Output Link Sets are associated with RB > ID's. Let me try a different way: - Who assigns a RB ID? - Who actually knows what it refers to (in the physical space)? - Does anyone outside the node itself need to know anything other than "A resource block exists, with these properties, and this is its ID"? - Shouldn't all of the discussion and explanation of terms and concepts be in the Information Model document? > >> Section 3.1 > >> > >> Why isn't the Resource Accessibility Field expressed in terms of the > >> use of a generic Connectivity Matrix Field from section 2.1 of > >> [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive > >> application agnostic encodings that could be used without modification > >> (but with applicability notes) by specific technologies. > > > > [YOUNG] Not quite. Connectivity Matrix encoding cannot be used for Resource > > Accessibility Field as the latter > > has additional entity (namely, RB set field) to describe. We generalized a > > single-stage connectivity matrix in [Gen-Encode] that can > > be applicable to any switching technology. Here in WSON, we have a need to > > model RB constraints (for the pool of Wavelength Converters) > > from/to input/output link sets. Putting two different entities into one coding > > was not the choice of the authors. > > I don't understand. > You say that the generalized single-stage connectivity matrix can be applicable > to any switching technology and then you don't use it for WSON saying that you > need other constraints as well. > Are you, in fact, saying that the generalized single-stage connectivity matrix > is not applicable to WSON? > > YOUNG>> No that is not what I am saying. WSON uses both the connectivity > matrix and the RB. > The RB is only unique for WSON element. OK. I think this may drop out from getting the definition of RB clear as in the separate thread. In order that RB is a unique concept applicable only to a WSON node, it must follow that Resource is similarly a unique concept applicable only to a WSON node. Now, the definition we have been arriving at for Resource becomes circular :-( It is defined in terms of WSON technology (it is a regenerator or a wavelength converter component in a WSON node). Could you describe those concepts generically? For example, a wavelength converter is a component that does a label swap and has severely restricted swap capabilities. For example, a regenerator is a component that sits in the path, retains the label, but has a limited input label capability. It could quite probably be the case that these components only arise in a WSON system, but it is very helpful to properly describe them in general terms. Once described in general terms we can decide whether they should be generic components of the encoding model, or remain as specific for WSON. > >> Section 3.2 > >> > >> I looked for the equivalent of the Resource Wavelength Constraints > >> Field in [Gen-Encode]. I understand that Input Wavelength Constraints > >> Field and Output Wavelength Constraints Field are encoded using the > >> generic Label Set of [Gen-Encode], but I thought that the whole concept > >> of Resource Constraints would be generic. > > > > [YOUNG] Again, I think the design of generalization is not intended to > > share the same encoding to describe two different entities. Besides, I do > > not see the need to generalize encoding of an entity that has no particular > > use in other technologies than WSON. > > I think the point of generalization is to come up with an encoding that can be > re-used in different witching environments. > Obviously, the only environment with wavelength is WSON. But all switching > environments have labels that are switched, and have constraints applicable to > those labels and to the ability to switch the labels. > > Suppose I wrote: > > Resources, such as switches and filters, may have limited > input or output label ranges. Additionally, due to the > structure of the switches not all labels can necessarily > reach or leave all the resources. These properties are described by > using one or more resource restrictions fields as defined > below: > > That is just a rewrite of 3.2 in general terms and seems to not be a problem. > Indeed, if general-constraint-encode had had... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I|O|B| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set Field | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Label Constraints | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Label Constraints | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ...then I would have thought it a perfect fit. > > > Section 3.3 > > > > As with the previous section I don't see anything that is WSON-specific > > in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field > > and I wondered why [Gen-Encode] doesn't have anything to cover this. > > > > [YOUNG] RB is wavelength converters, which is a unique WSON element. > > No! > You might as well say that a lambda is a unique WSON concept and so cannot > re-use the generic concept of the LABEL object. > > Isn't a "wavelength converter" just a special case of a label switch? That is > certainly how I read RFC 6163 > Wavelength converters take an input optical signal at one wavelength > and emit an equivalent content optical signal at another wavelength > on output. > > I think you are just not stepping back far enough to see the concept of > "generalization." > > YOUNG>> As the figure 1 from Appendix A, WC's are additional element on top > of a label switch. I still think it is a unique WSON element which may not be > relevant to Generic label switch paradigm. OK. Got it. We were talking past each other with terminology because I was looking for the black-box behaviour of a WSON node while you are modelling and controlling the internal components of a WSON node. With this in mind, of course you are right. The physical components, that is the partitioned physical components, only exist in a WSON node. I, on the other hand, was looking at how you model the generic multi-function switch. How would you model a switch that was able to selectively switch signals from one port to another and selectively change the labels applied to those signals? My claim would be that you use (or could use) exactly the same abstract components. That said, this conversation has gone on long enough. I think that only you and I are interested in the outcome. That makes me pretty sure that the WG is not very interested. Equally, it makes me sure I shouldn't get in the way. > >> Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? > > > > [YOUNG] I think the reason for B bit is not included in Section 3.4 is the > > context where it won't be very useful (even if we have a B bit) as input > > wavelengths available will hardly match with output wavelength available > > in most cases. > > Compared to this, wavelength constraints can more often be same for input > > and output. > > This isn't very convincing. > "in most cases" suggests sometimes it will. > Are you saying the use of one extra bit outweighs the saving in encoding in the > rare cases where that bit could be used? > > YOUNG>> I can add B bit if you think it must be there in Sections 3.4 and 4. I'm sorry if I am driving you to do things "because Adrian says so." My job is to get you to come to the right answer. It doesn't matter what I think now. What matters is that you come to the right answer and are able to defend it. There can be a convincing technical reason that you can explain, or you can say that there is no significant technical reason to jump either way and so you have simply picked one way. > >> Section 4 > >> > >> How do I know the length of the ResourceBlockInfo field? I need to know > >> this to decide whether to try to parse the next bytes as another > >> Optional subfield. I *do* when I reach the end of one Optional subfield, > >> but I don't know whether another follows. > >> > >> Possibly you intend the object that includes a ResourceBlockInfo field > >> to provide the length information, but other fields defined in this > >> document do include lengths or enough information to deduce the lengths. [snip] > YOUNG>> The object that includes a ResourceBlockInfo field provides the length > info. > I grant however there is inconsistency here. Not sure what is the best. Perhaps, > effectiveness may be sacrificed unless things are broken. That is fine. Please, for the sake of future reviewers, add a note so say "The length of the ResourceBlockInfo field is determined from the length of the object that includes it." > >> Section 4.1 > >> How do I interpret a Vendor-Specific Application Code? Is there an OUI > >> I'm missing? > > > > [YOUNG] Not sure if I understood this question. What is "OUI"? [snip] Moved to a separate thread to try to get conclusion. > >> 4.1.1 and 4.1.2 > >> > >> An Optional F can be added indicating a FEC Encoding. > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |B| D |S| c | W | y | t | z | v | F | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | reserved | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> F (suffix): = 0 reserved, = 1 Fec Encoding > >> > >> Values not mentioned here are not allowed in this application > >> code > >> > >> If F is optional but only one value is allowed (viz. 1) how do I opt to > >> not indicate a FEC Encoding? > > > > [YOUNG] I guess 0 will do it. > > But I can't set zero because it is reserved. > > [YOUNG] I can add "F bit not equal 1" implies a FEC Encoding is not included. Why can't you OLD An Optional F can be added indicating a FEC Encoding. NEW The F flag indicates the presence or not of an optional FEC Encoding suffix. END and OLD F (suffix): = 0 reserved, = 1 Fec Encoding NEW F (suffix): = 0 No FEC Encoding suffix present, = 1 FEC Encoding suffix present END Adrian From nobody Fri Jan 23 10:46: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 E97DB1A86F6 for ; Fri, 23 Jan 2015 10:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 IRpkh2U60k5O for ; Fri, 23 Jan 2015 10:46:08 -0800 (PST) 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 D421A1A7002 for ; Fri, 23 Jan 2015 10:46:07 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIjwJY020876; Fri, 23 Jan 2015 18:45:58 GMT Received: from 950129200 (089144209017.atnat0018.highway.a1.net [89.144.209.17]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIjtRM020857 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 18:45:57 GMT From: "Adrian Farrel" To: "'Leeyoung'" , "'Giovanni Martinelli \(giomarti\)'" References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm> Date: Fri, 23 Jan 2015 18:45:54 -0000 Message-ID: <010501d0373c$d34e3db0$79eab910$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAmjcynMdOjxZUzM6y2aNWnfhgwAHd8I9cm15TodA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21278.002 X-TM-AS-Result: No--8.192-10.0-31-10 X-imss-scan-details: No--8.192-10.0-31-10 X-TMASE-MatchedRID: cgbqQT5W8hc4HKI/yaqRm+YAh37ZsBDCQKuv8uQBDjrVl0v7E9Khhjmt pOQ8tq11oL3FOYWIsdHUbKn/PdoC7En4dMSWXlsdttAWxuM5sl5kBDPLxNH5BuRmz46Q29bDXQT /yMDXZh21j2LKTBq2U8Y73AWvgGeH5U8oG6fPYRNIOSHptb5tx9tb21l1J0jcIHMhnr7X7SejxY yRBa/qJX3mXSdV7KK4OubYLCVnBVF5zdAzex5xZmgubNf+0eKAyqKRqIgMlCSSF6dRnbBxF3TUR CkzqBevzRg4qDlub1qUTGVAhB5EbQ== Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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: Fri, 23 Jan 2015 18:46:10 -0000 > Thanks Adrian for taking this on. Well, we'll get there eventually! > My preference is Option 1. OK. It is my least favorite option because it is most likely to hit interoperability issues. So, if the WG wants to go this way, we will have to work a little to explain how it works and why it isn't a problem (specifically for the IESG). > It would be hard to catch moving target around this > area if we were to take Option 2. I see no moving targets at all. This is how all other vendor-specific fields are handled in protocols. The way it works is that anyone receiving such a field looks at the first 32 bits and interprets it as an Enterprise Code from the IANA registry (hint: easy to get and many well-known vendors have them). If it is an Enterprise Code they recognise they process according to their own vendor-specific knowledge about the contents. If they don't recognise the Enterprise Code, they fail the processing. An Enterprise will often (always?) define their own structure starting with a version number or something similar, and often using TLVs. What have I missed about moving targets? Cheers, Adrian From nobody Fri Jan 23 10:52: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 EB0271A8700 for ; Fri, 23 Jan 2015 10:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 VXI70H1CGhaO for ; Fri, 23 Jan 2015 10:51:41 -0800 (PST) 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 3D5D91A86E3 for ; Fri, 23 Jan 2015 10:51:08 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIow8O022977; Fri, 23 Jan 2015 18:50:58 GMT Received: from 950129200 (089144209017.atnat0018.highway.a1.net [89.144.209.17]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIotc5022942 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 18:50:57 GMT From: "Adrian Farrel" To: "'Leeyoung'" , References: <006a01d03721$11490170$33db0450$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E013@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7E013@dfweml706-chm> Date: Fri, 23 Jan 2015 18:50:54 -0000 Message-ID: <010801d0373d$865ae160$9310a420$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMHSijD9OtehoLW+lP6yANWbX4HwgK+NNsPmkn0fDA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21278.002 X-TM-AS-Result: No--23.640-10.0-31-10 X-imss-scan-details: No--23.640-10.0-31-10 X-TMASE-MatchedRID: x2HXvaraFom+9Go4BgFPZgRH1Nr7oERdGSqdEmeD/nVJJReS9JUB3AaT alM8C773QQtdgo5YSWhIsgeX/PG9Zba06Jggiu2V3FqOVb7PDEKeimGtNywjttp1biJhIyNRXa2 +zE1cP+U3jelxKeBccKTRVhN59X1QgRy3HHXz6caaVoAi2I40/QXXmzqmsIi70KiNejbR39D6QR zjTw1oytJVo98vHaBPH84/fI58amMItMWhbSshqnV895e/Bd2JpfVcx39Kq+4b4NAU3x/cGUfl+ H4+MqTJvkVmw2xxRFia8KBvLePZCR1YpEPWJiyz84dsinZ5e1g0AKed0u9fB7rfxlRjqBJ3C9u4 t4siKdfXuKn6Epb/8XJx+bDPe9HX1M73D0qKwJQS7luGt6tlhlXKDhjPZTukdvZ5LJp45ksz6n4 2mzBmahD04cBTzvBYRWqZS1D9m9FFsw2Lp+kSuMOvQCMFyZ9Gecvjbu/xDjpV84HrPxCfbHLxsR yKaXupwM2jgIXgmkYs+lHplZhRHupLXJKeenhQj5hLPCX3ZdO/yN2q8U674tqCxkzSpW/XIEFqD yMwcNonAC0lpjxIxscHvwkNmxhvGAdnzrnkM485f9Xw/xqKXcidYBYDjITp+gD2vYtOFhgqtq5d 3cxkNQP90fJP9eHt Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org Subject: Re: [CCAMP] Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info 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: Fri, 23 Jan 2015 18:51:44 -0000 OK, this is looking good. I think some more work is needed on pool and set. Looks like my text for pool should be used for set, and a new definition is needed for pool to describe a collection of sets. If you can do this and suggest to me where in rwa-info to put that text, I'll work it with the RFC Editor. Then later docs will only need to point at rwa-info. Thanks! Adrian > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: 23 January 2015 15:57 > To: adrian@olddog.co.uk; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: RE: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp- > rwa-wson-encode and draft-ietf-ccamp-rwa-info > > Hi Adrian, > > I think we are on the same page. Please see inline for specific comment. > > Best regards, > Young > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, January 23, 2015 9:27 AM > To: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa- > wson-encode and draft-ietf-ccamp-rwa-info > > Hello, > > Continuing this discussion, I think we are getting closer. > > > > My comment for general vs. WSON-specific issue is that the design > philosophy > > > of general encoding was to generalize a common element that can be applied > > > to different technologies. For instance, connectivity matrix definitely can > be > > > applied to WSON, OTN and other Switching technology as one encoding can > > > fit to all. You seemed to desire a sharing of the same encoding to describe > > > different entities where possible. This is fine for label vs. wavelength as > > > there is one-to-one mapping for this. However, Resource Block encoding > > > cannot properly share with the connectivity matrix encoding with two > > > reasons: > > > > > > 1. They refer to different elements in the node. > > > 2. They require different sets of fields with different number of fields. > > OK, what we really seem to be running into is some rather vague definitions of > "resource" and "resource block". > Do you think we could spend some time nailing those down. Then we'll work out > where to put them (possibly in rwa-info). > > YOUNG>> Yes, I have just noticed that you held rwa-info and I hope you can > suggest some clarifying text into that draft, which I see below. > > The question is not about the protocol element "resource block" but is about > what it represents. > > So, as a starter, what is a Resource in a WSON system? > You have said (lower down this email) that " resources meant > regenerators/wavelength converters". > I can live with this (although it is a long way from the term "resource" used in > 3473 etc. where it is taken to mean buffers, bandwidth, memory, labels, > lambdas,... > That difference in interpretation is sufficiently large that it needs to be > brought out and made very clear. > You need something like: > In this document the term "Resource" is used to refer to a > physical component of a WSON node such as a regenerator > or a wavelength converter. Multiple instances of such > components are often present within a single WSON node. > This term is not to be confused with the concept of > forwarding or switching resources such as bandwidth or > lambdas. > > YOUNG>> Great suggestion. Yes, that is what is Resource is. The part of the > problem has been that the term 'resource' was picked when the WG asked us to > generalize Regenerators/wavelength converters. This term 'resource' may have > not been perfect, but it was chosen as such to have its meaning in a specific > context. > > Then you can answer what is a Resource Block in a WSON system? > From what I think I now understand, a resource block is simply a collection of > resources on a WSON network node that behave in the same way. This allows > easier > description in the protocol encoding, but has no other meaning. So you could > say: > A Resource Block is a collection of Resources from the same > WSON node that are grouped together for administrative reasons > and for ease of encoding in the protocols. All Resources in the > same Resource Block behave in the same way and have similar > characteristics relevant to the optical system, e.g., processing > properties, accessibility, etc. > > YOUNG>> Yes, it is correct. > > Then comes, what is a Resource Pool? Actually, this is only implicitly defined > in draft-ietf-ccamp-rwa-info and so we have quite a gap. It looks like you might > say: > A Resource Pool is a collection of Resource Blocks for the > purpose of representing throughput or cross-connect > capabilities in a WSON node. A Resource Pool associates > input ports or links on the node with output ports or > links and is used to indicate how signals may be passed > from an input port or link to an output port or link by > way of a Resource Block (in other words, by way of a > Resource). A Resource Pool may, therefore, be > modelled as a matrix. > > A Resource Block may be present in multiple Resource > Pools. > > YOUNG>> Yes. > > And finally, we have Resource Block Set. What is that? > I *think* it is just the encoding concept for a Resource Block Pool. > You have (in 2.1) > In a WSON node that includes resource blocks (RB), denoting subsets > of these blocks allows one to efficiently describe common properties > of the blocks and to describe the structure and characteristics, if > non-trivial, of the resource pool. > *Now* I see that your "subsets" should actually be "sets" and that will make > more sense. > > YOUNG>> Yes, "sets" make it clearer. > > But do you need the two terms "Resource Block Pool" and "Resource Block Set"? > Are they the same or different? When I read 3.2 it looks like the Resource Block > Pool is a collection of Resource Block Sets. > > YOUNG>> They are different. Resource Block Pool is sitting above the RB Sets. > There may be multiple RB Sets in a node that behave differently, e.g., different > input/output constraints on the access/egress to the Pool. > > > Have I finally got this right? > > YOUNG>> Yes, I think so. > > If so, then can we agree precise text and where to put it? > > YOUNG>> Yes. > > Thanks for your patience. > Adrian From nobody Fri Jan 23 10:59: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 791B11ACE32 for ; Fri, 23 Jan 2015 10:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PBVNhb-AdOXC for ; Fri, 23 Jan 2015 10:59:22 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48111ACE2E for ; Fri, 23 Jan 2015 10:59:21 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIxE1e013394; Fri, 23 Jan 2015 18:59:15 GMT Received: from 950129200 (089144209017.atnat0018.highway.a1.net [89.144.209.17]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIx9Hq013374 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 18:59:10 GMT From: "Adrian Farrel" To: "'Lam, Hing-Kam \(Kam\)'" , "'Gert Grammel'" , "'Giovanni Martinelli \(giomarti\)'" References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> Date: Fri, 23 Jan 2015 18:59:08 -0000 Message-ID: <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01D0373E.AC1CE820" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAmjcynMdOjxZUzM6y2aNWnfhgwAK7iupBAcWuDJQDAyHmlZsxJSUw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21278.002 X-TM-AS-Result: No--39.203-10.0-31-10 X-imss-scan-details: No--39.203-10.0-31-10 X-TMASE-MatchedRID: CxmI61mtwh+nykMun0J1wuOkx3c0pwugWDdWpJMntKgSYpIWfxKyLEYl +n82wED1Om7tZZlzaJMge8lbIoY9eBac+UrRjxx+l1zsjZ1/6azj5lyuq8IOQTkIJSQdQ27uJMJ XDJjkqdS/jrDM22faPLoWtKVPf8jwzluq0iwuS6glcqT+ugT9EIvIYUxpc3wMa0TOsL14A2nBux 0R7Q0FJ5RUdkJMj3T0WfvheV6pyrREydReAd9gkJEbNXwHGDRxhHz3EzK//HzaqqH/oHw+kQUfw BgmtWYiKOlw30dgDcXmbW1ULHbdKOdv6cWcdrc0UKL/EMdwPN8+WWrj7s+yn+QydRUvl3QTWbzY 4GA2m4vV7Iumy7in0rchJ4qPggEg/ZNpyV8TXRozSlmIs9AhOm79evoIpeI3cf40lLKqPGMJH1L SVN31mW986exXflOnvO0K1FolbmBj5V+yyEyAremc4/pDEQa2jLOy13Cgb4+e9toQ6h6LE3v4ix lgc06fUN8dQnEOEkp3Vf2l/e+4VUWzDYun6RK4y7TSWcbz49bAWTziWGaDPJ2Vet7Q0hBwmOPy3 Gh6CrTUywZycJ7xGUXkE84/COkUtzBuLRbw+9Mk78SxLKShoOdJKF0CJUbKK6rsMmth5SZxtyA5 JI+wF59S3YgdG3IH1eeaKehxgUJjjEH+RszpJnH7HV/mO4UTaBTWjXFXXd9Ev26FkhjLXcrpBMu iQ/7mrDHUBm6rZ1QhIMlpP/jXw2uCdtCAow1/71Wx2uUbPLdBldmDYjwlpqFSh25xC7TpBixx3l Aro9cSDdG85CKy5pYlxuk1ogQA00ktvTk0SGmeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7P9SXNGQ0BxJVnRXm1iHN1Yj80Za3RRg8MQRSEWfQ5f/J0T393oKtIUuNbyaLtDrlDTEQRh+ 4EYgq4X/HlZlHuc= Archived-At: Cc: "'Doolan, Paul \(Coriant - US/Irving\)'" , ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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: Fri, 23 Jan 2015 18:59:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010A_01D0373E.AC1CE820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for being awake, Kam. Useful info. Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry page for this, but it points to the IEEE page. As I understand Kam, 874.1 is not yet updated so it would be premature to point to it, but an option is to attempt to match it now and fix later if needed. Adrian From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com] Sent: 23 January 2015 17:10 To: Gert Grammel; adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Hi Gert, A vendor can purchase an OUI (Organizationally Unique Identifier) from the IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific application identifiers under its own OUI. SG15 doesn't need to host any registry for this purpose. Regards, Kam From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Hi Kam, Is SG15 considering to host a registry for the vendor specific application code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.874.1 to amend the specification of ApplicationIdentifier with the following additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString represents a standard application code as defined in the ITU-T Recommendations. If the ApplicationIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal representation of an OUI assigned to the vendor whose implementation generated the Application Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietary-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion from it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable. I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the document. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a boolean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=0 and OI=1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp ------=_NextPart_000_010A_01D0373E.AC1CE820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for being = awake, Kam.

 

Useful = info.

 

Gert, the OUI registry = is an IEEE registry as Kam says. IANA has a registry page for this, but = it points to the IEEE page.

 

As I understand Kam, = 874.1 is not yet updated so it would be premature to point to it, but an = option is to attempt to match it now and fix later if = needed.

 

Adrian

 

From: Lam, Hing-Kam = (Kam) [mailto:kam.lam@alcatel-lucent.com]
Sent: 23 January = 2015 17:10
To: Gert Grammel; adrian@olddog.co.uk; 'Giovanni = Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); = ccamp@ietf.org; ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi = Gert,

 <= /p>

A vendor can purchase an = OUI (Organizationally Unique Identifier) from the IEEE Registration = Authority.

Once a vendor has its = OUI, the vendor can manage its vendor-specific application identifiers = under its own OUI.

SG15 = doesn’t need to host any registry for this = purpose.

 <= /p>

Regards,

Kam

=

 <= /p>

From: Gert Grammel [mailto:ggrammel@juniper.net]
Sent: = Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); = adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: = Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi = Kam,

 <= /p>

Is SG15 considering to = host a registry for the vendor specific application code or is the IETF = registry supposed to be used?

 <= /p>

Thanks<= /p>

 <= /p>

Gert

 <= /p>

From: CCAMP [mailto:ccamp-bounces@ietf.org]= On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 = 17:03
To: adrian@olddog.co.uk; 'Giovanni = Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); = ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 = meeting, Q14/15 agreed to update G.874.1 to amend the specification of = ApplicationIdentifier with the following additional = text:

 

If the ApplicationIdentifierType is = STANDARD, the value of PrintableString represents a standard application = code as defined in the ITU-T Recommendations. If the = ApplicationIdentifierType is PROPRIETARY, the first six characters of = the PrintableString must contain the Hexadecimal representation of an = OUI assigned to the vendor whose implementation generated the = Application Identifier; the remaining octets of the PrintableString are = unspecified.

 

Paul Doolan had an I-D "https= ://tools.ietf.org/html/draft-doolan-proprietary-ac-00" to the = last IETF meeting with the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org]= On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 = AM

To: 'Giovanni Martinelli = (giomarti)'

Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

<= p class=3DMsoPlainText>Subject: [CCAMP] Vendor-Specific = Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am = not seeing a specific conclusion from it.

 

The current I-D makes (IMHO) the = Vendor-Specific Application Code unusable. I offered three = options:

 

1 This value is only to be used when = it is known that all devices

   participating in a = network have the same understanding of

   the content of the = Vendor-Specific Application Code field.

   How this knowledge is = achieved is outside the scope of this

   = document

 

2 When this value is set, the first 32 = (or 48) bits of the Vendor-

  Specific Application Code field = contain an Enterprise Number

  (or OUI) that defines the = context in which the remainder of

  that field is = interpreted.

 

3 Remove the option to include a = Vendor-Specific Application

   Code = field.

 

If the WG could please pick one of = these and help Young to update the document.

 

Thanks,

Adrian

 

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

> From: Giovanni = Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 = 13:50

> To: adrian@olddog.co.uk

> Cc: Leeyoung; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

=

> ccamp@ietf.org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of = draft-ietf-ccamp-rwa-wson-encode

>

> One additional comment (hoping = not additional confusion).

>

> The idea about Optical Interface = Class was taken from SRLG. Good or

> bad is a plain number and you do = simple operations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, = Giovanni Martinelli (giomarti)

> <giomarti@cisco.com><= /span>

> wrote:

>

> > Hi = Adrian,

> >

> > On 21 Jan 2015, at 22:55, = Adrian Farrel <adrian@olddog.co.uk> = wrote:

> >

> >> = Hi,

> >>

> >> Well, you seem to have a = half-way house.

> = >>

> >> You have specified the = existence of a thing, but not how to read it.

> >>

> >> If you wanted to make a = statement that this object will only be

> >> used = when

it is

> >> known that all systems = in a network come from the same vendor

> >> and/or = have

> the

> >> same understanding of = the encoding, that might be OK (although how

> >> = you

> would

> >> ascertain this might = also need to be described).

> >>

> >

> > The statement is to ensure = the interface compatibility without

> > encoding = all

the

> possible details and parameter = that define an interface (e.g.

> = modulation

format,

> forward error correction etc.). = This was the initial solution in the

> draft

then

> replaced by the interface class = concept.   The WSON (RWA-only) has the

> requirement is to make sure two = interface are compatible. This

> requirement, imho, can be satisfy = by a simple comparison which has a boolean = result.

> >

> > We end up then in  the = ITU application codes for the "certified" =

> > (we'll = this

is my

> term not 100% sure is the best = one) compatibility where proper

> encoding is = provided.

> = >

> >

> >> Or you could entirely = remove the vendor-specific option.

> >>

> >> Or you could put in an = OUI / enterprise number followed by

> >> = transparent

> = bytes.

> >>

> >

> > To me I'm perfectly fine = with the second option.

> >

> > = Cheers

> > G

> >

> >

> >> = Adrian

> >>

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

> >>> From: = Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> >>> Sent: 21 January = 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

=

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org

> >>> Subject: Re: [CCAMP] = AD review of draft-ietf-ccamp-rwa-wson-encode

> = >>>

> >>> = Specifically to the Interface class here below.

> = >>>

> >>> In the = initial draft merged to this one there was the usage of OUI =

> >>> = however

(I

> >>> guess after chatting = with Lou) we decided to remove any encoding

> >>> when the Interface = class is not standard.

> >>> In term of semantic = the protcol does not need to decode the

> >>> = Interface

class

> >> = since

> >>> it only assess the = interface compatibility if two interfaces has a

> >>> = class

value

> >> = that

> >>> match two interfaces = cann be connected.

> = >>>

> >>> Having = saying that I don't have strong opinion in adding the OUI =

> >>> = or

leaving

> >> = room

> >>> for maybe future = public interfaces database. For sure there's a

> >>> need = to

leave

> >>> room for specific = compatibility assesment since there optical

> >>> multivendor = compatibility has been already demonstrated.

> = >>>

> >>> hope = this help .

> = >>>

> >>> = Cheers

> >>> = G

> = >>>

> = >>>

> >>> On 21 = Jan 2015, at 21:57, Adrian Farrel <adrian@olddog.co.uk> = wrote:

> = >>>

> = >>>>>>

> >>>>>> Section = 4.1

> >>>>>> How do I = interpret a Vendor-Specific Application Code? Is there =

> >>>>>> an OUI = I'm missing?

> = >>>>>

> >>>>> = [YOUNG] Not sure if I understood this question. What is = "OUI"?

> = >>>>

> >>>> = http://en.wikipedia.org/wiki/Organizationally_unique_identifier<= /o:p>

> >>>> http:= //www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> = numbers.xhtml#ieee-802

> >>>> = -numbers-2

> = >>>>

> >>>> Or = perhaps an Enterprise Number

> >>>> h= ttp://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> = >>>>

> >>>> The = question is:

> = >>>>

> >>>> You = have sections 4.1.1 through 4.1.4 to tell me how to interpret =

> >>>> = the

> >> = Optical

> >>>> Interface Class = field when it contains an ITU-T Application = Mapping.

> >>>> When I received = s=3D0 and OI=3D1 it means that the Optical Interface =

> >>>> = Class

> >> = contains

> >>>> a "Vendor = Specific Optical Interface Class".

> >>>> How do I = interpret that Optical Interface Class?

> >>>> Which vendor = does it apply to?

> >>>> Is = there some information elsewhere that gives me a clue as to =

> >>>> = which

> vendor

> >>> = has

> >>>> encoded the = information?

> >>>> Or = is the information supposed to be encoded in the Optical =

> >>>> = Interface

Class,

> >>>> perhaps as the = first 48 bits?

> >>>> Or = am I supposed to know by context?

> >>

> >

 

_______________________________________= ________

CCAMP mailing = list

CCAMP@ietf.org

https://www.ietf.org= /mailman/listinfo/ccamp

------=_NextPart_000_010A_01D0373E.AC1CE820-- From nobody Fri Jan 23 12:13: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 37BA31A0379 for ; Fri, 23 Jan 2015 12:12:46 -0800 (PST) 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 TUuSe1p8hXL1 for ; Fri, 23 Jan 2015 12:12:43 -0800 (PST) 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 E95B91A0399 for ; Fri, 23 Jan 2015 12:12:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOJ12559; Fri, 23 Jan 2015 20:12:41 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 20:12:40 +0000 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; Fri, 23 Jan 2015 12:12:38 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Thread-Topic: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info Thread-Index: AdA3HZjonkvmk8bgRpWytOzEjnSVrwABW8lgABdiggAAD0AlwA== Date: Fri, 23 Jan 2015 20:12:38 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7E1C0@dfweml706-chm> References: <006a01d03721$11490170$33db0450$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E013@dfweml706-chm> <010801d0373d$865ae160$9310a420$@olddog.co.uk> In-Reply-To: <010801d0373d$865ae160$9310a420$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info 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, 23 Jan 2015 20:12:46 -0000 Hi Adrian, Ok. Here's my suggestion below. Thanks. Young ---------------------------------------------------------------------------= ---------------- 5. Node Information (WSON specific) As discussed in [RFC6163] a WSON node may contain electro-optical subsystems such as regenerators, wavelength converters or entire switching subsystems. The model present here can be used in characterizing the accessibility and availability of limited resources such as regenerators or wavelength converters as well as WSON signal attribute constraints of electro-optical subsystems. As such this information element is fairly specific to WSON technologies. /* Add: In this document the term "Resource" is used to refer to a physical component of a WSON node such as a regenerator or a wavelength converter. Multiple instances of such components are often present within a single WSON node. This term is not to be confused with the concept of forwarding or switching resources such as bandwidth or lambdas. */ A WSON node may include regenerators or wavelength converters arranged in a shared pool. As discussed in [RFC6163] this can include OEO based WDM switches as well. There are a number of different approaches used in the design of WDM switches containing regenerator or converter pools. However, from the point of view of path computation the following need to be known: 1. The nodes that support regeneration or wavelength conversion. 2. The accessibility and availability of a wavelength converter to convert from a given input wavelength on a particular input port to a desired output wavelength on a particular output port. 3. Limitations on the types of signals that can be converted and the conversions that can be performed. Since resources tend to be packaged together in blocks of similar devices, e.g., on line cards or other types of modules, the fundamental unit of identifiable resource in this document is the Bernstein & Lee Expires June 4, 2015 [Page 6] Internet-Draft WSON Information Model December 2014 "resource block".=20 /* Add: A Resource Block is a collection of Resources from the same WSON node that are grouped together for administrative reasons and for ease of encoding in the protocols. All Resources in the same Resource Block behave in the same way and have similar characteristics relevant to the optical system, e.g., processing properties, accessibility, etc. */ /* Delete:=20 =20 A resource block may contain one or more resources. A resource is the smallest identifiable unit of processing allocation. One can group together resources into blocks if they have similar characteristics relevant to the optical system being modeled, e.g., processing properties, accessibility, etc. */ =20 /* Add: A Resource Pool is a collection of Resource Blocks for the purpose of representing throughput or cross-connect capabilities in a WSON node. A Resource Pool associates input ports or links on the node with output ports or links and is used to indicate how signals may be passed from an input port or link to an output port or link by way of a Resource Block (in other words, by way of a Resource). A Resource Pool may, therefore, be modelled as a matrix.=20 A Resource Block may be present in multiple Resource Pools. */ This leads to the following formal high level model: ::=3D [...] [] Where ::=3D ... [...] [...] [] -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, January 23, 2015 12:51 PM To: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org Subject: RE: Resource, Resource Block, and Resource Pool in draft-ietf-ccam= p-rwa-wson-encode and draft-ietf-ccamp-rwa-info OK, this is looking good. I think some more work is needed on pool and set. Looks like my text for pool should be used for set, and a new definition is needed for pool to describe a collection of sets. If you can do this and suggest to me where in rwa-info to put that text, I'= ll work it with the RFC Editor. Then later docs will only need to point at rwa-info. Thanks! Adrian > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: 23 January 2015 15:57 > To: adrian@olddog.co.uk; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.= org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: RE: Resource, Resource Block, and Resource Pool in draft-ietf-cc= amp- > rwa-wson-encode and draft-ietf-ccamp-rwa-info >=20 > Hi Adrian, >=20 > I think we are on the same page. Please see inline for specific comment. >=20 > Best regards, > Young >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, January 23, 2015 9:27 AM > To: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-= rwa- > wson-encode and draft-ietf-ccamp-rwa-info >=20 > Hello, >=20 > Continuing this discussion, I think we are getting closer. >=20 > > > My comment for general vs. WSON-specific issue is that the design > philosophy > > > of general encoding was to generalize a common element that can be ap= plied > > > to different technologies. For instance, connectivity matrix definite= ly can > be > > > applied to WSON, OTN and other Switching technology as one encoding c= an > > > fit to all. You seemed to desire a sharing of the same encoding to describe > > > different entities where possible. This is fine for label vs. wavelen= gth as > > > there is one-to-one mapping for this. However, Resource Block encodin= g > > > cannot properly share with the connectivity matrix encoding with two > > > reasons: > > > > > > 1. They refer to different elements in the node. > > > 2. They require different sets of fields with different number of fie= lds. >=20 > OK, what we really seem to be running into is some rather vague definitio= ns of > "resource" and "resource block". > Do you think we could spend some time nailing those down. Then we'll work= out > where to put them (possibly in rwa-info). >=20 > YOUNG>> Yes, I have just noticed that you held rwa-info and I hope you ca= n > suggest some clarifying text into that draft, which I see below. >=20 > The question is not about the protocol element "resource block" but is ab= out > what it represents. >=20 > So, as a starter, what is a Resource in a WSON system? > You have said (lower down this email) that " resources meant > regenerators/wavelength converters". > I can live with this (although it is a long way from the term "resource" = used in > 3473 etc. where it is taken to mean buffers, bandwidth, memory, labels, > lambdas,... > That difference in interpretation is sufficiently large that it needs to = be > brought out and made very clear. > You need something like: > In this document the term "Resource" is used to refer to a > physical component of a WSON node such as a regenerator > or a wavelength converter. Multiple instances of such > components are often present within a single WSON node. > This term is not to be confused with the concept of > forwarding or switching resources such as bandwidth or > lambdas. >=20 > YOUNG>> Great suggestion. Yes, that is what is Resource is. The part of t= he > problem has been that the term 'resource' was picked when the WG asked us= to > generalize Regenerators/wavelength converters. This term 'resource' may h= ave > not been perfect, but it was chosen as such to have its meaning in a spec= ific > context. >=20 > Then you can answer what is a Resource Block in a WSON system? > From what I think I now understand, a resource block is simply a collecti= on of > resources on a WSON network node that behave in the same way. This allows > easier > description in the protocol encoding, but has no other meaning. So you co= uld > say: > A Resource Block is a collection of Resources from the same > WSON node that are grouped together for administrative reasons > and for ease of encoding in the protocols. All Resources in the > same Resource Block behave in the same way and have similar > characteristics relevant to the optical system, e.g., processing > properties, accessibility, etc. >=20 > YOUNG>> Yes, it is correct. >=20 > Then comes, what is a Resource Pool? Actually, this is only implicitly de= fined > in draft-ietf-ccamp-rwa-info and so we have quite a gap. It looks like yo= u might > say: > A Resource Pool is a collection of Resource Blocks for the > purpose of representing throughput or cross-connect > capabilities in a WSON node. A Resource Pool associates > input ports or links on the node with output ports or > links and is used to indicate how signals may be passed > from an input port or link to an output port or link by > way of a Resource Block (in other words, by way of a > Resource). A Resource Pool may, therefore, be > modelled as a matrix. >=20 > A Resource Block may be present in multiple Resource > Pools. >=20 > YOUNG>> Yes. >=20 > And finally, we have Resource Block Set. What is that? > I *think* it is just the encoding concept for a Resource Block Pool. > You have (in 2.1) > In a WSON node that includes resource blocks (RB), denoting subsets > of these blocks allows one to efficiently describe common properties > of the blocks and to describe the structure and characteristics, if > non-trivial, of the resource pool. > *Now* I see that your "subsets" should actually be "sets" and that will m= ake > more sense. >=20 > YOUNG>> Yes, "sets" make it clearer. >=20 > But do you need the two terms "Resource Block Pool" and "Resource Block S= et"? > Are they the same or different? When I read 3.2 it looks like the Resourc= e Block > Pool is a collection of Resource Block Sets. >=20 > YOUNG>> They are different. Resource Block Pool is sitting above the RB S= ets. > There may be multiple RB Sets in a node that behave differently, e.g., different > input/output constraints on the access/egress to the Pool. >=20 >=20 > Have I finally got this right? >=20 > YOUNG>> Yes, I think so. >=20 > If so, then can we agree precise text and where to put it? >=20 > YOUNG>> Yes. >=20 > Thanks for your patience. > Adrian From nobody Sat Jan 24 12:27:15 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 50FC21A0027; Sat, 24 Jan 2015 12:27:12 -0800 (PST) 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 j2pYDmmwPNjY; Sat, 24 Jan 2015 12:27:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A91FF1A0019; Sat, 24 Jan 2015 12:27:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150124202710.862.46353.idtracker@ietfa.amsl.com> Date: Sat, 24 Jan 2015 12:27:10 -0800 Archived-At: Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16.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: Sat, 24 Jan 2015 20:27:12 -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 : Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE Authors : Elisa Bellagamba Attila Takacs Gregory Mirsky Loa Andersson Pontus Skoldstrom Dave Ward Filename : draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16.txt Pages : 28 Date : 2015-01-24 Abstract: This specification describes the configuration of proactive MPLS-TP (MPLS-Transport Profile) Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 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 Sun Jan 25 17:50:15 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 2D2F71A1B88 for ; Sun, 25 Jan 2015 17:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 2UxQmo1Sy2Uz for ; Sun, 25 Jan 2015 17:50:05 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40F21A1A79 for ; Sun, 25 Jan 2015 17:50:04 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id EE204C6D11CF1; Mon, 26 Jan 2015 01:49:59 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t0Q1nYgo027362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Jan 2015 20:49:46 -0500 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.168]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sun, 25 Jan 2015 20:49:43 -0500 From: "Lam, Hing-Kam (Kam)" To: "adrian@olddog.co.uk" , "'Gert Grammel'" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyAQjVyuIZDVkicZ67yfGpHF5zN7BoAgAB2swCAAz9qIA== Date: Mon, 26 Jan 2015 01:49:42 +0000 Message-ID: <8DBC3FDAC14BE441AED9C5939C77758509EE461F@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk> In-Reply-To: <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_8DBC3FDAC14BE441AED9C5939C77758509EE461FUS70TWXCHMBA12z_" MIME-Version: 1.0 Archived-At: Cc: "'Doolan, Paul \(Coriant - US/Irving\)'" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 26 Jan 2015 01:50:13 -0000 --_000_8DBC3FDAC14BE441AED9C5939C77758509EE461FUS70TWXCHMBA12z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, Yes, while Q14/15 already reached agreement to update the Application Ident= ifier description, the update has not been formally approved and published = by SG15 yet. Q14/15 may be able to consent this update as an Amendment to G= .874.1 at the upcoming SG15 meeting in July 2015. Regards, Kam From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, January 23, 2015 1:59 PM To: Lam, Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tool= s.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Thanks for being awake, Kam. Useful info. Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry= page for this, but it points to the IEEE page. As I understand Kam, 874.1 is not yet updated so it would be premature to p= oint to it, but an option is to attempt to match it now and fix later if ne= eded. Adrian From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com] Sent: 23 January 2015 17:10 To: Gert Grammel; adrian@olddog.co.uk; 'Giovann= i Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Gert, A vendor can purchase an OUI (Organizationally Unique Identifier) from the = IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific applic= ation identifiers under its own OUI. SG15 doesn't need to host any registry for this purpose. Regards, Kam From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Kam, Is SG15 considering to host a registry for the vendor specific application = code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (= giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.8= 74.1 to amend the specification of ApplicationIdentifier with the following= additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString = represents a standard application code as defined in the ITU-T Recommendati= ons. If the ApplicationIdentifierType is PROPRIETARY, the first six charact= ers of the PrintableString must contain the Hexadecimal representation of a= n OUI assigned to the vendor whose implementation generated the Application= Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietar= y-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools= .ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-w= son-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel > wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a bool= ean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel > wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_8DBC3FDAC14BE441AED9C5939C77758509EE461FUS70TWXCHMBA12z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Adrian,<= /span>

 

Yes, while Q14/15 alre= ady reached agreement to update the Application Identifier description, the= update has not been formally approved and published by SG15 yet. Q14/15 ma= y be able to consent this update as an Amendment to G.874.1 at the upcoming SG15 meeting in July 2015.

 

Regards,

Kam<= /p>

 

From: Adrian F= arrel [mailto:adrian@olddog.co.uk]
Sent: Friday, January 23, 2015 1:59 PM
To: Lam, Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli (gioma= rti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chai= rs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Thanks = for being awake, Kam.

&n= bsp;

Useful = info.

&n= bsp;

Gert, t= he OUI registry is an IEEE registry as Kam says. IANA has a registry page f= or this, but it points to the IEEE page.

&n= bsp;

As I un= derstand Kam, 874.1 is not yet updated so it would be premature to point to= it, but an option is to attempt to match it now and fix later if needed.

&n= bsp;

Adrian<= o:p>

&n= bsp;

From: Lam, Hin= g-Kam (Kam) [mailto:kam.lam@a= lcatel-lucent.com]
Sent: 23 January 2015 17:10
To: Gert Grammel; adrian@oldd= og.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Gert,

 

A vendor can purchase = an OUI (Organizationally Unique Identifier) from the IEEE Registration Auth= ority.

Once a vendor has its = OUI, the vendor can manage its vendor-specific application identifiers unde= r its own OUI.

SG15 doesn’t nee= d to host any registry for this purpose.

 

Regards,

Kam<= /p>

 

From: Gert Gra= mmel [mailto:ggrammel@juniper.net]
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); adri= an@olddog.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Kam,

 

Is SG15 considering to= host a registry for the vendor specific application code or is the IETF re= gistry supposed to be used?

 

Thanks

 

Gert=

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: adrian@olddog.co.uk; = 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 meeting, Q= 14/15 agreed to update G.874.1 to amend the specification of ApplicationIde= ntifier with the following additional text:

 

If the ApplicationIden= tifierType is STANDARD, the value of PrintableString represents a standard = application code as defined in the ITU-T Recommendations. If the Applicatio= nIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal r= epresentation of an OUI assigned to the vendor whose implementation generat= ed the Application Identifier; the remaining octets of the PrintableString = are unspecified.

 

Paul Doolan had an I-D "https://tools.ietf.org/h= tml/draft-doolan-proprietary-ac-00" to the last IETF meeting with = the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM=

To: 'Giovanni Martinelli (giomarti)'

Cc: ccamp@ietf.= org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

Subject: [CCAMP] Vendor-Specific Application Code= in draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am not seeing= a specific conclusion from it.

 

The current I-D makes (IMHO) the Vendor-Specific = Application Code unusable. I offered three options:

 

1 This value is only to be used when it is known = that all devices

   participating in a network have the = same understanding of

   the content of the Vendor-Speci= fic Application Code field.

   How this knowledge is achieved is ou= tside the scope of this

   document

 

2 When this value is set, the first 32 (or 48) bi= ts of the Vendor-

  Specific Application Code field contain an= Enterprise Number

  (or OUI) that defines the context in which= the remainder of

  that field is interpreted.

 

3 Remove the option to include a Vendor-Specific = Application

   Code field.

 

If the WG could please pick one of these and help= Young to update the document.

 

Thanks,

Adrian

 

> -----Original Message-----

> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 13:50

> To: a= drian@olddog.co.uk

> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> ccamp@ietf= .org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of draft-ietf= -ccamp-rwa-wson-encode

>

> One additional comment (hoping not additiona= l confusion).

>

> The idea about Optical Interface Class was t= aken from SRLG. Good or

> bad is a plain number and you do simple oper= ations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, Giovanni Martinell= i (giomarti)

> <gi= omarti@cisco.com>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel= <adrian@olddog.co.uk> wro= te:

> >

> >> Hi,

> >>

> >> Well, you seem to have a half-way h= ouse.

> >>

> >> You have specified the existence of= a thing, but not how to read it.

> >>

> >> If you wanted to make a statement t= hat this object will only be

> >> used when

it is

> >> known that all systems in a network= come from the same vendor

> >> and/or have

> the

> >> same understanding of the encoding,= that might be OK (although how

> >> you

> would

> >> ascertain this might also need to b= e described).

> >>

> >

> > The statement is to ensure the interfac= e compatibility without

> > encoding all

the

> possible details and parameter that define a= n interface (e.g.

> modulation

format,

> forward error correction etc.). This was the= initial solution in the

> draft

then

> replaced by the interface class concept.&nbs= p;  The WSON (RWA-only) has the

> requirement is to make sure two interface ar= e compatible. This

> requirement, imho, can be satisfy by a simpl= e comparison which has a boolean result.

> >

> > We end up then in  the ITU applica= tion codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatib= ility where proper

> encoding is provided.

> >

> >

> >> Or you could entirely remove the ve= ndor-specific option.

> >>

> >> Or you could put in an OUI / enterp= rise number followed by

> >> transparent

> bytes.

> >>

> >

> > To me I'm perfectly fine with the secon= d option.

> >

> > Cheers

> > G

> >

> >

> >> Adrian

> >>

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

> >>> From: Giovanni Martinelli (giom= arti) [mailto:giomarti@cisco.com]=

> >>> Sent: 21 January 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>

> >>> Subject: Re: [CCAMP] AD review = of draft-ietf-ccamp-rwa-wson-encode

> >>>

> >>> Specifically to the Interface c= lass here below.

> >>>

> >>> In the initial draft merged to = this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) = we decided to remove any encoding

> >>> when the Interface class is not= standard.

> >>> In term of semantic the protcol= does not need to decode the

> >>> Interface

class

> >> since

> >>> it only assess the interface co= mpatibility if two interfaces has a

> >>> class

value

> >> that

> >>> match two interfaces cann be co= nnected.

> >>>

> >>> Having saying that I don't have= strong opinion in adding the OUI

> >>> or

leaving

> >> room

> >>> for maybe future public interfa= ces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility= assesment since there optical

> >>> multivendor compatibility has b= een already demonstrated.

> >>>

> >>> hope this help .

> >>>

> >>> Cheers

> >>> G

> >>>

> >>>

> >>> On 21 Jan 2015, at 21:57, Adria= n Farrel <adrian@olddog.co.uk= > wrote:

> >>>

> >>>>>>

> >>>>>> Section 4.1

> >>>>>> How do I interpret = a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?=

> >>>>>

> >>>>> [YOUNG] Not sure if I u= nderstood this question. What is "OUI"?

> >>>>

> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier

> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> numbers.xhtml#ieee-802

> >>>> -numbers-2

> >>>>

> >>>> Or perhaps an Enterprise Nu= mber

> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> >>>>

> >>>> The question is:=

> >>>>

> >>>> You have sections 4.1.1 thr= ough 4.1.4 to tell me how to interpret

> >>>> the

> >> Optical

> >>>> Interface Class field when = it contains an ITU-T Application Mapping.

> >>>> When I received s=3D0 and O= I=3D1 it means that the Optical Interface

> >>>> Class

> >> contains

> >>>> a "Vendor Specific Opt= ical Interface Class".

> >>>> How do I interpret that Opt= ical Interface Class?

> >>>> Which vendor does it apply = to?

> >>>> Is there some information e= lsewhere that gives me a clue as to

> >>>> which

> vendor

> >>> has

> >>>> encoded the information?

> >>>> Or is the information suppo= sed to be encoded in the Optical

> >>>> Interface

Class,

> >>>> perhaps as the first 48 bit= s?

> >>>> Or am I supposed to know by= context?

> >>

> >

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/ccamp

--_000_8DBC3FDAC14BE441AED9C5939C77758509EE461FUS70TWXCHMBA12z_-- From nobody Mon Jan 26 06:49: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 ADD4F1A8AD6; Mon, 26 Jan 2015 06:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 W5HUAdpmSb9m; Mon, 26 Jan 2015 06:49:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 804F41A8AD8; Mon, 26 Jan 2015 06:49:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126144946.8408.85648.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 06:49:46 -0800 Archived-At: Cc: ccamp mailing list , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE' to Proposed Standard (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16.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, 26 Jan 2015 14:49:49 -0000 The IESG has approved the following document: - 'Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE' (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16.txt) as Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext/ Technical Summary This specification describes the configuration of pro-active MPLS-TP (MPLS-Transport Profile) Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE. Working Group Summary No issues. Good support by the Working Group. Document Quality There have been no public statements, though significant interest was expressed by the Working Group. The document was revised after review by the AD and after IANA and GenArt reviews. Personnel Deborah Brungard is the Document Shepherd. Adrian Farrel is the Area Director RFC Editor Note This document shows six authors on the front page. The authors all swear that they are equally responsible for the text in the document, and so we request that you retain all six names on the front page. From nobody Mon Jan 26 10:20:41 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 106DA1A6F14 for ; Mon, 26 Jan 2015 10:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_SLUT=2.522, 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=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 fFiXFVB463Nj for ; Mon, 26 Jan 2015 10:20:36 -0800 (PST) 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 D65281A6EE9 for ; Mon, 26 Jan 2015 10:20:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT43917; Mon, 26 Jan 2015 18:20:34 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 18:20:33 +0000 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; Mon, 26 Jan 2015 10:20:25 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Thread-Index: AdAmyKqM3E2i5eP+S/KXayUoWZed4QFfHtywAm61lQAAEBoNkABPde+AAIJYvaA= Date: Mon, 26 Jan 2015 18:20:24 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7E706@dfweml706-chm> References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7DA1A@dfweml706-chm> <009801d0373b$32210f90$96632eb0$@olddog.co.uk> In-Reply-To: <009801d0373b$32210f90$96632eb0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode 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, 26 Jan 2015 18:20:39 -0000 Hi Adrian, Thanks. Please see inline for my response.=20 Young -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, January 23, 2015 12:34 PM To: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode Hi, Picking up the remaining comments that I haven't cut out into separate thre= ads. > YOUNG>> How about the figure 1 in Appendix A.1, I think it should have be= en > labeled as "RB Pool" instead of WC Pool. I will change "WC" to "RB" and p= oint to > this figure from Section 2.1 and Section 3.2 where RB Set is explained in= the > context of Resource Pool. I don't think you should point to the Appendix to achieve explanation in y= our text. You should explain the terms more clearly as in my other thread. That said, figure 1 *is* very helpful. I don't think you should change the labelling in the figure. The thing it shows is a pool of wavelength convert= ers. That's good. Perhaps you could add a note as: OLD This wavelength converter pool can be encoded as follows: NEW The wavelength converters are resource blocks and the wavelength converter pool is a resource block pool. This can be encoded as follows: END YOUNG>> OK. That's fine with me.=20 > >> Section 2.1 > >> > >> The RB identifier represents the ID of the resource block which is = a > >> 32 bit integer. [snip]=20 > As I asked above, when you advertise RB ID 1 to me, how do I know which > resources you are referring to? >=20 > YOUNG>> In Section 3.1 Resource Accessibility Field is defined and encode= d as > below: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Reserved(8bits)|C| Reserved (23 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Link Set Field A #1 | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set Field A #1 | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Additional Link set and RB set pairs as needed to | > : specify PoolInputMatrix : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Link Set Field B #1 | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set B Field #1 (for output connectivity) | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Additional Link Set and RB set pairs as needed to | > : specify PoolOutputMatrix : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > RB Set Field defines the RD ID's and Input/Output Link Sets are associate= d with RB > ID's. Let me try a different way: - Who assigns a RB ID? YOUNG>> I think it can be assigned by the configuration entity of the manag= ement plane or can be manually configured.=20 - Who actually knows what it refers to (in the physical space)? YOUNG>> In the physical space it is wavelength converter pool. The network = operators must know this entity as they are installing this block in their = nodes. - Does anyone outside the node itself need to know anything other than "A resource block exists, with these properties, and this is its ID"? YOUNG>> The specified list is sufficient and the RB encoding is exactly try= ing to give these information to outsiders (e.g., path computation entity) = so that these constraints would be factored in.=20 - Shouldn't all of the discussion and explanation of terms and concepts=20 be in the Information Model document? YOUNG>> Yes, per your request, this is done in the info. Model doc.=20 > >> Section 3.1 > >> > >> Why isn't the Resource Accessibility Field expressed in terms of the > >> use of a generic Connectivity Matrix Field from section 2.1 of > >> [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive > >> application agnostic encodings that could be used without modification > >> (but with applicability notes) by specific technologies. > > > > [YOUNG] Not quite. Connectivity Matrix encoding cannot be used for Reso= urce > > Accessibility Field as the latter > > has additional entity (namely, RB set field) to describe. We generalize= d a > > single-stage connectivity matrix in [Gen-Encode] that can > > be applicable to any switching technology. Here in WSON, we have a need= to > > model RB constraints (for the pool of Wavelength Converters) > > from/to input/output link sets. Putting two different entities into one coding > > was not the choice of the authors. >=20 > I don't understand. > You say that the generalized single-stage connectivity matrix can be applicable > to any switching technology and then you don't use it for WSON saying tha= t you > need other constraints as well. > Are you, in fact, saying that the generalized single-stage connectivity m= atrix > is not applicable to WSON? >=20 > YOUNG>> No that is not what I am saying. WSON uses both the connectivity > matrix and the RB. > The RB is only unique for WSON element. OK. I think this may drop out from getting the definition of RB clear as in= the separate thread. In order that RB is a unique concept applicable only to a WSON node, it mus= t follow that Resource is similarly a unique concept applicable only to a WSO= N node. Now, the definition we have been arriving at for Resource becomes circular = :-( It is defined in terms of WSON technology (it is a regenerator or a wavelen= gth converter component in a WSON node). Could you describe those concepts generically? For example, a wavelength converter is a component that does a label swap and has severely restricted= swap capabilities. For example, a regenerator is a component that sits in the pa= th, retains the label, but has a limited input label capability. It could quite probably be the case that these components only arise in a W= SON system, but it is very helpful to properly describe them in general terms. Once described in general terms we can decide whether they should be generi= c components of the encoding model, or remain as specific for WSON. YOUNG>> In light of the next point below, shall we drop out this discussion= ?=20 > >> Section 3.2 > >> > >> I looked for the equivalent of the Resource Wavelength Constraints > >> Field in [Gen-Encode]. I understand that Input Wavelength Constraints > >> Field and Output Wavelength Constraints Field are encoded using the > >> generic Label Set of [Gen-Encode], but I thought that the whole conce= pt > >> of Resource Constraints would be generic. > > > > [YOUNG] Again, I think the design of generalization is not intended to > > share the same encoding to describe two different entities. Besides, I = do > > not see the need to generalize encoding of an entity that has no partic= ular > > use in other technologies than WSON. >=20 > I think the point of generalization is to come up with an encoding that c= an be > re-used in different witching environments. > Obviously, the only environment with wavelength is WSON. But all switchin= g > environments have labels that are switched, and have constraints applicab= le to > those labels and to the ability to switch the labels. >=20 > Suppose I wrote: >=20 > Resources, such as switches and filters, may have limited > input or output label ranges. Additionally, due to the > structure of the switches not all labels can necessarily > reach or leave all the resources. These properties are described by > using one or more resource restrictions fields as defined > below: >=20 > That is just a rewrite of 3.2 in general terms and seems to not be a prob= lem. > Indeed, if general-constraint-encode had had... >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I|O|B| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RB Set Field | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Input Label Constraints | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Output Label Constraints | > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > ...then I would have thought it a perfect fit. >=20 > > Section 3.3 > > > > As with the previous section I don't see anything that is WSON-specific > > in the concept of the 3.3. Resource Block Pool State (RBPoolState) Fiel= d > > and I wondered why [Gen-Encode] doesn't have anything to cover this. > > > > [YOUNG] RB is wavelength converters, which is a unique WSON element. >=20 > No! > You might as well say that a lambda is a unique WSON concept and so canno= t > re-use the generic concept of the LABEL object. >=20 > Isn't a "wavelength converter" just a special case of a label switch? Tha= t is > certainly how I read RFC 6163 > Wavelength converters take an input optical signal at one wavelength > and emit an equivalent content optical signal at another wavelength > on output. >=20 > I think you are just not stepping back far enough to see the concept of > "generalization." >=20 > YOUNG>> As the figure 1 from Appendix A, WC's are additional element on t= op > of a label switch. I still think it is a unique WSON element which may no= t be > relevant to Generic label switch paradigm. OK. Got it. We were talking past each other with terminology because I was looking for the black-box behaviour of a WSON node while you are modelling = and controlling the internal components of a WSON node. With this in mind, of course you are right. The physical components, that i= s the partitioned physical components, only exist in a WSON node. I, on the other hand, was looking at how you model the generic multi-functi= on switch. How would you model a switch that was able to selectively switch si= gnals from one port to another and selectively change the labels applied to those signals? My claim would be that you use (or could use) exactly the same abs= tract components.=20 That said, this conversation has gone on long enough. I think that only you= and I are interested in the outcome. That makes me pretty sure that the WG is n= ot very interested. Equally, it makes me sure I shouldn't get in the way. YOUNG>> Yes, thanks.=20 > >> Why don't Sections 3.4 and 4 have a B-bit like that in 3.2? > > > > [YOUNG] I think the reason for B bit is not included in Section 3.4 is = the > > context where it won't be very useful (even if we have a B bit) as inpu= t > > wavelengths available will hardly match with output wavelength availabl= e > > in most cases. > > Compared to this, wavelength constraints can more often be same for inp= ut > > and output. >=20 > This isn't very convincing. > "in most cases" suggests sometimes it will. > Are you saying the use of one extra bit outweighs the saving in encoding = in the > rare cases where that bit could be used? >=20 > YOUNG>> I can add B bit if you think it must be there in Sections 3.4 and= 4. I'm sorry if I am driving you to do things "because Adrian says so." My job is to get you to come to the right answer. It doesn't matter what I = think now. What matters is that you come to the right answer and are able to defe= nd it. There can be a convincing technical reason that you can explain, or you= can say that there is no significant technical reason to jump either way and so= you have simply picked one way. YOUNG>> I will add an extra bit in Sections 3.4 and 4. I wouldn't imagine t= his bit will be ever useful in practices, but as you convinced me there may= be a very rare case for the usefulness of this bit.=20 > >> Section 4 > >> > >> How do I know the length of the ResourceBlockInfo field? I need to kno= w > >> this to decide whether to try to parse the next bytes as another > >> Optional subfield. I *do* when I reach the end of one Optional subfiel= d, > >> but I don't know whether another follows. > >> > >> Possibly you intend the object that includes a ResourceBlockInfo field > >> to provide the length information, but other fields defined in this > >> document do include lengths or enough information to deduce the length= s. [snip] > YOUNG>> The object that includes a ResourceBlockInfo field provides the l= ength > info. > I grant however there is inconsistency here. Not sure what is the best. Perhaps, > effectiveness may be sacrificed unless things are broken. That is fine. Please, for the sake of future reviewers, add a note so say "The length of = the ResourceBlockInfo field is determined from the length of the object that includes it." YOUNG>> OK.=20 > >> Section 4.1 > >> How do I interpret a Vendor-Specific Application Code? Is there an OUI > >> I'm missing? > > > > [YOUNG] Not sure if I understood this question. What is "OUI"? [snip] Moved to a separate thread to try to get conclusion. > >> 4.1.1 and 4.1.2 > >> > >> An Optional F can be added indicating a FEC Encoding. > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > >> |B| D |S| c | W | y | t | z | v | F = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > >> | reserved = | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > >> > >> F (suffix): =3D 0 reserved, =3D 1 Fec Encoding > >> > >> Values not mentioned here are not allowed in this application > >> code > >> > >> If F is optional but only one value is allowed (viz. 1) how do I opt t= o > >> not indicate a FEC Encoding? > > > > [YOUNG] I guess 0 will do it. >=20 > But I can't set zero because it is reserved. >=20 > [YOUNG] I can add "F bit not equal 1" implies a FEC Encoding is not inclu= ded. Why can't you OLD An Optional F can be added indicating a FEC Encoding. NEW The F flag indicates the presence or not of an optional FEC Encoding suffix= . END and OLD F (suffix): =3D 0 reserved, =3D 1 Fec Encoding NEW F (suffix): =3D 0 No FEC Encoding suffix present, =3D 1 FEC Encoding suffix= present END YOUNG>> Thanks, will change as such. Adrian From nobody Wed Jan 28 09:46:21 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 62F611A6F3B for ; Wed, 28 Jan 2015 09:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Bf44hrGDPBxb for ; Wed, 28 Jan 2015 09:46:09 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B871A6F1E for ; Wed, 28 Jan 2015 09:46:08 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) with ESMTP id 06029c45.2b29a3c05940.6047852.00-2420.16890962.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 28 Jan 2015 17:46:08 +0000 (UTC) X-MXL-Hash: 54c9206071608d42-66c5799a19fd4c32d50c62a7a81cffc26416fd48 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id d4029c45.0.6047713.00-2380.16890532.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 28 Jan 2015 17:45:53 +0000 (UTC) X-MXL-Hash: 54c92051617805e6-4836691e8e061bb587e406ee5c74a58d93c4cd58 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 t0SHjnT8025715; Wed, 28 Jan 2015 12:45:49 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0SHjcJi025389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Jan 2015 12:45:40 -0500 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 28 Jan 2015 17:45:31 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.33]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 12:45:31 -0500 From: "BRUNGARD, DEBORAH A" To: "Lam, Hing-Kam (Kam)" , "adrian@olddog.co.uk" , "'Gert Grammel'" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyYZjvw3dXepkE2NuQ5jP6dwD5zOPoGAgAAFu4CAAB6eAIADl18AgAPVByA= Date: Wed, 28 Jan 2015 17:45:30 +0000 Message-ID: References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE461F@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: <8DBC3FDAC14BE441AED9C5939C77758509EE461F@US70TWXCHMBA12.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.98.88] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C83B4DF954MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=I+DSsqcg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=1Y0K2hHDVGMA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=48vgC7mUAAAA:8 a=AEDFM0qtAA] X-AnalysisOut: [AA:8 a=gxZvrgisAAAA:8 a=OUXY8nFuAAAA:8 a=AUd_NHdVAAAA:8 a=] X-AnalysisOut: [8pif782wAAAA:8 a=I0CVDw5ZAAAA:8 a=GTa9nLpUU4C8n5C2bWwA:9 a] X-AnalysisOut: [=CjuIK1q_8ugA:10 a=zlQSpWFwuVZOPTlP:21 a=jIK9sgMBD_tzjEan:] X-AnalysisOut: [21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=NQjzSkyZOnIxDVqcXkw] X-AnalysisOut: [A:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 ] X-AnalysisOut: [a=frz4AuCg-hUA:10 a=ktXy5y3YgFNISsJ6:21 a=-WAZvgykHkkj_fUK] X-AnalysisOut: [:21 a=iwZ3hlekZil-Kni7: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: Cc: "'Doolan, Paul \(Coriant - US/Irving\)'" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 28 Jan 2015 17:46:18 -0000 --_000_F64C10EAA68C8044B33656FA214632C83B4DF954MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, As Lou noted, Adrian's option 1 was the intention as this was discussed whe= n G872 was being revised to introduce Application Identifier (IETF's March = 2013 meeting). As Kam notes, ITU's work on G.874.1 has evolved to include t= he OUI. As a network operator, I prefer as Adrian says - let's attempt to match dra= ft G.874.1 (it does have agreement). So Adrian's option 2. While the contex= t of this work is within an operator's network, the OUI will help to ensure= interoperability. Adrian - good catch- Deborah From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: Sunday, January 25, 2015 8:50 PM To: adrian@olddog.co.uk; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tool= s.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Adrian, Yes, while Q14/15 already reached agreement to update the Application Ident= ifier description, the update has not been formally approved and published = by SG15 yet. Q14/15 may be able to consent this update as an Amendment to G= .874.1 at the upcoming SG15 meeting in July 2015. Regards, Kam From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, January 23, 2015 1:59 PM To: Lam, Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Thanks for being awake, Kam. Useful info. Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry= page for this, but it points to the IEEE page. As I understand Kam, 874.1 is not yet updated so it would be premature to p= oint to it, but an option is to attempt to match it now and fix later if ne= eded. Adrian From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com] Sent: 23 January 2015 17:10 To: Gert Grammel; adrian@olddog.co.uk; 'Giovann= i Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Gert, A vendor can purchase an OUI (Organizationally Unique Identifier) from the = IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific applic= ation identifiers under its own OUI. SG15 doesn't need to host any registry for this purpose. Regards, Kam From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Kam, Is SG15 considering to host a registry for the vendor specific application = code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (= giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.8= 74.1 to amend the specification of ApplicationIdentifier with the following= additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString = represents a standard application code as defined in the ITU-T Recommendati= ons. If the ApplicationIdentifierType is PROPRIETARY, the first six charact= ers of the PrintableString must contain the Hexadecimal representation of a= n OUI assigned to the vendor whose implementation generated the Application= Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietar= y-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools= .ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-w= son-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel > wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a bool= ean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel > wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_F64C10EAA68C8044B33656FA214632C83B4DF954MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

As Lou noted, Adrian&#= 8217;s option 1 was the intention as this was discussed when G872 was being= revised to introduce Application Identifier (IETF’s March 2013 meeti= ng). As Kam notes, ITU’s work on G.874.1 has evolved to include the OUI.

 

As a network operator,= I prefer as Adrian says – let’s attempt to match draft G.874.1= (it does have agreement). So Adrian’s option 2. While the context of= this work is within an operator’s network, the OUI will help to ensure interoperability.

 

Adrian – good ca= tch-

Deborah

 

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: Sunday, January 25, 2015 8:50 PM
To: adrian@olddog.co.uk; 'Gert Grammel'; 'Giovanni Martinelli (gioma= rti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chai= rs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Adrian,<= /span>

 

Yes, while Q14/15 alre= ady reached agreement to update the Application Identifier description, the= update has not been formally approved and published by SG15 yet. Q14/15 ma= y be able to consent this update as an Amendment to G.874.1 at the upcoming SG15 meeting in July 2015.

 

Regards,

Kam<= /p>

 

 

Thanks = for being awake, Kam.

&n= bsp;

Useful = info.

&n= bsp;

Gert, t= he OUI registry is an IEEE registry as Kam says. IANA has a registry page f= or this, but it points to the IEEE page.

&n= bsp;

As I un= derstand Kam, 874.1 is not yet updated so it would be premature to point to= it, but an option is to attempt to match it now and fix later if needed.

&n= bsp;

Adrian<= o:p>

&n= bsp;

From: Lam, Hin= g-Kam (Kam) [mailto:kam.lam@a= lcatel-lucent.com]
Sent: 23 January 2015 17:10
To: Gert Grammel; adrian@oldd= og.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Gert,

 

A vendor can purchase = an OUI (Organizationally Unique Identifier) from the IEEE Registration Auth= ority.

Once a vendor has its = OUI, the vendor can manage its vendor-specific application identifiers unde= r its own OUI.

SG15 doesn’t nee= d to host any registry for this purpose.

 

Regards,

Kam<= /p>

 

From: Gert Gra= mmel [mailto:ggrammel@juniper.net]
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); adri= an@olddog.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Kam,

 

Is SG15 considering to= host a registry for the vendor specific application code or is the IETF re= gistry supposed to be used?

 

Thanks

 

Gert=

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: adrian@olddog.co.uk; = 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 meeting, Q= 14/15 agreed to update G.874.1 to amend the specification of ApplicationIde= ntifier with the following additional text:

 

If the ApplicationIden= tifierType is STANDARD, the value of PrintableString represents a standard = application code as defined in the ITU-T Recommendations. If the Applicatio= nIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal r= epresentation of an OUI assigned to the vendor whose implementation generat= ed the Application Identifier; the remaining octets of the PrintableString = are unspecified.

 

Paul Doolan had an I-D "https://tools.ietf.org/h= tml/draft-doolan-proprietary-ac-00" to the last IETF meeting with = the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM=

To: 'Giovanni Martinelli (giomarti)'

Cc: ccamp@ietf.= org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

Subject: [CCAMP] Vendor-Specific Application Code= in draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am not seeing= a specific conclusion from it.

 

The current I-D makes (IMHO) the Vendor-Specific = Application Code unusable. I offered three options:

 

1 This value is only to be used when it is known = that all devices

   participating in a network have the = same understanding of

   the content of the Vendor-Speci= fic Application Code field.

   How this knowledge is achieved is ou= tside the scope of this

   document

 

2 When this value is set, the first 32 (or 48) bi= ts of the Vendor-

  Specific Application Code field contain an= Enterprise Number

  (or OUI) that defines the context in which= the remainder of

  that field is interpreted.

 

3 Remove the option to include a Vendor-Specific = Application

   Code field.

 

If the WG could please pick one of these and help= Young to update the document.

 

Thanks,

Adrian

 

> -----Original Message-----

> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 13:50

> To: a= drian@olddog.co.uk

> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> ccamp@ietf= .org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of draft-ietf= -ccamp-rwa-wson-encode

>

> One additional comment (hoping not additiona= l confusion).

>

> The idea about Optical Interface Class was t= aken from SRLG. Good or

> bad is a plain number and you do simple oper= ations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, Giovanni Martinell= i (giomarti)

> <gi= omarti@cisco.com>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel= <adrian@olddog.co.uk> wro= te:

> >

> >> Hi,

> >>

> >> Well, you seem to have a half-way h= ouse.

> >>

> >> You have specified the existence of= a thing, but not how to read it.

> >>

> >> If you wanted to make a statement t= hat this object will only be

> >> used when

it is

> >> known that all systems in a network= come from the same vendor

> >> and/or have

> the

> >> same understanding of the encoding,= that might be OK (although how

> >> you

> would

> >> ascertain this might also need to b= e described).

> >>

> >

> > The statement is to ensure the interfac= e compatibility without

> > encoding all

the

> possible details and parameter that define a= n interface (e.g.

> modulation

format,

> forward error correction etc.). This was the= initial solution in the

> draft

then

> replaced by the interface class concept.&nbs= p;  The WSON (RWA-only) has the

> requirement is to make sure two interface ar= e compatible. This

> requirement, imho, can be satisfy by a simpl= e comparison which has a boolean result.

> >

> > We end up then in  the ITU applica= tion codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatib= ility where proper

> encoding is provided.

> >

> >

> >> Or you could entirely remove the ve= ndor-specific option.

> >>

> >> Or you could put in an OUI / enterp= rise number followed by

> >> transparent

> bytes.

> >>

> >

> > To me I'm perfectly fine with the secon= d option.

> >

> > Cheers

> > G

> >

> >

> >> Adrian

> >>

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

> >>> From: Giovanni Martinelli (giom= arti) [mailto:giomarti@cisco.com]=

> >>> Sent: 21 January 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>

> >>> Subject: Re: [CCAMP] AD review = of draft-ietf-ccamp-rwa-wson-encode

> >>>

> >>> Specifically to the Interface c= lass here below.

> >>>

> >>> In the initial draft merged to = this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) = we decided to remove any encoding

> >>> when the Interface class is not= standard.

> >>> In term of semantic the protcol= does not need to decode the

> >>> Interface

class

> >> since

> >>> it only assess the interface co= mpatibility if two interfaces has a

> >>> class

value

> >> that

> >>> match two interfaces cann be co= nnected.

> >>>

> >>> Having saying that I don't have= strong opinion in adding the OUI

> >>> or

leaving

> >> room

> >>> for maybe future public interfa= ces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility= assesment since there optical

> >>> multivendor compatibility has b= een already demonstrated.

> >>>

> >>> hope this help .

> >>>

> >>> Cheers

> >>> G

> >>>

> >>>

> >>> On 21 Jan 2015, at 21:57, Adria= n Farrel <adrian@olddog.co.uk= > wrote:

> >>>

> >>>>>>

> >>>>>> Section 4.1

> >>>>>> How do I interpret = a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?=

> >>>>>

> >>>>> [YOUNG] Not sure if I u= nderstood this question. What is "OUI"?

> >>>>

> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier

> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> numbers.xhtml#ieee-802

> >>>> -numbers-2

> >>>>

> >>>> Or perhaps an Enterprise Nu= mber

> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> >>>>

> >>>> The question is:=

> >>>>

> >>>> You have sections 4.1.1 thr= ough 4.1.4 to tell me how to interpret

> >>>> the

> >> Optical

> >>>> Interface Class field when = it contains an ITU-T Application Mapping.

> >>>> When I received s=3D0 and O= I=3D1 it means that the Optical Interface

> >>>> Class

> >> contains

> >>>> a "Vendor Specific Opt= ical Interface Class".

> >>>> How do I interpret that Opt= ical Interface Class?

> >>>> Which vendor does it apply = to?

> >>>> Is there some information e= lsewhere that gives me a clue as to

> >>>> which

> vendor

> >>> has

> >>>> encoded the information?

> >>>> Or is the information suppo= sed to be encoded in the Optical

> >>>> Interface

Class,

> >>>> perhaps as the first 48 bit= s?

> >>>> Or am I supposed to know by= context?

> >>

> >

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/ccamp

--_000_F64C10EAA68C8044B33656FA214632C83B4DF954MISOUT7MSGUSRDE_-- From nobody Wed Jan 28 11:32: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 DAFF21A005B for ; Wed, 28 Jan 2015 11:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 f0gef8NPm43F for ; Wed, 28 Jan 2015 11:32:46 -0800 (PST) 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 F361E1A0064 for ; Wed, 28 Jan 2015 11:32:44 -0800 (PST) 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 BRV66225; Wed, 28 Jan 2015 19:32:43 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 19:32:42 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 28 Jan 2015 11:32:31 -0800 From: Leeyoung To: "BRUNGARD, DEBORAH A" , "Lam, Hing-Kam (Kam)" , "adrian@olddog.co.uk" , "'Gert Grammel'" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyKmWicGibpQEGWYW2s/gCycJzOdnmAgAAengCAA5dgAIAEL7YA//+TloA= Date: Wed, 28 Jan 2015 19:32:30 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7F07B@dfweml706-chm> References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE461F@US70TWXCHMBA12.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.240] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F07Bdfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'Doolan, Paul \(Coriant - US/Irving\)'" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 28 Jan 2015 19:32:55 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F07Bdfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah, Thanks for sharing your operator's perspective. I am wondering how the OUI= would really help for interoperability other than identifying the specific= vendors that are using their proprietary code. Say vendor A uses FEC type A while vendor B used FEC type B, and both of th= em are proprietary FECs. I believe the OUI will help the operator identify = this fact and conclude the systems are not compatible. But would this reall= y help operators toward interoperability? I believe a better way for operat= ors to attain interoperability is to force vendors use standard FECs and ha= ve them agree on the same type of FECs within the standard FECs. My point i= s how vendor specific code would be really helpful even if we employ the OU= I field. Thanks, Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH = A Sent: Wednesday, January 28, 2015 11:46 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Grammel'; 'Giovanni Mar= tinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tool= s.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi All, As Lou noted, Adrian's option 1 was the intention as this was discussed whe= n G872 was being revised to introduce Application Identifier (IETF's March = 2013 meeting). As Kam notes, ITU's work on G.874.1 has evolved to include t= he OUI. As a network operator, I prefer as Adrian says - let's attempt to match dra= ft G.874.1 (it does have agreement). So Adrian's option 2. While the contex= t of this work is within an operator's network, the OUI will help to ensure= interoperability. Adrian - good catch- Deborah From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: Sunday, January 25, 2015 8:50 PM To: adrian@olddog.co.uk; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tool= s.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Adrian, Yes, while Q14/15 already reached agreement to update the Application Ident= ifier description, the update has not been formally approved and published = by SG15 yet. Q14/15 may be able to consent this update as an Amendment to G= .874.1 at the upcoming SG15 meeting in July 2015. Regards, Kam From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, January 23, 2015 1:59 PM To: Lam, Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Thanks for being awake, Kam. Useful info. Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry= page for this, but it points to the IEEE page. As I understand Kam, 874.1 is not yet updated so it would be premature to p= oint to it, but an option is to attempt to match it now and fix later if ne= eded. Adrian From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com] Sent: 23 January 2015 17:10 To: Gert Grammel; adrian@olddog.co.uk; 'Giovann= i Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Gert, A vendor can purchase an OUI (Organizationally Unique Identifier) from the = IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific applic= ation identifiers under its own OUI. SG15 doesn't need to host any registry for this purpose. Regards, Kam From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Kam, Is SG15 considering to host a registry for the vendor specific application = code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (= giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.8= 74.1 to amend the specification of ApplicationIdentifier with the following= additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString = represents a standard application code as defined in the ITU-T Recommendati= ons. If the ApplicationIdentifierType is PROPRIETARY, the first six charact= ers of the PrintableString must contain the Hexadecimal representation of a= n OUI assigned to the vendor whose implementation generated the Application= Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietar= y-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools= .ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-w= son-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel > wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a bool= ean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel > wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F07Bdfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Deborah,=

 

Thanks for sharing you= r operator’s perspective.  I am wondering how the OUI would real= ly help for interoperability other than identifying the specific vendors th= at are using their proprietary code.  

 

Say vendor A uses FEC = type A while vendor B used FEC type B, and both of them are proprietary FEC= s. I believe the OUI will help the operator identify this fact and conclude= the systems are not compatible. But would this really help operators toward interoperability? I believe a bett= er way for operators to attain interoperability is to force vendors use sta= ndard FECs and have them agree on the same type of FECs within the standard= FECs. My point is how vendor specific code would be really helpful even if we employ the OUI field. <= /span>

 

Thanks,

Young

 

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Wednesday, January 28, 2015 11:46 AM
To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Grammel'; 'Giova= nni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chai= rs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi All,

 

As Lou noted, Adrian&#= 8217;s option 1 was the intention as this was discussed when G872 was being= revised to introduce Application Identifier (IETF’s March 2013 meeti= ng). As Kam notes, ITU’s work on G.874.1 has evolved to include the OUI.

 

As a network operator,= I prefer as Adrian says – let’s attempt to match draft G.874.1= (it does have agreement). So Adrian’s option 2. While the context of= this work is within an operator’s network, the OUI will help to ensure interoperability.

 

Adrian – good ca= tch-

Deborah

 

From: CCAMP [m= ailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: Sunday, January 25, 2015 8:50 PM
To: adrian@olddog.co.uk; 'Gert Grammel'; 'Giovanni Martinelli (gioma= rti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chai= rs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Adrian,<= /span>

 

Yes, while Q14/15 alre= ady reached agreement to update the Application Identifier description, the= update has not been formally approved and published by SG15 yet. Q14/15 ma= y be able to consent this update as an Amendment to G.874.1 at the upcoming SG15 meeting in July 2015.

 

Regards,

Kam<= /p>

 

 

Thanks = for being awake, Kam.

&n= bsp;

Useful = info.

&n= bsp;

Gert, t= he OUI registry is an IEEE registry as Kam says. IANA has a registry page f= or this, but it points to the IEEE page.

&n= bsp;

As I un= derstand Kam, 874.1 is not yet updated so it would be premature to point to= it, but an option is to attempt to match it now and fix later if needed.

&n= bsp;

Adrian<= o:p>

&n= bsp;

From: Lam, Hin= g-Kam (Kam) [mailto:kam.lam@a= lcatel-lucent.com]
Sent: 23 January 2015 17:10
To: Gert Grammel; adrian@oldd= og.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Gert,

 

A vendor can purchase = an OUI (Organizationally Unique Identifier) from the IEEE Registration Auth= ority.

Once a vendor has its = OUI, the vendor can manage its vendor-specific application identifiers unde= r its own OUI.

SG15 doesn’t nee= d to host any registry for this purpose.

 

Regards,

Kam<= /p>

 

From: Gert Gra= mmel [mailto:ggrammel@juniper.net]
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); adri= an@olddog.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Kam,

 

Is SG15 considering to= host a registry for the vendor specific application code or is the IETF re= gistry supposed to be used?

 

Thanks

 

Gert=

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: adrian@olddog.co.uk; = 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 meeting, Q= 14/15 agreed to update G.874.1 to amend the specification of ApplicationIde= ntifier with the following additional text:

 

If the ApplicationIden= tifierType is STANDARD, the value of PrintableString represents a standard = application code as defined in the ITU-T Recommendations. If the Applicatio= nIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal r= epresentation of an OUI assigned to the vendor whose implementation generat= ed the Application Identifier; the remaining octets of the PrintableString = are unspecified.

 

Paul Doolan had an I-D "https://tools.ietf.org/h= tml/draft-doolan-proprietary-ac-00" to the last IETF meeting with = the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM=

To: 'Giovanni Martinelli (giomarti)'

Cc: ccamp@ietf.= org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

Subject: [CCAMP] Vendor-Specific Application Code= in draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am not seeing= a specific conclusion from it.

 

The current I-D makes (IMHO) the Vendor-Specific = Application Code unusable. I offered three options:

 

1 This value is only to be used when it is known = that all devices

   participating in a network have the = same understanding of

   the content of the Vendor-Speci= fic Application Code field.

   How this knowledge is achieved is ou= tside the scope of this

   document

 

2 When this value is set, the first 32 (or 48) bi= ts of the Vendor-

  Specific Application Code field contain an= Enterprise Number

  (or OUI) that defines the context in which= the remainder of

  that field is interpreted.

 

3 Remove the option to include a Vendor-Specific = Application

   Code field.

 

If the WG could please pick one of these and help= Young to update the document.

 

Thanks,

Adrian

 

> -----Original Message-----

> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 13:50

> To: a= drian@olddog.co.uk

> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> ccamp@ietf= .org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of draft-ietf= -ccamp-rwa-wson-encode

>

> One additional comment (hoping not additiona= l confusion).

>

> The idea about Optical Interface Class was t= aken from SRLG. Good or

> bad is a plain number and you do simple oper= ations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, Giovanni Martinell= i (giomarti)

> <gi= omarti@cisco.com>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel= <adrian@olddog.co.uk> wro= te:

> >

> >> Hi,

> >>

> >> Well, you seem to have a half-way h= ouse.

> >>

> >> You have specified the existence of= a thing, but not how to read it.

> >>

> >> If you wanted to make a statement t= hat this object will only be

> >> used when

it is

> >> known that all systems in a network= come from the same vendor

> >> and/or have

> the

> >> same understanding of the encoding,= that might be OK (although how

> >> you

> would

> >> ascertain this might also need to b= e described).

> >>

> >

> > The statement is to ensure the interfac= e compatibility without

> > encoding all

the

> possible details and parameter that define a= n interface (e.g.

> modulation

format,

> forward error correction etc.). This was the= initial solution in the

> draft

then

> replaced by the interface class concept.&nbs= p;  The WSON (RWA-only) has the

> requirement is to make sure two interface ar= e compatible. This

> requirement, imho, can be satisfy by a simpl= e comparison which has a boolean result.

> >

> > We end up then in  the ITU applica= tion codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatib= ility where proper

> encoding is provided.

> >

> >

> >> Or you could entirely remove the ve= ndor-specific option.

> >>

> >> Or you could put in an OUI / enterp= rise number followed by

> >> transparent

> bytes.

> >>

> >

> > To me I'm perfectly fine with the secon= d option.

> >

> > Cheers

> > G

> >

> >

> >> Adrian

> >>

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

> >>> From: Giovanni Martinelli (giom= arti) [mailto:giomarti@cisco.com]=

> >>> Sent: 21 January 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>

> >>> Subject: Re: [CCAMP] AD review = of draft-ietf-ccamp-rwa-wson-encode

> >>>

> >>> Specifically to the Interface c= lass here below.

> >>>

> >>> In the initial draft merged to = this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) = we decided to remove any encoding

> >>> when the Interface class is not= standard.

> >>> In term of semantic the protcol= does not need to decode the

> >>> Interface

class

> >> since

> >>> it only assess the interface co= mpatibility if two interfaces has a

> >>> class

value

> >> that

> >>> match two interfaces cann be co= nnected.

> >>>

> >>> Having saying that I don't have= strong opinion in adding the OUI

> >>> or

leaving

> >> room

> >>> for maybe future public interfa= ces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility= assesment since there optical

> >>> multivendor compatibility has b= een already demonstrated.

> >>>

> >>> hope this help .

> >>>

> >>> Cheers

> >>> G

> >>>

> >>>

> >>> On 21 Jan 2015, at 21:57, Adria= n Farrel <adrian@olddog.co.uk= > wrote:

> >>>

> >>>>>>

> >>>>>> Section 4.1

> >>>>>> How do I interpret = a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?=

> >>>>>

> >>>>> [YOUNG] Not sure if I u= nderstood this question. What is "OUI"?

> >>>>

> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier

> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> numbers.xhtml#ieee-802

> >>>> -numbers-2

> >>>>

> >>>> Or perhaps an Enterprise Nu= mber

> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> >>>>

> >>>> The question is:=

> >>>>

> >>>> You have sections 4.1.1 thr= ough 4.1.4 to tell me how to interpret

> >>>> the

> >> Optical

> >>>> Interface Class field when = it contains an ITU-T Application Mapping.

> >>>> When I received s=3D0 and O= I=3D1 it means that the Optical Interface

> >>>> Class

> >> contains

> >>>> a "Vendor Specific Opt= ical Interface Class".

> >>>> How do I interpret that Opt= ical Interface Class?

> >>>> Which vendor does it apply = to?

> >>>> Is there some information e= lsewhere that gives me a clue as to

> >>>> which

> vendor

> >>> has

> >>>> encoded the information?

> >>>> Or is the information suppo= sed to be encoded in the Optical

> >>>> Interface

Class,

> >>>> perhaps as the first 48 bit= s?

> >>>> Or am I supposed to know by= context?

> >>

> >

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/ccamp

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F07Bdfweml706chm_-- From nobody Wed Jan 28 11:56: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 B39CF1A1A38 for ; Wed, 28 Jan 2015 11:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 jGFlvU5fjUeq for ; Wed, 28 Jan 2015 11:56:21 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF76D1A00F7 for ; Wed, 28 Jan 2015 11:56:20 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) with ESMTP id 5ee39c45.2b29ece7a940.6134109.00-2475.17137300.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 28 Jan 2015 19:56:21 +0000 (UTC) X-MXL-Hash: 54c93ee529053893-93248767fb690c9bf9028f19dc06a1deec65abe6 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id fde39c45.0.6134058.00-2240.17137149.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 28 Jan 2015 19:56:17 +0000 (UTC) X-MXL-Hash: 54c93ee173ff1829-714f51eedccf3bb38b70df8891fe6036d1e888fc 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 t0SJuE3K002076; Wed, 28 Jan 2015 14:56:14 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t0SJtwD0001790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Jan 2015 14:56:05 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 28 Jan 2015 19:55:50 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.33]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 14:55:49 -0500 From: "BRUNGARD, DEBORAH A" To: Leeyoung , "Lam, Hing-Kam (Kam)" , "adrian@olddog.co.uk" , "'Gert Grammel'" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyYZjvw3dXepkE2NuQ5jP6dwD5zOPoGAgAAFu4CAAB6eAIADl18AgAPVByCAAHiUAP//rnHQ Date: Wed, 28 Jan 2015 19:55:48 +0000 Message-ID: References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE461F@US70TWXCHMBA12.zam.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7F07B@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7F07B@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.98.88] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C83B4DFC36MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=I+DSsqcg c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=1Y0K2hHDVGMA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=YNv0rlydsVwA:10 a=i0EeH86SAAAA:8 a=AEDFM0qtAA] X-AnalysisOut: [AA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=OUXY8nFuAAAA:8 a=] X-AnalysisOut: [AUd_NHdVAAAA:8 a=8pif782wAAAA:8 a=I0CVDw5ZAAAA:8 a=CeU_hsl] X-AnalysisOut: [V9Zc-FOCK7MIA:9 a=CjuIK1q_8ugA:10 a=otwmM483Y7gHYCsa:21 a=] X-AnalysisOut: [XfrkLvJtl2NMHDiD:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=wS] X-AnalysisOut: [yYqcDW3xVstjl8lhwA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a] X-AnalysisOut: [=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=QO2jzmpHnE6b5Z7L:21 a] X-AnalysisOut: [=FHmqq1rcSNZ_chAV:21 a=jQahMTVfMc89GMGM: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: Cc: "'Doolan, Paul \(Coriant - US/Irving\)'" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 28 Jan 2015 19:56:38 -0000 --_000_F64C10EAA68C8044B33656FA214632C83B4DFC36MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young, Are you voting for option 3? My thoughts were if (big IF) we are going to allow proprietary Application = Identifiers (which SG15 has agreed) then best would be if we can at least h= ave some way to identify (better than an undefined string). As you say, it = still does not guarantee interoperability unless it is the same vendor (hop= efully ). If two different vendors (e.g. black link), then it would be for = the vendors (and operator) to ensure interoperability if supporting non-sta= ndard AIs. And as we know, it's not just the AI that is needed to determine= if it will work properly. Thanks, Deborah From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, January 28, 2015 2:33 PM To: BRUNGARD, DEBORAH A; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Gr= ammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tool= s.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Deborah, Thanks for sharing your operator's perspective. I am wondering how the OUI= would really help for interoperability other than identifying the specific= vendors that are using their proprietary code. Say vendor A uses FEC type A while vendor B used FEC type B, and both of th= em are proprietary FECs. I believe the OUI will help the operator identify = this fact and conclude the systems are not compatible. But would this reall= y help operators toward interoperability? I believe a better way for operat= ors to attain interoperability is to force vendors use standard FECs and ha= ve them agree on the same type of FECs within the standard FECs. My point i= s how vendor specific code would be really helpful even if we employ the OU= I field. Thanks, Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH = A Sent: Wednesday, January 28, 2015 11:46 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi All, As Lou noted, Adrian's option 1 was the intention as this was discussed whe= n G872 was being revised to introduce Application Identifier (IETF's March = 2013 meeting). As Kam notes, ITU's work on G.874.1 has evolved to include t= he OUI. As a network operator, I prefer as Adrian says - let's attempt to match dra= ft G.874.1 (it does have agreement). So Adrian's option 2. While the contex= t of this work is within an operator's network, the OUI will help to ensure= interoperability. Adrian - good catch- Deborah From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: Sunday, January 25, 2015 8:50 PM To: adrian@olddog.co.uk; 'Gert Grammel'; 'Giova= nni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Adrian, Yes, while Q14/15 already reached agreement to update the Application Ident= ifier description, the update has not been formally approved and published = by SG15 yet. Q14/15 may be able to consent this update as an Amendment to G= .874.1 at the upcoming SG15 meeting in July 2015. Regards, Kam From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, January 23, 2015 1:59 PM To: Lam, Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Thanks for being awake, Kam. Useful info. Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry= page for this, but it points to the IEEE page. As I understand Kam, 874.1 is not yet updated so it would be premature to p= oint to it, but an option is to attempt to match it now and fix later if ne= eded. Adrian From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com] Sent: 23 January 2015 17:10 To: Gert Grammel; adrian@olddog.co.uk; 'Giovann= i Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Gert, A vendor can purchase an OUI (Organizationally Unique Identifier) from the = IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific applic= ation identifiers under its own OUI. SG15 doesn't need to host any registry for this purpose. Regards, Kam From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Kam, Is SG15 considering to host a registry for the vendor specific application = code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (= giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.8= 74.1 to amend the specification of ApplicationIdentifier with the following= additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString = represents a standard application code as defined in the ITU-T Recommendati= ons. If the ApplicationIdentifierType is PROPRIETARY, the first six charact= ers of the PrintableString must contain the Hexadecimal representation of a= n OUI assigned to the vendor whose implementation generated the Application= Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietar= y-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools= .ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-w= son-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel > wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a bool= ean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel > wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_F64C10EAA68C8044B33656FA214632C83B4DFC36MISOUT7MSGUSRDE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young,

 

Are you voting for opt= ion 3?

 

My thoughts were if (b= ig IF) we are going to allow proprietary Application Identifiers (which SG1= 5 has agreed) then best would be if we can at least have some way to identi= fy (better than an undefined string). As you say, it still does not guarantee interoperability unless it is the = same vendor (hopefully ). If two different vendors (e.g. black link), then = it would be for the vendors (and operator) to ensure interoperability if su= pporting non-standard AIs. And as we know, it’s not just the AI that is needed to determine if it will= work properly.

 

Thanks,

Deborah

 

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, January 28, 2015 2:33 PM
To: BRUNGARD, DEBORAH A; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chai= rs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Deborah,=

 

Thanks for sharing you= r operator’s perspective.  I am wondering how the OUI would real= ly help for interoperability other than identifying the specific vendors th= at are using their proprietary code.  

 

Say vendor A uses FEC = type A while vendor B used FEC type B, and both of them are proprietary FEC= s. I believe the OUI will help the operator identify this fact and conclude= the systems are not compatible. But would this really help operators toward interoperability? I believe a bett= er way for operators to attain interoperability is to force vendors use sta= ndard FECs and have them agree on the same type of FECs within the standard= FECs. My point is how vendor specific code would be really helpful even if we employ the OUI field. <= /span>

 

Thanks,

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Wednesday, January 28, 2015 11:46 AM
To: Lam, Hing-Kam (Kam); adri= an@olddog.co.uk; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-ch= airs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi All,

 

As Lou noted, Adrian&#= 8217;s option 1 was the intention as this was discussed when G872 was being= revised to introduce Application Identifier (IETF’s March 2013 meeti= ng). As Kam notes, ITU’s work on G.874.1 has evolved to include the OUI.

 

As a network operator,= I prefer as Adrian says – let’s attempt to match draft G.874.1= (it does have agreement). So Adrian’s option 2. While the context of= this work is within an operator’s network, the OUI will help to ensure interoperability.

 

Adrian – good ca= tch-

Deborah

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: Sunday, January 25, 2015 8:50 PM
To: adrian@olddog.co.uk; = 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-ch= airs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Adrian,<= /span>

 

Yes, while Q14/15 alre= ady reached agreement to update the Application Identifier description, the= update has not been formally approved and published by SG15 yet. Q14/15 ma= y be able to consent this update as an Amendment to G.874.1 at the upcoming SG15 meeting in July 2015.

 

Regards,

Kam<= /p>

 

 

Thanks = for being awake, Kam.

&n= bsp;

Useful = info.

&n= bsp;

Gert, t= he OUI registry is an IEEE registry as Kam says. IANA has a registry page f= or this, but it points to the IEEE page.

&n= bsp;

As I un= derstand Kam, 874.1 is not yet updated so it would be premature to point to= it, but an option is to attempt to match it now and fix later if needed.

&n= bsp;

Adrian<= o:p>

&n= bsp;

From: Lam, Hin= g-Kam (Kam) [mailto:kam.lam@a= lcatel-lucent.com]
Sent: 23 January 2015 17:10
To: Gert Grammel; adrian@oldd= og.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Gert,

 

A vendor can purchase = an OUI (Organizationally Unique Identifier) from the IEEE Registration Auth= ority.

Once a vendor has its = OUI, the vendor can manage its vendor-specific application identifiers unde= r its own OUI.

SG15 doesn’t nee= d to host any registry for this purpose.

 

Regards,

Kam<= /p>

 

From: Gert Gra= mmel [mailto:ggrammel@juniper.net]
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); adri= an@olddog.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Kam,

 

Is SG15 considering to= host a registry for the vendor specific application code or is the IETF re= gistry supposed to be used?

 

Thanks

 

Gert=

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: adrian@olddog.co.uk; = 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 meeting, Q= 14/15 agreed to update G.874.1 to amend the specification of ApplicationIde= ntifier with the following additional text:

 

If the ApplicationIden= tifierType is STANDARD, the value of PrintableString represents a standard = application code as defined in the ITU-T Recommendations. If the Applicatio= nIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal r= epresentation of an OUI assigned to the vendor whose implementation generat= ed the Application Identifier; the remaining octets of the PrintableString = are unspecified.

 

Paul Doolan had an I-D "https://tools.ietf.org/h= tml/draft-doolan-proprietary-ac-00" to the last IETF meeting with = the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM=

To: 'Giovanni Martinelli (giomarti)'

Cc: ccamp@ietf.= org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

Subject: [CCAMP] Vendor-Specific Application Code= in draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am not seeing= a specific conclusion from it.

 

The current I-D makes (IMHO) the Vendor-Specific = Application Code unusable. I offered three options:

 

1 This value is only to be used when it is known = that all devices

   participating in a network have the = same understanding of

   the content of the Vendor-Speci= fic Application Code field.

   How this knowledge is achieved is ou= tside the scope of this

   document

 

2 When this value is set, the first 32 (or 48) bi= ts of the Vendor-

  Specific Application Code field contain an= Enterprise Number

  (or OUI) that defines the context in which= the remainder of

  that field is interpreted.

 

3 Remove the option to include a Vendor-Specific = Application

   Code field.

 

If the WG could please pick one of these and help= Young to update the document.

 

Thanks,

Adrian

 

> -----Original Message-----

> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 13:50

> To: a= drian@olddog.co.uk

> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> ccamp@ietf= .org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of draft-ietf= -ccamp-rwa-wson-encode

>

> One additional comment (hoping not additiona= l confusion).

>

> The idea about Optical Interface Class was t= aken from SRLG. Good or

> bad is a plain number and you do simple oper= ations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, Giovanni Martinell= i (giomarti)

> <gi= omarti@cisco.com>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel= <adrian@olddog.co.uk> wro= te:

> >

> >> Hi,

> >>

> >> Well, you seem to have a half-way h= ouse.

> >>

> >> You have specified the existence of= a thing, but not how to read it.

> >>

> >> If you wanted to make a statement t= hat this object will only be

> >> used when

it is

> >> known that all systems in a network= come from the same vendor

> >> and/or have

> the

> >> same understanding of the encoding,= that might be OK (although how

> >> you

> would

> >> ascertain this might also need to b= e described).

> >>

> >

> > The statement is to ensure the interfac= e compatibility without

> > encoding all

the

> possible details and parameter that define a= n interface (e.g.

> modulation

format,

> forward error correction etc.). This was the= initial solution in the

> draft

then

> replaced by the interface class concept.&nbs= p;  The WSON (RWA-only) has the

> requirement is to make sure two interface ar= e compatible. This

> requirement, imho, can be satisfy by a simpl= e comparison which has a boolean result.

> >

> > We end up then in  the ITU applica= tion codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatib= ility where proper

> encoding is provided.

> >

> >

> >> Or you could entirely remove the ve= ndor-specific option.

> >>

> >> Or you could put in an OUI / enterp= rise number followed by

> >> transparent

> bytes.

> >>

> >

> > To me I'm perfectly fine with the secon= d option.

> >

> > Cheers

> > G

> >

> >

> >> Adrian

> >>

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

> >>> From: Giovanni Martinelli (giom= arti) [mailto:giomarti@cisco.com]=

> >>> Sent: 21 January 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>

> >>> Subject: Re: [CCAMP] AD review = of draft-ietf-ccamp-rwa-wson-encode

> >>>

> >>> Specifically to the Interface c= lass here below.

> >>>

> >>> In the initial draft merged to = this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) = we decided to remove any encoding

> >>> when the Interface class is not= standard.

> >>> In term of semantic the protcol= does not need to decode the

> >>> Interface

class

> >> since

> >>> it only assess the interface co= mpatibility if two interfaces has a

> >>> class

value

> >> that

> >>> match two interfaces cann be co= nnected.

> >>>

> >>> Having saying that I don't have= strong opinion in adding the OUI

> >>> or

leaving

> >> room

> >>> for maybe future public interfa= ces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility= assesment since there optical

> >>> multivendor compatibility has b= een already demonstrated.

> >>>

> >>> hope this help .

> >>>

> >>> Cheers

> >>> G

> >>>

> >>>

> >>> On 21 Jan 2015, at 21:57, Adria= n Farrel <adrian@olddog.co.uk= > wrote:

> >>>

> >>>>>>

> >>>>>> Section 4.1

> >>>>>> How do I interpret = a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?=

> >>>>>

> >>>>> [YOUNG] Not sure if I u= nderstood this question. What is "OUI"?

> >>>>

> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier

> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> numbers.xhtml#ieee-802

> >>>> -numbers-2

> >>>>

> >>>> Or perhaps an Enterprise Nu= mber

> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> >>>>

> >>>> The question is:=

> >>>>

> >>>> You have sections 4.1.1 thr= ough 4.1.4 to tell me how to interpret

> >>>> the

> >> Optical

> >>>> Interface Class field when = it contains an ITU-T Application Mapping.

> >>>> When I received s=3D0 and O= I=3D1 it means that the Optical Interface

> >>>> Class

> >> contains

> >>>> a "Vendor Specific Opt= ical Interface Class".

> >>>> How do I interpret that Opt= ical Interface Class?

> >>>> Which vendor does it apply = to?

> >>>> Is there some information e= lsewhere that gives me a clue as to

> >>>> which

> vendor

> >>> has

> >>>> encoded the information?

> >>>> Or is the information suppo= sed to be encoded in the Optical

> >>>> Interface

Class,

> >>>> perhaps as the first 48 bit= s?

> >>>> Or am I supposed to know by= context?

> >>

> >

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/ccamp

--_000_F64C10EAA68C8044B33656FA214632C83B4DFC36MISOUT7MSGUSRDE_-- From nobody Wed Jan 28 12:05: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 A84911A1B36 for ; Wed, 28 Jan 2015 12:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 irQzXHKkrPB3 for ; Wed, 28 Jan 2015 12:05:19 -0800 (PST) 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 0FA781A1A67 for ; Wed, 28 Jan 2015 12:05:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BON45521; Wed, 28 Jan 2015 20:05:12 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 20:05:11 +0000 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; Wed, 28 Jan 2015 12:05:09 -0800 From: Leeyoung To: "BRUNGARD, DEBORAH A" , "Lam, Hing-Kam (Kam)" , "adrian@olddog.co.uk" , "'Gert Grammel'" , "'Giovanni Martinelli (giomarti)'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyKmWicGibpQEGWYW2s/gCycJzOdnmAgAAengCAA5dgAIAEL7YA//+TloCAAJDSAP//e+qg Date: Wed, 28 Jan 2015 20:05:09 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE461F@US70TWXCHMBA12.zam.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7F07B@dfweml706-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.240] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'Doolan, Paul \(Coriant - US/Irving\)'" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 28 Jan 2015 20:05:46 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9dfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah, I agree with what you said. That was my point. Option 1 is my preference an= d the WG has agreed on that ,I think. Thanks, Young From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] Sent: Wednesday, January 28, 2015 1:56 PM To: Leeyoung; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Grammel'; 'Gi= ovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tool= s.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Young, Are you voting for option 3? My thoughts were if (big IF) we are going to allow proprietary Application = Identifiers (which SG15 has agreed) then best would be if we can at least h= ave some way to identify (better than an undefined string). As you say, it = still does not guarantee interoperability unless it is the same vendor (hop= efully ). If two different vendors (e.g. black link), then it would be for = the vendors (and operator) to ensure interoperability if supporting non-sta= ndard AIs. And as we know, it's not just the AI that is needed to determine= if it will work properly. Thanks, Deborah From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, January 28, 2015 2:33 PM To: BRUNGARD, DEBORAH A; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Gr= ammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tool= s.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Deborah, Thanks for sharing your operator's perspective. I am wondering how the OUI= would really help for interoperability other than identifying the specific= vendors that are using their proprietary code. Say vendor A uses FEC type A while vendor B used FEC type B, and both of th= em are proprietary FECs. I believe the OUI will help the operator identify = this fact and conclude the systems are not compatible. But would this reall= y help operators toward interoperability? I believe a better way for operat= ors to attain interoperability is to force vendors use standard FECs and ha= ve them agree on the same type of FECs within the standard FECs. My point i= s how vendor specific code would be really helpful even if we employ the OU= I field. Thanks, Young From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH = A Sent: Wednesday, January 28, 2015 11:46 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi All, As Lou noted, Adrian's option 1 was the intention as this was discussed whe= n G872 was being revised to introduce Application Identifier (IETF's March = 2013 meeting). As Kam notes, ITU's work on G.874.1 has evolved to include t= he OUI. As a network operator, I prefer as Adrian says - let's attempt to match dra= ft G.874.1 (it does have agreement). So Adrian's option 2. While the contex= t of this work is within an operator's network, the OUI will help to ensure= interoperability. Adrian - good catch- Deborah From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: Sunday, January 25, 2015 8:50 PM To: adrian@olddog.co.uk; 'Gert Grammel'; 'Giova= nni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Adrian, Yes, while Q14/15 already reached agreement to update the Application Ident= ifier description, the update has not been formally approved and published = by SG15 yet. Q14/15 may be able to consent this update as an Amendment to G= .874.1 at the upcoming SG15 meeting in July 2015. Regards, Kam From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, January 23, 2015 1:59 PM To: Lam, Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Thanks for being awake, Kam. Useful info. Gert, the OUI registry is an IEEE registry as Kam says. IANA has a registry= page for this, but it points to the IEEE page. As I understand Kam, 874.1 is not yet updated so it would be premature to p= oint to it, but an option is to attempt to match it now and fix later if ne= eded. Adrian From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com] Sent: 23 January 2015 17:10 To: Gert Grammel; adrian@olddog.co.uk; 'Giovann= i Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Gert, A vendor can purchase an OUI (Organizationally Unique Identifier) from the = IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific applic= ation identifiers under its own OUI. SG15 doesn't need to host any registry for this purpose. Regards, Kam From: Gert Grammel [mailto:ggrammel@juniper.net] Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Hi Kam, Is SG15 considering to host a registry for the vendor specific application = code or is the IETF registry supposed to be used? Thanks Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam= ) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (= giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-= ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-r= wa-wson-encode Dear all, For your information. In the last SG15 meeting, Q14/15 agreed to update G.8= 74.1 to amend the specification of ApplicationIdentifier with the following= additional text: If the ApplicationIdentifierType is STANDARD, the value of PrintableString = represents a standard application code as defined in the ITU-T Recommendati= ons. If the ApplicationIdentifierType is PROPRIETARY, the first six charact= ers of the PrintableString must contain the Hexadecimal representation of a= n OUI assigned to the vendor whose implementation generated the Application= Identifier; the remaining octets of the PrintableString are unspecified. Paul Doolan had an I-D "https://tools.ietf.org/html/draft-doolan-proprietar= y-ac-00" to the last IETF meeting with the similar proposal. Regards, Kam -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools= .ietf.org Subject: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-w= son-encode Hi, I appreciate this discussion, but I am not seeing a specific conclusion fro= m it. The current I-D makes (IMHO) the Vendor-Specific Application Code unusable.= I offered three options: 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. 3 Remove the option to include a Vendor-Specific Application Code field. If the WG could please pick one of these and help Young to update the docum= ent. Thanks, Adrian > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > > One additional comment (hoping not additional confusion). > > The idea about Optical Interface Class was taken from SRLG. Good or > bad is a plain number and you do simple operations on it. > > Cheers > G > > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti) > > > wrote: > > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel > wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read it. > >> > >> If you wanted to make a statement that this object will only be > >> used when it is > >> known that all systems in a network come from the same vendor > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without > > encoding all the > possible details and parameter that define an interface (e.g. > modulation format, > forward error correction etc.). This was the initial solution in the > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This > requirement, imho, can be satisfy by a simple comparison which has a bool= ean result. > > > > We end up then in the ITU application codes for the "certified" > > (we'll this is my > term not 100% sure is the best one) compatibility where proper > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a > >>> need to leave > >>> room for specific compatibility assesment since there optical > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel > wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical Interface > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9dfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Deborah,=

 

I agree with what you = said. That was my point. Option 1 is my preference and the WG has agreed on= that ,I think.

 

Thanks,

Young

 

From: BRUNGARD= , DEBORAH A [mailto:db3546@att.com]
Sent: Wednesday, January 28, 2015 1:56 PM
To: Leeyoung; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Gramme= l'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chai= rs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Young,

 

Are you voting for opt= ion 3?

 

My thoughts were if (b= ig IF) we are going to allow proprietary Application Identifiers (which SG1= 5 has agreed) then best would be if we can at least have some way to identi= fy (better than an undefined string). As you say, it still does not guarantee interoperability unless it is the = same vendor (hopefully ). If two different vendors (e.g. black link), then = it would be for the vendors (and operator) to ensure interoperability if su= pporting non-standard AIs. And as we know, it’s not just the AI that is needed to determine if it will= work properly.

 

Thanks,

Deborah

 

 

From: Leeyoung= [mailto:leeyoung@huawei.com]
Sent: Wednesday, January 28, 2015 2:33 PM
To: BRUNGARD, DEBORAH A; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; '= Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chai= rs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Deborah,=

 

Thanks for sharing you= r operator’s perspective.  I am wondering how the OUI would real= ly help for interoperability other than identifying the specific vendors th= at are using their proprietary code.  

 

Say vendor A uses FEC = type A while vendor B used FEC type B, and both of them are proprietary FEC= s. I believe the OUI will help the operator identify this fact and conclude= the systems are not compatible. But would this really help operators toward interoperability? I believe a bett= er way for operators to attain interoperability is to force vendors use sta= ndard FECs and have them agree on the same type of FECs within the standard= FECs. My point is how vendor specific code would be really helpful even if we employ the OUI field. <= /span>

 

Thanks,

Young

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Wednesday, January 28, 2015 11:46 AM
To: Lam, Hing-Kam (Kam); adri= an@olddog.co.uk; 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-ch= airs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi All,

 

As Lou noted, Adrian&#= 8217;s option 1 was the intention as this was discussed when G872 was being= revised to introduce Application Identifier (IETF’s March 2013 meeti= ng). As Kam notes, ITU’s work on G.874.1 has evolved to include the OUI.

 

As a network operator,= I prefer as Adrian says – let’s attempt to match draft G.874.1= (it does have agreement). So Adrian’s option 2. While the context of= this work is within an operator’s network, the OUI will help to ensure interoperability.

 

Adrian – good ca= tch-

Deborah

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: Sunday, January 25, 2015 8:50 PM
To: adrian@olddog.co.uk; = 'Gert Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-ch= airs@tools.ietf.org; draf= t-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Adrian,<= /span>

 

Yes, while Q14/15 alre= ady reached agreement to update the Application Identifier description, the= update has not been formally approved and published by SG15 yet. Q14/15 ma= y be able to consent this update as an Amendment to G.874.1 at the upcoming SG15 meeting in July 2015.

 

Regards,

Kam<= /p>

 

 

Thanks = for being awake, Kam.

&n= bsp;

Useful = info.

&n= bsp;

Gert, t= he OUI registry is an IEEE registry as Kam says. IANA has a registry page f= or this, but it points to the IEEE page.

&n= bsp;

As I un= derstand Kam, 874.1 is not yet updated so it would be premature to point to= it, but an option is to attempt to match it now and fix later if needed.

&n= bsp;

Adrian<= o:p>

&n= bsp;

From: Lam, Hin= g-Kam (Kam) [mailto:kam.lam@a= lcatel-lucent.com]
Sent: 23 January 2015 17:10
To: Gert Grammel; adrian@oldd= og.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Gert,

 

A vendor can purchase = an OUI (Organizationally Unique Identifier) from the IEEE Registration Auth= ority.

Once a vendor has its = OUI, the vendor can manage its vendor-specific application identifiers unde= r its own OUI.

SG15 doesn’t nee= d to host any registry for this purpose.

 

Regards,

Kam<= /p>

 

From: Gert Gra= mmel [mailto:ggrammel@juniper.net]
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, Hing-Kam (Kam); adri= an@olddog.co.uk; 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Hi Kam,

 

Is SG15 considering to= host a registry for the vendor specific application code or is the IETF re= gistry supposed to be used?

 

Thanks

 

Gert=

 

From: CCAMP [<= a href=3D"mailto:ccamp-bounces@ietf.org">mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 17:03
To: adrian@olddog.co.uk; = 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-= ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 meeting, Q= 14/15 agreed to update G.874.1 to amend the specification of ApplicationIde= ntifier with the following additional text:

 

If the ApplicationIden= tifierType is STANDARD, the value of PrintableString represents a standard = application code as defined in the ITU-T Recommendations. If the Applicatio= nIdentifierType is PROPRIETARY, the first six characters of the PrintableString must contain the Hexadecimal r= epresentation of an OUI assigned to the vendor whose implementation generat= ed the Application Identifier; the remaining octets of the PrintableString = are unspecified.

 

Paul Doolan had an I-D "https://tools.ietf.org/h= tml/draft-doolan-proprietary-ac-00" to the last IETF meeting with = the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 AM=

To: 'Giovanni Martinelli (giomarti)'

Cc: ccamp@ietf.= org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

Subject: [CCAMP] Vendor-Specific Application Code= in draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am not seeing= a specific conclusion from it.

 

The current I-D makes (IMHO) the Vendor-Specific = Application Code unusable. I offered three options:

 

1 This value is only to be used when it is known = that all devices

   participating in a network have the = same understanding of

   the content of the Vendor-Speci= fic Application Code field.

   How this knowledge is achieved is ou= tside the scope of this

   document

 

2 When this value is set, the first 32 (or 48) bi= ts of the Vendor-

  Specific Application Code field contain an= Enterprise Number

  (or OUI) that defines the context in which= the remainder of

  that field is interpreted.

 

3 Remove the option to include a Vendor-Specific = Application

   Code field.

 

If the WG could please pick one of these and help= Young to update the document.

 

Thanks,

Adrian

 

> -----Original Message-----

> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 13:50

> To: a= drian@olddog.co.uk

> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> ccamp@ietf= .org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of draft-ietf= -ccamp-rwa-wson-encode

>

> One additional comment (hoping not additiona= l confusion).

>

> The idea about Optical Interface Class was t= aken from SRLG. Good or

> bad is a plain number and you do simple oper= ations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, Giovanni Martinell= i (giomarti)

> <gi= omarti@cisco.com>

> wrote:

>

> > Hi Adrian,

> >

> > On 21 Jan 2015, at 22:55, Adrian Farrel= <adrian@olddog.co.uk> wro= te:

> >

> >> Hi,

> >>

> >> Well, you seem to have a half-way h= ouse.

> >>

> >> You have specified the existence of= a thing, but not how to read it.

> >>

> >> If you wanted to make a statement t= hat this object will only be

> >> used when

it is

> >> known that all systems in a network= come from the same vendor

> >> and/or have

> the

> >> same understanding of the encoding,= that might be OK (although how

> >> you

> would

> >> ascertain this might also need to b= e described).

> >>

> >

> > The statement is to ensure the interfac= e compatibility without

> > encoding all

the

> possible details and parameter that define a= n interface (e.g.

> modulation

format,

> forward error correction etc.). This was the= initial solution in the

> draft

then

> replaced by the interface class concept.&nbs= p;  The WSON (RWA-only) has the

> requirement is to make sure two interface ar= e compatible. This

> requirement, imho, can be satisfy by a simpl= e comparison which has a boolean result.

> >

> > We end up then in  the ITU applica= tion codes for the "certified"

> > (we'll this

is my

> term not 100% sure is the best one) compatib= ility where proper

> encoding is provided.

> >

> >

> >> Or you could entirely remove the ve= ndor-specific option.

> >>

> >> Or you could put in an OUI / enterp= rise number followed by

> >> transparent

> bytes.

> >>

> >

> > To me I'm perfectly fine with the secon= d option.

> >

> > Cheers

> > G

> >

> >

> >> Adrian

> >>

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

> >>> From: Giovanni Martinelli (giom= arti) [mailto:giomarti@cisco.com]=

> >>> Sent: 21 January 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org<= /a>

> >>> Subject: Re: [CCAMP] AD review = of draft-ietf-ccamp-rwa-wson-encode

> >>>

> >>> Specifically to the Interface c= lass here below.

> >>>

> >>> In the initial draft merged to = this one there was the usage of OUI

> >>> however

(I

> >>> guess after chatting with Lou) = we decided to remove any encoding

> >>> when the Interface class is not= standard.

> >>> In term of semantic the protcol= does not need to decode the

> >>> Interface

class

> >> since

> >>> it only assess the interface co= mpatibility if two interfaces has a

> >>> class

value

> >> that

> >>> match two interfaces cann be co= nnected.

> >>>

> >>> Having saying that I don't have= strong opinion in adding the OUI

> >>> or

leaving

> >> room

> >>> for maybe future public interfa= ces database. For sure there's a

> >>> need to

leave

> >>> room for specific compatibility= assesment since there optical

> >>> multivendor compatibility has b= een already demonstrated.

> >>>

> >>> hope this help .

> >>>

> >>> Cheers

> >>> G

> >>>

> >>>

> >>> On 21 Jan 2015, at 21:57, Adria= n Farrel <adrian@olddog.co.uk= > wrote:

> >>>

> >>>>>>

> >>>>>> Section 4.1

> >>>>>> How do I interpret = a Vendor-Specific Application Code? Is there

> >>>>>> an OUI I'm missing?=

> >>>>>

> >>>>> [YOUNG] Not sure if I u= nderstood this question. What is "OUI"?

> >>>>

> >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier

> >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> numbers.xhtml#ieee-802

> >>>> -numbers-2

> >>>>

> >>>> Or perhaps an Enterprise Nu= mber

> >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> >>>>

> >>>> The question is:=

> >>>>

> >>>> You have sections 4.1.1 thr= ough 4.1.4 to tell me how to interpret

> >>>> the

> >> Optical

> >>>> Interface Class field when = it contains an ITU-T Application Mapping.

> >>>> When I received s=3D0 and O= I=3D1 it means that the Optical Interface

> >>>> Class

> >> contains

> >>>> a "Vendor Specific Opt= ical Interface Class".

> >>>> How do I interpret that Opt= ical Interface Class?

> >>>> Which vendor does it apply = to?

> >>>> Is there some information e= lsewhere that gives me a clue as to

> >>>> which

> vendor

> >>> has

> >>>> encoded the information?

> >>>> Or is the information suppo= sed to be encoded in the Optical

> >>>> Interface

Class,

> >>>> perhaps as the first 48 bit= s?

> >>>> Or am I supposed to know by= context?

> >>

> >

 

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/ccamp

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9dfweml706chm_-- From nobody Wed Jan 28 12:17:02 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 72F741A0110 for ; Wed, 28 Jan 2015 12:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 o4IW1MiiSxrV for ; Wed, 28 Jan 2015 12:16:54 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0034F1A00EA for ; Wed, 28 Jan 2015 12:16:53 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id AAD9E56313015; Wed, 28 Jan 2015 20:16:47 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t0SKGlUS002127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Jan 2015 15:16:48 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 15:16:47 -0500 From: "Varma, Eve L (Eve)" To: "'leeyoung@huawei.com'" , "'db3546@att.com'" , "Lam, Hing-Kam (Kam)" , "'adrian@olddog.co.uk'" , "'ggrammel@juniper.net'" , "'giomarti@cisco.com'" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQOzdWGU7/BA/10Uaebc6PdLqqCw== Date: Wed, 28 Jan 2015 20:16:46 +0000 Message-ID: <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_6D32668528F93D449A073F45707153D82C533567US70UWXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: "'paul.doolan@coriant.com'" , "'ccamp@ietf.org'" , "'ccamp-chairs@tools.ietf.org'" , "'draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org'" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 28 Jan 2015 20:17:00 -0000 --_000_6D32668528F93D449A073F45707153D82C533567US70UWXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkknbSBnZXR0aW5nIGEgYml0IGNvbmZ1c2VkIC0gSSB0aG91Z2h0IHRoYXQg dGhlcmUgd2FzIHNlbnRpbWVudCB0byBtYXRjaCB0aGUgYXBwcm9hY2ggaW4gRy44NzQuMTsgd2Fz bid0IHRoYXQgb3B0aW9uIDI/DQoNCkJlc3QgcmVnYXJkcywNCkV2ZQ0KDQpGcm9tOiBMZWV5b3Vu ZyBbbWFpbHRvOmxlZXlvdW5nQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkg MjgsIDIwMTUgMDM6MDUgUE0NClRvOiBCUlVOR0FSRCwgREVCT1JBSCBBIDxkYjM1NDZAYXR0LmNv bT47IExhbSwgSGluZy1LYW0gKEthbSk7IGFkcmlhbkBvbGRkb2cuY28udWsgPGFkcmlhbkBvbGRk b2cuY28udWs+OyAnR2VydCBHcmFtbWVsJyA8Z2dyYW1tZWxAanVuaXBlci5uZXQ+OyAnR2lvdmFu bmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJyA8Z2lvbWFydGlAY2lzY28uY29tPg0KQ2M6ICdEb29s YW4sIFBhdWwgKENvcmlhbnQgLSBVUy9JcnZpbmcpJyA8cGF1bC5kb29sYW5AY29yaWFudC5jb20+ OyBjY2FtcEBpZXRmLm9yZyA8Y2NhbXBAaWV0Zi5vcmc+OyBjY2FtcC1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmcgPGNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IGRyYWZ0LWlldGYtY2NhbXAtcndh LXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyA8ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nv bi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gVmVuZG9y LVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1l bmNvZGUNCg0KSGkgRGVib3JhaCwNCg0KSSBhZ3JlZSB3aXRoIHdoYXQgeW91IHNhaWQuIFRoYXQg d2FzIG15IHBvaW50LiBPcHRpb24gMSBpcyBteSBwcmVmZXJlbmNlIGFuZCB0aGUgV0cgaGFzIGFn cmVlZCBvbiB0aGF0ICxJIHRoaW5rLg0KDQpUaGFua3MsDQpZb3VuZw0KDQpGcm9tOiBCUlVOR0FS RCwgREVCT1JBSCBBIFttYWlsdG86ZGIzNTQ2QGF0dC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMjgsIDIwMTUgMTo1NiBQTQ0KVG86IExlZXlvdW5nOyBMYW0sIEhpbmctS2FtIChLYW0p OyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyAnR2VydCBHcmFtbWVsJzsgJ0dpb3Zhbm5pIE1hcnRpbmVs bGkgKGdpb21hcnRpKScNCkNjOiAnRG9vbGFuLCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKSc7 IGNjYW1wQGlldGYub3JnOyBjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYt Y2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFtD Q0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2Ft cC1yd2Etd3Nvbi1lbmNvZGUNCg0KSGkgWW91bmcsDQoNCkFyZSB5b3Ugdm90aW5nIGZvciBvcHRp b24gMz8NCg0KTXkgdGhvdWdodHMgd2VyZSBpZiAoYmlnIElGKSB3ZSBhcmUgZ29pbmcgdG8gYWxs b3cgcHJvcHJpZXRhcnkgQXBwbGljYXRpb24gSWRlbnRpZmllcnMgKHdoaWNoIFNHMTUgaGFzIGFn cmVlZCkgdGhlbiBiZXN0IHdvdWxkIGJlIGlmIHdlIGNhbiBhdCBsZWFzdCBoYXZlIHNvbWUgd2F5 IHRvIGlkZW50aWZ5IChiZXR0ZXIgdGhhbiBhbiB1bmRlZmluZWQgc3RyaW5nKS4gQXMgeW91IHNh eSwgaXQgc3RpbGwgZG9lcyBub3QgZ3VhcmFudGVlIGludGVyb3BlcmFiaWxpdHkgdW5sZXNzIGl0 IGlzIHRoZSBzYW1lIHZlbmRvciAoaG9wZWZ1bGx5ICkuIElmIHR3byBkaWZmZXJlbnQgdmVuZG9y cyAoZS5nLiBibGFjayBsaW5rKSwgdGhlbiBpdCB3b3VsZCBiZSBmb3IgdGhlIHZlbmRvcnMgKGFu ZCBvcGVyYXRvcikgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkgaWYgc3VwcG9ydGluZyBub24t c3RhbmRhcmQgQUlzLiBBbmQgYXMgd2Uga25vdywgaXTigJlzIG5vdCBqdXN0IHRoZSBBSSB0aGF0 IGlzIG5lZWRlZCB0byBkZXRlcm1pbmUgaWYgaXQgd2lsbCB3b3JrIHByb3Blcmx5Lg0KDQpUaGFu a3MsDQpEZWJvcmFoDQoNCg0KRnJvbTogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWku Y29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI4LCAyMDE1IDI6MzMgUE0NClRvOiBCUlVO R0FSRCwgREVCT1JBSCBBOyBMYW0sIEhpbmctS2FtIChLYW0pOyBhZHJpYW5Ab2xkZG9nLmNvLnVr OyAnR2VydCBHcmFtbWVsJzsgJ0dpb3Zhbm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKScNCkNjOiAn RG9vbGFuLCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKSc7IGNjYW1wQGlldGYub3JnOyBjY2Ft cC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2Rl LmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmlj IEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUNCg0K SGkgRGVib3JhaCwNCg0KVGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgb3BlcmF0b3LigJlzIHBlcnNw ZWN0aXZlLiAgSSBhbSB3b25kZXJpbmcgaG93IHRoZSBPVUkgd291bGQgcmVhbGx5IGhlbHAgZm9y IGludGVyb3BlcmFiaWxpdHkgb3RoZXIgdGhhbiBpZGVudGlmeWluZyB0aGUgc3BlY2lmaWMgdmVu ZG9ycyB0aGF0IGFyZSB1c2luZyB0aGVpciBwcm9wcmlldGFyeSBjb2RlLg0KDQpTYXkgdmVuZG9y IEEgdXNlcyBGRUMgdHlwZSBBIHdoaWxlIHZlbmRvciBCIHVzZWQgRkVDIHR5cGUgQiwgYW5kIGJv dGggb2YgdGhlbSBhcmUgcHJvcHJpZXRhcnkgRkVDcy4gSSBiZWxpZXZlIHRoZSBPVUkgd2lsbCBo ZWxwIHRoZSBvcGVyYXRvciBpZGVudGlmeSB0aGlzIGZhY3QgYW5kIGNvbmNsdWRlIHRoZSBzeXN0 ZW1zIGFyZSBub3QgY29tcGF0aWJsZS4gQnV0IHdvdWxkIHRoaXMgcmVhbGx5IGhlbHAgb3BlcmF0 b3JzIHRvd2FyZCBpbnRlcm9wZXJhYmlsaXR5PyBJIGJlbGlldmUgYSBiZXR0ZXIgd2F5IGZvciBv cGVyYXRvcnMgdG8gYXR0YWluIGludGVyb3BlcmFiaWxpdHkgaXMgdG8gZm9yY2UgdmVuZG9ycyB1 c2Ugc3RhbmRhcmQgRkVDcyBhbmQgaGF2ZSB0aGVtIGFncmVlIG9uIHRoZSBzYW1lIHR5cGUgb2Yg RkVDcyB3aXRoaW4gdGhlIHN0YW5kYXJkIEZFQ3MuIE15IHBvaW50IGlzIGhvdyB2ZW5kb3Igc3Bl Y2lmaWMgY29kZSB3b3VsZCBiZSByZWFsbHkgaGVscGZ1bCBldmVuIGlmIHdlIGVtcGxveSB0aGUg T1VJIGZpZWxkLg0KDQpUaGFua3MsDQpZb3VuZw0KDQpGcm9tOiBDQ0FNUCBbbWFpbHRvOmNjYW1w LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCUlVOR0FSRCwgREVCT1JBSCBBDQpTZW50 OiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMTUgMTE6NDYgQU0NClRvOiBMYW0sIEhpbmctS2Ft IChLYW0pOyBhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPjsg J0dlcnQgR3JhbW1lbCc7ICdHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknDQpDYzogJ0Rv b2xhbiwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyknOyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86 Y2NhbXBAaWV0Zi5vcmc+OyBjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmNjYW1w LWNoYWlyc0B0b29scy5pZXRmLm9yZz47IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2Rl LmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNv ZGUuYWxsQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNp ZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUN Cg0KSGkgQWxsLA0KDQpBcyBMb3Ugbm90ZWQsIEFkcmlhbuKAmXMgb3B0aW9uIDEgd2FzIHRoZSBp bnRlbnRpb24gYXMgdGhpcyB3YXMgZGlzY3Vzc2VkIHdoZW4gRzg3MiB3YXMgYmVpbmcgcmV2aXNl ZCB0byBpbnRyb2R1Y2UgQXBwbGljYXRpb24gSWRlbnRpZmllciAoSUVURuKAmXMgTWFyY2ggMjAx MyBtZWV0aW5nKS4gQXMgS2FtIG5vdGVzLCBJVFXigJlzIHdvcmsgb24gRy44NzQuMSBoYXMgZXZv bHZlZCB0byBpbmNsdWRlIHRoZSBPVUkuDQoNCkFzIGEgbmV0d29yayBvcGVyYXRvciwgSSBwcmVm ZXIgYXMgQWRyaWFuIHNheXMg4oCTIGxldOKAmXMgYXR0ZW1wdCB0byBtYXRjaCBkcmFmdCBHLjg3 NC4xIChpdCBkb2VzIGhhdmUgYWdyZWVtZW50KS4gU28gQWRyaWFu4oCZcyBvcHRpb24gMi4gV2hp bGUgdGhlIGNvbnRleHQgb2YgdGhpcyB3b3JrIGlzIHdpdGhpbiBhbiBvcGVyYXRvcuKAmXMgbmV0 d29yaywgdGhlIE9VSSB3aWxsIGhlbHAgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkuDQoNCkFk cmlhbiDigJMgZ29vZCBjYXRjaC0NCkRlYm9yYWgNCg0KRnJvbTogQ0NBTVAgW21haWx0bzpjY2Ft cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFtLCBIaW5nLUthbSAoS2FtKQ0KU2Vu dDogU3VuZGF5LCBKYW51YXJ5IDI1LCAyMDE1IDg6NTAgUE0NClRvOiBhZHJpYW5Ab2xkZG9nLmNv LnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPjsgJ0dlcnQgR3JhbW1lbCc7ICdHaW92YW5u aSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknDQpDYzogJ0Rvb2xhbiwgUGF1bCAoQ29yaWFudCAtIFVT L0lydmluZyknOyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBjY2FtcC1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZz47 IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPg0K U3ViamVjdDogUmU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4g ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUNCg0KSGkgQWRyaWFuLA0KDQpZZXMsIHdo aWxlIFExNC8xNSBhbHJlYWR5IHJlYWNoZWQgYWdyZWVtZW50IHRvIHVwZGF0ZSB0aGUgQXBwbGlj YXRpb24gSWRlbnRpZmllciBkZXNjcmlwdGlvbiwgdGhlIHVwZGF0ZSBoYXMgbm90IGJlZW4gZm9y bWFsbHkgYXBwcm92ZWQgYW5kIHB1Ymxpc2hlZCBieSBTRzE1IHlldC4gUTE0LzE1IG1heSBiZSBh YmxlIHRvIGNvbnNlbnQgdGhpcyB1cGRhdGUgYXMgYW4gQW1lbmRtZW50IHRvIEcuODc0LjEgYXQg dGhlIHVwY29taW5nIFNHMTUgbWVldGluZyBpbiBKdWx5IDIwMTUuDQoNClJlZ2FyZHMsDQpLYW0N Cg0KRnJvbTogQWRyaWFuIEZhcnJlbCBbbWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWtdDQpTZW50 OiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUgMTo1OSBQTQ0KVG86IExhbSwgSGluZy1LYW0gKEth bSk7ICdHZXJ0IEdyYW1tZWwnOyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJw0KQ2M6 ICdEb29sYW4sIFBhdWwgKENvcmlhbnQgLSBVUy9JcnZpbmcpJzsgY2NhbXBAaWV0Zi5vcmc8bWFp bHRvOmNjYW1wQGlldGYub3JnPjsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpj Y2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVu Y29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24t ZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIFZlbmRvci1T cGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5j b2RlDQoNClRoYW5rcyBmb3IgYmVpbmcgYXdha2UsIEthbS4NCg0KVXNlZnVsIGluZm8uDQoNCkdl cnQsIHRoZSBPVUkgcmVnaXN0cnkgaXMgYW4gSUVFRSByZWdpc3RyeSBhcyBLYW0gc2F5cy4gSUFO QSBoYXMgYSByZWdpc3RyeSBwYWdlIGZvciB0aGlzLCBidXQgaXQgcG9pbnRzIHRvIHRoZSBJRUVF IHBhZ2UuDQoNCkFzIEkgdW5kZXJzdGFuZCBLYW0sIDg3NC4xIGlzIG5vdCB5ZXQgdXBkYXRlZCBz byBpdCB3b3VsZCBiZSBwcmVtYXR1cmUgdG8gcG9pbnQgdG8gaXQsIGJ1dCBhbiBvcHRpb24gaXMg dG8gYXR0ZW1wdCB0byBtYXRjaCBpdCBub3cgYW5kIGZpeCBsYXRlciBpZiBuZWVkZWQuDQoNCkFk cmlhbg0KDQpGcm9tOiBMYW0sIEhpbmctS2FtIChLYW0pIFttYWlsdG86a2FtLmxhbUBhbGNhdGVs LWx1Y2VudC5jb21dDQpTZW50OiAyMyBKYW51YXJ5IDIwMTUgMTc6MTANClRvOiBHZXJ0IEdyYW1t ZWw7IGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+OyAnR2lv dmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJw0KQ2M6IERvb2xhbiwgUGF1bCAoQ29yaWFudCAt IFVTL0lydmluZyk7IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz47IGNjYW1w LWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86Y2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3Jn PjsgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPG1h aWx0bzpkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBp biBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZQ0KDQpIaSBHZXJ0LA0KDQpBIHZlbmRv ciBjYW4gcHVyY2hhc2UgYW4gT1VJIChPcmdhbml6YXRpb25hbGx5IFVuaXF1ZSBJZGVudGlmaWVy KSBmcm9tIHRoZSBJRUVFIFJlZ2lzdHJhdGlvbiBBdXRob3JpdHkuDQpPbmNlIGEgdmVuZG9yIGhh cyBpdHMgT1VJLCB0aGUgdmVuZG9yIGNhbiBtYW5hZ2UgaXRzIHZlbmRvci1zcGVjaWZpYyBhcHBs aWNhdGlvbiBpZGVudGlmaWVycyB1bmRlciBpdHMgb3duIE9VSS4NClNHMTUgZG9lc27igJl0IG5l ZWQgdG8gaG9zdCBhbnkgcmVnaXN0cnkgZm9yIHRoaXMgcHVycG9zZS4NCg0KUmVnYXJkcywNCkth bQ0KDQpGcm9tOiBHZXJ0IEdyYW1tZWwgW21haWx0bzpnZ3JhbW1lbEBqdW5pcGVyLm5ldF0NClNl bnQ6IEZyaWRheSwgSmFudWFyeSAyMywgMjAxNSAxMTo0OSBBTQ0KVG86IExhbSwgSGluZy1LYW0g KEthbSk7IGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+OyAn R2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJw0KQ2M6IERvb2xhbiwgUGF1bCAoQ29yaWFu dCAtIFVTL0lydmluZyk7IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz47IGNj YW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86Y2NhbXAtY2hhaXJzQHRvb2xzLmlldGYu b3JnPjsgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29k ZSBpbiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZQ0KDQpIaSBLYW0sDQoNCklzIFNH MTUgY29uc2lkZXJpbmcgdG8gaG9zdCBhIHJlZ2lzdHJ5IGZvciB0aGUgdmVuZG9yIHNwZWNpZmlj IGFwcGxpY2F0aW9uIGNvZGUgb3IgaXMgdGhlIElFVEYgcmVnaXN0cnkgc3VwcG9zZWQgdG8gYmUg dXNlZD8NCg0KVGhhbmtzDQoNCkdlcnQNCg0KRnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFtLCBIaW5nLUthbSAoS2FtKQ0KU2VudDogMjMg SmFudWFyeSAyMDE1IDE3OjAzDQpUbzogYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFu QG9sZGRvZy5jby51az47ICdHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknDQpDYzogRG9v bGFuLCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKTsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNj YW1wQGlldGYub3JnPjsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpjY2FtcC1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5h bGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2Rl LmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZp YyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlDQoN Cg0KRGVhciBhbGwsDQoNCg0KDQpGb3IgeW91ciBpbmZvcm1hdGlvbi4gSW4gdGhlIGxhc3QgU0cx NSBtZWV0aW5nLCBRMTQvMTUgYWdyZWVkIHRvIHVwZGF0ZSBHLjg3NC4xIHRvIGFtZW5kIHRoZSBz cGVjaWZpY2F0aW9uIG9mIEFwcGxpY2F0aW9uSWRlbnRpZmllciB3aXRoIHRoZSBmb2xsb3dpbmcg YWRkaXRpb25hbCB0ZXh0Og0KDQoNCg0KSWYgdGhlIEFwcGxpY2F0aW9uSWRlbnRpZmllclR5cGUg aXMgU1RBTkRBUkQsIHRoZSB2YWx1ZSBvZiBQcmludGFibGVTdHJpbmcgcmVwcmVzZW50cyBhIHN0 YW5kYXJkIGFwcGxpY2F0aW9uIGNvZGUgYXMgZGVmaW5lZCBpbiB0aGUgSVRVLVQgUmVjb21tZW5k YXRpb25zLiBJZiB0aGUgQXBwbGljYXRpb25JZGVudGlmaWVyVHlwZSBpcyBQUk9QUklFVEFSWSwg dGhlIGZpcnN0IHNpeCBjaGFyYWN0ZXJzIG9mIHRoZSBQcmludGFibGVTdHJpbmcgbXVzdCBjb250 YWluIHRoZSBIZXhhZGVjaW1hbCByZXByZXNlbnRhdGlvbiBvZiBhbiBPVUkgYXNzaWduZWQgdG8g dGhlIHZlbmRvciB3aG9zZSBpbXBsZW1lbnRhdGlvbiBnZW5lcmF0ZWQgdGhlIEFwcGxpY2F0aW9u IElkZW50aWZpZXI7IHRoZSByZW1haW5pbmcgb2N0ZXRzIG9mIHRoZSBQcmludGFibGVTdHJpbmcg YXJlIHVuc3BlY2lmaWVkLg0KDQoNCg0KUGF1bCBEb29sYW4gaGFkIGFuIEktRCAiaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvb2xhbi1wcm9wcmlldGFyeS1hYy0wMCIgdG8gdGhl IGxhc3QgSUVURiBtZWV0aW5nIHdpdGggdGhlIHNpbWlsYXIgcHJvcG9zYWwuDQoNCg0KDQpSZWdh cmRzLA0KDQpLYW0NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IEND QU1QIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBG YXJyZWwNCg0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDk6NDEgQU0NCg0KVG86ICdH aW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknDQoNCkNjOiBjY2FtcEBpZXRmLm9yZzxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+OyBjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmNj YW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5j b2RlLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1l bmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPg0KDQpTdWJqZWN0OiBbQ0NBTVBdIFZlbmRvci1TcGVj aWZpYyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2Rl DQoNCg0KDQpIaSwNCg0KDQoNCkkgYXBwcmVjaWF0ZSB0aGlzIGRpc2N1c3Npb24sIGJ1dCBJIGFt IG5vdCBzZWVpbmcgYSBzcGVjaWZpYyBjb25jbHVzaW9uIGZyb20gaXQuDQoNCg0KDQpUaGUgY3Vy cmVudCBJLUQgbWFrZXMgKElNSE8pIHRoZSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29k ZSB1bnVzYWJsZS4gSSBvZmZlcmVkIHRocmVlIG9wdGlvbnM6DQoNCg0KDQoxIFRoaXMgdmFsdWUg aXMgb25seSB0byBiZSB1c2VkIHdoZW4gaXQgaXMga25vd24gdGhhdCBhbGwgZGV2aWNlcw0KDQog ICBwYXJ0aWNpcGF0aW5nIGluIGEgbmV0d29yayBoYXZlIHRoZSBzYW1lIHVuZGVyc3RhbmRpbmcg b2YNCg0KICAgdGhlIGNvbnRlbnQgb2YgdGhlIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBD b2RlIGZpZWxkLg0KDQogICBIb3cgdGhpcyBrbm93bGVkZ2UgaXMgYWNoaWV2ZWQgaXMgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcw0KDQogICBkb2N1bWVudA0KDQoNCg0KMiBXaGVuIHRoaXMgdmFs dWUgaXMgc2V0LCB0aGUgZmlyc3QgMzIgKG9yIDQ4KSBiaXRzIG9mIHRoZSBWZW5kb3ItDQoNCiAg U3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBmaWVsZCBjb250YWluIGFuIEVudGVycHJpc2UgTnVt YmVyDQoNCiAgKG9yIE9VSSkgdGhhdCBkZWZpbmVzIHRoZSBjb250ZXh0IGluIHdoaWNoIHRoZSBy ZW1haW5kZXIgb2YNCg0KICB0aGF0IGZpZWxkIGlzIGludGVycHJldGVkLg0KDQoNCg0KMyBSZW1v dmUgdGhlIG9wdGlvbiB0byBpbmNsdWRlIGEgVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uDQoN CiAgIENvZGUgZmllbGQuDQoNCg0KDQpJZiB0aGUgV0cgY291bGQgcGxlYXNlIHBpY2sgb25lIG9m IHRoZXNlIGFuZCBoZWxwIFlvdW5nIHRvIHVwZGF0ZSB0aGUgZG9jdW1lbnQuDQoNCg0KDQpUaGFu a3MsDQoNCkFkcmlhbg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZy b206IEdpb3Zhbm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKSBbbWFpbHRvOmdpb21hcnRpQGNpc2Nv LmNvbV0NCg0KPiBTZW50OiAyMyBKYW51YXJ5IDIwMTUgMTM6NTANCg0KPiBUbzogYWRyaWFuQG9s ZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4NCg0KPiBDYzogTGVleW91bmc7 IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPjsN Cg0KPiBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBjY2FtcC1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCg0KPiBT dWJqZWN0OiBSZTogW0NDQU1QXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nv bi1lbmNvZGUNCg0KPg0KDQo+IE9uZSBhZGRpdGlvbmFsIGNvbW1lbnQgKGhvcGluZyBub3QgYWRk aXRpb25hbCBjb25mdXNpb24pLg0KDQo+DQoNCj4gVGhlIGlkZWEgYWJvdXQgT3B0aWNhbCBJbnRl cmZhY2UgQ2xhc3Mgd2FzIHRha2VuIGZyb20gU1JMRy4gR29vZCBvcg0KDQo+IGJhZCBpcyBhIHBs YWluIG51bWJlciBhbmQgeW91IGRvIHNpbXBsZSBvcGVyYXRpb25zIG9uIGl0Lg0KDQo+DQoNCj4g Q2hlZXJzDQoNCj4gRw0KDQo+DQoNCj4gT24gMjIgSmFuIDIwMTUsIGF0IDA5OjQyLCBHaW92YW5u aSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSkNCg0KPiA8Z2lvbWFydGlAY2lzY28uY29tPG1haWx0bzpn aW9tYXJ0aUBjaXNjby5jb20+Pg0KDQo+IHdyb3RlOg0KDQo+DQoNCj4gPiBIaSBBZHJpYW4sDQoN Cj4gPg0KDQo+ID4gT24gMjEgSmFuIDIwMTUsIGF0IDIyOjU1LCBBZHJpYW4gRmFycmVsIDxhZHJp YW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPj4gd3JvdGU6DQoNCj4g Pg0KDQo+ID4+IEhpLA0KDQo+ID4+DQoNCj4gPj4gV2VsbCwgeW91IHNlZW0gdG8gaGF2ZSBhIGhh bGYtd2F5IGhvdXNlLg0KDQo+ID4+DQoNCj4gPj4gWW91IGhhdmUgc3BlY2lmaWVkIHRoZSBleGlz dGVuY2Ugb2YgYSB0aGluZywgYnV0IG5vdCBob3cgdG8gcmVhZCBpdC4NCg0KPiA+Pg0KDQo+ID4+ IElmIHlvdSB3YW50ZWQgdG8gbWFrZSBhIHN0YXRlbWVudCB0aGF0IHRoaXMgb2JqZWN0IHdpbGwg b25seSBiZQ0KDQo+ID4+IHVzZWQgd2hlbg0KDQppdCBpcw0KDQo+ID4+IGtub3duIHRoYXQgYWxs IHN5c3RlbXMgaW4gYSBuZXR3b3JrIGNvbWUgZnJvbSB0aGUgc2FtZSB2ZW5kb3INCg0KPiA+PiBh bmQvb3IgaGF2ZQ0KDQo+IHRoZQ0KDQo+ID4+IHNhbWUgdW5kZXJzdGFuZGluZyBvZiB0aGUgZW5j b2RpbmcsIHRoYXQgbWlnaHQgYmUgT0sgKGFsdGhvdWdoIGhvdw0KDQo+ID4+IHlvdQ0KDQo+IHdv dWxkDQoNCj4gPj4gYXNjZXJ0YWluIHRoaXMgbWlnaHQgYWxzbyBuZWVkIHRvIGJlIGRlc2NyaWJl ZCkuDQoNCj4gPj4NCg0KPiA+DQoNCj4gPiBUaGUgc3RhdGVtZW50IGlzIHRvIGVuc3VyZSB0aGUg aW50ZXJmYWNlIGNvbXBhdGliaWxpdHkgd2l0aG91dA0KDQo+ID4gZW5jb2RpbmcgYWxsDQoNCnRo ZQ0KDQo+IHBvc3NpYmxlIGRldGFpbHMgYW5kIHBhcmFtZXRlciB0aGF0IGRlZmluZSBhbiBpbnRl cmZhY2UgKGUuZy4NCg0KPiBtb2R1bGF0aW9uDQoNCmZvcm1hdCwNCg0KPiBmb3J3YXJkIGVycm9y IGNvcnJlY3Rpb24gZXRjLikuIFRoaXMgd2FzIHRoZSBpbml0aWFsIHNvbHV0aW9uIGluIHRoZQ0K DQo+IGRyYWZ0DQoNCnRoZW4NCg0KPiByZXBsYWNlZCBieSB0aGUgaW50ZXJmYWNlIGNsYXNzIGNv bmNlcHQuICAgVGhlIFdTT04gKFJXQS1vbmx5KSBoYXMgdGhlDQoNCj4gcmVxdWlyZW1lbnQgaXMg dG8gbWFrZSBzdXJlIHR3byBpbnRlcmZhY2UgYXJlIGNvbXBhdGlibGUuIFRoaXMNCg0KPiByZXF1 aXJlbWVudCwgaW1obywgY2FuIGJlIHNhdGlzZnkgYnkgYSBzaW1wbGUgY29tcGFyaXNvbiB3aGlj aCBoYXMgYSBib29sZWFuIHJlc3VsdC4NCg0KPiA+DQoNCj4gPiBXZSBlbmQgdXAgdGhlbiBpbiAg dGhlIElUVSBhcHBsaWNhdGlvbiBjb2RlcyBmb3IgdGhlICJjZXJ0aWZpZWQiDQoNCj4gPiAod2Un bGwgdGhpcw0KDQppcyBteQ0KDQo+IHRlcm0gbm90IDEwMCUgc3VyZSBpcyB0aGUgYmVzdCBvbmUp IGNvbXBhdGliaWxpdHkgd2hlcmUgcHJvcGVyDQoNCj4gZW5jb2RpbmcgaXMgcHJvdmlkZWQuDQoN Cj4gPg0KDQo+ID4NCg0KPiA+PiBPciB5b3UgY291bGQgZW50aXJlbHkgcmVtb3ZlIHRoZSB2ZW5k b3Itc3BlY2lmaWMgb3B0aW9uLg0KDQo+ID4+DQoNCj4gPj4gT3IgeW91IGNvdWxkIHB1dCBpbiBh biBPVUkgLyBlbnRlcnByaXNlIG51bWJlciBmb2xsb3dlZCBieQ0KDQo+ID4+IHRyYW5zcGFyZW50 DQoNCj4gYnl0ZXMuDQoNCj4gPj4NCg0KPiA+DQoNCj4gPiBUbyBtZSBJJ20gcGVyZmVjdGx5IGZp bmUgd2l0aCB0aGUgc2Vjb25kIG9wdGlvbi4NCg0KPiA+DQoNCj4gPiBDaGVlcnMNCg0KPiA+IEcN Cg0KPiA+DQoNCj4gPg0KDQo+ID4+IEFkcmlhbg0KDQo+ID4+DQoNCj4gPj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQoNCj4gPj4+IEZyb206IEdpb3Zhbm5pIE1hcnRpbmVsbGkgKGdpb21h cnRpKSBbbWFpbHRvOmdpb21hcnRpQGNpc2NvLmNvbV0NCg0KPiA+Pj4gU2VudDogMjEgSmFudWFy eSAyMDE1IDIxOjIyDQoNCj4gPj4+IFRvOiBhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJp YW5Ab2xkZG9nLmNvLnVrPg0KDQo+ID4+PiBDYzogTGVleW91bmc7IGRyYWZ0LWlldGYtY2NhbXAt cndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jY2Ft cC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPjsNCg0KPiA+Pj4gY2NhbXBAaWV0 Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPjsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzpjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQoNCj4gPj4+IFN1YmplY3Q6IFJl OiBbQ0NBTVBdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZQ0K DQo+ID4+Pg0KDQo+ID4+PiBTcGVjaWZpY2FsbHkgdG8gdGhlIEludGVyZmFjZSBjbGFzcyBoZXJl IGJlbG93Lg0KDQo+ID4+Pg0KDQo+ID4+PiBJbiB0aGUgaW5pdGlhbCBkcmFmdCBtZXJnZWQgdG8g dGhpcyBvbmUgdGhlcmUgd2FzIHRoZSB1c2FnZSBvZiBPVUkNCg0KPiA+Pj4gaG93ZXZlcg0KDQoo SQ0KDQo+ID4+PiBndWVzcyBhZnRlciBjaGF0dGluZyB3aXRoIExvdSkgd2UgZGVjaWRlZCB0byBy ZW1vdmUgYW55IGVuY29kaW5nDQoNCj4gPj4+IHdoZW4gdGhlIEludGVyZmFjZSBjbGFzcyBpcyBu b3Qgc3RhbmRhcmQuDQoNCj4gPj4+IEluIHRlcm0gb2Ygc2VtYW50aWMgdGhlIHByb3Rjb2wgZG9l cyBub3QgbmVlZCB0byBkZWNvZGUgdGhlDQoNCj4gPj4+IEludGVyZmFjZQ0KDQpjbGFzcw0KDQo+ ID4+IHNpbmNlDQoNCj4gPj4+IGl0IG9ubHkgYXNzZXNzIHRoZSBpbnRlcmZhY2UgY29tcGF0aWJp bGl0eSBpZiB0d28gaW50ZXJmYWNlcyBoYXMgYQ0KDQo+ID4+PiBjbGFzcw0KDQp2YWx1ZQ0KDQo+ ID4+IHRoYXQNCg0KPiA+Pj4gbWF0Y2ggdHdvIGludGVyZmFjZXMgY2FubiBiZSBjb25uZWN0ZWQu DQoNCj4gPj4+DQoNCj4gPj4+IEhhdmluZyBzYXlpbmcgdGhhdCBJIGRvbid0IGhhdmUgc3Ryb25n IG9waW5pb24gaW4gYWRkaW5nIHRoZSBPVUkNCg0KPiA+Pj4gb3INCg0KbGVhdmluZw0KDQo+ID4+ IHJvb20NCg0KPiA+Pj4gZm9yIG1heWJlIGZ1dHVyZSBwdWJsaWMgaW50ZXJmYWNlcyBkYXRhYmFz ZS4gRm9yIHN1cmUgdGhlcmUncyBhDQoNCj4gPj4+IG5lZWQgdG8NCg0KbGVhdmUNCg0KPiA+Pj4g cm9vbSBmb3Igc3BlY2lmaWMgY29tcGF0aWJpbGl0eSBhc3Nlc21lbnQgc2luY2UgdGhlcmUgb3B0 aWNhbA0KDQo+ID4+PiBtdWx0aXZlbmRvciBjb21wYXRpYmlsaXR5IGhhcyBiZWVuIGFscmVhZHkg ZGVtb25zdHJhdGVkLg0KDQo+ID4+Pg0KDQo+ID4+PiBob3BlIHRoaXMgaGVscCAuDQoNCj4gPj4+ DQoNCj4gPj4+IENoZWVycw0KDQo+ID4+PiBHDQoNCj4gPj4+DQoNCj4gPj4+DQoNCj4gPj4+IE9u IDIxIEphbiAyMDE1LCBhdCAyMTo1NywgQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51 azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+IHdyb3RlOg0KDQo+ID4+Pg0KDQo+ID4+Pj4+ Pg0KDQo+ID4+Pj4+PiBTZWN0aW9uIDQuMQ0KDQo+ID4+Pj4+PiBIb3cgZG8gSSBpbnRlcnByZXQg YSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZT8gSXMgdGhlcmUNCg0KPiA+Pj4+Pj4g YW4gT1VJIEknbSBtaXNzaW5nPw0KDQo+ID4+Pj4+DQoNCj4gPj4+Pj4gW1lPVU5HXSBOb3Qgc3Vy ZSBpZiBJIHVuZGVyc3Rvb2QgdGhpcyBxdWVzdGlvbi4gV2hhdCBpcyAiT1VJIj8NCg0KPiA+Pj4+ DQoNCj4gPj4+PiBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL09yZ2FuaXphdGlvbmFsbHlf dW5pcXVlX2lkZW50aWZpZXINCg0KPiA+Pj4+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvaWVlZS04MDItbnVtYmVycy9pZWVlLTgwMi0NCg0KPiA+Pj4gbnVtYmVycy54aHRtbCNpZWVl LTgwMg0KDQo+ID4+Pj4gLW51bWJlcnMtMg0KDQo+ID4+Pj4NCg0KPiA+Pj4+IE9yIHBlcmhhcHMg YW4gRW50ZXJwcmlzZSBOdW1iZXINCg0KPiA+Pj4+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMvZW50ZXJwcmlzZS1udW1iZXJzL2VudGVycHJpc2UtDQoNCj4gbnVtYmVycw0KDQo+ID4+ Pj4NCg0KPiA+Pj4+IFRoZSBxdWVzdGlvbiBpczoNCg0KPiA+Pj4+DQoNCj4gPj4+PiBZb3UgaGF2 ZSBzZWN0aW9ucyA0LjEuMSB0aHJvdWdoIDQuMS40IHRvIHRlbGwgbWUgaG93IHRvIGludGVycHJl dA0KDQo+ID4+Pj4gdGhlDQoNCj4gPj4gT3B0aWNhbA0KDQo+ID4+Pj4gSW50ZXJmYWNlIENsYXNz IGZpZWxkIHdoZW4gaXQgY29udGFpbnMgYW4gSVRVLVQgQXBwbGljYXRpb24gTWFwcGluZy4NCg0K PiA+Pj4+IFdoZW4gSSByZWNlaXZlZCBzPTAgYW5kIE9JPTEgaXQgbWVhbnMgdGhhdCB0aGUgT3B0 aWNhbCBJbnRlcmZhY2UNCg0KPiA+Pj4+IENsYXNzDQoNCj4gPj4gY29udGFpbnMNCg0KPiA+Pj4+ IGEgIlZlbmRvciBTcGVjaWZpYyBPcHRpY2FsIEludGVyZmFjZSBDbGFzcyIuDQoNCj4gPj4+PiBI b3cgZG8gSSBpbnRlcnByZXQgdGhhdCBPcHRpY2FsIEludGVyZmFjZSBDbGFzcz8NCg0KPiA+Pj4+ IFdoaWNoIHZlbmRvciBkb2VzIGl0IGFwcGx5IHRvPw0KDQo+ID4+Pj4gSXMgdGhlcmUgc29tZSBp bmZvcm1hdGlvbiBlbHNld2hlcmUgdGhhdCBnaXZlcyBtZSBhIGNsdWUgYXMgdG8NCg0KPiA+Pj4+ IHdoaWNoDQoNCj4gdmVuZG9yDQoNCj4gPj4+IGhhcw0KDQo+ID4+Pj4gZW5jb2RlZCB0aGUgaW5m b3JtYXRpb24/DQoNCj4gPj4+PiBPciBpcyB0aGUgaW5mb3JtYXRpb24gc3VwcG9zZWQgdG8gYmUg ZW5jb2RlZCBpbiB0aGUgT3B0aWNhbA0KDQo+ID4+Pj4gSW50ZXJmYWNlDQoNCkNsYXNzLA0KDQo+ ID4+Pj4gcGVyaGFwcyBhcyB0aGUgZmlyc3QgNDggYml0cz8NCg0KPiA+Pj4+IE9yIGFtIEkgc3Vw cG9zZWQgdG8ga25vdyBieSBjb250ZXh0Pw0KDQo+ID4+DQoNCj4gPg0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ0NBTVAgbWFpbGluZyBs aXN0DQoNCkNDQU1QQGlldGYub3JnPG1haWx0bzpDQ0FNUEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K --_000_6D32668528F93D449A073F45707153D82C533567US70UWXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjVwdDsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRl YXIgYWxsLDxicj4NCjxicj4NCkknbSBnZXR0aW5nIGEgYml0IGNvbmZ1c2VkIC0gSSB0aG91Z2h0 IHRoYXQgdGhlcmUgd2FzIHNlbnRpbWVudCB0byBtYXRjaCB0aGUgYXBwcm9hY2ggaW4gRy44NzQu MTsgd2Fzbid0IHRoYXQgb3B0aW9uIDI/PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCkV2 ZTwvZm9udD48YnI+DQombmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9u dCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGI+RnJvbTwvYj46IExlZXlvdW5nIFttYWlsdG86bGVl eW91bmdAaHVhd2VpLmNvbV0NCjxicj4NCjxiPlNlbnQ8L2I+OiBXZWRuZXNkYXksIEphbnVhcnkg MjgsIDIwMTUgMDM6MDUgUE08YnI+DQo8Yj5UbzwvYj46IEJSVU5HQVJELCBERUJPUkFIIEEgJmx0 O2RiMzU0NkBhdHQuY29tJmd0OzsgTGFtLCBIaW5nLUthbSAoS2FtKTsgYWRyaWFuQG9sZGRvZy5j by51ayAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDs7ICdHZXJ0IEdyYW1tZWwnICZsdDtnZ3Jh bW1lbEBqdW5pcGVyLm5ldCZndDs7ICdHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknICZs dDtnaW9tYXJ0aUBjaXNjby5jb20mZ3Q7DQo8YnI+DQo8Yj5DYzwvYj46ICdEb29sYW4sIFBhdWwg KENvcmlhbnQgLSBVUy9JcnZpbmcpJyAmbHQ7cGF1bC5kb29sYW5AY29yaWFudC5jb20mZ3Q7OyBj Y2FtcEBpZXRmLm9yZyAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7OyBjY2FtcC1jaGFpcnNAdG9vbHMu aWV0Zi5vcmcgJmx0O2NjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYt Y2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1j Y2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnJmd0Ow0KPGJyPg0KPGI+U3Vi amVjdDwvYj46IFJlOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGlu IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlDQo8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJy Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIERlYm9yYWgsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGggd2hhdCB5b3Ugc2FpZC4gVGhhdCB3 YXMgbXkgcG9pbnQuIE9wdGlvbiAxIGlzIG15IHByZWZlcmVuY2UgYW5kIHRoZSBXRyBoYXMgYWdy ZWVkIG9uIHRoYXQgLEkgdGhpbmsuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WW91bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCUlVOR0FSRCwgREVCT1JBSCBB IFttYWlsdG86ZGIzNTQ2QGF0dC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBK YW51YXJ5IDI4LCAyMDE1IDE6NTYgUE08YnI+DQo8Yj5Ubzo8L2I+IExlZXlvdW5nOyBMYW0sIEhp bmctS2FtIChLYW0pOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyAnR2VydCBHcmFtbWVsJzsgJ0dpb3Zh bm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKSc8YnI+DQo8Yj5DYzo8L2I+ICdEb29sYW4sIFBhdWwg KENvcmlhbnQgLSBVUy9JcnZpbmcpJzsgY2NhbXBAaWV0Zi5vcmc7IGNjYW1wLWNoYWlyc0B0b29s cy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBB cHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkhpIFlvdW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+QXJlIHlvdSB2b3RpbmcgZm9yIG9wdGlvbiAzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+TXkgdGhvdWdodHMgd2VyZSBpZiAoYmlnIElGKSB3ZSBhcmUgZ29pbmcgdG8g YWxsb3cgcHJvcHJpZXRhcnkgQXBwbGljYXRpb24gSWRlbnRpZmllcnMgKHdoaWNoIFNHMTUgaGFz IGFncmVlZCkgdGhlbiBiZXN0IHdvdWxkIGJlIGlmIHdlIGNhbiBhdCBsZWFzdCBoYXZlIHNvbWUg d2F5IHRvIGlkZW50aWZ5IChiZXR0ZXIgdGhhbiBhbiB1bmRlZmluZWQgc3RyaW5nKS4NCiBBcyB5 b3Ugc2F5LCBpdCBzdGlsbCBkb2VzIG5vdCBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0eSB1bmxl c3MgaXQgaXMgdGhlIHNhbWUgdmVuZG9yIChob3BlZnVsbHkgKS4gSWYgdHdvIGRpZmZlcmVudCB2 ZW5kb3JzIChlLmcuIGJsYWNrIGxpbmspLCB0aGVuIGl0IHdvdWxkIGJlIGZvciB0aGUgdmVuZG9y cyAoYW5kIG9wZXJhdG9yKSB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eSBpZiBzdXBwb3J0aW5n IG5vbi1zdGFuZGFyZCBBSXMuIEFuZCBhcw0KIHdlIGtub3csIGl04oCZcyBub3QganVzdCB0aGUg QUkgdGhhdCBpcyBuZWVkZWQgdG8gZGV0ZXJtaW5lIGlmIGl0IHdpbGwgd29yayBwcm9wZXJseS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+RGVib3JhaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMZWV5b3VuZyBbbWFpbHRvOmxl ZXlvdW5nQGh1YXdlaS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5 IDI4LCAyMDE1IDI6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IEJSVU5HQVJELCBERUJPUkFIIEE7IExh bSwgSGluZy1LYW0gKEthbSk7IGFkcmlhbkBvbGRkb2cuY28udWs7ICdHZXJ0IEdyYW1tZWwnOyAn R2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJzxicj4NCjxiPkNjOjwvYj4gJ0Rvb2xhbiwg UGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyknOyBjY2FtcEBpZXRmLm9yZzsgY2NhbXAtY2hhaXJz QHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9v bHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNp ZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SGkgRGVib3JhaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIG9wZXJhdG9y4oCZcyBwZXJzcGVjdGl2 ZS4mbmJzcDsgSSBhbSB3b25kZXJpbmcgaG93IHRoZSBPVUkgd291bGQgcmVhbGx5IGhlbHAgZm9y IGludGVyb3BlcmFiaWxpdHkgb3RoZXIgdGhhbiBpZGVudGlmeWluZyB0aGUgc3BlY2lmaWMgdmVu ZG9ycyB0aGF0IGFyZSB1c2luZyB0aGVpciBwcm9wcmlldGFyeSBjb2RlLiAmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNheSB2ZW5kb3IgQSB1c2VzIEZFQyB0eXBl IEEgd2hpbGUgdmVuZG9yIEIgdXNlZCBGRUMgdHlwZSBCLCBhbmQgYm90aCBvZiB0aGVtIGFyZSBw cm9wcmlldGFyeSBGRUNzLiBJIGJlbGlldmUgdGhlIE9VSSB3aWxsIGhlbHAgdGhlIG9wZXJhdG9y IGlkZW50aWZ5IHRoaXMgZmFjdCBhbmQgY29uY2x1ZGUgdGhlIHN5c3RlbXMgYXJlIG5vdCBjb21w YXRpYmxlLiBCdXQNCiB3b3VsZCB0aGlzIHJlYWxseSBoZWxwIG9wZXJhdG9ycyB0b3dhcmQgaW50 ZXJvcGVyYWJpbGl0eT8gSSBiZWxpZXZlIGEgYmV0dGVyIHdheSBmb3Igb3BlcmF0b3JzIHRvIGF0 dGFpbiBpbnRlcm9wZXJhYmlsaXR5IGlzIHRvIGZvcmNlIHZlbmRvcnMgdXNlIHN0YW5kYXJkIEZF Q3MgYW5kIGhhdmUgdGhlbSBhZ3JlZSBvbiB0aGUgc2FtZSB0eXBlIG9mIEZFQ3Mgd2l0aGluIHRo ZSBzdGFuZGFyZCBGRUNzLiBNeSBwb2ludCBpcyBob3cgdmVuZG9yIHNwZWNpZmljDQogY29kZSB3 b3VsZCBiZSByZWFsbHkgaGVscGZ1bCBldmVuIGlmIHdlIGVtcGxveSB0aGUgT1VJIGZpZWxkLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+WW91bmcgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gQ0NBTVAgWzxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkJSVU5HQVJELCBERUJPUkFIIEE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51 YXJ5IDI4LCAyMDE1IDExOjQ2IEFNPGJyPg0KPGI+VG86PC9iPiBMYW0sIEhpbmctS2FtIChLYW0p OyA8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51 azwvYT47ICdHZXJ0IEdyYW1tZWwnOyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJzxi cj4NCjxiPkNjOjwvYj4gJ0Rvb2xhbiwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyknOyA8YSBo cmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPg0KY2NhbXBAaWV0Zi5vcmc8L2E+OyA8YSBocmVm PSJtYWlsdG86Y2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5jY2FtcC1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24t ZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNv ZGUuYWxsQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NDQU1Q XSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1wLXJ3 YS13c29uLWVuY29kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBBbGwsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5BcyBMb3Ugbm90ZWQsIEFkcmlhbuKAmXMgb3B0aW9uIDEgd2Fz IHRoZSBpbnRlbnRpb24gYXMgdGhpcyB3YXMgZGlzY3Vzc2VkIHdoZW4gRzg3MiB3YXMgYmVpbmcg cmV2aXNlZCB0byBpbnRyb2R1Y2UgQXBwbGljYXRpb24gSWRlbnRpZmllciAoSUVURuKAmXMgTWFy Y2ggMjAxMyBtZWV0aW5nKS4gQXMgS2FtIG5vdGVzLCBJVFXigJlzIHdvcmsgb24gRy44NzQuMSBo YXMgZXZvbHZlZA0KIHRvIGluY2x1ZGUgdGhlIE9VSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkFzIGEgbmV0d29yayBvcGVyYXRvciwgSSBwcmVmZXIgYXMgQWRyaWFuIHNh eXMg4oCTIGxldOKAmXMgYXR0ZW1wdCB0byBtYXRjaCBkcmFmdCBHLjg3NC4xIChpdCBkb2VzIGhh dmUgYWdyZWVtZW50KS4gU28gQWRyaWFu4oCZcyBvcHRpb24gMi4gV2hpbGUgdGhlIGNvbnRleHQg b2YgdGhpcyB3b3JrIGlzIHdpdGhpbiBhbiBvcGVyYXRvcuKAmXMgbmV0d29yaywgdGhlIE9VSSB3 aWxsDQogaGVscCB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkFkcmlhbiDigJMgZ29vZCBjYXRjaC08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ RGVib3JhaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IENDQU1QIFs8YSBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5MYW0sIEhpbmctS2FtIChLYW0pPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSmFudWFyeSAy NSwgMjAxNSA4OjUwIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9s ZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT47ICdHZXJ0IEdyYW1tZWwnOyAnR2lv dmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJzxicj4NCjxiPkNjOjwvYj4gJ0Rvb2xhbiwgUGF1 bCAoQ29yaWFudCAtIFVTL0lydmluZyknOyA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmci Pg0KY2NhbXBAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86Y2NhbXAtY2hhaXJzQHRvb2xz LmlldGYub3JnIj5jY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyI+ ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRp b24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5IaSBBZHJpYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5ZZXMs IHdoaWxlIFExNC8xNSBhbHJlYWR5IHJlYWNoZWQgYWdyZWVtZW50IHRvIHVwZGF0ZSB0aGUgQXBw bGljYXRpb24gSWRlbnRpZmllciBkZXNjcmlwdGlvbiwgdGhlIHVwZGF0ZSBoYXMgbm90IGJlZW4g Zm9ybWFsbHkgYXBwcm92ZWQgYW5kIHB1Ymxpc2hlZCBieSBTRzE1IHlldC4gUTE0LzE1IG1heSBi ZSBhYmxlIHRvIGNvbnNlbnQgdGhpcyB1cGRhdGUgYXMNCiBhbiBBbWVuZG1lbnQgdG8gRy44NzQu MSBhdCB0aGUgdXBjb21pbmcgU0cxNSBtZWV0aW5nIGluIEp1bHkgMjAxNS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkthbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEFkcmlhbiBGYXJyZWwgWzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5tYWls dG86YWRyaWFuQG9sZGRvZy5jby51azwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBK YW51YXJ5IDIzLCAyMDE1IDE6NTkgUE08YnI+DQo8Yj5Ubzo8L2I+IExhbSwgSGluZy1LYW0gKEth bSk7ICdHZXJ0IEdyYW1tZWwnOyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJzxicj4N CjxiPkNjOjwvYj4gJ0Rvb2xhbiwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyknOyA8YSBocmVm PSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPg0KY2NhbXBAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86Y2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5jY2FtcC1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5j b2RlLmFsbEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUu YWxsQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NDQU1QXSBW ZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13 c29uLWVuY29kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciBiZWlu ZyBhd2FrZSwgS2FtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5Vc2VmdWwgaW5mby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R2VydCwgdGhlIE9VSSByZWdp c3RyeSBpcyBhbiBJRUVFIHJlZ2lzdHJ5IGFzIEthbSBzYXlzLiBJQU5BIGhhcyBhIHJlZ2lzdHJ5 IHBhZ2UgZm9yIHRoaXMsIGJ1dCBpdCBwb2ludHMgdG8gdGhlIElFRUUgcGFnZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMg SSB1bmRlcnN0YW5kIEthbSwgODc0LjEgaXMgbm90IHlldCB1cGRhdGVkIHNvIGl0IHdvdWxkIGJl IHByZW1hdHVyZSB0byBwb2ludCB0byBpdCwgYnV0IGFuIG9wdGlvbiBpcyB0byBhdHRlbXB0IHRv IG1hdGNoIGl0IG5vdyBhbmQgZml4IGxhdGVyIGlmIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QWRyaWFuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMYW0sIEhpbmctS2FtIChLYW0p IFs8YSBocmVmPSJtYWlsdG86a2FtLmxhbUBhbGNhdGVsLWx1Y2VudC5jb20iPm1haWx0bzprYW0u bGFtQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjMgSmFudWFy eSAyMDE1IDE3OjEwPGJyPg0KPGI+VG86PC9iPiBHZXJ0IEdyYW1tZWw7IDxhIGhyZWY9Im1haWx0 bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjsgJ0dpb3Zhbm5p IE1hcnRpbmVsbGkgKGdpb21hcnRpKSc8YnI+DQo8Yj5DYzo8L2I+IERvb2xhbiwgUGF1bCAoQ29y aWFudCAtIFVTL0lydmluZyk7IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBA aWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9y ZyI+Y2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1p ZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2Rl IGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgR2VydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkEgdmVuZG9yIGNhbiBwdXJjaGFzZSBhbiBPVUkgKE9yZ2FuaXphdGlvbmFs bHkgVW5pcXVlIElkZW50aWZpZXIpIGZyb20gdGhlIElFRUUgUmVnaXN0cmF0aW9uIEF1dGhvcml0 eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+T25jZSBhIHZlbmRvciBoYXMgaXRzIE9VSSwgdGhlIHZlbmRvciBj YW4gbWFuYWdlIGl0cyB2ZW5kb3Itc3BlY2lmaWMgYXBwbGljYXRpb24gaWRlbnRpZmllcnMgdW5k ZXIgaXRzIG93biBPVUkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U0cxNSBkb2VzbuKAmXQgbmVlZCB0byBo b3N0IGFueSByZWdpc3RyeSBmb3IgdGhpcyBwdXJwb3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+S2FtPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gR2VydCBHcmFt bWVsIFs8YSBocmVmPSJtYWlsdG86Z2dyYW1tZWxAanVuaXBlci5uZXQiPm1haWx0bzpnZ3JhbW1l bEBqdW5pcGVyLm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDIz LCAyMDE1IDExOjQ5IEFNPGJyPg0KPGI+VG86PC9iPiBMYW0sIEhpbmctS2FtIChLYW0pOyA8YSBo cmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT47 ICdHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknPGJyPg0KPGI+Q2M6PC9iPiBEb29sYW4s IFBhdWwgKENvcmlhbnQgLSBVUy9JcnZpbmcpOyA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5v cmciPmNjYW1wQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNAdG9v bHMuaWV0Zi5vcmciPmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmci Pg0KZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGlj YXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5IaSBLYW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JcyBT RzE1IGNvbnNpZGVyaW5nIHRvIGhvc3QgYSByZWdpc3RyeSBmb3IgdGhlIHZlbmRvciBzcGVjaWZp YyBhcHBsaWNhdGlvbiBjb2RlIG9yIGlzIHRoZSBJRVRGIHJlZ2lzdHJ5IHN1cHBvc2VkIHRvIGJl IHVzZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkdlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDQ0FNUCBbPGEgaHJlZj0i bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TGFtLCBIaW5nLUthbSAoS2FtKTxicj4NCjxi PlNlbnQ6PC9iPiAyMyBKYW51YXJ5IDIwMTUgMTc6MDM8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjsgJ0dp b3Zhbm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKSc8YnI+DQo8Yj5DYzo8L2I+IERvb2xhbiwgUGF1 bCAoQ29yaWFudCAtIFVTL0lydmluZyk7IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+ Y2NhbXBAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5p ZXRmLm9yZyI+Y2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyI+DQpk cmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlv biBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGVhciBhbGwsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkZvciB5b3VyIGluZm9ybWF0aW9uLiBJbiB0aGUgbGFzdCBTRzE1 IG1lZXRpbmcsIFExNC8xNSBhZ3JlZWQgdG8gdXBkYXRlIEcuODc0LjEgdG8gYW1lbmQgdGhlIHNw ZWNpZmljYXRpb24gb2YgQXBwbGljYXRpb25JZGVudGlmaWVyIHdpdGggdGhlIGZvbGxvd2luZyBh ZGRpdGlvbmFsIHRleHQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5JZiB0aGUgQXBwbGljYXRpb25JZGVudGlmaWVyVHlwZSBpcyBTVEFOREFS RCwgdGhlIHZhbHVlIG9mIFByaW50YWJsZVN0cmluZyByZXByZXNlbnRzIGEgc3RhbmRhcmQgYXBw bGljYXRpb24gY29kZSBhcyBkZWZpbmVkIGluIHRoZSBJVFUtVCBSZWNvbW1lbmRhdGlvbnMuIElm IHRoZSBBcHBsaWNhdGlvbklkZW50aWZpZXJUeXBlIGlzIFBST1BSSUVUQVJZLCB0aGUNCiBmaXJz dCBzaXggY2hhcmFjdGVycyBvZiB0aGUgUHJpbnRhYmxlU3RyaW5nIG11c3QgY29udGFpbiB0aGUg SGV4YWRlY2ltYWwgcmVwcmVzZW50YXRpb24gb2YgYW4gT1VJIGFzc2lnbmVkIHRvIHRoZSB2ZW5k b3Igd2hvc2UgaW1wbGVtZW50YXRpb24gZ2VuZXJhdGVkIHRoZSBBcHBsaWNhdGlvbiBJZGVudGlm aWVyOyB0aGUgcmVtYWluaW5nIG9jdGV0cyBvZiB0aGUgUHJpbnRhYmxlU3RyaW5nIGFyZSB1bnNw ZWNpZmllZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGF1bCBEb29sYW4gaGFkIGFu IEktRCAmcXVvdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9v bGFuLXByb3ByaWV0YXJ5LWFjLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZG9vbGFuLXByb3ByaWV0YXJ5LWFjLTAwPC9hPiZxdW90OyB0byB0aGUgbGFzdCBJRVRGIG1lZXRp bmcgd2l0aCB0aGUgc2ltaWxhciBwcm9wb3NhbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkthbTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RnJvbTogQ0NBTVAgWzxhIGhy ZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TZW50OiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUgOTo0 MSBBTTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VG86ICdHaW92YW5u aSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5DYzogPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9y ZzwvYT47IDxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPg0KY2Nh bXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYt Y2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWNj YW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdWJqZWN0OiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZp YyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5JIGFwcHJlY2lhdGUgdGhpcyBkaXNjdXNzaW9uLCBidXQgSSBhbSBub3Qgc2VlaW5nIGEg c3BlY2lmaWMgY29uY2x1c2lvbiBmcm9tIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5UaGUgY3VycmVudCBJLUQgbWFrZXMgKElNSE8pIHRoZSBWZW5kb3ItU3BlY2lmaWMgQXBwbGlj YXRpb24gQ29kZSB1bnVzYWJsZS4gSSBvZmZlcmVkIHRocmVlIG9wdGlvbnM6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjEgVGhpcyB2YWx1ZSBpcyBvbmx5IHRvIGJlIHVzZWQgd2hlbiBp dCBpcyBrbm93biB0aGF0IGFsbCBkZXZpY2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcGFydGljaXBhdGluZyBpbiBhIG5ldHdvcmsgaGF2ZSB0 aGUgc2FtZSB1bmRlcnN0YW5kaW5nIG9mDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBjb250ZW50IG9mIHRoZSBWZW5kb3ItU3Bl Y2lmaWMgQXBwbGljYXRpb24gQ29kZSBmaWVsZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBIb3cgdGhpcyBrbm93bGVkZ2UgaXMgYWNoaWV2ZWQg aXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjIgV2hlbiB0aGlzIHZhbHVlIGlzIHNldCwgdGhlIGZpcnN0IDMyIChvciA0OCkgYml0 cyBvZiB0aGUgVmVuZG9yLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7IFNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgZmllbGQgY29udGFpbiBhbiBFbnRlcnBy aXNlIE51bWJlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 IChvciBPVUkpIHRoYXQgZGVmaW5lcyB0aGUgY29udGV4dCBpbiB3aGljaCB0aGUgcmVtYWluZGVy IG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgdGhhdCBm aWVsZCBpcyBpbnRlcnByZXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MyBSZW1v dmUgdGhlIG9wdGlvbiB0byBpbmNsdWRlIGEgVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQ29kZSBm aWVsZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SWYgdGhlIFdHIGNvdWxkIHBsZWFz ZSBwaWNrIG9uZSBvZiB0aGVzZSBhbmQgaGVscCBZb3VuZyB0byB1cGRhdGUgdGhlIGRvY3VtZW50 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BZHJpYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGcm9tOiBHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0 aSkgWzxhIGhyZWY9Im1haWx0bzpnaW9tYXJ0aUBjaXNjby5jb20iPm1haWx0bzpnaW9tYXJ0aUBj aXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBTZW50OiAyMyBKYW51YXJ5IDIwMTUgMTM6NTA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVr Ij5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBDYzogTGVleW91bmc7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWNj YW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi1jY2Ft cC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPC9hPjs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPGEgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYu b3JnIj5jY2FtcEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNAdG9v bHMuaWV0Zi5vcmciPg0KY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTdWJqZWN0OiBSZTogW0NDQU1QXSBB RCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE9uZSBhZGRpdGlvbmFsIGNvbW1lbnQgKGhvcGluZyBub3Qg YWRkaXRpb25hbCBjb25mdXNpb24pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg VGhlIGlkZWEgYWJvdXQgT3B0aWNhbCBJbnRlcmZhY2UgQ2xhc3Mgd2FzIHRha2VuIGZyb20gU1JM Ry4gR29vZCBvcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGJhZCBpcyBhIHBsYWluIG51bWJlciBhbmQgeW91IGRvIHNpbXBsZSBvcGVyYXRpb25zIG9uIGl0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2hlZXJzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IE9uIDIyIEphbiAyMDE1LCBhdCAwOTo0MiwgR2lvdmFubmkgTWFydGluZWxsaSAo Z2lvbWFydGkpDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpnaW9tYXJ0aUBjaXNjby5jb20iPmdpb21hcnRpQGNpc2NvLmNv bTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBIaSBBZHJpYW4sPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBPbiAyMSBKYW4gMjAxNSwg YXQgMjI6NTUsIEFkcmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9n LmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgSGksPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IFdlbGwsIHlvdSBzZWVtIHRvIGhhdmUgYSBo YWxmLXdheSBob3VzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsgWW91IGhhdmUgc3BlY2lmaWVkIHRoZSBleGlzdGVuY2Ugb2YgYSB0aGluZywgYnV0 IG5vdCBob3cgdG8gcmVhZCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsgSWYgeW91IHdhbnRlZCB0byBtYWtlIGEgc3RhdGVtZW50IHRoYXQgdGhp cyBvYmplY3Qgd2lsbCBvbmx5IGJlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsgdXNlZCB3aGVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5pdCBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyBrbm93biB0aGF0IGFsbCBzeXN0ZW1zIGluIGEgbmV0d29yayBjb21l IGZyb20gdGhlIHNhbWUgdmVuZG9yDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsgYW5kL29yIGhhdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHNhbWUgdW5kZXJzdGFuZGluZyBvZiB0aGUgZW5jb2Rpbmcs IHRoYXQgbWlnaHQgYmUgT0sgKGFsdGhvdWdoIGhvdw0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHlvdTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3b3VsZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBhc2NlcnRhaW4gdGhpcyBtaWdodCBhbHNvIG5lZWQg dG8gYmUgZGVzY3JpYmVkKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 IFRoZSBzdGF0ZW1lbnQgaXMgdG8gZW5zdXJlIHRoZSBpbnRlcmZhY2UgY29tcGF0aWJpbGl0eSB3 aXRob3V0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyBlbmNvZGluZyBhbGw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRo ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBwb3NzaWJsZSBk ZXRhaWxzIGFuZCBwYXJhbWV0ZXIgdGhhdCBkZWZpbmUgYW4gaW50ZXJmYWNlIChlLmcuDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbW9kdWxhdGlvbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Zm9ybWF0LDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBmb3J3YXJkIGVycm9yIGNvcnJlY3Rpb24g ZXRjLikuIFRoaXMgd2FzIHRoZSBpbml0aWFsIHNvbHV0aW9uIGluIHRoZQ0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRyYWZ0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij50aGVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IHJlcGxhY2VkIGJ5IHRoZSBpbnRlcmZhY2UgY2xhc3MgY29uY2VwdC4m bmJzcDsmbmJzcDsgVGhlIFdTT04gKFJXQS1vbmx5KSBoYXMgdGhlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJlcXVpcmVtZW50IGlzIHRvIG1ha2Ugc3VyZSB0 d28gaW50ZXJmYWNlIGFyZSBjb21wYXRpYmxlLiBUaGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVxdWlyZW1lbnQsIGltaG8sIGNhbiBiZSBzYXRpc2Z5 IGJ5IGEgc2ltcGxlIGNvbXBhcmlzb24gd2hpY2ggaGFzIGEgYm9vbGVhbiByZXN1bHQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBXZSBlbmQgdXAgdGhlbiBpbiZu YnNwOyB0aGUgSVRVIGFwcGxpY2F0aW9uIGNvZGVzIGZvciB0aGUgJnF1b3Q7Y2VydGlmaWVkJnF1 b3Q7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAo d2UnbGwgdGhpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aXMgbXk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGVybSBub3QgMTAw JSBzdXJlIGlzIHRoZSBiZXN0IG9uZSkgY29tcGF0aWJpbGl0eSB3aGVyZSBwcm9wZXINCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBlbmNvZGluZyBpcyBwcm92 aWRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IE9yIHlvdSBjb3Vs ZCBlbnRpcmVseSByZW1vdmUgdGhlIHZlbmRvci1zcGVjaWZpYyBvcHRpb24uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IE9yIHlvdSBjb3VsZCBwdXQg aW4gYW4gT1VJIC8gZW50ZXJwcmlzZSBudW1iZXIgZm9sbG93ZWQgYnkNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyB0cmFuc3BhcmVudDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBieXRlcy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFRvIG1lIEknbSBwZXJmZWN0bHkgZmluZSB3 aXRoIHRoZSBzZWNvbmQgb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgQ2hlZXJzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsgRzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgQWRyaWFu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbTogR2lvdmFubmkgTWFydGluZWxsaSAoZ2lv bWFydGkpIFs8YSBocmVmPSJtYWlsdG86Z2lvbWFydGlAY2lzY28uY29tIj5tYWlsdG86Z2lvbWFy dGlAY2lzY28uY29tPC9hPl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsmZ3Q7IFNlbnQ6IDIxIEphbnVhcnkgMjAxNSAyMToyMjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgVG86IDxhIGhy ZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsg Q2M6IExlZXlvdW5nOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1l bmNvZGUuYWxsQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5j b2RlLmFsbEB0b29scy5pZXRmLm9yZzwvYT47PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5v cmciPmNjYW1wQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNAdG9v bHMuaWV0Zi5vcmciPmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJl OiBbQ0NBTVBdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7 IFNwZWNpZmljYWxseSB0byB0aGUgSW50ZXJmYWNlIGNsYXNzIGhlcmUgYmVsb3cuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSW4gdGhl IGluaXRpYWwgZHJhZnQgbWVyZ2VkIHRvIHRoaXMgb25lIHRoZXJlIHdhcyB0aGUgdXNhZ2Ugb2Yg T1VJDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7IGhvd2V2ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPihJ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0 OyBndWVzcyBhZnRlciBjaGF0dGluZyB3aXRoIExvdSkgd2UgZGVjaWRlZCB0byByZW1vdmUgYW55 IGVuY29kaW5nDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7IHdoZW4gdGhlIEludGVyZmFjZSBjbGFzcyBpcyBub3Qgc3RhbmRhcmQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBJ biB0ZXJtIG9mIHNlbWFudGljIHRoZSBwcm90Y29sIGRvZXMgbm90IG5lZWQgdG8gZGVjb2RlIHRo ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OyBJbnRlcmZhY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmNs YXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 IHNpbmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jmd0OyBpdCBvbmx5IGFzc2VzcyB0aGUgaW50ZXJmYWNlIGNvbXBhdGliaWxpdHkgaWYgdHdv IGludGVyZmFjZXMgaGFzIGENCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgY2xhc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPnZhbHVlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsmZ3Q7IG1hdGNoIHR3byBpbnRlcmZhY2VzIGNhbm4gYmUgY29ubmVjdGVk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsm Z3Q7IEhhdmluZyBzYXlpbmcgdGhhdCBJIGRvbid0IGhhdmUgc3Ryb25nIG9waW5pb24gaW4gYWRk aW5nIHRoZSBPVUkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyZndDsgb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PmxlYXZpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsgcm9vbTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDsgZm9yIG1heWJlIGZ1dHVyZSBwdWJsaWMgaW50ZXJmYWNlcyBkYXRhYmFzZS4g Rm9yIHN1cmUgdGhlcmUncyBhDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7IG5lZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPmxlYXZlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyByb29tIGZvciBzcGVjaWZpYyBjb21wYXRpYmlsaXR5IGFzc2Vz bWVudCBzaW5jZSB0aGVyZSBvcHRpY2FsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IG11bHRpdmVuZG9yIGNvbXBhdGliaWxpdHkgaGFz IGJlZW4gYWxyZWFkeSBkZW1vbnN0cmF0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgaG9wZSB0aGlzIGhlbHAgLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IENoZWVyczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsg RzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OyBPbiAyMSBKYW4gMjAxNSwgYXQgMjE6NTcsIEFkcmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9 Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlY3Rpb24gNC4xPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBIb3cgZG8gSSBpbnRlcnByZXQgYSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZT8g SXMgdGhlcmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW4gT1VJIEknbSBtaXNzaW5nPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBbWU9VTkddIE5vdCBzdXJlIGlmIEkgdW5kZXJzdG9vZCB0aGlzIHF1ZXN0aW9uLiBXaGF0 IGlzICZxdW90O09VSSZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9lbi53aWtpcGVk aWEub3JnL3dpa2kvT3JnYW5pemF0aW9uYWxseV91bmlxdWVfaWRlbnRpZmllciI+DQpodHRwOi8v ZW4ud2lraXBlZGlhLm9yZy93aWtpL09yZ2FuaXphdGlvbmFsbHlfdW5pcXVlX2lkZW50aWZpZXI8 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9pZWVlLTgw Mi1udW1iZXJzL2llZWUtODAyLSI+DQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2ll ZWUtODAyLW51bWJlcnMvaWVlZS04MDItPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbnVtYmVycy54aHRtbCNpZWVlLTgwMjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IC1udW1iZXJzLTI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9yIHBlcmhhcHMgYW4gRW50ZXJwcmlzZSBOdW1iZXI8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2VudGVycHJpc2UtbnVt YmVycy9lbnRlcnByaXNlLSI+DQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2VudGVy cHJpc2UtbnVtYmVycy9lbnRlcnByaXNlLTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgbnVtYmVyczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhlIHF1ZXN0aW9uIGlzOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgWW91IGhhdmUgc2VjdGlvbnMgNC4xLjEgdGhyb3VnaCA0LjEuNCB0byB0ZWxsIG1lIGhv dyB0byBpbnRlcnByZXQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBPcHRpY2FsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSW50ZXJmYWNlIENsYXNzIGZpZWxk IHdoZW4gaXQgY29udGFpbnMgYW4gSVRVLVQgQXBwbGljYXRpb24gTWFwcGluZy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBXaGVu IEkgcmVjZWl2ZWQgcz0wIGFuZCBPST0xIGl0IG1lYW5zIHRoYXQgdGhlIE9wdGljYWwgSW50ZXJm YWNlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBDbGFzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jmd0OyBjb250YWluczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGEgJnF1b3Q7VmVuZG9yIFNwZWNpZmljIE9wdGlj YWwgSW50ZXJmYWNlIENsYXNzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyBkbyBJIGludGVycHJldCB0aGF0IE9w dGljYWwgSW50ZXJmYWNlIENsYXNzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdoaWNoIHZlbmRvciBkb2VzIGl0IGFwcGx5IHRv PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IElzIHRoZXJlIHNvbWUgaW5mb3JtYXRpb24gZWxzZXdoZXJlIHRoYXQgZ2l2ZXMgbWUg YSBjbHVlIGFzIHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyB3aGljaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyB2ZW5kb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7IGhhczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGVuY29kZWQgdGhlIGluZm9ybWF0aW9uPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IE9yIGlzIHRoZSBpbmZvcm1hdGlvbiBzdXBwb3NlZCB0byBiZSBlbmNvZGVkIGluIHRoZSBP cHRpY2FsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBJbnRlcmZhY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkNsYXNzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHBlcmhhcHMgYXMgdGhlIGZpcnN0IDQ4IGJpdHM/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgT3Ig YW0gSSBzdXBwb3NlZCB0byBrbm93IGJ5IGNvbnRleHQ/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNDQU1QIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0ibWFpbHRvOkNDQU1QQGlldGYu b3JnIj5DQ0FNUEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Nh bXAiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6D32668528F93D449A073F45707153D82C533567US70UWXCHMBA03z_-- From nobody Wed Jan 28 12:41: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 CCC5E1A0379 for ; Wed, 28 Jan 2015 12:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tJ0ITpVZu8xO for ; Wed, 28 Jan 2015 12:41:44 -0800 (PST) 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 03F171A0367 for ; Wed, 28 Jan 2015 12:41:42 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0SKfQch030994; Wed, 28 Jan 2015 20:41:26 GMT Received: from 950129200 (62-46-81-125.adsl.highway.telekom.at [62.46.81.125]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0SKfJkp030977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2015 20:41:20 GMT From: "Adrian Farrel" To: "'Varma, Eve L \(Eve\)'" , , , "'Lam, Hing-Kam \(Kam\)'" , , References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> In-Reply-To: <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> Date: Wed, 28 Jan 2015 20:41:19 -0000 Message-ID: <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_086A_01D03B3A.C741BAE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFT1Enj0304XbWYKDk/PfYcrx4nO53Oyuzg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21290.002 X-TM-AS-Result: No--35.247-10.0-31-10 X-imss-scan-details: No--35.247-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkD0/Ir0O3wwScEd6AVHFtpjnvBHr/aFnM6/wPtA9baOj8Af IMzUPnhOCidEuVnD9LRCbLLv0hhW0K7Kv+wYXRsgWIy0RfuB5IcXZ6k61HUJz1pbYq2f4jz+ONL /wt8zzItEpOCumutgtS295DwYZ8xb7QyV3KLI3eNgP1dNF1ow7QreImldQ5BDJKoUzP1GfbYR89 gRMI54EOlnt7hgePbS9EXoTRZ3UPExKGXTPiprua8+ihL49RByX5TqQagR07c/YMpjv+v0aiTCV wyY5KnU2EATNBgPnoITN1UvDUpzFK2MZsjWks12neIQmu8UmaG6QCTCuzfiVYfwano0g3qCTUO3 VzYqRmpjNt0KJgsAqd/W77R+MIEbvIGdwg6kO3wER9Ta+6BEXXUh2OMdFI0JW3bzMTMiqsQnRZF AjYQbtHoMd7FhKzKaob7JVM1aSSz31EmIMyYYYolD2T5imTkJ9NYqzb2oOWvkMnUVL5d0Ez+qBL RQ/8tXBWUYKmVTr9UeMxMMe/VT7rlepOYfePOtx7fVVD7rJEYgzzoB6jqxgmLM/ReBSwUwBsTxC acZZxUaWhqJ9mvxZHD1uI0mX/EKxaqjHWNnk3Daize54oCwVEcM+OqxWZf6xj9DGL3/UlxGJfp/ NsBA9Tpu7WWZc2iTff2uVR8fIC9+4nq3hjAv6CVypP66BP0QpNh/2/1+WiU/b9mm6+OZxAAqJVd IwA49zlwAVXOf1uAgtX5QorXC6T8UsmrfIcb1D/of1psMgxGagpdUd+Iwz5UQzHWBKOFA59C6Q6 3XTRIkePsv2B62QSHLV9tiezQQ2DBKoUnK0AWeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIB92tTm hoDRQDJmNK5f3bTAmP6SRk8DFVZNctPxlPVy/SNp9vp2B0IVMDZQ7S6DB8= Archived-At: Cc: paul.doolan@coriant.com, ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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: Wed, 28 Jan 2015 20:41:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_086A_01D03B3A.C741BAE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eve, =20 What joy! =20 We've waited all these years to be identically confused:-) =20 I think the confusion may come from Young saying that knowing the OU = makes no difference to interop. I think that is false because: - you have no way to know that your neighbor is from the same vendor (recall, this is an MCN protocol) - your device might support working with multiple vendors =20 So there are two possible interworking issues: 1. You might crash trying to process a field assuming it is one of yours = when it isn't 2. You might be unable to disambiguate for real interop choices =20 The proposed G.874.1 approach seems entirely painless to me and requires = only one line of additional text. Viz.: =20 The format of the Vendor-Specific Application Identifier is a matter for = the vendor concerned and may be private or published in vendor-specific = documentation, but in all cases the first six characters of the = Vendor-Specific Application Identifier MUST contain the hexadecimal = representation of an OUI assigned to the vendor whose implementation = generated the Application Identifier. =20 Is that so hard? =20 Adrian =20 =20 From: Varma, Eve L (Eve) [mailto:eve.varma@alcatel-lucent.com]=20 Sent: 28 January 2015 20:17 To: 'leeyoung@huawei.com'; 'db3546@att.com'; Lam, Hing-Kam (Kam); = 'adrian@olddog.co.uk'; 'ggrammel@juniper.net'; 'giomarti@cisco.com' Cc: 'paul.doolan@coriant.com'; 'ccamp@ietf.org'; = 'ccamp-chairs@tools.ietf.org'; = 'draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org' Subject: Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Dear all, I'm getting a bit confused - I thought that there was sentiment to match = the approach in G.874.1; wasn't that option 2? Best regards, Eve =20 From: Leeyoung [mailto:leeyoung@huawei.com]=20 Sent: Wednesday, January 28, 2015 03:05 PM To: BRUNGARD, DEBORAH A ; Lam, Hing-Kam (Kam); = adrian@olddog.co.uk ; 'Gert Grammel' = ; 'Giovanni Martinelli (giomarti)' = =20 Cc: 'Doolan, Paul (Coriant - US/Irving)' ; = ccamp@ietf.org ; ccamp-chairs@tools.ietf.org = ; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org = =20 Subject: Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode=20 =20 Hi Deborah, =20 I agree with what you said. That was my point. Option 1 is my preference = and the WG has agreed on that ,I think.=20 =20 Thanks, Young =20 From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=20 Sent: Wednesday, January 28, 2015 1:56 PM To: Leeyoung; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Grammel'; = 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Hi Young, =20 Are you voting for option 3? =20 My thoughts were if (big IF) we are going to allow proprietary = Application Identifiers (which SG15 has agreed) then best would be if we = can at least have some way to identify (better than an undefined = string). As you say, it still does not guarantee interoperability unless = it is the same vendor (hopefully ). If two different vendors (e.g. black = link), then it would be for the vendors (and operator) to ensure = interoperability if supporting non-standard AIs. And as we know, = it=E2=80=99s not just the AI that is needed to determine if it will work = properly. =20 Thanks, Deborah =20 =20 From: Leeyoung [mailto:leeyoung@huawei.com]=20 Sent: Wednesday, January 28, 2015 2:33 PM To: BRUNGARD, DEBORAH A; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert = Grammel'; 'Giovanni Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Hi Deborah, =20 Thanks for sharing your operator=E2=80=99s perspective. I am wondering = how the OUI would really help for interoperability other than = identifying the specific vendors that are using their proprietary code. = =20 Say vendor A uses FEC type A while vendor B used FEC type B, and both of = them are proprietary FECs. I believe the OUI will help the operator = identify this fact and conclude the systems are not compatible. But = would this really help operators toward interoperability? I believe a = better way for operators to attain interoperability is to force vendors = use standard FECs and have them agree on the same type of FECs within = the standard FECs. My point is how vendor specific code would be really = helpful even if we employ the OUI field.=20 =20 Thanks, Young=20 =20 From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, = DEBORAH A Sent: Wednesday, January 28, 2015 11:46 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Grammel'; 'Giovanni = Martinelli (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Hi All, =20 As Lou noted, Adrian=E2=80=99s option 1 was the intention as this was = discussed when G872 was being revised to introduce Application = Identifier (IETF=E2=80=99s March 2013 meeting). As Kam notes, = ITU=E2=80=99s work on G.874.1 has evolved to include the OUI. =20 As a network operator, I prefer as Adrian says =E2=80=93 let=E2=80=99s = attempt to match draft G.874.1 (it does have agreement). So = Adrian=E2=80=99s option 2. While the context of this work is within an = operator=E2=80=99s network, the OUI will help to ensure = interoperability. =20 Adrian =E2=80=93 good catch- Deborah =20 From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam = (Kam) Sent: Sunday, January 25, 2015 8:50 PM To: adrian@olddog.co.uk; 'Gert Grammel'; 'Giovanni Martinelli = (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Hi Adrian, =20 Yes, while Q14/15 already reached agreement to update the Application = Identifier description, the update has not been formally approved and = published by SG15 yet. Q14/15 may be able to consent this update as an = Amendment to G.874.1 at the upcoming SG15 meeting in July 2015. =20 Regards, Kam =20 From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, January 23, 2015 1:59 PM To: Lam, Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli = (giomarti)' Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Thanks for being awake, Kam. =20 Useful info. =20 Gert, the OUI registry is an IEEE registry as Kam says. IANA has a = registry page for this, but it points to the IEEE page. =20 As I understand Kam, 874.1 is not yet updated so it would be premature = to point to it, but an option is to attempt to match it now and fix = later if needed. =20 Adrian =20 From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com]=20 Sent: 23 January 2015 17:10 To: Gert Grammel; adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Hi Gert, =20 A vendor can purchase an OUI (Organizationally Unique Identifier) from = the IEEE Registration Authority. Once a vendor has its OUI, the vendor can manage its vendor-specific = application identifiers under its own OUI.=20 SG15 doesn=E2=80=99t need to host any registry for this purpose. =20 Regards, Kam =20 From: Gert Grammel [mailto:ggrammel@juniper.net]=20 Sent: Friday, January 23, 2015 11:49 AM To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Giovanni Martinelli = (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Hi Kam, =20 Is SG15 considering to host a registry for the vendor specific = application code or is the IETF registry supposed to be used? =20 Thanks =20 Gert =20 From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lam, Hing-Kam = (Kam) Sent: 23 January 2015 17:03 To: adrian@olddog.co.uk; 'Giovanni Martinelli (giomarti)' Cc: Doolan, Paul (Coriant - US/Irving); ccamp@ietf.org; = ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Dear all, =20 For your information. In the last SG15 meeting, Q14/15 agreed to update = G.874.1 to amend the specification of ApplicationIdentifier with the = following additional text: =20 If the ApplicationIdentifierType is STANDARD, the value of = PrintableString represents a standard application code as defined in the = ITU-T Recommendations. If the ApplicationIdentifierType is PROPRIETARY, = the first six characters of the PrintableString must contain the = Hexadecimal representation of an OUI assigned to the vendor whose = implementation generated the Application Identifier; the remaining = octets of the PrintableString are unspecified. =20 Paul Doolan had an I-D = "https://tools.ietf.org/html/draft-doolan-proprietary-ac-00" to the last = IETF meeting with the similar proposal. =20 Regards, Kam =20 -----Original Message----- From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Friday, January 23, 2015 9:41 AM To: 'Giovanni Martinelli (giomarti)' Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode =20 Hi, =20 I appreciate this discussion, but I am not seeing a specific conclusion = from it. =20 The current I-D makes (IMHO) the Vendor-Specific Application Code = unusable. I offered three options: =20 1 This value is only to be used when it is known that all devices participating in a network have the same understanding of=20 the content of the Vendor-Specific Application Code field. How this knowledge is achieved is outside the scope of this document =20 2 When this value is set, the first 32 (or 48) bits of the Vendor- Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. =20 3 Remove the option to include a Vendor-Specific Application Code field. =20 If the WG could please pick one of these and help Young to update the = document. =20 Thanks, Adrian =20 > -----Original Message----- > From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > Sent: 23 January 2015 13:50 > To: adrian@olddog.co.uk > Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode >=20 > One additional comment (hoping not additional confusion). >=20 > The idea about Optical Interface Class was taken from SRLG. Good or=20 > bad is a plain number and you do simple operations on it. >=20 > Cheers > G >=20 > On 22 Jan 2015, at 09:42, Giovanni Martinelli (giomarti)=20 > > wrote: >=20 > > Hi Adrian, > > > > On 21 Jan 2015, at 22:55, Adrian Farrel wrote: > > > >> Hi, > >> > >> Well, you seem to have a half-way house. > >> > >> You have specified the existence of a thing, but not how to read = it. > >> > >> If you wanted to make a statement that this object will only be=20 > >> used when it is > >> known that all systems in a network come from the same vendor=20 > >> and/or have > the > >> same understanding of the encoding, that might be OK (although how=20 > >> you > would > >> ascertain this might also need to be described). > >> > > > > The statement is to ensure the interface compatibility without=20 > > encoding all the > possible details and parameter that define an interface (e.g.=20 > modulation format, > forward error correction etc.). This was the initial solution in the=20 > draft then > replaced by the interface class concept. The WSON (RWA-only) has the > requirement is to make sure two interface are compatible. This=20 > requirement, imho, can be satisfy by a simple comparison which has a = boolean result. > > > > We end up then in the ITU application codes for the "certified"=20 > > (we'll this is my > term not 100% sure is the best one) compatibility where proper=20 > encoding is provided. > > > > > >> Or you could entirely remove the vendor-specific option. > >> > >> Or you could put in an OUI / enterprise number followed by=20 > >> transparent > bytes. > >> > > > > To me I'm perfectly fine with the second option. > > > > Cheers > > G > > > > > >> Adrian > >> > >>> -----Original Message----- > >>> From: Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com] > >>> Sent: 21 January 2015 21:22 > >>> To: adrian@olddog.co.uk > >>> Cc: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; > >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org > >>> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode > >>> > >>> Specifically to the Interface class here below. > >>> > >>> In the initial draft merged to this one there was the usage of OUI = > >>> however (I > >>> guess after chatting with Lou) we decided to remove any encoding=20 > >>> when the Interface class is not standard. > >>> In term of semantic the protcol does not need to decode the=20 > >>> Interface class > >> since > >>> it only assess the interface compatibility if two interfaces has a = > >>> class value > >> that > >>> match two interfaces cann be connected. > >>> > >>> Having saying that I don't have strong opinion in adding the OUI=20 > >>> or leaving > >> room > >>> for maybe future public interfaces database. For sure there's a=20 > >>> need to leave > >>> room for specific compatibility assesment since there optical=20 > >>> multivendor compatibility has been already demonstrated. > >>> > >>> hope this help . > >>> > >>> Cheers > >>> G > >>> > >>> > >>> On 21 Jan 2015, at 21:57, Adrian Farrel = wrote: > >>> > >>>>>> > >>>>>> Section 4.1 > >>>>>> How do I interpret a Vendor-Specific Application Code? Is there = > >>>>>> an OUI I'm missing? > >>>>> > >>>>> [YOUNG] Not sure if I understood this question. What is "OUI"? > >>>> > >>>> http://en.wikipedia.org/wiki/Organizationally_unique_identifier > >>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802- > >>> numbers.xhtml#ieee-802 > >>>> -numbers-2 > >>>> > >>>> Or perhaps an Enterprise Number > >>>> http://www.iana.org/assignments/enterprise-numbers/enterprise- > numbers > >>>> > >>>> The question is: > >>>> > >>>> You have sections 4.1.1 through 4.1.4 to tell me how to interpret = > >>>> the > >> Optical > >>>> Interface Class field when it contains an ITU-T Application = Mapping. > >>>> When I received s=3D0 and OI=3D1 it means that the Optical = Interface=20 > >>>> Class > >> contains > >>>> a "Vendor Specific Optical Interface Class". > >>>> How do I interpret that Optical Interface Class? > >>>> Which vendor does it apply to? > >>>> Is there some information elsewhere that gives me a clue as to=20 > >>>> which > vendor > >>> has > >>>> encoded the information? > >>>> Or is the information supposed to be encoded in the Optical=20 > >>>> Interface Class, > >>>> perhaps as the first 48 bits? > >>>> Or am I supposed to know by context? > >> > > =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp ------=_NextPart_000_086A_01D03B3A.C741BAE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Eve,

 

What = joy!

 

We've waited all these = years to be identically confused:-)

 

I think the confusion = may come from Young saying that knowing the OU makes no difference to = interop.

I think that is false = because:

- you have no way to = know that your neighbor is from the same = vendor

=C2=A0 (recall, this is an MCN = protocol)

- your device might = support working with multiple vendors

 

So there are two = possible interworking issues:

1. You might crash = trying to process a field assuming it is one of yours when it = isn't

2. You might be unable = to disambiguate for real interop choices

 

The proposed G.874.1 = approach seems entirely painless to me and requires only one line of = additional text. Viz.:

 

The format of the = Vendor-Specific Application Identifier is a matter for the vendor = concerned and may be private or published in vendor-specific = documentation, but in all cases the first six characters of the = Vendor-Specific Application Identifier MUST contain the hexadecimal = representation of an OUI assigned to the vendor whose implementation = generated the Application Identifier.

 

Is that so = hard?

 

Adrian

 

 

From: Varma, Eve L = (Eve) [mailto:eve.varma@alcatel-lucent.com]
Sent: 28 January = 2015 20:17
To: 'leeyoung@huawei.com'; 'db3546@att.com'; Lam, = Hing-Kam (Kam); 'adrian@olddog.co.uk'; 'ggrammel@juniper.net'; = 'giomarti@cisco.com'
Cc: 'paul.doolan@coriant.com'; = 'ccamp@ietf.org'; 'ccamp-chairs@tools.ietf.org'; = 'draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org'
Subject: = Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Dear all,

I'm = getting a bit confused - I thought that there was sentiment to match the = approach in G.874.1; wasn't that option 2?

Best = regards,
Eve
 

From: Leeyoung = [mailto:leeyoung@huawei.com]
Sent: Wednesday, January 28, = 2015 03:05 PM
To: BRUNGARD, DEBORAH A <db3546@att.com>; = Lam, Hing-Kam (Kam); adrian@olddog.co.uk <adrian@olddog.co.uk>; = 'Gert Grammel' <ggrammel@juniper.net>; 'Giovanni Martinelli = (giomarti)' <giomarti@cisco.com>
Cc: 'Doolan, Paul = (Coriant - US/Irving)' <paul.doolan@coriant.com>; ccamp@ietf.org = <ccamp@ietf.org>; ccamp-chairs@tools.ietf.org = <ccamp-chairs@tools.ietf.org>; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org = <draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org> =
Subject: Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode
 

Hi = Deborah,

 <= /p>

I agree with what you = said. That was my point. Option 1 is my preference and the WG has agreed = on that ,I think.

 <= /p>

Thanks,=

Young

 <= /p>

From: BRUNGARD, DEBORAH A [mailto:db3546@att.com] =
Sent: Wednesday, January 28, 2015 1:56 PM
To: = Leeyoung; Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Grammel'; = 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - = US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi = Young,

 <= /p>

Are you voting for = option 3?

 <= /p>

My thoughts were if (big = IF) we are going to allow proprietary Application Identifiers (which = SG15 has agreed) then best would be if we can at least have some way to = identify (better than an undefined string). As you say, it still does = not guarantee interoperability unless it is the same vendor (hopefully = ). If two different vendors (e.g. black link), then it would be for the = vendors (and operator) to ensure interoperability if supporting = non-standard AIs. And as we know, it=E2=80=99s not just the AI that is = needed to determine if it will work properly.

 <= /p>

Thanks,=

Deborah=

 <= /p>

 <= /p>

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: = Wednesday, January 28, 2015 2:33 PM
To: BRUNGARD, DEBORAH A; = Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert Grammel'; 'Giovanni = Martinelli (giomarti)'
Cc: 'Doolan, Paul (Coriant - = US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi = Deborah,

 <= /p>

Thanks for sharing your = operator=E2=80=99s perspective.  I am wondering how the OUI would = really help for interoperability other than identifying the specific = vendors that are using their proprietary code. =  

 <= /p>

Say vendor A uses FEC = type A while vendor B used FEC type B, and both of them are proprietary = FECs. I believe the OUI will help the operator identify this fact and = conclude the systems are not compatible. But would this really help = operators toward interoperability? I believe a better way for operators = to attain interoperability is to force vendors use standard FECs and = have them agree on the same type of FECs within the standard FECs. My = point is how vendor specific code would be really helpful even if we = employ the OUI field.

 <= /p>

Thanks,=

Young =

 <= /p>

From: CCAMP [mailto:ccamp-bounces@ietf.org]= On Behalf Of BRUNGARD, DEBORAH A
Sent: Wednesday, = January 28, 2015 11:46 AM
To: Lam, Hing-Kam (Kam); adrian@olddog.co.uk; 'Gert = Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul = (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi = All,

 <= /p>

As Lou noted, = Adrian=E2=80=99s option 1 was the intention as this was discussed when = G872 was being revised to introduce Application Identifier = (IETF=E2=80=99s March 2013 meeting). As Kam notes, ITU=E2=80=99s work on = G.874.1 has evolved to include the OUI.

 <= /p>

As a network operator, I = prefer as Adrian says =E2=80=93 let=E2=80=99s attempt to match draft = G.874.1 (it does have agreement). So Adrian=E2=80=99s option 2. While = the context of this work is within an operator=E2=80=99s network, the = OUI will help to ensure interoperability.

 <= /p>

Adrian =E2=80=93 good = catch-

Deborah=

 <= /p>

From: CCAMP [mailto:ccamp-bounces@ietf.org]= On Behalf Of Lam, Hing-Kam (Kam)
Sent: Sunday, January = 25, 2015 8:50 PM
To: adrian@olddog.co.uk; 'Gert = Grammel'; 'Giovanni Martinelli (giomarti)'
Cc: 'Doolan, Paul = (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi = Adrian,

 <= /p>

Yes, while Q14/15 = already reached agreement to update the Application Identifier = description, the update has not been formally approved and published by = SG15 yet. Q14/15 may be able to consent this update as an Amendment to = G.874.1 at the upcoming SG15 meeting in July = 2015.

 <= /p>

Regards,

Kam

=

 <= /p>

From: Adrian Farrel [mailto:adrian@olddog.co.uk] =
Sent: Friday, January 23, 2015 1:59 PM
To: Lam, = Hing-Kam (Kam); 'Gert Grammel'; 'Giovanni Martinelli = (giomarti)'
Cc: 'Doolan, Paul (Coriant - US/Irving)'; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Thanks for being awake, = Kam.

 

Useful = info.

 

Gert, the OUI registry = is an IEEE registry as Kam says. IANA has a registry page for this, but = it points to the IEEE page.

 

As I understand Kam, = 874.1 is not yet updated so it would be premature to point to it, but an = option is to attempt to match it now and fix later if = needed.

 

Adrian

 

From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.= com]
Sent: 23 January 2015 17:10
To: Gert = Grammel; adrian@olddog.co.uk; = 'Giovanni Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - = US/Irving); ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi = Gert,

 <= /p>

A vendor can purchase an = OUI (Organizationally Unique Identifier) from the IEEE Registration = Authority.

Once a vendor has its = OUI, the vendor can manage its vendor-specific application identifiers = under its own OUI.

SG15 = doesn=E2=80=99t need to host any registry for this = purpose.

 <= /p>

Regards,

Kam

=

 <= /p>

From: Gert Grammel [mailto:ggrammel@juniper.net] =
Sent: Friday, January 23, 2015 11:49 AM
To: Lam, = Hing-Kam (Kam); adrian@olddog.co.uk; 'Giovanni = Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); = ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = RE: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi = Kam,

 <= /p>

Is SG15 considering to = host a registry for the vendor specific application code or is the IETF = registry supposed to be used?

 <= /p>

Thanks<= /p>

 <= /p>

Gert

 <= /p>

From: CCAMP [mailto:ccamp-bounces@ietf.org]= On Behalf Of Lam, Hing-Kam (Kam)
Sent: 23 January 2015 = 17:03
To: adrian@olddog.co.uk; 'Giovanni = Martinelli (giomarti)'
Cc: Doolan, Paul (Coriant - US/Irving); = ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Subject: = Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Dear all,

 

For your information. In the last SG15 = meeting, Q14/15 agreed to update G.874.1 to amend the specification of = ApplicationIdentifier with the following additional = text:

 

If the ApplicationIdentifierType is = STANDARD, the value of PrintableString represents a standard application = code as defined in the ITU-T Recommendations. If the = ApplicationIdentifierType is PROPRIETARY, the first six characters of = the PrintableString must contain the Hexadecimal representation of an = OUI assigned to the vendor whose implementation generated the = Application Identifier; the remaining octets of the PrintableString are = unspecified.

 

Paul Doolan had an I-D "https= ://tools.ietf.org/html/draft-doolan-proprietary-ac-00" to the = last IETF meeting with the similar proposal.

 

Regards,

Kam

 

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

From: CCAMP [mailto:ccamp-bounces@ietf.org]= On Behalf Of Adrian Farrel

Sent: Friday, January 23, 2015 9:41 = AM

To: 'Giovanni Martinelli = (giomarti)'

Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org

<= p class=3DMsoPlainText>Subject: [CCAMP] Vendor-Specific = Application Code in = draft-ietf-ccamp-rwa-wson-encode

 

Hi,

 

I appreciate this discussion, but I am = not seeing a specific conclusion from it.

 

The current I-D makes (IMHO) the = Vendor-Specific Application Code unusable. I offered three = options:

 

1 This value is only to be used when = it is known that all devices

   participating in a = network have the same understanding of

   the content of the = Vendor-Specific Application Code field.

   How this knowledge is = achieved is outside the scope of this

   = document

 

2 When this value is set, the first 32 = (or 48) bits of the Vendor-

  Specific Application Code field = contain an Enterprise Number

  (or OUI) that defines the = context in which the remainder of

  that field is = interpreted.

 

3 Remove the option to include a = Vendor-Specific Application

   Code = field.

 

If the WG could please pick one of = these and help Young to update the document.

 

Thanks,

Adrian

 

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

> From: Giovanni = Martinelli (giomarti) [mailto:giomarti@cisco.com]

> Sent: 23 January 2015 = 13:50

> To: adrian@olddog.co.uk

> Cc: Leeyoung; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

=

> ccamp@ietf.org; ccamp-chairs@tools.ietf.org

> Subject: Re: [CCAMP] AD review of = draft-ietf-ccamp-rwa-wson-encode

>

> One additional comment (hoping = not additional confusion).

>

> The idea about Optical Interface = Class was taken from SRLG. Good or

> bad is a plain number and you do = simple operations on it.

>

> Cheers

> G

>

> On 22 Jan 2015, at 09:42, = Giovanni Martinelli (giomarti)

> <giomarti@cisco.com><= /span>

> wrote:

>

> > Hi = Adrian,

> >

> > On 21 Jan 2015, at 22:55, = Adrian Farrel <adrian@olddog.co.uk> = wrote:

> >

> >> = Hi,

> >>

> >> Well, you seem to have a = half-way house.

> = >>

> >> You have specified the = existence of a thing, but not how to read it.

> >>

> >> If you wanted to make a = statement that this object will only be

> >> used = when

it is

> >> known that all systems = in a network come from the same vendor

> >> and/or = have

> the

> >> same understanding of = the encoding, that might be OK (although how

> >> = you

> would

> >> ascertain this might = also need to be described).

> >>

> >

> > The statement is to ensure = the interface compatibility without

> > encoding = all

the

> possible details and parameter = that define an interface (e.g.

> = modulation

format,

> forward error correction etc.). = This was the initial solution in the

> draft

then

> replaced by the interface class = concept.   The WSON (RWA-only) has the

> requirement is to make sure two = interface are compatible. This

> requirement, imho, can be satisfy = by a simple comparison which has a boolean = result.

> >

> > We end up then in  the = ITU application codes for the "certified" =

> > (we'll = this

is my

> term not 100% sure is the best = one) compatibility where proper

> encoding is = provided.

> = >

> >

> >> Or you could entirely = remove the vendor-specific option.

> >>

> >> Or you could put in an = OUI / enterprise number followed by

> >> = transparent

> = bytes.

> >>

> >

> > To me I'm perfectly fine = with the second option.

> >

> > = Cheers

> > G

> >

> >

> >> = Adrian

> >>

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

> >>> From: = Giovanni Martinelli (giomarti) [mailto:giomarti@cisco.com]

> >>> Sent: 21 January = 2015 21:22

> >>> To: adrian@olddog.co.uk

> >>> Cc: Leeyoung; draft= -ietf-ccamp-rwa-wson-encode.all@tools.ietf.org;

=

> >>> ccamp@ietf.org; ccamp-chairs@tools.ietf.org

> >>> Subject: Re: [CCAMP] = AD review of draft-ietf-ccamp-rwa-wson-encode

> = >>>

> >>> = Specifically to the Interface class here below.

> = >>>

> >>> In the = initial draft merged to this one there was the usage of OUI =

> >>> = however

(I

> >>> guess after chatting = with Lou) we decided to remove any encoding

> >>> when the Interface = class is not standard.

> >>> In term of semantic = the protcol does not need to decode the

> >>> = Interface

class

> >> = since

> >>> it only assess the = interface compatibility if two interfaces has a

> >>> = class

value

> >> = that

> >>> match two interfaces = cann be connected.

> = >>>

> >>> Having = saying that I don't have strong opinion in adding the OUI =

> >>> = or

leaving

> >> = room

> >>> for maybe future = public interfaces database. For sure there's a

> >>> need = to

leave

> >>> room for specific = compatibility assesment since there optical

> >>> multivendor = compatibility has been already demonstrated.

> = >>>

> >>> hope = this help .

> = >>>

> >>> = Cheers

> >>> = G

> = >>>

> = >>>

> >>> On 21 = Jan 2015, at 21:57, Adrian Farrel <adrian@olddog.co.uk> = wrote:

> = >>>

> = >>>>>>

> >>>>>> Section = 4.1

> >>>>>> How do I = interpret a Vendor-Specific Application Code? Is there =

> >>>>>> an OUI = I'm missing?

> = >>>>>

> >>>>> = [YOUNG] Not sure if I understood this question. What is = "OUI"?

> = >>>>

> >>>> = http://en.wikipedia.org/wiki/Organizationally_unique_identifier<= /o:p>

> >>>> http:= //www.iana.org/assignments/ieee-802-numbers/ieee-802-

> >>> = numbers.xhtml#ieee-802

> >>>> = -numbers-2

> = >>>>

> >>>> Or = perhaps an Enterprise Number

> >>>> h= ttp://www.iana.org/assignments/enterprise-numbers/enterprise-

> numbers

> = >>>>

> >>>> The = question is:

> = >>>>

> >>>> You = have sections 4.1.1 through 4.1.4 to tell me how to interpret =

> >>>> = the

> >> = Optical

> >>>> Interface Class = field when it contains an ITU-T Application = Mapping.

> >>>> When I received = s=3D0 and OI=3D1 it means that the Optical Interface =

> >>>> = Class

> >> = contains

> >>>> a "Vendor = Specific Optical Interface Class".

> >>>> How do I = interpret that Optical Interface Class?

> >>>> Which vendor = does it apply to?

> >>>> Is = there some information elsewhere that gives me a clue as to =

> >>>> = which

> vendor

> >>> = has

> >>>> encoded the = information?

> >>>> Or = is the information supposed to be encoded in the Optical =

> >>>> = Interface

Class,

> >>>> perhaps as the = first 48 bits?

> >>>> Or = am I supposed to know by context?

> >>

> >

 

_______________________________________= ________

CCAMP mailing = list

CCAMP@ietf.org

https://www.ietf.org= /mailman/listinfo/ccamp

------=_NextPart_000_086A_01D03B3A.C741BAE0-- From nobody Wed Jan 28 13:02: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 EB21E1A039B for ; Wed, 28 Jan 2015 13:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 RTbpxJvg_LgB for ; Wed, 28 Jan 2015 13:02:46 -0800 (PST) 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 AA22C1A005C for ; Wed, 28 Jan 2015 13:02:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BON48125; Wed, 28 Jan 2015 21:02:43 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 Jan 2015 21:02:42 +0000 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, 28 Jan 2015 13:02:35 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "'Varma, Eve L (Eve)'" , "db3546@att.com" , "'Lam, Hing-Kam (Kam)'" , "ggrammel@juniper.net" , "giomarti@cisco.com" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyKmWicGibpQEGWYW2s/gCycJzOdnmAgAAengCAA5dgAIAEL7YA//+TloCAAJDSAP//e+qggACJ8QCAAAbcgP//fJJw Date: Wed, 28 Jan 2015 21:02:35 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> In-Reply-To: <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Aczt Aklo Gm8/ JIwZ ZOcb f8k/ gjE5 uXLs 1uFE 3vva 6ABI AA6Arw== ADmXjw== AGXj7A== ALShvg== AOc91g==; 10; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGMAYwBhAG0AcAAtAGMAaABhAGkAcgBzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAYwBjAGEAbQBwAEAAaQBlAHQAZgAuAG8AcgBnADsAZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHIAdwBhAC0AdwBzAG8AbgAtAGUAbgBjAG8AZABlAC4AYQBsAGwAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBlAHYAZQAuAHYAYQByAG0AYQBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtADsAZwBnAHIAYQBtAG0AZQBsAEAAagB1AG4AaQBwAGUAcgAuAG4AZQB0ADsAZwBpAG8AbQBhAHIAdABpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBrAGEAbQAuAGwAYQBtAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0AOwBwAGEAdQBsAC4AZABvAG8AbABhAG4AQABjAG8AcgBpAGEAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {6436DED9-CF0D-4BF0-B69D-7CDB0DEE8B6C}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Wed, 28 Jan 2015 21:02:15 GMT; UgBFADoAIABbAEMAQwBBAE0AUABdACAAVgBlAG4AZABvAHIALQBTAHAAZQBjAGkAZgBpAGMAIABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABDAG8AZABlACAAaQBuACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHIAdwBhAC0AdwBzAG8AbgAtAGUAbgBjAG8AZABlAA== x-cr-puzzleid: {6436DED9-CF0D-4BF0-B69D-7CDB0DEE8B6C} x-originating-ip: [10.47.135.240] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F161dfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "paul.doolan@coriant.com" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 28 Jan 2015 21:02:53 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F161dfweml706chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIGlzIGFsd2F5cyBhIHByaW9yaSBrbm93bGVkZ2UgaW4gb3B0aWNhbCBuZXR3 b3JrIGRvbWFpbiBhcyB0byB3aG8gYXJlIHlvdSBpbnRlcmZhY2luZyB3aXRoLiBTbyB5b3Uga25v dyB3aGljaCB2ZW5kb3IgeW91IGFyZSBpbnRlcmZhY2luZy4gSWYgeW91IGRvIG5vdCBrbm93LCB0 aGVuIHlvdSBhcmUgaW4gdHJvdWJsZS4NCg0KTm93LCB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHN0 YW5kYXJkIEZFQ3MgYW5kIG1vZHVsYXRpb25zIGluIHRoZSBBST8gR2l2ZW4gc2V2ZXJhbCBjaG9p Y2VzIGVhY2ggdmVuZG9yIG1heSBzdXBwb3J0IGluIGl0cyBkZXZpY2UsIHRoZSBwYXRoIGNvbXB1 dGF0aW9uIHdvdWxkIGZpbmQgYSBtYXRjaGVkIHR5cGVzIGZvciBGRUMgYW5kIG1vZHVsYXRpb24g Zm9yIGEgZ2l2ZW4gb3B0aWNhbCBwYXRoLiBUaGlzIGlzIHdoYXQgaXMgaW50ZW5kZWQgd2hlbiBv cHRpY2FsIHNpZ25hbCBwcm9jZXNzaW5nIGNvbnN0cmFpbnRzIHdlcmUgcHJvcG9zZWQgYXMgcGFy dCBvZiBwYXRoIGNvbXB1dGF0aW9uIGNvbnN0cmFpbnRzIGluIG9wdGljYWwgbmV0d29ya3MuDQoN ClRoZXJlIGlzIHZlcnkgbGl0dGxlIGNoYW5jZSBmb3IgdmVuZG9yIHNwZWNpZmljIEZFQ3MgYW5k IE1vZHVsYXRpb25zIHdpbGwgbWF0Y2ggZXZlbiBpZiB0aGV5IGFyZSBpZGVudGlmaWVkIHdpdGgg dGhlIE9VSSBjb2RlLg0KDQpNeSB0d28gY2VudHMsDQpZb3VuZw0KDQpGcm9tOiBBZHJpYW4gRmFy cmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5jby51a10NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFy eSAyOCwgMjAxNSAyOjQxIFBNDQpUbzogJ1Zhcm1hLCBFdmUgTCAoRXZlKSc7IExlZXlvdW5nOyBk YjM1NDZAYXR0LmNvbTsgJ0xhbSwgSGluZy1LYW0gKEthbSknOyBnZ3JhbW1lbEBqdW5pcGVyLm5l dDsgZ2lvbWFydGlAY2lzY28uY29tDQpDYzogcGF1bC5kb29sYW5AY29yaWFudC5jb207IGNjYW1w QGlldGYub3JnOyBjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAt cndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFtDQ0FNUF0g VmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Et d3Nvbi1lbmNvZGUNCg0KRXZlLA0KDQpXaGF0IGpveSENCg0KV2UndmUgd2FpdGVkIGFsbCB0aGVz ZSB5ZWFycyB0byBiZSBpZGVudGljYWxseSBjb25mdXNlZDotKQ0KDQpJIHRoaW5rIHRoZSBjb25m dXNpb24gbWF5IGNvbWUgZnJvbSBZb3VuZyBzYXlpbmcgdGhhdCBrbm93aW5nIHRoZSBPVSBtYWtl cyBubyBkaWZmZXJlbmNlIHRvIGludGVyb3AuDQpJIHRoaW5rIHRoYXQgaXMgZmFsc2UgYmVjYXVz ZToNCi0geW91IGhhdmUgbm8gd2F5IHRvIGtub3cgdGhhdCB5b3VyIG5laWdoYm9yIGlzIGZyb20g dGhlIHNhbWUgdmVuZG9yDQogIChyZWNhbGwsIHRoaXMgaXMgYW4gTUNOIHByb3RvY29sKQ0KLSB5 b3VyIGRldmljZSBtaWdodCBzdXBwb3J0IHdvcmtpbmcgd2l0aCBtdWx0aXBsZSB2ZW5kb3JzDQoN ClNvIHRoZXJlIGFyZSB0d28gcG9zc2libGUgaW50ZXJ3b3JraW5nIGlzc3VlczoNCjEuIFlvdSBt aWdodCBjcmFzaCB0cnlpbmcgdG8gcHJvY2VzcyBhIGZpZWxkIGFzc3VtaW5nIGl0IGlzIG9uZSBv ZiB5b3VycyB3aGVuIGl0IGlzbid0DQoyLiBZb3UgbWlnaHQgYmUgdW5hYmxlIHRvIGRpc2FtYmln dWF0ZSBmb3IgcmVhbCBpbnRlcm9wIGNob2ljZXMNCg0KVGhlIHByb3Bvc2VkIEcuODc0LjEgYXBw cm9hY2ggc2VlbXMgZW50aXJlbHkgcGFpbmxlc3MgdG8gbWUgYW5kIHJlcXVpcmVzIG9ubHkgb25l IGxpbmUgb2YgYWRkaXRpb25hbCB0ZXh0LiBWaXouOg0KDQpUaGUgZm9ybWF0IG9mIHRoZSBWZW5k b3ItU3BlY2lmaWMgQXBwbGljYXRpb24gSWRlbnRpZmllciBpcyBhIG1hdHRlciBmb3IgdGhlIHZl bmRvciBjb25jZXJuZWQgYW5kIG1heSBiZSBwcml2YXRlIG9yIHB1Ymxpc2hlZCBpbiB2ZW5kb3It c3BlY2lmaWMgZG9jdW1lbnRhdGlvbiwgYnV0IGluIGFsbCBjYXNlcyB0aGUgZmlyc3Qgc2l4IGNo YXJhY3RlcnMgb2YgdGhlIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBJZGVudGlmaWVyIE1V U1QgY29udGFpbiB0aGUgaGV4YWRlY2ltYWwgcmVwcmVzZW50YXRpb24gb2YgYW4gT1VJIGFzc2ln bmVkIHRvIHRoZSB2ZW5kb3Igd2hvc2UgaW1wbGVtZW50YXRpb24gZ2VuZXJhdGVkIHRoZSBBcHBs aWNhdGlvbiBJZGVudGlmaWVyLg0KDQpJcyB0aGF0IHNvIGhhcmQ/DQoNCkFkcmlhbg0KDQoNCkZy b206IFZhcm1hLCBFdmUgTCAoRXZlKSBbbWFpbHRvOmV2ZS52YXJtYUBhbGNhdGVsLWx1Y2VudC5j b21dDQpTZW50OiAyOCBKYW51YXJ5IDIwMTUgMjA6MTcNClRvOiAnbGVleW91bmdAaHVhd2VpLmNv bSc7ICdkYjM1NDZAYXR0LmNvbSc7IExhbSwgSGluZy1LYW0gKEthbSk7ICdhZHJpYW5Ab2xkZG9n LmNvLnVrJzsgJ2dncmFtbWVsQGp1bmlwZXIubmV0JzsgJ2dpb21hcnRpQGNpc2NvLmNvbScNCkNj OiAncGF1bC5kb29sYW5AY29yaWFudC5jb20nOyAnY2NhbXBAaWV0Zi5vcmcnOyAnY2NhbXAtY2hh aXJzQHRvb2xzLmlldGYub3JnJzsgJ2RyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFs bEB0b29scy5pZXRmLm9yZycNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBB cHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlDQoNCkRl YXIgYWxsLA0KDQpJJ20gZ2V0dGluZyBhIGJpdCBjb25mdXNlZCAtIEkgdGhvdWdodCB0aGF0IHRo ZXJlIHdhcyBzZW50aW1lbnQgdG8gbWF0Y2ggdGhlIGFwcHJvYWNoIGluIEcuODc0LjE7IHdhc24n dCB0aGF0IG9wdGlvbiAyPw0KDQpCZXN0IHJlZ2FyZHMsDQpFdmUNCg0KRnJvbTogTGVleW91bmcg W21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI4 LCAyMDE1IDAzOjA1IFBNDQpUbzogQlJVTkdBUkQsIERFQk9SQUggQSA8ZGIzNTQ2QGF0dC5jb20+ OyBMYW0sIEhpbmctS2FtIChLYW0pOyBhZHJpYW5Ab2xkZG9nLmNvLnVrIDxhZHJpYW5Ab2xkZG9n LmNvLnVrPjsgJ0dlcnQgR3JhbW1lbCcgPGdncmFtbWVsQGp1bmlwZXIubmV0PjsgJ0dpb3Zhbm5p IE1hcnRpbmVsbGkgKGdpb21hcnRpKScgPGdpb21hcnRpQGNpc2NvLmNvbT4NCkNjOiAnRG9vbGFu LCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKScgPHBhdWwuZG9vbGFuQGNvcmlhbnQuY29tPjsg Y2NhbXBAaWV0Zi5vcmcgPGNjYW1wQGlldGYub3JnPjsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYu b3JnIDxjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13 c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcgPGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24t ZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFZlbmRvci1T cGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5j b2RlDQoNCkhpIERlYm9yYWgsDQoNCkkgYWdyZWUgd2l0aCB3aGF0IHlvdSBzYWlkLiBUaGF0IHdh cyBteSBwb2ludC4gT3B0aW9uIDEgaXMgbXkgcHJlZmVyZW5jZSBhbmQgdGhlIFdHIGhhcyBhZ3Jl ZWQgb24gdGhhdCAsSSB0aGluay4NCg0KVGhhbmtzLA0KWW91bmcNCg0KRnJvbTogQlJVTkdBUkQs IERFQk9SQUggQSBbbWFpbHRvOmRiMzU0NkBhdHQuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51 YXJ5IDI4LCAyMDE1IDE6NTYgUE0NClRvOiBMZWV5b3VuZzsgTGFtLCBIaW5nLUthbSAoS2FtKTsg YWRyaWFuQG9sZGRvZy5jby51azsgJ0dlcnQgR3JhbW1lbCc7ICdHaW92YW5uaSBNYXJ0aW5lbGxp IChnaW9tYXJ0aSknDQpDYzogJ0Rvb2xhbiwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyknOyBj Y2FtcEBpZXRmLm9yZzsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWNj YW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbQ0NB TVBdIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAt cndhLXdzb24tZW5jb2RlDQoNCkhpIFlvdW5nLA0KDQpBcmUgeW91IHZvdGluZyBmb3Igb3B0aW9u IDM/DQoNCk15IHRob3VnaHRzIHdlcmUgaWYgKGJpZyBJRikgd2UgYXJlIGdvaW5nIHRvIGFsbG93 IHByb3ByaWV0YXJ5IEFwcGxpY2F0aW9uIElkZW50aWZpZXJzICh3aGljaCBTRzE1IGhhcyBhZ3Jl ZWQpIHRoZW4gYmVzdCB3b3VsZCBiZSBpZiB3ZSBjYW4gYXQgbGVhc3QgaGF2ZSBzb21lIHdheSB0 byBpZGVudGlmeSAoYmV0dGVyIHRoYW4gYW4gdW5kZWZpbmVkIHN0cmluZykuIEFzIHlvdSBzYXks IGl0IHN0aWxsIGRvZXMgbm90IGd1YXJhbnRlZSBpbnRlcm9wZXJhYmlsaXR5IHVubGVzcyBpdCBp cyB0aGUgc2FtZSB2ZW5kb3IgKGhvcGVmdWxseSApLiBJZiB0d28gZGlmZmVyZW50IHZlbmRvcnMg KGUuZy4gYmxhY2sgbGluayksIHRoZW4gaXQgd291bGQgYmUgZm9yIHRoZSB2ZW5kb3JzIChhbmQg b3BlcmF0b3IpIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5IGlmIHN1cHBvcnRpbmcgbm9uLXN0 YW5kYXJkIEFJcy4gQW5kIGFzIHdlIGtub3csIGl04oCZcyBub3QganVzdCB0aGUgQUkgdGhhdCBp cyBuZWVkZWQgdG8gZGV0ZXJtaW5lIGlmIGl0IHdpbGwgd29yayBwcm9wZXJseS4NCg0KVGhhbmtz LA0KRGVib3JhaA0KDQoNCkZyb206IExlZXlvdW5nIFttYWlsdG86bGVleW91bmdAaHVhd2VpLmNv bV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyOCwgMjAxNSAyOjMzIFBNDQpUbzogQlJVTkdB UkQsIERFQk9SQUggQTsgTGFtLCBIaW5nLUthbSAoS2FtKTsgYWRyaWFuQG9sZGRvZy5jby51azsg J0dlcnQgR3JhbW1lbCc7ICdHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknDQpDYzogJ0Rv b2xhbiwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyknOyBjY2FtcEBpZXRmLm9yZzsgY2NhbXAt Y2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5h bGxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBB cHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlDQoNCkhp IERlYm9yYWgsDQoNClRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIG9wZXJhdG9y4oCZcyBwZXJzcGVj dGl2ZS4gIEkgYW0gd29uZGVyaW5nIGhvdyB0aGUgT1VJIHdvdWxkIHJlYWxseSBoZWxwIGZvciBp bnRlcm9wZXJhYmlsaXR5IG90aGVyIHRoYW4gaWRlbnRpZnlpbmcgdGhlIHNwZWNpZmljIHZlbmRv cnMgdGhhdCBhcmUgdXNpbmcgdGhlaXIgcHJvcHJpZXRhcnkgY29kZS4NCg0KU2F5IHZlbmRvciBB IHVzZXMgRkVDIHR5cGUgQSB3aGlsZSB2ZW5kb3IgQiB1c2VkIEZFQyB0eXBlIEIsIGFuZCBib3Ro IG9mIHRoZW0gYXJlIHByb3ByaWV0YXJ5IEZFQ3MuIEkgYmVsaWV2ZSB0aGUgT1VJIHdpbGwgaGVs cCB0aGUgb3BlcmF0b3IgaWRlbnRpZnkgdGhpcyBmYWN0IGFuZCBjb25jbHVkZSB0aGUgc3lzdGVt cyBhcmUgbm90IGNvbXBhdGlibGUuIEJ1dCB3b3VsZCB0aGlzIHJlYWxseSBoZWxwIG9wZXJhdG9y cyB0b3dhcmQgaW50ZXJvcGVyYWJpbGl0eT8gSSBiZWxpZXZlIGEgYmV0dGVyIHdheSBmb3Igb3Bl cmF0b3JzIHRvIGF0dGFpbiBpbnRlcm9wZXJhYmlsaXR5IGlzIHRvIGZvcmNlIHZlbmRvcnMgdXNl IHN0YW5kYXJkIEZFQ3MgYW5kIGhhdmUgdGhlbSBhZ3JlZSBvbiB0aGUgc2FtZSB0eXBlIG9mIEZF Q3Mgd2l0aGluIHRoZSBzdGFuZGFyZCBGRUNzLiBNeSBwb2ludCBpcyBob3cgdmVuZG9yIHNwZWNp ZmljIGNvZGUgd291bGQgYmUgcmVhbGx5IGhlbHBmdWwgZXZlbiBpZiB3ZSBlbXBsb3kgdGhlIE9V SSBmaWVsZC4NCg0KVGhhbmtzLA0KWW91bmcNCg0KRnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQlJVTkdBUkQsIERFQk9SQUggQQ0KU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDI4LCAyMDE1IDExOjQ2IEFNDQpUbzogTGFtLCBIaW5nLUthbSAo S2FtKTsgYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az47ICdH ZXJ0IEdyYW1tZWwnOyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJw0KQ2M6ICdEb29s YW4sIFBhdWwgKENvcmlhbnQgLSBVUy9JcnZpbmcpJzsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNj YW1wQGlldGYub3JnPjsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpjY2FtcC1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5h bGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2Rl LmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZp YyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlDQoN CkhpIEFsbCwNCg0KQXMgTG91IG5vdGVkLCBBZHJpYW7igJlzIG9wdGlvbiAxIHdhcyB0aGUgaW50 ZW50aW9uIGFzIHRoaXMgd2FzIGRpc2N1c3NlZCB3aGVuIEc4NzIgd2FzIGJlaW5nIHJldmlzZWQg dG8gaW50cm9kdWNlIEFwcGxpY2F0aW9uIElkZW50aWZpZXIgKElFVEbigJlzIE1hcmNoIDIwMTMg bWVldGluZykuIEFzIEthbSBub3RlcywgSVRV4oCZcyB3b3JrIG9uIEcuODc0LjEgaGFzIGV2b2x2 ZWQgdG8gaW5jbHVkZSB0aGUgT1VJLg0KDQpBcyBhIG5ldHdvcmsgb3BlcmF0b3IsIEkgcHJlZmVy IGFzIEFkcmlhbiBzYXlzIOKAkyBsZXTigJlzIGF0dGVtcHQgdG8gbWF0Y2ggZHJhZnQgRy44NzQu MSAoaXQgZG9lcyBoYXZlIGFncmVlbWVudCkuIFNvIEFkcmlhbuKAmXMgb3B0aW9uIDIuIFdoaWxl IHRoZSBjb250ZXh0IG9mIHRoaXMgd29yayBpcyB3aXRoaW4gYW4gb3BlcmF0b3LigJlzIG5ldHdv cmssIHRoZSBPVUkgd2lsbCBoZWxwIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpBZHJp YW4g4oCTIGdvb2QgY2F0Y2gtDQpEZWJvcmFoDQoNCkZyb206IENDQU1QIFttYWlsdG86Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhbSwgSGluZy1LYW0gKEthbSkNClNlbnQ6 IFN1bmRheSwgSmFudWFyeSAyNSwgMjAxNSA4OjUwIFBNDQpUbzogYWRyaWFuQG9sZGRvZy5jby51 azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az47ICdHZXJ0IEdyYW1tZWwnOyAnR2lvdmFubmkg TWFydGluZWxsaSAoZ2lvbWFydGkpJw0KQ2M6ICdEb29sYW4sIFBhdWwgKENvcmlhbnQgLSBVUy9J cnZpbmcpJzsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPjsgY2NhbXAtY2hh aXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBk cmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGluIGRy YWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlDQoNCkhpIEFkcmlhbiwNCg0KWWVzLCB3aGls ZSBRMTQvMTUgYWxyZWFkeSByZWFjaGVkIGFncmVlbWVudCB0byB1cGRhdGUgdGhlIEFwcGxpY2F0 aW9uIElkZW50aWZpZXIgZGVzY3JpcHRpb24sIHRoZSB1cGRhdGUgaGFzIG5vdCBiZWVuIGZvcm1h bGx5IGFwcHJvdmVkIGFuZCBwdWJsaXNoZWQgYnkgU0cxNSB5ZXQuIFExNC8xNSBtYXkgYmUgYWJs ZSB0byBjb25zZW50IHRoaXMgdXBkYXRlIGFzIGFuIEFtZW5kbWVudCB0byBHLjg3NC4xIGF0IHRo ZSB1cGNvbWluZyBTRzE1IG1lZXRpbmcgaW4gSnVseSAyMDE1Lg0KDQpSZWdhcmRzLA0KS2FtDQoN CkZyb206IEFkcmlhbiBGYXJyZWwgW21haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrXQ0KU2VudDog RnJpZGF5LCBKYW51YXJ5IDIzLCAyMDE1IDE6NTkgUE0NClRvOiBMYW0sIEhpbmctS2FtIChLYW0p OyAnR2VydCBHcmFtbWVsJzsgJ0dpb3Zhbm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKScNCkNjOiAn RG9vbGFuLCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKSc7IGNjYW1wQGlldGYub3JnPG1haWx0 bzpjY2FtcEBpZXRmLm9yZz47IGNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86Y2Nh bXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNv ZGUuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVu Y29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBWZW5kb3ItU3Bl Y2lmaWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29k ZQ0KDQpUaGFua3MgZm9yIGJlaW5nIGF3YWtlLCBLYW0uDQoNClVzZWZ1bCBpbmZvLg0KDQpHZXJ0 LCB0aGUgT1VJIHJlZ2lzdHJ5IGlzIGFuIElFRUUgcmVnaXN0cnkgYXMgS2FtIHNheXMuIElBTkEg aGFzIGEgcmVnaXN0cnkgcGFnZSBmb3IgdGhpcywgYnV0IGl0IHBvaW50cyB0byB0aGUgSUVFRSBw YWdlLg0KDQpBcyBJIHVuZGVyc3RhbmQgS2FtLCA4NzQuMSBpcyBub3QgeWV0IHVwZGF0ZWQgc28g aXQgd291bGQgYmUgcHJlbWF0dXJlIHRvIHBvaW50IHRvIGl0LCBidXQgYW4gb3B0aW9uIGlzIHRv IGF0dGVtcHQgdG8gbWF0Y2ggaXQgbm93IGFuZCBmaXggbGF0ZXIgaWYgbmVlZGVkLg0KDQpBZHJp YW4NCg0KRnJvbTogTGFtLCBIaW5nLUthbSAoS2FtKSBbbWFpbHRvOmthbS5sYW1AYWxjYXRlbC1s dWNlbnQuY29tXQ0KU2VudDogMjMgSmFudWFyeSAyMDE1IDE3OjEwDQpUbzogR2VydCBHcmFtbWVs OyBhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPjsgJ0dpb3Zh bm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKScNCkNjOiBEb29sYW4sIFBhdWwgKENvcmlhbnQgLSBV Uy9JcnZpbmcpOyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBjY2FtcC1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZz47 IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPg0K U3ViamVjdDogUkU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4g ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUNCg0KSGkgR2VydCwNCg0KQSB2ZW5kb3Ig Y2FuIHB1cmNoYXNlIGFuIE9VSSAoT3JnYW5pemF0aW9uYWxseSBVbmlxdWUgSWRlbnRpZmllcikg ZnJvbSB0aGUgSUVFRSBSZWdpc3RyYXRpb24gQXV0aG9yaXR5Lg0KT25jZSBhIHZlbmRvciBoYXMg aXRzIE9VSSwgdGhlIHZlbmRvciBjYW4gbWFuYWdlIGl0cyB2ZW5kb3Itc3BlY2lmaWMgYXBwbGlj YXRpb24gaWRlbnRpZmllcnMgdW5kZXIgaXRzIG93biBPVUkuDQpTRzE1IGRvZXNu4oCZdCBuZWVk IHRvIGhvc3QgYW55IHJlZ2lzdHJ5IGZvciB0aGlzIHB1cnBvc2UuDQoNClJlZ2FyZHMsDQpLYW0N Cg0KRnJvbTogR2VydCBHcmFtbWVsIFttYWlsdG86Z2dyYW1tZWxAanVuaXBlci5uZXRdDQpTZW50 OiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUgMTE6NDkgQU0NClRvOiBMYW0sIEhpbmctS2FtIChL YW0pOyBhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPjsgJ0dp b3Zhbm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKScNCkNjOiBEb29sYW4sIFBhdWwgKENvcmlhbnQg LSBVUy9JcnZpbmcpOyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBjY2Ft cC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9y Zz47IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUg aW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUNCg0KSGkgS2FtLA0KDQpJcyBTRzE1 IGNvbnNpZGVyaW5nIHRvIGhvc3QgYSByZWdpc3RyeSBmb3IgdGhlIHZlbmRvciBzcGVjaWZpYyBh cHBsaWNhdGlvbiBjb2RlIG9yIGlzIHRoZSBJRVRGIHJlZ2lzdHJ5IHN1cHBvc2VkIHRvIGJlIHVz ZWQ/DQoNClRoYW5rcw0KDQpHZXJ0DQoNCkZyb206IENDQU1QIFttYWlsdG86Y2NhbXAtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhbSwgSGluZy1LYW0gKEthbSkNClNlbnQ6IDIzIEph bnVhcnkgMjAxNSAxNzowMw0KVG86IGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWs+OyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJw0KQ2M6IERvb2xh biwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyk7IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2Ft cEBpZXRmLm9yZz47IGNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86Y2NhbXAtY2hh aXJzQHRvb2xzLmlldGYub3JnPjsgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxs QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5h bGxAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMg QXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZQ0KDQoN CkRlYXIgYWxsLA0KDQoNCg0KRm9yIHlvdXIgaW5mb3JtYXRpb24uIEluIHRoZSBsYXN0IFNHMTUg bWVldGluZywgUTE0LzE1IGFncmVlZCB0byB1cGRhdGUgRy44NzQuMSB0byBhbWVuZCB0aGUgc3Bl Y2lmaWNhdGlvbiBvZiBBcHBsaWNhdGlvbklkZW50aWZpZXIgd2l0aCB0aGUgZm9sbG93aW5nIGFk ZGl0aW9uYWwgdGV4dDoNCg0KDQoNCklmIHRoZSBBcHBsaWNhdGlvbklkZW50aWZpZXJUeXBlIGlz IFNUQU5EQVJELCB0aGUgdmFsdWUgb2YgUHJpbnRhYmxlU3RyaW5nIHJlcHJlc2VudHMgYSBzdGFu ZGFyZCBhcHBsaWNhdGlvbiBjb2RlIGFzIGRlZmluZWQgaW4gdGhlIElUVS1UIFJlY29tbWVuZGF0 aW9ucy4gSWYgdGhlIEFwcGxpY2F0aW9uSWRlbnRpZmllclR5cGUgaXMgUFJPUFJJRVRBUlksIHRo ZSBmaXJzdCBzaXggY2hhcmFjdGVycyBvZiB0aGUgUHJpbnRhYmxlU3RyaW5nIG11c3QgY29udGFp biB0aGUgSGV4YWRlY2ltYWwgcmVwcmVzZW50YXRpb24gb2YgYW4gT1VJIGFzc2lnbmVkIHRvIHRo ZSB2ZW5kb3Igd2hvc2UgaW1wbGVtZW50YXRpb24gZ2VuZXJhdGVkIHRoZSBBcHBsaWNhdGlvbiBJ ZGVudGlmaWVyOyB0aGUgcmVtYWluaW5nIG9jdGV0cyBvZiB0aGUgUHJpbnRhYmxlU3RyaW5nIGFy ZSB1bnNwZWNpZmllZC4NCg0KDQoNClBhdWwgRG9vbGFuIGhhZCBhbiBJLUQgImh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kb29sYW4tcHJvcHJpZXRhcnktYWMtMDAiIHRvIHRoZSBs YXN0IElFVEYgbWVldGluZyB3aXRoIHRoZSBzaW1pbGFyIHByb3Bvc2FsLg0KDQoNCg0KUmVnYXJk cywNCg0KS2FtDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBDQ0FN UCBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFy cmVsDQoNClNlbnQ6IEZyaWRheSwgSmFudWFyeSAyMywgMjAxNSA5OjQxIEFNDQoNClRvOiAnR2lv dmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJw0KDQpDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRv OmNjYW1wQGlldGYub3JnPjsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpjY2Ft cC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29k ZS5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5j b2RlLmFsbEB0b29scy5pZXRmLm9yZz4NCg0KU3ViamVjdDogW0NDQU1QXSBWZW5kb3ItU3BlY2lm aWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZQ0K DQoNCg0KSGksDQoNCg0KDQpJIGFwcHJlY2lhdGUgdGhpcyBkaXNjdXNzaW9uLCBidXQgSSBhbSBu b3Qgc2VlaW5nIGEgc3BlY2lmaWMgY29uY2x1c2lvbiBmcm9tIGl0Lg0KDQoNCg0KVGhlIGN1cnJl bnQgSS1EIG1ha2VzIChJTUhPKSB0aGUgVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUg dW51c2FibGUuIEkgb2ZmZXJlZCB0aHJlZSBvcHRpb25zOg0KDQoNCg0KMSBUaGlzIHZhbHVlIGlz IG9ubHkgdG8gYmUgdXNlZCB3aGVuIGl0IGlzIGtub3duIHRoYXQgYWxsIGRldmljZXMNCg0KICAg cGFydGljaXBhdGluZyBpbiBhIG5ldHdvcmsgaGF2ZSB0aGUgc2FtZSB1bmRlcnN0YW5kaW5nIG9m DQoNCiAgIHRoZSBjb250ZW50IG9mIHRoZSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29k ZSBmaWVsZC4NCg0KICAgSG93IHRoaXMga25vd2xlZGdlIGlzIGFjaGlldmVkIGlzIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoaXMNCg0KICAgZG9jdW1lbnQNCg0KDQoNCjIgV2hlbiB0aGlzIHZhbHVl IGlzIHNldCwgdGhlIGZpcnN0IDMyIChvciA0OCkgYml0cyBvZiB0aGUgVmVuZG9yLQ0KDQogIFNw ZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgZmllbGQgY29udGFpbiBhbiBFbnRlcnByaXNlIE51bWJl cg0KDQogIChvciBPVUkpIHRoYXQgZGVmaW5lcyB0aGUgY29udGV4dCBpbiB3aGljaCB0aGUgcmVt YWluZGVyIG9mDQoNCiAgdGhhdCBmaWVsZCBpcyBpbnRlcnByZXRlZC4NCg0KDQoNCjMgUmVtb3Zl IHRoZSBvcHRpb24gdG8gaW5jbHVkZSBhIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbg0KDQog ICBDb2RlIGZpZWxkLg0KDQoNCg0KSWYgdGhlIFdHIGNvdWxkIHBsZWFzZSBwaWNrIG9uZSBvZiB0 aGVzZSBhbmQgaGVscCBZb3VuZyB0byB1cGRhdGUgdGhlIGRvY3VtZW50Lg0KDQoNCg0KVGhhbmtz LA0KDQpBZHJpYW4NCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiBGcm9t OiBHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSkgW21haWx0bzpnaW9tYXJ0aUBjaXNjby5j b21dDQoNCj4gU2VudDogMjMgSmFudWFyeSAyMDE1IDEzOjUwDQoNCj4gVG86IGFkcmlhbkBvbGRk b2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+DQoNCj4gQ2M6IExlZXlvdW5nOyBk cmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZz47DQoN Cj4gY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPjsgY2NhbXAtY2hhaXJzQHRv b2xzLmlldGYub3JnPG1haWx0bzpjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQoNCj4gU3Vi amVjdDogUmU6IFtDQ0FNUF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24t ZW5jb2RlDQoNCj4NCg0KPiBPbmUgYWRkaXRpb25hbCBjb21tZW50IChob3Bpbmcgbm90IGFkZGl0 aW9uYWwgY29uZnVzaW9uKS4NCg0KPg0KDQo+IFRoZSBpZGVhIGFib3V0IE9wdGljYWwgSW50ZXJm YWNlIENsYXNzIHdhcyB0YWtlbiBmcm9tIFNSTEcuIEdvb2Qgb3INCg0KPiBiYWQgaXMgYSBwbGFp biBudW1iZXIgYW5kIHlvdSBkbyBzaW1wbGUgb3BlcmF0aW9ucyBvbiBpdC4NCg0KPg0KDQo+IENo ZWVycw0KDQo+IEcNCg0KPg0KDQo+IE9uIDIyIEphbiAyMDE1LCBhdCAwOTo0MiwgR2lvdmFubmkg TWFydGluZWxsaSAoZ2lvbWFydGkpDQoNCj4gPGdpb21hcnRpQGNpc2NvLmNvbTxtYWlsdG86Z2lv bWFydGlAY2lzY28uY29tPj4NCg0KPiB3cm90ZToNCg0KPg0KDQo+ID4gSGkgQWRyaWFuLA0KDQo+ ID4NCg0KPiA+IE9uIDIxIEphbiAyMDE1LCBhdCAyMjo1NSwgQWRyaWFuIEZhcnJlbCA8YWRyaWFu QG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+IHdyb3RlOg0KDQo+ID4N Cg0KPiA+PiBIaSwNCg0KPiA+Pg0KDQo+ID4+IFdlbGwsIHlvdSBzZWVtIHRvIGhhdmUgYSBoYWxm LXdheSBob3VzZS4NCg0KPiA+Pg0KDQo+ID4+IFlvdSBoYXZlIHNwZWNpZmllZCB0aGUgZXhpc3Rl bmNlIG9mIGEgdGhpbmcsIGJ1dCBub3QgaG93IHRvIHJlYWQgaXQuDQoNCj4gPj4NCg0KPiA+PiBJ ZiB5b3Ugd2FudGVkIHRvIG1ha2UgYSBzdGF0ZW1lbnQgdGhhdCB0aGlzIG9iamVjdCB3aWxsIG9u bHkgYmUNCg0KPiA+PiB1c2VkIHdoZW4NCg0KaXQgaXMNCg0KPiA+PiBrbm93biB0aGF0IGFsbCBz eXN0ZW1zIGluIGEgbmV0d29yayBjb21lIGZyb20gdGhlIHNhbWUgdmVuZG9yDQoNCj4gPj4gYW5k L29yIGhhdmUNCg0KPiB0aGUNCg0KPiA+PiBzYW1lIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGVuY29k aW5nLCB0aGF0IG1pZ2h0IGJlIE9LIChhbHRob3VnaCBob3cNCg0KPiA+PiB5b3UNCg0KPiB3b3Vs ZA0KDQo+ID4+IGFzY2VydGFpbiB0aGlzIG1pZ2h0IGFsc28gbmVlZCB0byBiZSBkZXNjcmliZWQp Lg0KDQo+ID4+DQoNCj4gPg0KDQo+ID4gVGhlIHN0YXRlbWVudCBpcyB0byBlbnN1cmUgdGhlIGlu dGVyZmFjZSBjb21wYXRpYmlsaXR5IHdpdGhvdXQNCg0KPiA+IGVuY29kaW5nIGFsbA0KDQp0aGUN Cg0KPiBwb3NzaWJsZSBkZXRhaWxzIGFuZCBwYXJhbWV0ZXIgdGhhdCBkZWZpbmUgYW4gaW50ZXJm YWNlIChlLmcuDQoNCj4gbW9kdWxhdGlvbg0KDQpmb3JtYXQsDQoNCj4gZm9yd2FyZCBlcnJvciBj b3JyZWN0aW9uIGV0Yy4pLiBUaGlzIHdhcyB0aGUgaW5pdGlhbCBzb2x1dGlvbiBpbiB0aGUNCg0K PiBkcmFmdA0KDQp0aGVuDQoNCj4gcmVwbGFjZWQgYnkgdGhlIGludGVyZmFjZSBjbGFzcyBjb25j ZXB0LiAgIFRoZSBXU09OIChSV0Etb25seSkgaGFzIHRoZQ0KDQo+IHJlcXVpcmVtZW50IGlzIHRv IG1ha2Ugc3VyZSB0d28gaW50ZXJmYWNlIGFyZSBjb21wYXRpYmxlLiBUaGlzDQoNCj4gcmVxdWly ZW1lbnQsIGltaG8sIGNhbiBiZSBzYXRpc2Z5IGJ5IGEgc2ltcGxlIGNvbXBhcmlzb24gd2hpY2gg aGFzIGEgYm9vbGVhbiByZXN1bHQuDQoNCj4gPg0KDQo+ID4gV2UgZW5kIHVwIHRoZW4gaW4gIHRo ZSBJVFUgYXBwbGljYXRpb24gY29kZXMgZm9yIHRoZSAiY2VydGlmaWVkIg0KDQo+ID4gKHdlJ2xs IHRoaXMNCg0KaXMgbXkNCg0KPiB0ZXJtIG5vdCAxMDAlIHN1cmUgaXMgdGhlIGJlc3Qgb25lKSBj b21wYXRpYmlsaXR5IHdoZXJlIHByb3Blcg0KDQo+IGVuY29kaW5nIGlzIHByb3ZpZGVkLg0KDQo+ ID4NCg0KPiA+DQoNCj4gPj4gT3IgeW91IGNvdWxkIGVudGlyZWx5IHJlbW92ZSB0aGUgdmVuZG9y LXNwZWNpZmljIG9wdGlvbi4NCg0KPiA+Pg0KDQo+ID4+IE9yIHlvdSBjb3VsZCBwdXQgaW4gYW4g T1VJIC8gZW50ZXJwcmlzZSBudW1iZXIgZm9sbG93ZWQgYnkNCg0KPiA+PiB0cmFuc3BhcmVudA0K DQo+IGJ5dGVzLg0KDQo+ID4+DQoNCj4gPg0KDQo+ID4gVG8gbWUgSSdtIHBlcmZlY3RseSBmaW5l IHdpdGggdGhlIHNlY29uZCBvcHRpb24uDQoNCj4gPg0KDQo+ID4gQ2hlZXJzDQoNCj4gPiBHDQoN Cj4gPg0KDQo+ID4NCg0KPiA+PiBBZHJpYW4NCg0KPiA+Pg0KDQo+ID4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KDQo+ID4+PiBGcm9tOiBHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0 aSkgW21haWx0bzpnaW9tYXJ0aUBjaXNjby5jb21dDQoNCj4gPj4+IFNlbnQ6IDIxIEphbnVhcnkg MjAxNSAyMToyMg0KDQo+ID4+PiBUbzogYWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFu QG9sZGRvZy5jby51az4NCg0KPiA+Pj4gQ2M6IExlZXlvdW5nOyBkcmFmdC1pZXRmLWNjYW1wLXJ3 YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAt cndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZz47DQoNCj4gPj4+IGNjYW1wQGlldGYu b3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz47IGNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzxt YWlsdG86Y2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KDQo+ID4+PiBTdWJqZWN0OiBSZTog W0NDQU1QXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUNCg0K PiA+Pj4NCg0KPiA+Pj4gU3BlY2lmaWNhbGx5IHRvIHRoZSBJbnRlcmZhY2UgY2xhc3MgaGVyZSBi ZWxvdy4NCg0KPiA+Pj4NCg0KPiA+Pj4gSW4gdGhlIGluaXRpYWwgZHJhZnQgbWVyZ2VkIHRvIHRo aXMgb25lIHRoZXJlIHdhcyB0aGUgdXNhZ2Ugb2YgT1VJDQoNCj4gPj4+IGhvd2V2ZXINCg0KKEkN Cg0KPiA+Pj4gZ3Vlc3MgYWZ0ZXIgY2hhdHRpbmcgd2l0aCBMb3UpIHdlIGRlY2lkZWQgdG8gcmVt b3ZlIGFueSBlbmNvZGluZw0KDQo+ID4+PiB3aGVuIHRoZSBJbnRlcmZhY2UgY2xhc3MgaXMgbm90 IHN0YW5kYXJkLg0KDQo+ID4+PiBJbiB0ZXJtIG9mIHNlbWFudGljIHRoZSBwcm90Y29sIGRvZXMg bm90IG5lZWQgdG8gZGVjb2RlIHRoZQ0KDQo+ID4+PiBJbnRlcmZhY2UNCg0KY2xhc3MNCg0KPiA+ PiBzaW5jZQ0KDQo+ID4+PiBpdCBvbmx5IGFzc2VzcyB0aGUgaW50ZXJmYWNlIGNvbXBhdGliaWxp dHkgaWYgdHdvIGludGVyZmFjZXMgaGFzIGENCg0KPiA+Pj4gY2xhc3MNCg0KdmFsdWUNCg0KPiA+ PiB0aGF0DQoNCj4gPj4+IG1hdGNoIHR3byBpbnRlcmZhY2VzIGNhbm4gYmUgY29ubmVjdGVkLg0K DQo+ID4+Pg0KDQo+ID4+PiBIYXZpbmcgc2F5aW5nIHRoYXQgSSBkb24ndCBoYXZlIHN0cm9uZyBv cGluaW9uIGluIGFkZGluZyB0aGUgT1VJDQoNCj4gPj4+IG9yDQoNCmxlYXZpbmcNCg0KPiA+PiBy b29tDQoNCj4gPj4+IGZvciBtYXliZSBmdXR1cmUgcHVibGljIGludGVyZmFjZXMgZGF0YWJhc2Uu IEZvciBzdXJlIHRoZXJlJ3MgYQ0KDQo+ID4+PiBuZWVkIHRvDQoNCmxlYXZlDQoNCj4gPj4+IHJv b20gZm9yIHNwZWNpZmljIGNvbXBhdGliaWxpdHkgYXNzZXNtZW50IHNpbmNlIHRoZXJlIG9wdGlj YWwNCg0KPiA+Pj4gbXVsdGl2ZW5kb3IgY29tcGF0aWJpbGl0eSBoYXMgYmVlbiBhbHJlYWR5IGRl bW9uc3RyYXRlZC4NCg0KPiA+Pj4NCg0KPiA+Pj4gaG9wZSB0aGlzIGhlbHAgLg0KDQo+ID4+Pg0K DQo+ID4+PiBDaGVlcnMNCg0KPiA+Pj4gRw0KDQo+ID4+Pg0KDQo+ID4+Pg0KDQo+ID4+PiBPbiAy MSBKYW4gMjAxNSwgYXQgMjE6NTcsIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8 bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+PiB3cm90ZToNCg0KPiA+Pj4NCg0KPiA+Pj4+Pj4N Cg0KPiA+Pj4+Pj4gU2VjdGlvbiA0LjENCg0KPiA+Pj4+Pj4gSG93IGRvIEkgaW50ZXJwcmV0IGEg VmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGU/IElzIHRoZXJlDQoNCj4gPj4+Pj4+IGFu IE9VSSBJJ20gbWlzc2luZz8NCg0KPiA+Pj4+Pg0KDQo+ID4+Pj4+IFtZT1VOR10gTm90IHN1cmUg aWYgSSB1bmRlcnN0b29kIHRoaXMgcXVlc3Rpb24uIFdoYXQgaXMgIk9VSSI/DQoNCj4gPj4+Pg0K DQo+ID4+Pj4gaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Pcmdhbml6YXRpb25hbGx5X3Vu aXF1ZV9pZGVudGlmaWVyDQoNCj4gPj4+PiBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz L2llZWUtODAyLW51bWJlcnMvaWVlZS04MDItDQoNCj4gPj4+IG51bWJlcnMueGh0bWwjaWVlZS04 MDINCg0KPiA+Pj4+IC1udW1iZXJzLTINCg0KPiA+Pj4+DQoNCj4gPj4+PiBPciBwZXJoYXBzIGFu IEVudGVycHJpc2UgTnVtYmVyDQoNCj4gPj4+PiBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL2VudGVycHJpc2UtbnVtYmVycy9lbnRlcnByaXNlLQ0KDQo+IG51bWJlcnMNCg0KPiA+Pj4+ DQoNCj4gPj4+PiBUaGUgcXVlc3Rpb24gaXM6DQoNCj4gPj4+Pg0KDQo+ID4+Pj4gWW91IGhhdmUg c2VjdGlvbnMgNC4xLjEgdGhyb3VnaCA0LjEuNCB0byB0ZWxsIG1lIGhvdyB0byBpbnRlcnByZXQN Cg0KPiA+Pj4+IHRoZQ0KDQo+ID4+IE9wdGljYWwNCg0KPiA+Pj4+IEludGVyZmFjZSBDbGFzcyBm aWVsZCB3aGVuIGl0IGNvbnRhaW5zIGFuIElUVS1UIEFwcGxpY2F0aW9uIE1hcHBpbmcuDQoNCj4g Pj4+PiBXaGVuIEkgcmVjZWl2ZWQgcz0wIGFuZCBPST0xIGl0IG1lYW5zIHRoYXQgdGhlIE9wdGlj YWwgSW50ZXJmYWNlDQoNCj4gPj4+PiBDbGFzcw0KDQo+ID4+IGNvbnRhaW5zDQoNCj4gPj4+PiBh ICJWZW5kb3IgU3BlY2lmaWMgT3B0aWNhbCBJbnRlcmZhY2UgQ2xhc3MiLg0KDQo+ID4+Pj4gSG93 IGRvIEkgaW50ZXJwcmV0IHRoYXQgT3B0aWNhbCBJbnRlcmZhY2UgQ2xhc3M/DQoNCj4gPj4+PiBX aGljaCB2ZW5kb3IgZG9lcyBpdCBhcHBseSB0bz8NCg0KPiA+Pj4+IElzIHRoZXJlIHNvbWUgaW5m b3JtYXRpb24gZWxzZXdoZXJlIHRoYXQgZ2l2ZXMgbWUgYSBjbHVlIGFzIHRvDQoNCj4gPj4+PiB3 aGljaA0KDQo+IHZlbmRvcg0KDQo+ID4+PiBoYXMNCg0KPiA+Pj4+IGVuY29kZWQgdGhlIGluZm9y bWF0aW9uPw0KDQo+ID4+Pj4gT3IgaXMgdGhlIGluZm9ybWF0aW9uIHN1cHBvc2VkIHRvIGJlIGVu Y29kZWQgaW4gdGhlIE9wdGljYWwNCg0KPiA+Pj4+IEludGVyZmFjZQ0KDQpDbGFzcywNCg0KPiA+ Pj4+IHBlcmhhcHMgYXMgdGhlIGZpcnN0IDQ4IGJpdHM/DQoNCj4gPj4+PiBPciBhbSBJIHN1cHBv c2VkIHRvIGtub3cgYnkgY29udGV4dD8NCg0KPiA+Pg0KDQo+ID4NCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNDQU1QIG1haWxpbmcgbGlz dA0KDQpDQ0FNUEBpZXRmLm9yZzxtYWlsdG86Q0NBTVBAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== --_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F161dfweml706chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0 Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0 IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBh bHdheXMgYSBwcmlvcmkga25vd2xlZGdlIGluIG9wdGljYWwgbmV0d29yayBkb21haW4gYXMgdG8g d2hvIGFyZSB5b3UgaW50ZXJmYWNpbmcgd2l0aC4gU28geW91IGtub3cgd2hpY2ggdmVuZG9yIHlv dSBhcmUgaW50ZXJmYWNpbmcuIElmIHlvdSBkbyBub3Qga25vdywgdGhlbiB5b3UgYXJlIGluIHRy b3VibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ob3csIHdoYXQgaXMg dGhlIHB1cnBvc2Ugb2Ygc3RhbmRhcmQgRkVDcyBhbmQgbW9kdWxhdGlvbnMgaW4gdGhlIEFJPyBH aXZlbiBzZXZlcmFsIGNob2ljZXMgZWFjaCB2ZW5kb3IgbWF5IHN1cHBvcnQgaW4gaXRzIGRldmlj ZSwgdGhlIHBhdGggY29tcHV0YXRpb24gd291bGQgZmluZCBhIG1hdGNoZWQgdHlwZXMgZm9yIEZF QyBhbmQgbW9kdWxhdGlvbiBmb3IgYSBnaXZlbg0KIG9wdGljYWwgcGF0aC4gVGhpcyBpcyB3aGF0 IGlzIGludGVuZGVkIHdoZW4gb3B0aWNhbCBzaWduYWwgcHJvY2Vzc2luZyBjb25zdHJhaW50cyB3 ZXJlIHByb3Bvc2VkIGFzIHBhcnQgb2YgcGF0aCBjb21wdXRhdGlvbiBjb25zdHJhaW50cyBpbiBv cHRpY2FsIG5ldHdvcmtzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5U aGVyZSBpcyB2ZXJ5IGxpdHRsZSBjaGFuY2UgZm9yIHZlbmRvciBzcGVjaWZpYyBGRUNzIGFuZCBN b2R1bGF0aW9ucyB3aWxsIG1hdGNoIGV2ZW4gaWYgdGhleSBhcmUgaWRlbnRpZmllZCB3aXRoIHRo ZSBPVUkgY29kZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TXkgdHdv IGNlbnRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Zb3VuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFkcmlhbiBGYXJyZWwgW21haWx0bzph ZHJpYW5Ab2xkZG9nLmNvLnVrXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFy eSAyOCwgMjAxNSAyOjQxIFBNPGJyPg0KPGI+VG86PC9iPiAnVmFybWEsIEV2ZSBMIChFdmUpJzsg TGVleW91bmc7IGRiMzU0NkBhdHQuY29tOyAnTGFtLCBIaW5nLUthbSAoS2FtKSc7IGdncmFtbWVs QGp1bmlwZXIubmV0OyBnaW9tYXJ0aUBjaXNjby5jb208YnI+DQo8Yj5DYzo8L2I+IHBhdWwuZG9v bGFuQGNvcmlhbnQuY29tOyBjY2FtcEBpZXRmLm9yZzsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYu b3JnOyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0 aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkV2ZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hhdCBqb3khPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldlJ3ZlIHdhaXRl ZCBhbGwgdGhlc2UgeWVhcnMgdG8gYmUgaWRlbnRpY2FsbHkgY29uZnVzZWQ6LSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSB0 aGluayB0aGUgY29uZnVzaW9uIG1heSBjb21lIGZyb20gWW91bmcgc2F5aW5nIHRoYXQga25vd2lu ZyB0aGUgT1UgbWFrZXMgbm8gZGlmZmVyZW5jZSB0byBpbnRlcm9wLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SSB0aGluayB0aGF0IGlzIGZhbHNlIGJlY2F1c2U6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4tIHlvdSBoYXZlIG5vIHdheSB0byBrbm93IHRoYXQgeW91ciBuZWlnaGJv ciBpcyBmcm9tIHRoZSBzYW1lIHZlbmRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7IChyZWNhbGwsIHRoaXMgaXMgYW4gTUNOIHByb3RvY29sKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+LSB5b3VyIGRldmljZSBtaWdodCBzdXBwb3J0IHdvcmtpbmcgd2l0aCBtdWx0aXBs ZSB2ZW5kb3JzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlNvIHRoZXJlIGFyZSB0d28gcG9zc2libGUgaW50ZXJ3b3JraW5nIGlz c3Vlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjEuIFlvdSBtaWdodCBjcmFzaCB0cnlp bmcgdG8gcHJvY2VzcyBhIGZpZWxkIGFzc3VtaW5nIGl0IGlzIG9uZSBvZiB5b3VycyB3aGVuIGl0 IGlzbid0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4yLiBZb3UgbWlnaHQgYmUgdW5hYmxl IHRvIGRpc2FtYmlndWF0ZSBmb3IgcmVhbCBpbnRlcm9wIGNob2ljZXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIHByb3Bv c2VkIEcuODc0LjEgYXBwcm9hY2ggc2VlbXMgZW50aXJlbHkgcGFpbmxlc3MgdG8gbWUgYW5kIHJl cXVpcmVzIG9ubHkgb25lIGxpbmUgb2YgYWRkaXRpb25hbCB0ZXh0LiBWaXouOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUg Zm9ybWF0IG9mIHRoZSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gSWRlbnRpZmllciBpcyBh IG1hdHRlciBmb3IgdGhlIHZlbmRvciBjb25jZXJuZWQgYW5kIG1heSBiZSBwcml2YXRlIG9yIHB1 Ymxpc2hlZCBpbiB2ZW5kb3Itc3BlY2lmaWMgZG9jdW1lbnRhdGlvbiwgYnV0IGluIGFsbCBjYXNl cyB0aGUgZmlyc3Qgc2l4IGNoYXJhY3RlcnMNCiBvZiB0aGUgVmVuZG9yLVNwZWNpZmljIEFwcGxp Y2F0aW9uIElkZW50aWZpZXIgTVVTVCBjb250YWluIHRoZSBoZXhhZGVjaW1hbCByZXByZXNlbnRh dGlvbiBvZiBhbiBPVUkgYXNzaWduZWQgdG8gdGhlIHZlbmRvciB3aG9zZSBpbXBsZW1lbnRhdGlv biBnZW5lcmF0ZWQgdGhlIEFwcGxpY2F0aW9uIElkZW50aWZpZXIuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklzIHRoYXQgc28g aGFyZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+QWRyaWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFZhcm1hLCBFdmUgTCAoRXZl KSBbbWFpbHRvOmV2ZS52YXJtYUBhbGNhdGVsLWx1Y2VudC5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gMjggSmFudWFyeSAyMDE1IDIwOjE3PGJyPg0KPGI+VG86PC9iPiAnbGVleW91bmdAaHVhd2Vp LmNvbSc7ICdkYjM1NDZAYXR0LmNvbSc7IExhbSwgSGluZy1LYW0gKEthbSk7ICdhZHJpYW5Ab2xk ZG9nLmNvLnVrJzsgJ2dncmFtbWVsQGp1bmlwZXIubmV0JzsgJ2dpb21hcnRpQGNpc2NvLmNvbSc8 YnI+DQo8Yj5DYzo8L2I+ICdwYXVsLmRvb2xhbkBjb3JpYW50LmNvbSc7ICdjY2FtcEBpZXRmLm9y Zyc7ICdjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1jY2FtcC1yd2Et d3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnJzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNj YW1wLXJ3YS13c29uLWVuY29kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkRlYXIgYWxsLDxicj4NCjxicj4NCkknbSBnZXR0aW5nIGEgYml0IGNvbmZ1c2VkIC0g SSB0aG91Z2h0IHRoYXQgdGhlcmUgd2FzIHNlbnRpbWVudCB0byBtYXRjaCB0aGUgYXBwcm9hY2gg aW4gRy44NzQuMTsgd2Fzbid0IHRoYXQgb3B0aW9uIDI/PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRz LDxicj4NCkV2ZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OiBMZWV5b3VuZyBbbWFpbHRvOmxl ZXlvdW5nQGh1YXdlaS5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjogV2VkbmVzZGF5LCBKYW51YXJ5 IDI4LCAyMDE1IDAzOjA1IFBNPGJyPg0KPGI+VG88L2I+OiBCUlVOR0FSRCwgREVCT1JBSCBBICZs dDtkYjM1NDZAYXR0LmNvbSZndDs7IExhbSwgSGluZy1LYW0gKEthbSk7IGFkcmlhbkBvbGRkb2cu Y28udWsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7OyAnR2VydCBHcmFtbWVsJyAmbHQ7Z2dy YW1tZWxAanVuaXBlci5uZXQmZ3Q7OyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJyAm bHQ7Z2lvbWFydGlAY2lzY28uY29tJmd0Ow0KPGJyPg0KPGI+Q2M8L2I+OiAnRG9vbGFuLCBQYXVs IChDb3JpYW50IC0gVVMvSXJ2aW5nKScgJmx0O3BhdWwuZG9vbGFuQGNvcmlhbnQuY29tJmd0Ozsg Y2NhbXBAaWV0Zi5vcmcgJmx0O2NjYW1wQGlldGYub3JnJmd0OzsgY2NhbXAtY2hhaXJzQHRvb2xz LmlldGYub3JnICZsdDtjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRm LWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYt Y2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZyZndDsNCjxicj4NCjxiPlN1 YmplY3Q8L2I+OiBSZTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBp biBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZQ0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkg RGVib3JhaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0 aCB3aGF0IHlvdSBzYWlkLiBUaGF0IHdhcyBteSBwb2ludC4gT3B0aW9uIDEgaXMgbXkgcHJlZmVy ZW5jZSBhbmQgdGhlIFdHIGhhcyBhZ3JlZWQgb24gdGhhdCAsSSB0aGluay4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Zb3VuZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEJSVU5HQVJELCBERUJPUkFIIEEgW21haWx0bzpkYjM1NDZAYXR0LmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMTUgMTo1NiBQTTxicj4NCjxiPlRv OjwvYj4gTGVleW91bmc7IExhbSwgSGluZy1LYW0gKEthbSk7IGFkcmlhbkBvbGRkb2cuY28udWs7 ICdHZXJ0IEdyYW1tZWwnOyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJzxicj4NCjxi PkNjOjwvYj4gJ0Rvb2xhbiwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyknOyBjY2FtcEBpZXRm Lm9yZzsgY2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13 c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtD Q0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2Ft cC1yd2Etd3Nvbi1lbmNvZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgWW91bmcsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BcmUgeW91IHZvdGluZyBmb3Igb3B0aW9uIDM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NeSB0aG91Z2h0cyB3ZXJlIGlmIChi aWcgSUYpIHdlIGFyZSBnb2luZyB0byBhbGxvdyBwcm9wcmlldGFyeSBBcHBsaWNhdGlvbiBJZGVu dGlmaWVycyAod2hpY2ggU0cxNSBoYXMgYWdyZWVkKSB0aGVuIGJlc3Qgd291bGQgYmUgaWYgd2Ug Y2FuIGF0IGxlYXN0IGhhdmUgc29tZSB3YXkgdG8gaWRlbnRpZnkgKGJldHRlciB0aGFuIGFuIHVu ZGVmaW5lZCBzdHJpbmcpLg0KIEFzIHlvdSBzYXksIGl0IHN0aWxsIGRvZXMgbm90IGd1YXJhbnRl ZSBpbnRlcm9wZXJhYmlsaXR5IHVubGVzcyBpdCBpcyB0aGUgc2FtZSB2ZW5kb3IgKGhvcGVmdWxs eSApLiBJZiB0d28gZGlmZmVyZW50IHZlbmRvcnMgKGUuZy4gYmxhY2sgbGluayksIHRoZW4gaXQg d291bGQgYmUgZm9yIHRoZSB2ZW5kb3JzIChhbmQgb3BlcmF0b3IpIHRvIGVuc3VyZSBpbnRlcm9w ZXJhYmlsaXR5IGlmIHN1cHBvcnRpbmcgbm9uLXN0YW5kYXJkIEFJcy4gQW5kIGFzDQogd2Uga25v dywgaXTigJlzIG5vdCBqdXN0IHRoZSBBSSB0aGF0IGlzIG5lZWRlZCB0byBkZXRlcm1pbmUgaWYg aXQgd2lsbCB3b3JrIHByb3Blcmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5EZWJvcmFoPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IExlZXlvdW5nIFttYWlsdG86bGVleW91bmdAaHVhd2VpLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMTUgMjozMyBQTTxicj4NCjxiPlRvOjwvYj4g QlJVTkdBUkQsIERFQk9SQUggQTsgTGFtLCBIaW5nLUthbSAoS2FtKTsgYWRyaWFuQG9sZGRvZy5j by51azsgJ0dlcnQgR3JhbW1lbCc7ICdHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknPGJy Pg0KPGI+Q2M6PC9iPiAnRG9vbGFuLCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKSc7IGNjYW1w QGlldGYub3JnOyBjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAt cndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS RTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRm LWNjYW1wLXJ3YS13c29uLWVuY29kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBEZWJvcmFoLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciBzaGFyaW5nIHlvdXIg b3BlcmF0b3LigJlzIHBlcnNwZWN0aXZlLiZuYnNwOyBJIGFtIHdvbmRlcmluZyBob3cgdGhlIE9V SSB3b3VsZCByZWFsbHkgaGVscCBmb3IgaW50ZXJvcGVyYWJpbGl0eSBvdGhlciB0aGFuIGlkZW50 aWZ5aW5nIHRoZSBzcGVjaWZpYyB2ZW5kb3JzIHRoYXQgYXJlIHVzaW5nIHRoZWlyIHByb3ByaWV0 YXJ5IGNvZGUuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U2F5 IHZlbmRvciBBIHVzZXMgRkVDIHR5cGUgQSB3aGlsZSB2ZW5kb3IgQiB1c2VkIEZFQyB0eXBlIEIs IGFuZCBib3RoIG9mIHRoZW0gYXJlIHByb3ByaWV0YXJ5IEZFQ3MuIEkgYmVsaWV2ZSB0aGUgT1VJ IHdpbGwgaGVscCB0aGUgb3BlcmF0b3IgaWRlbnRpZnkgdGhpcyBmYWN0IGFuZCBjb25jbHVkZSB0 aGUgc3lzdGVtcyBhcmUgbm90IGNvbXBhdGlibGUuIEJ1dA0KIHdvdWxkIHRoaXMgcmVhbGx5IGhl bHAgb3BlcmF0b3JzIHRvd2FyZCBpbnRlcm9wZXJhYmlsaXR5PyBJIGJlbGlldmUgYSBiZXR0ZXIg d2F5IGZvciBvcGVyYXRvcnMgdG8gYXR0YWluIGludGVyb3BlcmFiaWxpdHkgaXMgdG8gZm9yY2Ug dmVuZG9ycyB1c2Ugc3RhbmRhcmQgRkVDcyBhbmQgaGF2ZSB0aGVtIGFncmVlIG9uIHRoZSBzYW1l IHR5cGUgb2YgRkVDcyB3aXRoaW4gdGhlIHN0YW5kYXJkIEZFQ3MuIE15IHBvaW50IGlzIGhvdyB2 ZW5kb3Igc3BlY2lmaWMNCiBjb2RlIHdvdWxkIGJlIHJlYWxseSBoZWxwZnVsIGV2ZW4gaWYgd2Ug ZW1wbG95IHRoZSBPVUkgZmllbGQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Zb3VuZyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDQ0FNUCBbPGEgaHJlZj0ibWFp bHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QlJVTkdBUkQsIERFQk9SQUggQTxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjgsIDIwMTUgMTE6NDYgQU08YnI+DQo8Yj5Ubzo8 L2I+IExhbSwgSGluZy1LYW0gKEthbSk7IDxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNv LnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjsgJ0dlcnQgR3JhbW1lbCc7ICdHaW92YW5uaSBN YXJ0aW5lbGxpIChnaW9tYXJ0aSknPGJyPg0KPGI+Q2M6PC9iPiAnRG9vbGFuLCBQYXVsIChDb3Jp YW50IC0gVVMvSXJ2aW5nKSc7IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+DQpjY2Ft cEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5v cmciPmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1p ZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2Rl IGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhp IEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFzIExvdSBub3RlZCwg QWRyaWFu4oCZcyBvcHRpb24gMSB3YXMgdGhlIGludGVudGlvbiBhcyB0aGlzIHdhcyBkaXNjdXNz ZWQgd2hlbiBHODcyIHdhcyBiZWluZyByZXZpc2VkIHRvIGludHJvZHVjZSBBcHBsaWNhdGlvbiBJ ZGVudGlmaWVyIChJRVRG4oCZcyBNYXJjaCAyMDEzIG1lZXRpbmcpLiBBcyBLYW0gbm90ZXMsIElU VeKAmXMgd29yayBvbiBHLjg3NC4xIGhhcyBldm9sdmVkDQogdG8gaW5jbHVkZSB0aGUgT1VJLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXMgYSBuZXR3b3JrIG9wZXJhdG9y LCBJIHByZWZlciBhcyBBZHJpYW4gc2F5cyDigJMgbGV04oCZcyBhdHRlbXB0IHRvIG1hdGNoIGRy YWZ0IEcuODc0LjEgKGl0IGRvZXMgaGF2ZSBhZ3JlZW1lbnQpLiBTbyBBZHJpYW7igJlzIG9wdGlv biAyLiBXaGlsZSB0aGUgY29udGV4dCBvZiB0aGlzIHdvcmsgaXMgd2l0aGluIGFuIG9wZXJhdG9y 4oCZcyBuZXR3b3JrLCB0aGUgT1VJIHdpbGwNCiBoZWxwIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmls aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QWRyaWFuIOKAkyBnb29k IGNhdGNoLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5EZWJvcmFoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ0NBTVAgWzxhIGhyZWY9Im1haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxhbSwgSGluZy1LYW0gKEthbSk8YnI+DQo8Yj5TZW50 OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDI1LCAyMDE1IDg6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IDxh IGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9h PjsgJ0dlcnQgR3JhbW1lbCc7ICdHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSknPGJyPg0K PGI+Q2M6PC9iPiAnRG9vbGFuLCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKSc7IDxhIGhyZWY9 Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+DQpjY2FtcEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1h aWx0bzpjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPmNjYW1wLWNoYWlyc0B0b29scy5pZXRm Lm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNv ZGUuYWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5h bGxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0NBTVBdIFZl bmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdz b24tZW5jb2RlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIEFkcmlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlllcywgd2hpbGUgUTE0LzE1IGFscmVhZHkgcmVhY2hlZCBhZ3Jl ZW1lbnQgdG8gdXBkYXRlIHRoZSBBcHBsaWNhdGlvbiBJZGVudGlmaWVyIGRlc2NyaXB0aW9uLCB0 aGUgdXBkYXRlIGhhcyBub3QgYmVlbiBmb3JtYWxseSBhcHByb3ZlZCBhbmQgcHVibGlzaGVkIGJ5 IFNHMTUgeWV0LiBRMTQvMTUgbWF5IGJlIGFibGUgdG8gY29uc2VudCB0aGlzIHVwZGF0ZSBhcw0K IGFuIEFtZW5kbWVudCB0byBHLjg3NC4xIGF0IHRoZSB1cGNvbWluZyBTRzE1IG1lZXRpbmcgaW4g SnVseSAyMDE1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+S2FtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWRyaWFuIEZhcnJlbCBbPGEgaHJlZj0ibWFpbHRvOmFk cmlhbkBvbGRkb2cuY28udWsiPm1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUgMTo1OSBQTTxicj4NCjxiPlRv OjwvYj4gTGFtLCBIaW5nLUthbSAoS2FtKTsgJ0dlcnQgR3JhbW1lbCc7ICdHaW92YW5uaSBNYXJ0 aW5lbGxpIChnaW9tYXJ0aSknPGJyPg0KPGI+Q2M6PC9iPiAnRG9vbGFuLCBQYXVsIChDb3JpYW50 IC0gVVMvSXJ2aW5nKSc7IDxhIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+DQpjY2FtcEBp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmci PmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRm LWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGlu IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5UaGFua3MgZm9yIGJlaW5nIGF3YWtlLCBLYW0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlVzZWZ1bCBpbmZvLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5HZXJ0LCB0aGUgT1VJIHJlZ2lzdHJ5IGlzIGFuIElFRUUgcmVnaXN0cnkgYXMgS2FtIHNh eXMuIElBTkEgaGFzIGEgcmVnaXN0cnkgcGFnZSBmb3IgdGhpcywgYnV0IGl0IHBvaW50cyB0byB0 aGUgSUVFRSBwYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5BcyBJIHVuZGVyc3RhbmQgS2FtLCA4NzQuMSBpcyBub3QgeWV0 IHVwZGF0ZWQgc28gaXQgd291bGQgYmUgcHJlbWF0dXJlIHRvIHBvaW50IHRvIGl0LCBidXQgYW4g b3B0aW9uIGlzIHRvIGF0dGVtcHQgdG8gbWF0Y2ggaXQgbm93IGFuZCBmaXggbGF0ZXIgaWYgbmVl ZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5BZHJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IExhbSwgSGluZy1LYW0gKEthbSkgWzxhIGhyZWY9Im1haWx0bzprYW0ubGFtQGFsY2F0ZWwt bHVjZW50LmNvbSI+bWFpbHRvOmthbS5sYW1AYWxjYXRlbC1sdWNlbnQuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiAyMyBKYW51YXJ5IDIwMTUgMTc6MTA8YnI+DQo8Yj5Ubzo8L2I+IEdlcnQg R3JhbW1lbDsgPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRk b2cuY28udWs8L2E+OyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJzxicj4NCjxiPkNj OjwvYj4gRG9vbGFuLCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKTsgPGEgaHJlZj0ibWFpbHRv OmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86Y2Nh bXAtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5jY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+ OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRv b2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29s cy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtDQ0FNUF0gVmVuZG9yLVNw ZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNv ZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBHZXJ0LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QSB2ZW5kb3IgY2FuIHB1cmNoYXNl IGFuIE9VSSAoT3JnYW5pemF0aW9uYWxseSBVbmlxdWUgSWRlbnRpZmllcikgZnJvbSB0aGUgSUVF RSBSZWdpc3RyYXRpb24gQXV0aG9yaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5PbmNlIGEgdmVuZG9yIGhh cyBpdHMgT1VJLCB0aGUgdmVuZG9yIGNhbiBtYW5hZ2UgaXRzIHZlbmRvci1zcGVjaWZpYyBhcHBs aWNhdGlvbiBpZGVudGlmaWVycyB1bmRlciBpdHMgb3duIE9VSS4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5T RzE1IGRvZXNu4oCZdCBuZWVkIHRvIGhvc3QgYW55IHJlZ2lzdHJ5IGZvciB0aGlzIHB1cnBvc2Uu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5LYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBHZXJ0IEdyYW1tZWwgWzxhIGhyZWY9Im1haWx0bzpnZ3JhbW1lbEBqdW5p cGVyLm5ldCI+bWFpbHRvOmdncmFtbWVsQGp1bmlwZXIubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUgMTE6NDkgQU08YnI+DQo8Yj5Ubzo8L2I+IExh bSwgSGluZy1LYW0gKEthbSk7IDxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj5h ZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPjsgJ0dpb3Zhbm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKSc8 YnI+DQo8Yj5DYzo8L2I+IERvb2xhbiwgUGF1bCAoQ29yaWFudCAtIFVTL0lydmluZyk7IDxhIGhy ZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0i bWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+Y2NhbXAtY2hhaXJzQHRvb2xzLmll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5j b2RlLmFsbEB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29k ZS5hbGxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQ0NBTVBd IFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndh LXdzb24tZW5jb2RlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIEthbSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPklzIFNHMTUgY29uc2lkZXJpbmcgdG8gaG9zdCBhIHJlZ2lzdHJ5 IGZvciB0aGUgdmVuZG9yIHNwZWNpZmljIGFwcGxpY2F0aW9uIGNvZGUgb3IgaXMgdGhlIElFVEYg cmVnaXN0cnkgc3VwcG9zZWQgdG8gYmUgdXNlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R2Vy dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IENDQU1QIFs8YSBocmVmPSJtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5MYW0s IEhpbmctS2FtIChLYW0pPGJyPg0KPGI+U2VudDo8L2I+IDIzIEphbnVhcnkgMjAxNSAxNzowMzxi cj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlh bkBvbGRkb2cuY28udWs8L2E+OyAnR2lvdmFubmkgTWFydGluZWxsaSAoZ2lvbWFydGkpJzxicj4N CjxiPkNjOjwvYj4gRG9vbGFuLCBQYXVsIChDb3JpYW50IC0gVVMvSXJ2aW5nKTsgPGEgaHJlZj0i bWFpbHRvOmNjYW1wQGlldGYub3JnIj5jY2FtcEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWls dG86Y2NhbXAtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5jY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUu YWxsQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFs bEB0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDQ0FNUF0gVmVu ZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nv bi1lbmNvZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Rm9yIHlvdXIgaW5mb3Jt YXRpb24uIEluIHRoZSBsYXN0IFNHMTUgbWVldGluZywgUTE0LzE1IGFncmVlZCB0byB1cGRhdGUg Ry44NzQuMSB0byBhbWVuZCB0aGUgc3BlY2lmaWNhdGlvbiBvZiBBcHBsaWNhdGlvbklkZW50aWZp ZXIgd2l0aCB0aGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPklmIHRoZSBBcHBsaWNhdGlvbklk ZW50aWZpZXJUeXBlIGlzIFNUQU5EQVJELCB0aGUgdmFsdWUgb2YgUHJpbnRhYmxlU3RyaW5nIHJl cHJlc2VudHMgYSBzdGFuZGFyZCBhcHBsaWNhdGlvbiBjb2RlIGFzIGRlZmluZWQgaW4gdGhlIElU VS1UIFJlY29tbWVuZGF0aW9ucy4gSWYgdGhlIEFwcGxpY2F0aW9uSWRlbnRpZmllclR5cGUgaXMg UFJPUFJJRVRBUlksIHRoZQ0KIGZpcnN0IHNpeCBjaGFyYWN0ZXJzIG9mIHRoZSBQcmludGFibGVT dHJpbmcgbXVzdCBjb250YWluIHRoZSBIZXhhZGVjaW1hbCByZXByZXNlbnRhdGlvbiBvZiBhbiBP VUkgYXNzaWduZWQgdG8gdGhlIHZlbmRvciB3aG9zZSBpbXBsZW1lbnRhdGlvbiBnZW5lcmF0ZWQg dGhlIEFwcGxpY2F0aW9uIElkZW50aWZpZXI7IHRoZSByZW1haW5pbmcgb2N0ZXRzIG9mIHRoZSBQ cmludGFibGVTdHJpbmcgYXJlIHVuc3BlY2lmaWVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5QYXVsIERvb2xhbiBoYWQgYW4gSS1EICZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1kb29sYW4tcHJvcHJpZXRhcnktYWMtMDAiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kb29sYW4tcHJvcHJpZXRhcnktYWMtMDA8L2E+JnF1b3Q7 IHRvIHRoZSBsYXN0IElFVEYgbWVldGluZyB3aXRoIHRoZSBzaW1pbGFyIHByb3Bvc2FsLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+S2FtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5Gcm9tOiBDQ0FNUCBbPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEFkcmlhbiBG YXJyZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNlbnQ6IEZyaWRh eSwgSmFudWFyeSAyMywgMjAxNSA5OjQxIEFNPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5UbzogJ0dpb3Zhbm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKSc8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNjOiA8YSBocmVmPSJtYWlsdG86Y2NhbXBA aWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmNjYW1wLWNoYWly c0B0b29scy5pZXRmLm9yZyI+DQpjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmll dGYub3JnIj4NCmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlN1YmplY3Q6 IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1j Y2FtcC1yd2Etd3Nvbi1lbmNvZGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGksPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgYXBwcmVjaWF0ZSB0aGlzIGRpc2N1c3Npb24s IGJ1dCBJIGFtIG5vdCBzZWVpbmcgYSBzcGVjaWZpYyBjb25jbHVzaW9uIGZyb20gaXQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBjdXJyZW50IEktRCBtYWtlcyAoSU1ITykgdGhl IFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIHVudXNhYmxlLiBJIG9mZmVyZWQgdGhy ZWUgb3B0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MSBUaGlzIHZhbHVlIGlz IG9ubHkgdG8gYmUgdXNlZCB3aGVuIGl0IGlzIGtub3duIHRoYXQgYWxsIGRldmljZXM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBwYXJ0aWNpcGF0 aW5nIGluIGEgbmV0d29yayBoYXZlIHRoZSBzYW1lIHVuZGVyc3RhbmRpbmcgb2YNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIGNv bnRlbnQgb2YgdGhlIFZlbmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGZpZWxkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEhvdyB0aGlz IGtub3dsZWRnZSBpcyBhY2hpZXZlZCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgZG9jdW1lbnQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MiBXaGVuIHRoaXMgdmFsdWUgaXMgc2V0LCB0 aGUgZmlyc3QgMzIgKG9yIDQ4KSBiaXRzIG9mIHRoZSBWZW5kb3ItPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBm aWVsZCBjb250YWluIGFuIEVudGVycHJpc2UgTnVtYmVyPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgKG9yIE9VSSkgdGhhdCBkZWZpbmVzIHRoZSBjb250ZXh0 IGluIHdoaWNoIHRoZSByZW1haW5kZXIgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyB0aGF0IGZpZWxkIGlzIGludGVycHJldGVkLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4zIFJlbW92ZSB0aGUgb3B0aW9uIHRvIGluY2x1ZGUgYSBWZW5kb3It U3BlY2lmaWMgQXBwbGljYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyBDb2RlIGZpZWxkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5JZiB0aGUgV0cgY291bGQgcGxlYXNlIHBpY2sgb25lIG9mIHRoZXNlIGFuZCBoZWxwIFlvdW5n IHRvIHVwZGF0ZSB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFkcmlhbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEZyb206IEdpb3Zh bm5pIE1hcnRpbmVsbGkgKGdpb21hcnRpKSBbPGEgaHJlZj0ibWFpbHRvOmdpb21hcnRpQGNpc2Nv LmNvbSI+bWFpbHRvOmdpb21hcnRpQGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNlbnQ6IDIzIEphbnVhcnkgMjAxNSAxMzo1MDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUbzogPGEgaHJlZj0ibWFp bHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IENjOiBMZWV5b3VuZzsgPGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRm Lm9yZyI+DQpkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5v cmc8L2E+OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8YSBo cmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+DQpjY2FtcC1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13 c29uLWVuY29kZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT25lIGFkZGl0aW9u YWwgY29tbWVudCAoaG9waW5nIG5vdCBhZGRpdGlvbmFsIGNvbmZ1c2lvbikuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgaWRlYSBhYm91dCBPcHRpY2FsIEludGVyZmFjZSBD bGFzcyB3YXMgdGFrZW4gZnJvbSBTUkxHLiBHb29kIG9yDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgYmFkIGlzIGEgcGxhaW4gbnVtYmVyIGFuZCB5b3UgZG8g c2ltcGxlIG9wZXJhdGlvbnMgb24gaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBDaGVlcnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT24gMjIgSmFuIDIwMTUsIGF0IDA5OjQy LCBHaW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdpb21hcnRpQGNpc2Nv LmNvbSI+Z2lvbWFydGlAY2lzY28uY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7IEhpIEFkcmlhbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7IE9uIDIxIEphbiAyMDE1LCBhdCAyMjo1NSwgQWRyaWFuIEZhcnJlbCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBI aSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgV2Vs bCwgeW91IHNlZW0gdG8gaGF2ZSBhIGhhbGYtd2F5IGhvdXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBZb3UgaGF2ZSBzcGVjaWZpZWQgdGhlIGV4 aXN0ZW5jZSBvZiBhIHRoaW5nLCBidXQgbm90IGhvdyB0byByZWFkIGl0LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBJZiB5b3Ugd2FudGVkIHRvIG1h a2UgYSBzdGF0ZW1lbnQgdGhhdCB0aGlzIG9iamVjdCB3aWxsIG9ubHkgYmUNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyB1c2VkIHdoZW48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPml0IGlzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGtub3duIHRoYXQgYWxsIHN5 c3RlbXMgaW4gYSBuZXR3b3JrIGNvbWUgZnJvbSB0aGUgc2FtZSB2ZW5kb3INCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBhbmQvb3IgaGF2ZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgc2FtZSB1bmRlcnN0 YW5kaW5nIG9mIHRoZSBlbmNvZGluZywgdGhhdCBtaWdodCBiZSBPSyAoYWx0aG91Z2ggaG93DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgeW91 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdvdWxkPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGFzY2VydGFp biB0aGlzIG1pZ2h0IGFsc28gbmVlZCB0byBiZSBkZXNjcmliZWQpLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVGhlIHN0YXRlbWVudCBpcyB0byBlbnN1cmUgdGhlIGlu dGVyZmFjZSBjb21wYXRpYmlsaXR5IHdpdGhvdXQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGVuY29kaW5nIGFsbDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+dGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IHBvc3NpYmxlIGRldGFpbHMgYW5kIHBhcmFtZXRlciB0aGF0IGRlZmluZSBh biBpbnRlcmZhY2UgKGUuZy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBtb2R1bGF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5mb3JtYXQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGZv cndhcmQgZXJyb3IgY29ycmVjdGlvbiBldGMuKS4gVGhpcyB3YXMgdGhlIGluaXRpYWwgc29sdXRp b24gaW4gdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg ZHJhZnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRoZW48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVwbGFjZWQgYnkgdGhlIGlu dGVyZmFjZSBjbGFzcyBjb25jZXB0LiZuYnNwOyZuYnNwOyBUaGUgV1NPTiAoUldBLW9ubHkpIGhh cyB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVxdWly ZW1lbnQgaXMgdG8gbWFrZSBzdXJlIHR3byBpbnRlcmZhY2UgYXJlIGNvbXBhdGlibGUuIFRoaXMN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyByZXF1aXJlbWVu dCwgaW1obywgY2FuIGJlIHNhdGlzZnkgYnkgYSBzaW1wbGUgY29tcGFyaXNvbiB3aGljaCBoYXMg YSBib29sZWFuIHJlc3VsdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7IFdlIGVuZCB1cCB0aGVuIGluJm5ic3A7IHRoZSBJVFUgYXBwbGljYXRpb24gY29kZXMgZm9y IHRoZSAmcXVvdDtjZXJ0aWZpZWQmcXVvdDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICh3ZSdsbCB0aGlzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5pcyBteTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyB0ZXJtIG5vdCAxMDAlIHN1cmUgaXMgdGhlIGJlc3Qgb25lKSBjb21wYXRpYmls aXR5IHdoZXJlIHByb3Blcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGVuY29kaW5nIGlzIHByb3ZpZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsgT3IgeW91IGNvdWxkIGVudGlyZWx5IHJlbW92ZSB0aGUgdmVuZG9yLXNwZWNp ZmljIG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsgT3IgeW91IGNvdWxkIHB1dCBpbiBhbiBPVUkgLyBlbnRlcnByaXNlIG51bWJlciBmb2xs b3dlZCBieQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7IHRyYW5zcGFyZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGJ5dGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVG8g bWUgSSdtIHBlcmZlY3RseSBmaW5lIHdpdGggdGhlIHNlY29uZCBvcHRpb24uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBDaGVlcnM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBHPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyBBZHJpYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBGcm9tOiBH aW92YW5uaSBNYXJ0aW5lbGxpIChnaW9tYXJ0aSkgWzxhIGhyZWY9Im1haWx0bzpnaW9tYXJ0aUBj aXNjby5jb20iPm1haWx0bzpnaW9tYXJ0aUBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgU2VudDogMjEgSmFudWFy eSAyMDE1IDIxOjIyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFk cmlhbkBvbGRkb2cuY28udWs8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBDYzogTGVleW91bmc7IDxhIGhyZWY9Im1haWx0bzpkcmFm dC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQt aWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnPC9hPjs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0i bWFpbHRvOmNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+Y2NhbXAtY2hhaXJzQHRvb2xzLmll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtDQ0FNUF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYt Y2NhbXAtcndhLXdzb24tZW5jb2RlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgU3BlY2lmaWNhbGx5IHRvIHRoZSBJbnRlcmZhY2UgY2xh c3MgaGVyZSBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7Jmd0OyBJbiB0aGUgaW5pdGlhbCBkcmFmdCBtZXJnZWQgdG8gdGhpcyBvbmUg dGhlcmUgd2FzIHRoZSB1c2FnZSBvZiBPVUkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgaG93ZXZlcjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+KEk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IGd1ZXNzIGFmdGVyIGNoYXR0aW5nIHdpdGggTG91KSB3 ZSBkZWNpZGVkIHRvIHJlbW92ZSBhbnkgZW5jb2RpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgd2hlbiB0aGUgSW50ZXJmYWNlIGNs YXNzIGlzIG5vdCBzdGFuZGFyZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsmZ3Q7IEluIHRlcm0gb2Ygc2VtYW50aWMgdGhlIHByb3Rjb2wgZG9l cyBub3QgbmVlZCB0byBkZWNvZGUgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IEludGVyZmFjZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Y2xhc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsgc2luY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IGl0IG9ubHkgYXNzZXNzIHRoZSBpbnRlcmZh Y2UgY29tcGF0aWJpbGl0eSBpZiB0d28gaW50ZXJmYWNlcyBoYXMgYQ0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBjbGFzczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+dmFsdWU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgdGhhdDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbWF0Y2ggdHdvIGludGVy ZmFjZXMgY2FubiBiZSBjb25uZWN0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgSGF2aW5nIHNheWluZyB0aGF0IEkgZG9uJ3QgaGF2 ZSBzdHJvbmcgb3BpbmlvbiBpbiBhZGRpbmcgdGhlIE9VSQ0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBvcjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+bGVhdmluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyByb29tPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBmb3IgbWF5YmUgZnV0dXJlIHB1Ymxp YyBpbnRlcmZhY2VzIGRhdGFiYXNlLiBGb3Igc3VyZSB0aGVyZSdzIGENCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbmVlZCB0bzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+bGVhdmU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IHJvb20gZm9yIHNwZWNp ZmljIGNvbXBhdGliaWxpdHkgYXNzZXNtZW50IHNpbmNlIHRoZXJlIG9wdGljYWwNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgbXVsdGl2 ZW5kb3IgY29tcGF0aWJpbGl0eSBoYXMgYmVlbiBhbHJlYWR5IGRlbW9uc3RyYXRlZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBob3Bl IHRoaXMgaGVscCAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyZndDsgQ2hlZXJzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBHPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7IE9uIDIxIEphbiAyMDE1LCBhdCAyMTo1NywgQWRy aWFuIEZhcnJlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlh bkBvbGRkb2cuY28udWs8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg U2VjdGlvbiA0LjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhvdyBkbyBJIGludGVycHJldCBhIFZlbmRvci1TcGVj aWZpYyBBcHBsaWNhdGlvbiBDb2RlPyBJcyB0aGVyZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbiBPVUkgSSdt IG1pc3Npbmc/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFtZT1VOR10gTm90IHN1cmUgaWYgSSB1bmRlcnN0 b29kIHRoaXMgcXVlc3Rpb24uIFdoYXQgaXMgJnF1b3Q7T1VJJnF1b3Q7PzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Pcmdhbml6YXRpb25hbGx5X3VuaXF1 ZV9pZGVudGlmaWVyIj4NCmh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvT3JnYW5pemF0aW9u YWxseV91bmlxdWVfaWRlbnRpZmllcjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzL2llZWUtODAyLW51bWJlcnMvaWVlZS04MDItIj4NCmh0dHA6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvaWVlZS04MDItbnVtYmVycy9pZWVlLTgwMi08L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBudW1i ZXJzLnhodG1sI2llZWUtODAyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLW51bWJlcnMtMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgT3IgcGVyaGFwcyBh biBFbnRlcnByaXNlIE51bWJlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvZW50ZXJwcmlzZS1udW1iZXJzL2VudGVycHJpc2UtIj4NCmh0dHA6Ly93d3cuaWFu YS5vcmcvYXNzaWdubWVudHMvZW50ZXJwcmlzZS1udW1iZXJzL2VudGVycHJpc2UtPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBudW1iZXJzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBUaGUgcXVlc3Rpb24gaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBZb3UgaGF2ZSBzZWN0aW9ucyA0LjEuMSB0aHJv dWdoIDQuMS40IHRvIHRlbGwgbWUgaG93IHRvIGludGVycHJldA0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IE9wdGljYWw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBJbnRlcmZhY2UgQ2xhc3MgZmllbGQgd2hlbiBpdCBjb250YWlucyBhbiBJVFUtVCBBcHBsaWNh dGlvbiBNYXBwaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdoZW4gSSByZWNlaXZlZCBzPTAgYW5kIE9JPTEgaXQgbWVhbnMg dGhhdCB0aGUgT3B0aWNhbCBJbnRlcmZhY2UNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IENsYXNzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGNvbnRhaW5zPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYSAmcXVv dDtWZW5kb3IgU3BlY2lmaWMgT3B0aWNhbCBJbnRlcmZhY2UgQ2xhc3MmcXVvdDsuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSG93 IGRvIEkgaW50ZXJwcmV0IHRoYXQgT3B0aWNhbCBJbnRlcmZhY2UgQ2xhc3M/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgV2hpY2gg dmVuZG9yIGRvZXMgaXQgYXBwbHkgdG8/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSXMgdGhlcmUgc29tZSBpbmZvcm1hdGlvbiBl bHNld2hlcmUgdGhhdCBnaXZlcyBtZSBhIGNsdWUgYXMgdG8NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHdoaWNoPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHZlbmRvcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgaGFzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZW5j b2RlZCB0aGUgaW5mb3JtYXRpb24/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgT3IgaXMgdGhlIGluZm9ybWF0aW9uIHN1cHBvc2Vk IHRvIGJlIGVuY29kZWQgaW4gdGhlIE9wdGljYWwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEludGVyZmFjZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q2xhc3MsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcGVyaGFwcyBhcyB0aGUg Zmlyc3QgNDggYml0cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBPciBhbSBJIHN1cHBvc2VkIHRvIGtub3cgYnkgY29udGV4dD88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q0NBTVAg bWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBo cmVmPSJtYWlsdG86Q0NBTVBAaWV0Zi5vcmciPkNDQU1QQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7AEB3D6833318045B4AE71C2C87E8E1729C7F161dfweml706chm_-- From nobody Wed Jan 28 13:35: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 14CB31A1AAE for ; Wed, 28 Jan 2015 13:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 kgsXHicPryYn for ; Wed, 28 Jan 2015 13:01:43 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0645.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::645]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBBE1A005C for ; Wed, 28 Jan 2015 13:01:42 -0800 (PST) Received: from DB3PR04MB0761.eurprd04.prod.outlook.com (25.160.51.152) by DB3PR04MB0763.eurprd04.prod.outlook.com (25.160.51.154) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 28 Jan 2015 21:01:14 +0000 Received: from DB3PR04MB0761.eurprd04.prod.outlook.com ([25.160.51.152]) by DB3PR04MB0761.eurprd04.prod.outlook.com ([25.160.51.152]) with mapi id 15.01.0065.013; Wed, 28 Jan 2015 21:01:14 +0000 From: "Doolan, Paul (Coriant - US/Irving)" To: Leeyoung Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyAc6iYd43akkuKQTVCSlXJGZzN8F2AgAAengCAA5dgAIAEL7YAgAAd5QCAABjjAA== Date: Wed, 28 Jan 2015 21:01:13 +0000 Message-ID: <249BEEE4-BBB1-4635-9E2A-83A7C1F15D8D@coriant.com> References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE3A6C@US70TWXCHMBA12.zam.alcatel-lucent.com> <8DBC3FDAC14BE441AED9C5939C77758509EE3B48@US70TWXCHMBA12.zam.alcatel-lucent.com> <010901d0373e$ac0d7ed0$04287c70$@olddog.co.uk> <8DBC3FDAC14BE441AED9C5939C77758509EE461F@US70TWXCHMBA12.zam.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E1729C7F07B@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7F07B@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [32.210.21.102] authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=coriant.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR04MB0763; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB0763; x-forefront-prvs: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(82746002)(62966003)(46102003)(102836002)(19580395003)(54356999)(19580405001)(2656002)(76176999)(106116001)(77156002)(40100003)(2900100001)(2950100001)(122556002)(16236675004)(33656002)(92566002)(50986999)(87936001)(66066001)(83716003)(110136001)(93886004)(86362001)(36756003)(230783001)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR04MB0763; H:DB3PR04MB0761.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_249BEEE4BBB146359E2A83A7C1F15D8Dcoriantcom_" MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2015 21:01:13.8682 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 76595477-907e-4695-988b-a6b39087332d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR04MB0763 Archived-At: X-Mailman-Approved-At: Wed, 28 Jan 2015 13:35:44 -0800 Cc: "ccamp-chairs@tools.ietf.org" , "ccamp@ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 28 Jan 2015 21:01:46 -0000 --_000_249BEEE4BBB146359E2A83A7C1F15D8Dcoriantcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jan 28, 2015, at 2:32 PM, Leeyoung > wrote: Hi Young, My point is how vendor specific code would be really helpful even if we emp= loy the OUI field. Without it there is risk of collision. A system that receives a proprietary= code point it recognizes is, without the OUI, unable to tell whether that = code point was generated by an equipment with the same proprietary implemen= tation or by some other system that just happened to pick the same code. pd --_000_249BEEE4BBB146359E2A83A7C1F15D8Dcoriantcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jan 28, 2015, at 2:32 PM, Leeyoung <leeyoung@huawei.com>
 wrote:

Hi Young,

My point is how vendor specific code would be really helpful even if we emplo= y the OUI field.

Without it there is risk of collision. A system that receives a propri= etary code point it recognizes is, without the OUI, unable to tell whether = that code point was generated by an equipment with the same proprietary imp= lementation or by some other system that just happened to pick the same code.

pd
--_000_249BEEE4BBB146359E2A83A7C1F15D8Dcoriantcom_-- From nobody Wed Jan 28 19:46:32 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 B27E41A8AED for ; Wed, 28 Jan 2015 19:46:26 -0800 (PST) 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 RR5nlEVwXHFW for ; Wed, 28 Jan 2015 19:46:22 -0800 (PST) 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 E3A241A1B63 for ; Wed, 28 Jan 2015 19:46:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRV90725; Thu, 29 Jan 2015 03:46:20 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 03:46:19 +0000 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.24]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 11:46:06 +0800 From: Fatai Zhang To: "adrian@olddog.co.uk" , Leeyoung , "'Giovanni Martinelli (giomarti)'" Thread-Topic: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNzI6MuUpoQhCrkiI4y02+dmLz5zNhSEAgAjw2xA= Date: Thu, 29 Jan 2015 03:46:05 +0000 Message-ID: References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm> <010501d0373c$d34e3db0$79eab910$@olddog.co.uk> In-Reply-To: <010501d0373c$d34e3db0$79eab910$@olddog.co.uk> 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_F82A4B6D50F9464B8EBA55651F541CF85CBF2DA4SZXEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 03:46:26 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF85CBF2DA4SZXEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young and all, As an individual, I agree with Adrain, which means I would support Option 2= . I think we just need add some sentences to fit Option 2. When s=3D0 and OI=3D1, the first 32 (or 48) bits of the Vendor-Specific App= lication Code field contain an Enterprise Number (or OUI) that defines the = context in which the remainder of that field is interpreted. In addition, w= e need to add some text to describe the process rules that Adrian hinted be= low. My question is: Which number (either an Enterprise number or OUI) should be used? I think w= e just need pick one of them. If an Enterprise Number is used, it needs 32 = bits, otherwise 48 bits should be used. If 48 bits are used, it needs to pu= t one line more (32 bits) to the current format of Optical Interface Class. To Young, you can also take a look at [draft-ietf-pce-rfc7150bis], which ha= s some informaiton releated to Enterprise Number. Best Regards Fatai -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Saturday, January 24, 2015 2:46 AM To: Leeyoung; 'Giovanni Martinelli (giomarti)' Cc: draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; ccamp@ietf.org; cc= amp-chairs@tools.ietf.org Subject: RE: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-= encode > Thanks Adrian for taking this on. Well, we'll get there eventually! > My preference is Option 1. OK. It is my least favorite option because it is most likely to hit interoperab= ility issues. So, if the WG wants to go this way, we will have to work a little to explai= n how it works and why it isn't a problem (specifically for the IESG). > It would be hard to catch moving target around this > area if we were to take Option 2. I see no moving targets at all. This is how all other vendor-specific fields are handled in protocols. The way it works is that anyone receiving such a field looks at the first 3= 2 bits and interprets it as an Enterprise Code from the IANA registry (hint: = easy to get and many well-known vendors have them). If it is an Enterprise Code they recognise they process according to their = own vendor-specific knowledge about the contents. If they don't recognise the Enterprise Code, they fail the processing. An Enterprise will often (always?) define their own structure starting with= a version number or something similar, and often using TLVs. What have I missed about moving targets? Cheers, Adrian --_000_F82A4B6D50F9464B8EBA55651F541CF85CBF2DA4SZXEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Y= oung and all,

 

As a= n individual, I agree with Adrain, which means I would support Option 2.

 

I th= ink we just need add some sentences to fit Option 2.

 

When= s=3D0 and OI=3D1, the first 32 (or 48) bits of the Vendor-Specific Applica= tion Code field contain an Enterprise Number (or OUI) that defines the cont= ext in which the remainder of that field is interpreted. In addition, we need to add some text to describe the process= rules that Adrian hinted below.

 

My q= uestion is:

Whic= h number (either an Enterprise number or OUI) should be used? I think we ju= st need pick one of them. If an Enterprise Number is used, it needs 32 bits= , otherwise 48 bits should be used. If 48 bits are used, it needs to put one line more (32 bits) to the current f= ormat of Optical Interface Class.

 

To Y= oung, you can also take a look at [draft-ietf-pce-rfc7150bis], which has so= me informaiton releated to Enterprise Number.

 

 

 

 

 

Best= Regards

 

Fata= i

 

 

-----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Saturday, January 24, 2015 2:46 AM
To: Leeyoung; 'Giovanni Martinelli (giomarti)'
Cc: draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; ccamp@ietf.org; cc= amp-chairs@tools.ietf.org
Subject: RE: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-= encode

 

> Thanks Adrian for takin= g this on.

 

Well, we'll get there eventu= ally!

 

> My preference is Option= 1.

 

OK.

It is my least favorite opti= on because it is most likely to hit interoperability

issues.

So, if the WG wants to go th= is way, we will have to work a little to explain how

it works and why it isn't a = problem (specifically for the IESG).

 

> It would be hard to cat= ch moving target around this

> area if we were to take= Option 2.

 

I see no moving targets at a= ll.

This is how all other vendor= -specific fields are handled in protocols.

The way it works is that any= one receiving such a field looks at the first 32

bits and interprets it as an= Enterprise Code from the IANA registry (hint: easy

to get and many well-known v= endors have them).

If it is an Enterprise Code = they recognise they process according to their own

vendor-specific knowledge ab= out the contents.

If they don't recognise the = Enterprise Code, they fail the processing.

An Enterprise will often (al= ways?) define their own structure starting with a

version number or something = similar, and often using TLVs.

 

What have I missed about mov= ing targets?

 

Cheers,

Adrian

 

--_000_F82A4B6D50F9464B8EBA55651F541CF85CBF2DA4SZXEMA504MBSchi_-- From nobody Thu Jan 29 05:17: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 A6DFF1A036C for ; Thu, 29 Jan 2015 05:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, 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 s7119ANroL09 for ; Thu, 29 Jan 2015 05:17:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072191A0154 for ; Thu, 29 Jan 2015 05:17:07 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B2DFE5E1C07FB; Thu, 29 Jan 2015 13:17:02 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t0TDH1Ae016156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 14:17:04 +0100 Received: from [149.204.107.121] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 29 Jan 2015 14:16:52 +0100 Message-ID: <54CA32C2.3000405@alcatel-lucent.com> Date: Thu, 29 Jan 2015 14:16:50 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Fatai Zhang , "adrian@olddog.co.uk" , Leeyoung , "'Giovanni Martinelli (giomarti)'" References: <006901d0371a$9e1f1960$da5d4c20$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E09C@dfweml706-chm> <010501d0373c$d34e3db0$79eab910$@olddog.co.uk> In-Reply-To: X-SubSwitch: [CCAMP]; [CCAMP] Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 13:17:09 -0000 +1 (support for Option 2)


Thanks,
Dieter
On 29.01.2015 04:46, Fatai Zhang wrote:

Hi Young and all,

As an individual, I agree with Adrain, which means I would support Option 2.

I think we just need add some sentences to fit Option 2.

When s=0 and OI=1, the first 32 (or 48) bits of the Vendor-Specific Application Code field contain an Enterprise Number (or OUI) that defines the context in which the remainder of that field is interpreted. In addition, we need to add some text to describe the process rules that Adrian hinted below.

My question is:

Which number (either an Enterprise number or OUI) should be used? I think we just need pick one of them. If an Enterprise Number is used, it needs 32 bits, otherwise 48 bits should be used. If 48 bits are used, it needs to put one line more (32 bits) to the current format of Optical Interface Class.

To Young, you can also take a look at [draft-ietf-pce-rfc7150bis], which has some informaiton releated to Enterprise Number.

Best Regards

Fatai

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Saturday, January 24, 2015 2:46 AM
To: Leeyoung; 'Giovanni Martinelli (giomarti)'
Cc: draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org; ccamp@ietf.org; ccamp-chairs@tools.ietf.org
Subject: RE: Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode

> Thanks Adrian for taking this on.

Well, we'll get there eventually!

> My preference is Option 1.

OK.

It is my least favorite option because it is most likely to hit interoperability

issues.

So, if the WG wants to go this way, we will have to work a little to explain how

it works and why it isn't a problem (specifically for the IESG).

> It would be hard to catch moving target around this

> area if we were to take Option 2.

I see no moving targets at all.

This is how all other vendor-specific fields are handled in protocols.

The way it works is that anyone receiving such a field looks at the first 32

bits and interprets it as an Enterprise Code from the IANA registry (hint: easy

to get and many well-known vendors have them).

If it is an Enterprise Code they recognise they process according to their own

vendor-specific knowledge about the contents.

If they don't recognise the Enterprise Code, they fail the processing.

An Enterprise will often (always?) define their own structure starting with a

version number or something similar, and often using TLVs.

What have I missed about moving targets?

Cheers,

Adrian



_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
From nobody Thu Jan 29 05:24: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 B701F1A036C for ; Thu, 29 Jan 2015 05:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zWawX1Y06fSG for ; Thu, 29 Jan 2015 05:24:46 -0800 (PST) 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 A3C831A037E for ; Thu, 29 Jan 2015 05:24:45 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0TDO28w000786; Thu, 29 Jan 2015 13:24:02 GMT Received: from 950129200 (194-166-224-30.adsl.highway.telekom.at [194.166.224.30]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0TDO0BU000776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2015 13:24:00 GMT From: "Adrian Farrel" To: "'Leeyoung'" , "'Varma, Eve L \(Eve\)'" , , "'Lam, Hing-Kam \(Kam\)'" , , References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> Date: Thu, 29 Jan 2015 13:23:59 -0000 Message-ID: <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJJUQOjjDfAQ8oFRmu1FlrhpmJTlQFT1EnjAetg4z8CJ7+qqJu5sV6g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21290.007 X-TM-AS-Result: No--2.376-10.0-31-10 X-imss-scan-details: No--2.376-10.0-31-10 X-TMASE-MatchedRID: hls5oAVArl84HKI/yaqRm0hEDfw/93BulnrMq7Sriu1uSX0LjRs5dfF1 IdU1dF/S93WdQoPE0d1hjPrPq/NtUxaadt99xiokJXKk/roE/RCPmFSaq6xM+GXczQlokCRZq+1 liYblo0L9VVCUNaKG6vYx6jUoivPIJtllgBC70fncWo5Vvs8MQpWr6iSXWtgPd71AOvz4tNx4lf x9oG1pi6NmZd67d7ssYMSJm0fVeNVbgcVfm+q5rI4V8tCoXo/SgdNXa4lpKNvJYIv7y0tu9jIW+ 5e3TygfAh5ldZzOWtO0dcofyvajnUV5O+xleW7dngIgpj8eDcByZ8zcONpAscRB0bsfrpPInxMy eYT53Rmgtni9Z1tMQQYbuTsOs7wqvdmOeyS992DG+5f3ulbfN6MSQ2p5W2Xbr3l36Qwm9rWTO6A CM932trpuFii4t6mcM4eY+qoaMQPEKh5bR1PYFof8kK+K1APpIcrpoIxNunWiPKQz22GTEVZca9 RSYo/b Archived-At: Cc: paul.doolan@coriant.com, ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 13:24:53 -0000 Hi again, > There is always a priori knowledge in optical network domain as to who = > are you interfacing with. So you know which vendor you are = interfacing.=20 > If you do not know, then you are in trouble. Hmmm. It is exactly type of trouble we are trying to detect and protect = against. I refute your statement of a priori knowledge. I think there is a priori = intention, but not knowledge. Unless you have very good eyesight or = someone at the other end of the fiber when you give it a tug, you don't = know. And even then. Fibering errors happen from time to time. Consider, = in particular a patch panel. > Now, what is the purpose of standard FECs and modulations in the AI? = Given > several choices each vendor may support in its device, the path = computation > would find a matched types for FEC and modulation for a given optical = path.=20 > This is what is intended when optical signal processing constraints = were=20 > proposed as part of path computation constraints in optical networks.=20 The case you are making here is for no standard control plane! What is the point of standardising if there is never any interworking? But actually, we know about interworking at the physical layer, and = (more important) we know about a single, end-to-end control plane that = spans multiple vendor devices. It all exists. Of course, we can fall back into the old-style vendor islands, and many = like to do so. But it is not a compulsory deployment model. > There is very little chance for vendor specific FECs and Modulations = will match > even if they are identified with the OUI code.=20 You have it the wrong way round! The OUI is largely to protect against expectations of interworking when = none can exist. It might (much less frequently) be used to describe the way that vendorA = and vendorB pick FECs and modulations in order to achieve interworking. Adrian From nobody Thu Jan 29 05:49: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 A861D1A0636 for ; Thu, 29 Jan 2015 05:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 D1e3SS9P7hGR for ; Thu, 29 Jan 2015 05:49:15 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAC31A038A for ; Thu, 29 Jan 2015 05:49:15 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so26566438wiv.0 for ; Thu, 29 Jan 2015 05:49:14 -0800 (PST) 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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=s74ZDgkzKWuMB6PdLYjbHLF0ux9w9F4ireM4r0WmWDk=; b=nXBQLUVv0haHnjqff6ey5lENzlnJS+lV+ebOe8HCkwLO+vgkjjYz+YAIWWKuWuAUjv rQqGmhzd00/JFi64oY/R3jm1iBpzovJIKihzabXZnrjFLhhkPJvOGOxryfPRzjH3He6R B8I712i57Bt1f03WmfyNDOElfWBJqvvTIpI3Y9Mbi6rt5/mfM5V1/RHPsc/LXhPoNh0c KEmRf6QRRJkn/ITHCmJ1Oi7XgyC1UDIAVh6a9WdLsTwzAhbG3veEs5hZbQXf3rDMakp7 FCS2B1PmmiVT1bWiiTsg5CHVId7GQgEWy0srFIOJ7YUskYfGa3NeBuh0huLmSAClofqh iXuQ== X-Received: by 10.180.218.73 with SMTP id pe9mr192839wic.13.1422539354316; Thu, 29 Jan 2015 05:49:14 -0800 (PST) Received: from McObelix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id fi10sm2558126wib.13.2015.01.29.05.49.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 05:49:13 -0800 (PST) Message-ID: <54CA3A58.1080309@gmail.com> Date: Thu, 29 Jan 2015 14:49:12 +0100 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Leeyoung' References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> In-Reply-To: <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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: Thu, 29 Jan 2015 13:49:21 -0000 All, I agree with Adrians assessment. +1 for option 2. Regards, Huub. ======== On 29-01-15 14:23, Adrian Farrel wrote: > Hi again, > >> There is always a priori knowledge in optical network domain as to who >> are you interfacing with. So you know which vendor you are interfacing. >> If you do not know, then you are in trouble. > > Hmmm. It is exactly type of trouble we are trying to detect and protect against. > > I refute your statement of a priori knowledge. I think there is a priori intention, but not knowledge. Unless you have very good eyesight or someone at the other end of the fiber when you give it a tug, you don't know. And even then. Fibering errors happen from time to time. Consider, in particular a patch panel. > >> Now, what is the purpose of standard FECs and modulations in the AI? Given >> several choices each vendor may support in its device, the path computation >> would find a matched types for FEC and modulation for a given optical path. >> This is what is intended when optical signal processing constraints were >> proposed as part of path computation constraints in optical networks. > > > The case you are making here is for no standard control plane! > What is the point of standardising if there is never any interworking? > But actually, we know about interworking at the physical layer, and (more important) we know about a single, end-to-end control plane that spans multiple vendor devices. It all exists. > > Of course, we can fall back into the old-style vendor islands, and many like to do so. But it is not a compulsory deployment model. > >> There is very little chance for vendor specific FECs and Modulations will match >> even if they are identified with the OUI code. > > You have it the wrong way round! > The OUI is largely to protect against expectations of interworking when none can exist. > It might (much less frequently) be used to describe the way that vendorA and vendorB pick FECs and modulations in order to achieve interworking. > > Adrian > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > -- ***************************************************************** 璇疯浣忥紝浣犳槸鐙竴鏃犱簩鐨勶紝灏卞儚鍏朵粬姣忎竴涓汉涓鏍 From nobody Thu Jan 29 06:51: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 6659A1A1A3D for ; Thu, 29 Jan 2015 06:51:39 -0800 (PST) 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 fRJjrC2BFgAJ for ; Thu, 29 Jan 2015 06:51:35 -0800 (PST) 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 9AADD1A1A33 for ; Thu, 29 Jan 2015 06:51:34 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOO29520; Thu, 29 Jan 2015 14:51:33 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 14:51:32 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 06:51:20 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "'Varma, Eve L (Eve)'" , "db3546@att.com" , "'Lam, Hing-Kam (Kam)'" , "ggrammel@juniper.net" , "giomarti@cisco.com" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyKmWicGibpQEGWYW2s/gCycJzOdnmAgAAengCAA5dgAIAEL7YA//+TloCAAJDSAP//e+qggACJ8QCAAAbcgP//fJJwADNyZIAADdFHgA== Date: Thu, 29 Jan 2015 14:51:20 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> In-Reply-To: <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: F0Ml I3lZ JpKH M8Av QHrK SSFr ahF6 csHr h9wV pzqS rbnY tArS xoUr zfuk 946r AARJew==; 10; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGMAYwBhAG0AcAAtAGMAaABhAGkAcgBzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAYwBjAGEAbQBwAEAAaQBlAHQAZgAuAG8AcgBnADsAZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHIAdwBhAC0AdwBzAG8AbgAtAGUAbgBjAG8AZABlAC4AYQBsAGwAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBlAHYAZQAuAHYAYQByAG0AYQBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtADsAZwBnAHIAYQBtAG0AZQBsAEAAagB1AG4AaQBwAGUAcgAuAG4AZQB0ADsAZwBpAG8AbQBhAHIAdABpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBrAGEAbQAuAGwAYQBtAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0AOwBwAGEAdQBsAC4AZABvAG8AbABhAG4AQABjAG8AcgBpAGEAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {E3731D3A-BB84-489F-B91C-AEDE031699AF}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 29 Jan 2015 14:50:57 GMT; UgBFADoAIABbAEMAQwBBAE0AUABdACAAVgBlAG4AZABvAHIALQBTAHAAZQBjAGkAZgBpAGMAIABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABDAG8AZABlACAAaQBuACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHIAdwBhAC0AdwBzAG8AbgAtAGUAbgBjAG8AZABlAA== x-cr-puzzleid: {E3731D3A-BB84-489F-B91C-AEDE031699AF} x-originating-ip: [10.47.138.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "paul.doolan@coriant.com" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 14:51:39 -0000 SGksDQoNCkl0IHNlZW1zIGxpa2UgdGhlIHdvcmxkIGlzIGFnYWluc3QgT3B0aW9uIDEuIE5vIGJp ZyBkZWFsLCBwbGVhc2UgcHJvdmlkZSByZWxldmFudCB0ZXh0IHRvIHN1cHBvcnQgT3B0aW9uIDIu IA0KDQpZb3VuZw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkcmlh biBGYXJyZWwgW21haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrXSANClNlbnQ6IFRodXJzZGF5LCBK YW51YXJ5IDI5LCAyMDE1IDc6MjQgQU0NClRvOiBMZWV5b3VuZzsgJ1Zhcm1hLCBFdmUgTCAoRXZl KSc7IGRiMzU0NkBhdHQuY29tOyAnTGFtLCBIaW5nLUthbSAoS2FtKSc7IGdncmFtbWVsQGp1bmlw ZXIubmV0OyBnaW9tYXJ0aUBjaXNjby5jb20NCkNjOiBwYXVsLmRvb2xhbkBjb3JpYW50LmNvbTsg Y2NhbXBAaWV0Zi5vcmc7IGNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1j Y2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogW0ND QU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1w LXJ3YS13c29uLWVuY29kZQ0KDQpIaSBhZ2FpbiwNCg0KPiBUaGVyZSBpcyBhbHdheXMgYSBwcmlv cmkga25vd2xlZGdlIGluIG9wdGljYWwgbmV0d29yayBkb21haW4gYXMgdG8gd2hvIA0KPiBhcmUg eW91IGludGVyZmFjaW5nIHdpdGguIFNvIHlvdSBrbm93IHdoaWNoIHZlbmRvciB5b3UgYXJlIGlu dGVyZmFjaW5nLiANCj4gSWYgeW91IGRvIG5vdCBrbm93LCB0aGVuIHlvdSBhcmUgaW4gdHJvdWJs ZS4NCg0KSG1tbS4gSXQgaXMgZXhhY3RseSB0eXBlIG9mIHRyb3VibGUgd2UgYXJlIHRyeWluZyB0 byBkZXRlY3QgYW5kIHByb3RlY3QgYWdhaW5zdC4NCg0KSSByZWZ1dGUgeW91ciBzdGF0ZW1lbnQg b2YgYSBwcmlvcmkga25vd2xlZGdlLiBJIHRoaW5rIHRoZXJlIGlzIGEgcHJpb3JpIGludGVudGlv biwgYnV0IG5vdCBrbm93bGVkZ2UuIFVubGVzcyB5b3UgaGF2ZSB2ZXJ5IGdvb2QgZXllc2lnaHQg b3Igc29tZW9uZSBhdCB0aGUgb3RoZXIgZW5kIG9mIHRoZSBmaWJlciB3aGVuIHlvdSBnaXZlIGl0 IGEgdHVnLCB5b3UgZG9uJ3Qga25vdy4gQW5kIGV2ZW4gdGhlbi4gRmliZXJpbmcgZXJyb3JzIGhh cHBlbiBmcm9tIHRpbWUgdG8gdGltZS4gQ29uc2lkZXIsIGluIHBhcnRpY3VsYXIgYSBwYXRjaCBw YW5lbC4NCg0KPiBOb3csIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3RhbmRhcmQgRkVDcyBhbmQg bW9kdWxhdGlvbnMgaW4gdGhlIEFJPyBHaXZlbg0KPiBzZXZlcmFsIGNob2ljZXMgZWFjaCB2ZW5k b3IgbWF5IHN1cHBvcnQgaW4gaXRzIGRldmljZSwgdGhlIHBhdGggY29tcHV0YXRpb24NCj4gd291 bGQgZmluZCBhIG1hdGNoZWQgdHlwZXMgZm9yIEZFQyBhbmQgbW9kdWxhdGlvbiBmb3IgYSBnaXZl biBvcHRpY2FsIHBhdGguIA0KPiBUaGlzIGlzIHdoYXQgaXMgaW50ZW5kZWQgd2hlbiBvcHRpY2Fs IHNpZ25hbCBwcm9jZXNzaW5nIGNvbnN0cmFpbnRzIHdlcmUgDQo+IHByb3Bvc2VkIGFzIHBhcnQg b2YgcGF0aCBjb21wdXRhdGlvbiBjb25zdHJhaW50cyBpbiBvcHRpY2FsIG5ldHdvcmtzLiANCg0K DQpUaGUgY2FzZSB5b3UgYXJlIG1ha2luZyBoZXJlIGlzIGZvciBubyBzdGFuZGFyZCBjb250cm9s IHBsYW5lIQ0KV2hhdCBpcyB0aGUgcG9pbnQgb2Ygc3RhbmRhcmRpc2luZyBpZiB0aGVyZSBpcyBu ZXZlciBhbnkgaW50ZXJ3b3JraW5nPw0KQnV0IGFjdHVhbGx5LCB3ZSBrbm93IGFib3V0IGludGVy d29ya2luZyBhdCB0aGUgcGh5c2ljYWwgbGF5ZXIsIGFuZCAobW9yZSBpbXBvcnRhbnQpIHdlIGtu b3cgYWJvdXQgYSBzaW5nbGUsIGVuZC10by1lbmQgY29udHJvbCBwbGFuZSB0aGF0IHNwYW5zIG11 bHRpcGxlIHZlbmRvciBkZXZpY2VzLiBJdCBhbGwgZXhpc3RzLg0KDQpPZiBjb3Vyc2UsIHdlIGNh biBmYWxsIGJhY2sgaW50byB0aGUgb2xkLXN0eWxlIHZlbmRvciBpc2xhbmRzLCBhbmQgbWFueSBs aWtlIHRvIGRvIHNvLiBCdXQgaXQgaXMgbm90IGEgY29tcHVsc29yeSBkZXBsb3ltZW50IG1vZGVs Lg0KDQo+IFRoZXJlIGlzIHZlcnkgbGl0dGxlIGNoYW5jZSBmb3IgdmVuZG9yIHNwZWNpZmljIEZF Q3MgYW5kIE1vZHVsYXRpb25zIHdpbGwgbWF0Y2gNCj4gZXZlbiBpZiB0aGV5IGFyZSBpZGVudGlm aWVkIHdpdGggdGhlIE9VSSBjb2RlLiANCg0KWW91IGhhdmUgaXQgdGhlIHdyb25nIHdheSByb3Vu ZCENClRoZSBPVUkgaXMgbGFyZ2VseSB0byBwcm90ZWN0IGFnYWluc3QgZXhwZWN0YXRpb25zIG9m IGludGVyd29ya2luZyB3aGVuIG5vbmUgY2FuIGV4aXN0Lg0KSXQgbWlnaHQgKG11Y2ggbGVzcyBm cmVxdWVudGx5KSBiZSB1c2VkIHRvIGRlc2NyaWJlIHRoZSB3YXkgdGhhdCB2ZW5kb3JBIGFuZCB2 ZW5kb3JCIHBpY2sgRkVDcyBhbmQgbW9kdWxhdGlvbnMgaW4gb3JkZXIgdG8gYWNoaWV2ZSBpbnRl cndvcmtpbmcuDQoNCkFkcmlhbg0KDQo= From nobody Thu Jan 29 07:59: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 8E5461A1BE3 for ; Thu, 29 Jan 2015 07:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] 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 ofXR0q9e-ehz for ; Thu, 29 Jan 2015 07:59:45 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4581A1B71 for ; Thu, 29 Jan 2015 07:59:45 -0800 (PST) Received: from localhost ([::1]:45327 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YGrVO-00052h-J6; Thu, 29 Jan 2015 18:59:42 +0300 Message-ID: <54CA58EC.6050108@labn.net> Date: Thu, 29 Jan 2015 10:59:40 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Leeyoung , "adrian@olddog.co.uk" , "'Varma, Eve L (Eve)'" , "db3546@att.com" , "'Lam, Hing-Kam (Kam)'" , "ggrammel@juniper.net" , "giomarti@cisco.com" References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "paul.doolan@coriant.com" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lberger@labn.net List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 15:59:47 -0000 I thought it would be good to let things settle a bit before responding as Shepherd. So option 1 (No definition of proprietary semantics and conflicts are handled outside of the control plane, i.e., belong to operator) was the intent of the WG at the time of publication request. This approach was also aligned with the then, and actually current, state of the ITU-T data plane (and management info) as discussed in our joint meeting. I believe option 3 (dropping the vendor specific option) isn't in conflict with this. There now seems to be support for changing the document to align it with, what I understand is, a planned update to G.874.1. This of course implies that such a change would result in this document being blocked until that update is published in 6 months or so, and assumes no substantive change its contents. Again with Shepherd hat on, I recommend avoiding the additional delay and not tie this document to the planned G.874.1 update at this time, i.e., by following option 1 (or even 3). This allows for a future bis/update that is align with the expected update to G.874.1 once it is published. Comments, objections, support? (AD, authors, chairs, wg, ...) Lou On 01/29/2015 09:51 AM, Leeyoung wrote: > Hi, > > It seems like the world is against Option 1. No big deal, please provide relevant text to support Option 2. > > Young > > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, January 29, 2015 7:24 AM > To: Leeyoung; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net; giomarti@cisco.com > Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode > > Hi again, > >> There is always a priori knowledge in optical network domain as to who >> are you interfacing with. So you know which vendor you are interfacing. >> If you do not know, then you are in trouble. > > Hmmm. It is exactly type of trouble we are trying to detect and protect against. > > I refute your statement of a priori knowledge. I think there is a priori intention, but not knowledge. Unless you have very good eyesight or someone at the other end of the fiber when you give it a tug, you don't know. And even then. Fibering errors happen from time to time. Consider, in particular a patch panel. > >> Now, what is the purpose of standard FECs and modulations in the AI? Given >> several choices each vendor may support in its device, the path computation >> would find a matched types for FEC and modulation for a given optical path. >> This is what is intended when optical signal processing constraints were >> proposed as part of path computation constraints in optical networks. > > > The case you are making here is for no standard control plane! > What is the point of standardising if there is never any interworking? > But actually, we know about interworking at the physical layer, and (more important) we know about a single, end-to-end control plane that spans multiple vendor devices. It all exists. > > Of course, we can fall back into the old-style vendor islands, and many like to do so. But it is not a compulsory deployment model. > >> There is very little chance for vendor specific FECs and Modulations will match >> even if they are identified with the OUI code. > > You have it the wrong way round! > The OUI is largely to protect against expectations of interworking when none can exist. > It might (much less frequently) be used to describe the way that vendorA and vendorB pick FECs and modulations in order to achieve interworking. > > Adrian > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From nobody Thu Jan 29 08:00: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 584AE1A1EEA for ; Thu, 29 Jan 2015 08:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 nAx50r7DW7AB for ; Thu, 29 Jan 2015 08:00:12 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789F81A1AF0 for ; Thu, 29 Jan 2015 08:00:11 -0800 (PST) Received: from BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) by BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 16:00:04 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB043.namprd05.prod.outlook.com (10.255.202.148) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 16:00:02 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.239]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.239]) with mapi id 15.01.0065.013; Thu, 29 Jan 2015 16:00:02 +0000 From: Gert Grammel To: "adrian@olddog.co.uk" , 'Leeyoung' , "'Varma, Eve L (Eve)'" , "db3546@att.com" , "'Lam, Hing-Kam (Kam)'" , "giomarti@cisco.com" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyYVlxw97EbEt0aRBiXb7/iXxZzN6TnggAAHMYCAAB6eAIADl2AAgAQvtgCAAB3lAIAABoIAgAACnYCAAAM/AIAABtyAgAAF8YCAARIzgIAAGC7A Date: Thu, 29 Jan 2015 16:00:02 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> In-Reply-To: <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.55.16] authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN1PR05MB043; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB043; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(2900100001)(93886004)(102836002)(230783001)(2501002)(66066001)(92566002)(46102003)(76576001)(74316001)(15975445007)(2950100001)(19580405001)(2656002)(87936001)(62966003)(54606007)(76176999)(40100003)(122556002)(54206007)(50986999)(99286002)(106116001)(54356999)(77156002)(33656002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB043; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2015 16:00:02.5883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB043 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB041; X-OriginatorOrg: juniper.net Archived-At: Cc: "paul.doolan@coriant.com" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 16:00:24 -0000 DQpIaSBMZWV5b3VuZywgDQoNCktlZXAgaW4gbWluZCB0aGF0IEcuNjk4LjIgYWxsb3dzIHRvIHVz ZSB0cmFuc2NlaXZlcnMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycywgYmFzZWQgb24gc3RhbmRhcmQg QUlzICg9QXBwbGljYXRpb24gQ29kZXMpLiBOb3cgaW4gY2FzZSBvZiBhIG11bHRpLXZlbmRvciBu ZXR3b3JrLCAqYWRkaXRpb25hbCogcHJvcHJpZXRhcnkgYXBwbGljYXRpb24gY29kZXMgY2FuIGJl IHVzZWQgaWYgdGhlcmUgaXMgYSBwcmUta25vd2xlZGdlIHRoYXQgdGhlIHByb3ByaWV0YXJ5IEFJ cyBtYXRjaC4gSSBiZWxpZXZlIHRoaXMgd2FzIG9uZSBjYXNlIHlvdSB3ZXJlIHJlZmVycmluZyB0 by4NClNvIGEgc2luZ2xlIHRyYW5zY2VpdmVyIEhXIGltcGxlbWVudGF0aW9uIHN1cHBvcnRpbmcg dGhlIHN0YW5kYXJkLUFJIHdpbGwgYWxtb3N0IGNlcnRhaW5seSBzdXBwb3J0IGFsc28gYSB2ZW5k b3ItQUkgZS5nLiwgIGlmIGEgaGlnaGVyIGxldmVsIG9mIE9TTlIgY2FuIGJlIHRvbGVyYXRlZCB0 aGFuIHRoZSBzdGFuZGFyZC1BSSBoYXMgZW5jb2RlZC4gSGVuY2Ugd2UgY2FuIGNvbmNsdWRlIHRo YXQgYSBzaW5nbGUgKHZlbmRvcikgdHJhbnNjZWl2ZXIgcG90ZW50aWFsbHkgc3VwcG9ydHMgYSBs aXN0IG9mIEFJcy4gU28gZXZlbiBieSBwaWNraW5nIE9wdGlvbiAyIHlvdXIgY2FzZSBjYW4gYmUg YWRkcmVzc2VkLg0KDQpIb3cgdG8gZW5jb2RlIHRob3NlIEFJcyBpcyBhbm90aGVyIG1hdHRlciBh cyBwcmludGFibGUgc3RyaW5ncyBhcmUgbm90IGFsd2F5cyB0aGUgYmVzdCBjaG9pY2UgdG8gdXNl LiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluZWxsaS13c29uLWludGVy ZmFjZS1jbGFzcy0wMyBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRoYXJp bmktbmV0bW9kLWctNjk4LTIteWFuZy0wMiBhbHJlYWR5IHByb3ZpZGUgc29tZSBlbmNvZGluZywg d2hlcmVieSBPVUkgd291bGQgbmVlZCB0byBiZSB3b3JrZWQgaW4uDQoNCkdlcnQNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRyaWFuIEZhcnJlbCBbbWFpbHRvOmFkcmlh bkBvbGRkb2cuY28udWtdIA0KU2VudDogMjkgSmFudWFyeSAyMDE1IDE0OjI0DQpUbzogJ0xlZXlv dW5nJzsgJ1Zhcm1hLCBFdmUgTCAoRXZlKSc7IGRiMzU0NkBhdHQuY29tOyAnTGFtLCBIaW5nLUth bSAoS2FtKSc7IEdlcnQgR3JhbW1lbDsgZ2lvbWFydGlAY2lzY28uY29tDQpDYzogcGF1bC5kb29s YW5AY29yaWFudC5jb207IGNjYW1wQGlldGYub3JnOyBjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc7IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZw0K U3ViamVjdDogUkU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4g ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUNCg0KSGkgYWdhaW4sDQoNCj4gVGhlcmUg aXMgYWx3YXlzIGEgcHJpb3JpIGtub3dsZWRnZSBpbiBvcHRpY2FsIG5ldHdvcmsgZG9tYWluIGFz IHRvIHdobyANCj4gYXJlIHlvdSBpbnRlcmZhY2luZyB3aXRoLiBTbyB5b3Uga25vdyB3aGljaCB2 ZW5kb3IgeW91IGFyZSBpbnRlcmZhY2luZy4NCj4gSWYgeW91IGRvIG5vdCBrbm93LCB0aGVuIHlv dSBhcmUgaW4gdHJvdWJsZS4NCg0KSG1tbS4gSXQgaXMgZXhhY3RseSB0eXBlIG9mIHRyb3VibGUg d2UgYXJlIHRyeWluZyB0byBkZXRlY3QgYW5kIHByb3RlY3QgYWdhaW5zdC4NCg0KSSByZWZ1dGUg eW91ciBzdGF0ZW1lbnQgb2YgYSBwcmlvcmkga25vd2xlZGdlLiBJIHRoaW5rIHRoZXJlIGlzIGEg cHJpb3JpIGludGVudGlvbiwgYnV0IG5vdCBrbm93bGVkZ2UuIFVubGVzcyB5b3UgaGF2ZSB2ZXJ5 IGdvb2QgZXllc2lnaHQgb3Igc29tZW9uZSBhdCB0aGUgb3RoZXIgZW5kIG9mIHRoZSBmaWJlciB3 aGVuIHlvdSBnaXZlIGl0IGEgdHVnLCB5b3UgZG9uJ3Qga25vdy4gQW5kIGV2ZW4gdGhlbi4gRmli ZXJpbmcgZXJyb3JzIGhhcHBlbiBmcm9tIHRpbWUgdG8gdGltZS4gQ29uc2lkZXIsIGluIHBhcnRp Y3VsYXIgYSBwYXRjaCBwYW5lbC4NCg0KPiBOb3csIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3Rh bmRhcmQgRkVDcyBhbmQgbW9kdWxhdGlvbnMgaW4gdGhlIEFJPyANCj4gR2l2ZW4gc2V2ZXJhbCBj aG9pY2VzIGVhY2ggdmVuZG9yIG1heSBzdXBwb3J0IGluIGl0cyBkZXZpY2UsIHRoZSBwYXRoIA0K PiBjb21wdXRhdGlvbiB3b3VsZCBmaW5kIGEgbWF0Y2hlZCB0eXBlcyBmb3IgRkVDIGFuZCBtb2R1 bGF0aW9uIGZvciBhIGdpdmVuIG9wdGljYWwgcGF0aC4NCj4gVGhpcyBpcyB3aGF0IGlzIGludGVu ZGVkIHdoZW4gb3B0aWNhbCBzaWduYWwgcHJvY2Vzc2luZyBjb25zdHJhaW50cyANCj4gd2VyZSBw cm9wb3NlZCBhcyBwYXJ0IG9mIHBhdGggY29tcHV0YXRpb24gY29uc3RyYWludHMgaW4gb3B0aWNh bCBuZXR3b3Jrcy4NCg0KDQpUaGUgY2FzZSB5b3UgYXJlIG1ha2luZyBoZXJlIGlzIGZvciBubyBz dGFuZGFyZCBjb250cm9sIHBsYW5lIQ0KV2hhdCBpcyB0aGUgcG9pbnQgb2Ygc3RhbmRhcmRpc2lu ZyBpZiB0aGVyZSBpcyBuZXZlciBhbnkgaW50ZXJ3b3JraW5nPw0KQnV0IGFjdHVhbGx5LCB3ZSBr bm93IGFib3V0IGludGVyd29ya2luZyBhdCB0aGUgcGh5c2ljYWwgbGF5ZXIsIGFuZCAobW9yZSBp bXBvcnRhbnQpIHdlIGtub3cgYWJvdXQgYSBzaW5nbGUsIGVuZC10by1lbmQgY29udHJvbCBwbGFu ZSB0aGF0IHNwYW5zIG11bHRpcGxlIHZlbmRvciBkZXZpY2VzLiBJdCBhbGwgZXhpc3RzLg0KDQpP ZiBjb3Vyc2UsIHdlIGNhbiBmYWxsIGJhY2sgaW50byB0aGUgb2xkLXN0eWxlIHZlbmRvciBpc2xh bmRzLCBhbmQgbWFueSBsaWtlIHRvIGRvIHNvLiBCdXQgaXQgaXMgbm90IGEgY29tcHVsc29yeSBk ZXBsb3ltZW50IG1vZGVsLg0KDQo+IFRoZXJlIGlzIHZlcnkgbGl0dGxlIGNoYW5jZSBmb3IgdmVu ZG9yIHNwZWNpZmljIEZFQ3MgYW5kIE1vZHVsYXRpb25zIA0KPiB3aWxsIG1hdGNoIGV2ZW4gaWYg dGhleSBhcmUgaWRlbnRpZmllZCB3aXRoIHRoZSBPVUkgY29kZS4NCg0KWW91IGhhdmUgaXQgdGhl IHdyb25nIHdheSByb3VuZCENClRoZSBPVUkgaXMgbGFyZ2VseSB0byBwcm90ZWN0IGFnYWluc3Qg ZXhwZWN0YXRpb25zIG9mIGludGVyd29ya2luZyB3aGVuIG5vbmUgY2FuIGV4aXN0Lg0KSXQgbWln aHQgKG11Y2ggbGVzcyBmcmVxdWVudGx5KSBiZSB1c2VkIHRvIGRlc2NyaWJlIHRoZSB3YXkgdGhh dCB2ZW5kb3JBIGFuZCB2ZW5kb3JCIHBpY2sgRkVDcyBhbmQgbW9kdWxhdGlvbnMgaW4gb3JkZXIg dG8gYWNoaWV2ZSBpbnRlcndvcmtpbmcuDQoNCkFkcmlhbg0KDQo= From nobody Thu Jan 29 08:07: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 C00C51A03A8 for ; Thu, 29 Jan 2015 08:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 ex6L-xu1ktwU for ; Thu, 29 Jan 2015 08:07:44 -0800 (PST) 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 263E41A047A for ; Thu, 29 Jan 2015 08:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2855; q=dns/txt; s=iport; t=1422547660; x=1423757260; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f6O7xsoz0llI0RDZoChZzu8XGlde8qGyK5jezWCmHq8=; b=SgEew2GMMK2303NhxR7BAPJyTnZBvbE86GQjRuLRK3rZL9PxmUqCTB4e LFkH1ZTiTPVmzAGf9SdTBI+bne/SxpdFqayQZ5vwPPgt+eCygviRbLBor JCSSSdTy3Zocv4CjqemGD4GQkdp0fpPWuDJ7r7duEzwzqyj+0klpGITgR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIFAHRaylStJV2a/2dsb2JhbABagwZSWQTCNIIbCoVxAoEhQwEBAQEBfYQNAQEEAQEBNw8lCw4EAQg2KwwLJQIEAQ0FiCwN11IBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBI90B4QpBY50hViDSoEXjXKDPSKCMoE8b4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,486,1418083200"; d="scan'208";a="391760388" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jan 2015 16:07:30 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0TG7TQw015018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 16:07:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.211]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 10:07:29 -0600 From: "Gabriele Maria Galimberti (ggalimbe)" To: "adrian@olddog.co.uk" , "'Leeyoung'" , "'Varma, Eve L (Eve)'" , "db3546@att.com" , "'Lam, Hing-Kam (Kam)'" , "ggrammel@juniper.net" , "Giovanni Martinelli (giomarti)" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQO92tg2blSM4Jd0q0kccY3X7UUA== Date: Thu, 29 Jan 2015 16:07:28 +0000 Message-ID: In-Reply-To: <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.148.212.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <92984EFDDCF11B44B1C12B2FD4568D31@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "paul.doolan@coriant.com" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 16:07:52 -0000 Hi All,=20 I'm in favour of option 2 as well. I'd like to note that there are other drafts in ccamp that may be affected by this change: - draft-galikunze-ccamp-g-698-2-snmp-mib - draft-dharinigert-ccamp-g-698-2-lmp - draft-dharini-netmod-g-698-2-yang I'm co-author of them and as such I'll coordinate with the other authors to fix the drafts. Best Regards,=20 Gabriele Gabriele Galimberti Technical Leader Cisco Photonics Srl via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy www.cisco.com/global/IT/ ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 On 1/29/15 2:23 PM, "Adrian Farrel" wrote: >Hi again, > >> There is always a priori knowledge in optical network domain as to who >> are you interfacing with. So you know which vendor you are interfacing. >> If you do not know, then you are in trouble. > >Hmmm. It is exactly type of trouble we are trying to detect and protect >against. > >I refute your statement of a priori knowledge. I think there is a priori >intention, but not knowledge. Unless you have very good eyesight or >someone at the other end of the fiber when you give it a tug, you don't >know. And even then. Fibering errors happen from time to time. Consider, >in particular a patch panel. > >> Now, what is the purpose of standard FECs and modulations in the AI? >>Given >> several choices each vendor may support in its device, the path >>computation >> would find a matched types for FEC and modulation for a given optical >>path.=20 >> This is what is intended when optical signal processing constraints >>were=20 >> proposed as part of path computation constraints in optical networks. > > >The case you are making here is for no standard control plane! >What is the point of standardising if there is never any interworking? >But actually, we know about interworking at the physical layer, and (more >important) we know about a single, end-to-end control plane that spans >multiple vendor devices. It all exists. > >Of course, we can fall back into the old-style vendor islands, and many >like to do so. But it is not a compulsory deployment model. > >> There is very little chance for vendor specific FECs and Modulations >>will match >> even if they are identified with the OUI code. > >You have it the wrong way round! >The OUI is largely to protect against expectations of interworking when >none can exist. >It might (much less frequently) be used to describe the way that vendorA >and vendorB pick FECs and modulations in order to achieve interworking. > >Adrian > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp From nobody Thu Jan 29 08:18:02 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 0DCA21A0104 for ; Thu, 29 Jan 2015 08:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r175ja48sRtE for ; Thu, 29 Jan 2015 08:17:59 -0800 (PST) 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 E48841A00E9 for ; Thu, 29 Jan 2015 08:17:57 -0800 (PST) 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 BRW61076; Thu, 29 Jan 2015 16:17:56 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 16:17:55 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.61]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Fri, 30 Jan 2015 00:17:52 +0800 From: "Zhangxian (Xian)" To: "lberger@labn.net" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQOzdWKmSQCof59UKyo5HGi/I8RJzVeP6AgAAF8YCAARI0gIAAGGcAgAATGACAAIfBTg== Date: Thu, 29 Jan 2015 16:17:51 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm>, <54CA58EC.6050108@labn.net> In-Reply-To: <54CA58EC.6050108@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.89.14] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 16:18:01 -0000 SGksIExvdSwgDQogDQogICBJIHN1cHBvcnQgeW91ciBwcm9wb3NhbC4gDQoNCiAgSnVzdCBhIHRo b3VnaHQ6IGdpdmVuIHRoZSBtYXNzaXZlIHN1cHBvcnQgb2YgT3B0aW9uIDIgZnJvbSBXRywgIG1h eWJlIHdlIGNhbiByZWNvbmNpbGUgYnkgbW92aW5nIHRoZSBXRyBkcmFmdCBmb3J3YXJkIHVzaW5n IGVpdGhlciBPcHRpb24gMS8zLCB3aGlsZSB3cml0aW5nIGEgc2hvcnQgZHJhZnQgdG8gZG9jdW1l bnQgdGhlIHVwZGF0ZSBuZWVkZWQgdG8gbWF0Y2ggdGhlIHRvLWJlLXVwZGF0ZWQgRy44NzQuMT8g U28gdGhhdCBvbmNlIGl0IGlzIHVwZGF0ZWQsIHdlIGNhbiBtb3ZlIHRoZSBkcmFmdCBxdWlja2x5 LiANCg0KUmVnYXJkcywNClhpYW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kt6K8/sjLOiBDQ0FNUCBbY2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMb3Ug QmVyZ2VyIFtsYmVyZ2VyQGxhYm4ubmV0XQ0Kt6LLzcqxvOQ6IDIwMTXE6jHUwjI5yNUgMjM6NTkN CsrVvP7IyzogTGVleW91bmc7IGFkcmlhbkBvbGRkb2cuY28udWs7ICdWYXJtYSwgRXZlIEwgKEV2 ZSknOyBkYjM1NDZAYXR0LmNvbTsgJ0xhbSwgSGluZy1LYW0gKEthbSknOyBnZ3JhbW1lbEBqdW5p cGVyLm5ldDsgZ2lvbWFydGlAY2lzY28uY29tDQqzrcvNOiBwYXVsLmRvb2xhbkBjb3JpYW50LmNv bTsgY2NhbXBAaWV0Zi5vcmc7IGNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0 Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnDQrW98ziOiBSZTogW0ND QU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRmLWNjYW1w LXJ3YS13c29uLWVuY29kZQ0KDQpJIHRob3VnaHQgaXQgd291bGQgYmUgZ29vZCB0byBsZXQgdGhp bmdzIHNldHRsZSBhIGJpdCBiZWZvcmUgcmVzcG9uZGluZw0KYXMgU2hlcGhlcmQuDQoNClNvIG9w dGlvbiAxIChObyBkZWZpbml0aW9uIG9mIHByb3ByaWV0YXJ5IHNlbWFudGljcyBhbmQgY29uZmxp Y3RzIGFyZQ0KaGFuZGxlZCBvdXRzaWRlIG9mIHRoZSBjb250cm9sIHBsYW5lLCBpLmUuLCBiZWxv bmcgdG8gb3BlcmF0b3IpIHdhcyB0aGUNCmludGVudCBvZiB0aGUgV0cgYXQgdGhlIHRpbWUgb2Yg cHVibGljYXRpb24gcmVxdWVzdC4gIFRoaXMgYXBwcm9hY2ggd2FzDQphbHNvIGFsaWduZWQgd2l0 aCB0aGUgdGhlbiwgYW5kIGFjdHVhbGx5IGN1cnJlbnQsIHN0YXRlIG9mIHRoZSBJVFUtVA0KZGF0 YSBwbGFuZSAoYW5kIG1hbmFnZW1lbnQgaW5mbykgYXMgZGlzY3Vzc2VkIGluIG91ciBqb2ludCBt ZWV0aW5nLiBJDQpiZWxpZXZlIG9wdGlvbiAzIChkcm9wcGluZyB0aGUgdmVuZG9yIHNwZWNpZmlj IG9wdGlvbikgaXNuJ3QgaW4gY29uZmxpY3QNCndpdGggdGhpcy4NCg0KVGhlcmUgbm93IHNlZW1z IHRvIGJlIHN1cHBvcnQgZm9yIGNoYW5naW5nIHRoZSBkb2N1bWVudCB0byBhbGlnbiBpdA0Kd2l0 aCwgd2hhdCBJIHVuZGVyc3RhbmQgaXMsIGEgcGxhbm5lZCB1cGRhdGUgdG8gRy44NzQuMS4gIFRo aXMgb2YgY291cnNlDQppbXBsaWVzIHRoYXQgc3VjaCBhIGNoYW5nZSB3b3VsZCByZXN1bHQgaW4g dGhpcyBkb2N1bWVudCBiZWluZyBibG9ja2VkDQp1bnRpbCB0aGF0IHVwZGF0ZSBpcyBwdWJsaXNo ZWQgaW4gNiBtb250aHMgb3Igc28sIGFuZCBhc3N1bWVzIG5vDQpzdWJzdGFudGl2ZSBjaGFuZ2Ug aXRzIGNvbnRlbnRzLg0KDQpBZ2FpbiB3aXRoIFNoZXBoZXJkIGhhdCBvbiwgSSByZWNvbW1lbmQg YXZvaWRpbmcgdGhlIGFkZGl0aW9uYWwgZGVsYXkNCmFuZCBub3QgdGllIHRoaXMgZG9jdW1lbnQg dG8gdGhlIHBsYW5uZWQgRy44NzQuMSB1cGRhdGUgYXQgdGhpcyB0aW1lLA0KaS5lLiwgYnkgZm9s bG93aW5nIG9wdGlvbiAxIChvciBldmVuIDMpLiAgVGhpcyBhbGxvd3MgZm9yIGEgZnV0dXJlDQpi aXMvdXBkYXRlIHRoYXQgaXMgYWxpZ24gd2l0aCB0aGUgZXhwZWN0ZWQgdXBkYXRlIHRvIEcuODc0 LjEgb25jZSBpdCBpcw0KcHVibGlzaGVkLg0KDQpDb21tZW50cywgb2JqZWN0aW9ucywgc3VwcG9y dD8gIChBRCwgYXV0aG9ycywgY2hhaXJzLCB3ZywgLi4uKQ0KDQpMb3UNCg0KT24gMDEvMjkvMjAx NSAwOTo1MSBBTSwgTGVleW91bmcgd3JvdGU6DQo+IEhpLA0KPg0KPiBJdCBzZWVtcyBsaWtlIHRo ZSB3b3JsZCBpcyBhZ2FpbnN0IE9wdGlvbiAxLiBObyBiaWcgZGVhbCwgcGxlYXNlIHByb3ZpZGUg cmVsZXZhbnQgdGV4dCB0byBzdXBwb3J0IE9wdGlvbiAyLg0KPg0KPiBZb3VuZw0KPg0KPg0KPg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBZHJpYW4gRmFycmVsIFttYWls dG86YWRyaWFuQG9sZGRvZy5jby51a10NCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjksIDIw MTUgNzoyNCBBTQ0KPiBUbzogTGVleW91bmc7ICdWYXJtYSwgRXZlIEwgKEV2ZSknOyBkYjM1NDZA YXR0LmNvbTsgJ0xhbSwgSGluZy1LYW0gKEthbSknOyBnZ3JhbW1lbEBqdW5pcGVyLm5ldDsgZ2lv bWFydGlAY2lzY28uY29tDQo+IENjOiBwYXVsLmRvb2xhbkBjb3JpYW50LmNvbTsgY2NhbXBAaWV0 Zi5vcmc7IGNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1jY2FtcC1yd2Et d3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIFZl bmRvci1TcGVjaWZpYyBBcHBsaWNhdGlvbiBDb2RlIGluIGRyYWZ0LWlldGYtY2NhbXAtcndhLXdz b24tZW5jb2RlDQo+DQo+IEhpIGFnYWluLA0KPg0KPj4gVGhlcmUgaXMgYWx3YXlzIGEgcHJpb3Jp IGtub3dsZWRnZSBpbiBvcHRpY2FsIG5ldHdvcmsgZG9tYWluIGFzIHRvIHdobw0KPj4gYXJlIHlv dSBpbnRlcmZhY2luZyB3aXRoLiBTbyB5b3Uga25vdyB3aGljaCB2ZW5kb3IgeW91IGFyZSBpbnRl cmZhY2luZy4NCj4+IElmIHlvdSBkbyBub3Qga25vdywgdGhlbiB5b3UgYXJlIGluIHRyb3VibGUu DQo+DQo+IEhtbW0uIEl0IGlzIGV4YWN0bHkgdHlwZSBvZiB0cm91YmxlIHdlIGFyZSB0cnlpbmcg dG8gZGV0ZWN0IGFuZCBwcm90ZWN0IGFnYWluc3QuDQo+DQo+IEkgcmVmdXRlIHlvdXIgc3RhdGVt ZW50IG9mIGEgcHJpb3JpIGtub3dsZWRnZS4gSSB0aGluayB0aGVyZSBpcyBhIHByaW9yaSBpbnRl bnRpb24sIGJ1dCBub3Qga25vd2xlZGdlLiBVbmxlc3MgeW91IGhhdmUgdmVyeSBnb29kIGV5ZXNp Z2h0IG9yIHNvbWVvbmUgYXQgdGhlIG90aGVyIGVuZCBvZiB0aGUgZmliZXIgd2hlbiB5b3UgZ2l2 ZSBpdCBhIHR1ZywgeW91IGRvbid0IGtub3cuIEFuZCBldmVuIHRoZW4uIEZpYmVyaW5nIGVycm9y cyBoYXBwZW4gZnJvbSB0aW1lIHRvIHRpbWUuIENvbnNpZGVyLCBpbiBwYXJ0aWN1bGFyIGEgcGF0 Y2ggcGFuZWwuDQo+DQo+PiBOb3csIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3RhbmRhcmQgRkVD cyBhbmQgbW9kdWxhdGlvbnMgaW4gdGhlIEFJPyBHaXZlbg0KPj4gc2V2ZXJhbCBjaG9pY2VzIGVh Y2ggdmVuZG9yIG1heSBzdXBwb3J0IGluIGl0cyBkZXZpY2UsIHRoZSBwYXRoIGNvbXB1dGF0aW9u DQo+PiB3b3VsZCBmaW5kIGEgbWF0Y2hlZCB0eXBlcyBmb3IgRkVDIGFuZCBtb2R1bGF0aW9uIGZv ciBhIGdpdmVuIG9wdGljYWwgcGF0aC4NCj4+IFRoaXMgaXMgd2hhdCBpcyBpbnRlbmRlZCB3aGVu IG9wdGljYWwgc2lnbmFsIHByb2Nlc3NpbmcgY29uc3RyYWludHMgd2VyZQ0KPj4gcHJvcG9zZWQg YXMgcGFydCBvZiBwYXRoIGNvbXB1dGF0aW9uIGNvbnN0cmFpbnRzIGluIG9wdGljYWwgbmV0d29y a3MuDQo+DQo+DQo+IFRoZSBjYXNlIHlvdSBhcmUgbWFraW5nIGhlcmUgaXMgZm9yIG5vIHN0YW5k YXJkIGNvbnRyb2wgcGxhbmUhDQo+IFdoYXQgaXMgdGhlIHBvaW50IG9mIHN0YW5kYXJkaXNpbmcg aWYgdGhlcmUgaXMgbmV2ZXIgYW55IGludGVyd29ya2luZz8NCj4gQnV0IGFjdHVhbGx5LCB3ZSBr bm93IGFib3V0IGludGVyd29ya2luZyBhdCB0aGUgcGh5c2ljYWwgbGF5ZXIsIGFuZCAobW9yZSBp bXBvcnRhbnQpIHdlIGtub3cgYWJvdXQgYSBzaW5nbGUsIGVuZC10by1lbmQgY29udHJvbCBwbGFu ZSB0aGF0IHNwYW5zIG11bHRpcGxlIHZlbmRvciBkZXZpY2VzLiBJdCBhbGwgZXhpc3RzLg0KPg0K PiBPZiBjb3Vyc2UsIHdlIGNhbiBmYWxsIGJhY2sgaW50byB0aGUgb2xkLXN0eWxlIHZlbmRvciBp c2xhbmRzLCBhbmQgbWFueSBsaWtlIHRvIGRvIHNvLiBCdXQgaXQgaXMgbm90IGEgY29tcHVsc29y eSBkZXBsb3ltZW50IG1vZGVsLg0KPg0KPj4gVGhlcmUgaXMgdmVyeSBsaXR0bGUgY2hhbmNlIGZv ciB2ZW5kb3Igc3BlY2lmaWMgRkVDcyBhbmQgTW9kdWxhdGlvbnMgd2lsbCBtYXRjaA0KPj4gZXZl biBpZiB0aGV5IGFyZSBpZGVudGlmaWVkIHdpdGggdGhlIE9VSSBjb2RlLg0KPg0KPiBZb3UgaGF2 ZSBpdCB0aGUgd3Jvbmcgd2F5IHJvdW5kIQ0KPiBUaGUgT1VJIGlzIGxhcmdlbHkgdG8gcHJvdGVj dCBhZ2FpbnN0IGV4cGVjdGF0aW9ucyBvZiBpbnRlcndvcmtpbmcgd2hlbiBub25lIGNhbiBleGlz dC4NCj4gSXQgbWlnaHQgKG11Y2ggbGVzcyBmcmVxdWVudGx5KSBiZSB1c2VkIHRvIGRlc2NyaWJl IHRoZSB3YXkgdGhhdCB2ZW5kb3JBIGFuZCB2ZW5kb3JCIHBpY2sgRkVDcyBhbmQgbW9kdWxhdGlv bnMgaW4gb3JkZXIgdG8gYWNoaWV2ZSBpbnRlcndvcmtpbmcuDQo+DQo+IEFkcmlhbg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBt YWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jY2FtcA0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA== From nobody Thu Jan 29 08:23:37 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 DDE431A874F for ; Thu, 29 Jan 2015 08:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, 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 eziByuNeEuPI for ; Thu, 29 Jan 2015 08:23:32 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 82B8C1A8742 for ; Thu, 29 Jan 2015 08:23:32 -0800 (PST) Received: (qmail 14646 invoked by uid 0); 29 Jan 2015 16:23:27 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 29 Jan 2015 16:23:27 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id lsN31p00F2SSUrH01sN6K6; Thu, 29 Jan 2015 09:22:19 -0700 X-Authority-Analysis: v=2.1 cv=BqwOn+n5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=hUXq7yzdp1YA:10 a=Zu_UBlEkk2cA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=YNv0rlydsVwA:10 a=48vgC7mUAAAA:8 a=AEDFM0qtAAAA:8 a=zQP7CpKOAAAA:8 a=OUXY8nFuAAAA:8 a=AUd_NHdVAAAA:8 a=LA_P08GTAAAA:8 a=r2wunU7YzEtRMcvcPpoA:9 a=C1wDX5cZ5RUraAx1:21 a=Pqw4Chk3US1haM5N:21 a=AWzbc7it75AA: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=4SfO+PfoAoJ/CT6yhKZur84FHhyl/Z+lXt+Ahj/3/a8=; b=qtTrSGISdsEX6hBTGc1PcSatK1UXX86m74/7NwzTqi4aI/s/4dWpMCrqPB9spT0/DzVFodKJz94dROXyH3s4wZjBW5eDDXa3Vnw8xcclNUve/6n+H9mFOsTEDxrbTJPE; Received: from box313.bluehost.com ([69.89.31.113]:59164 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YGrr1-00073C-1v; Thu, 29 Jan 2015 09:22:03 -0700 Message-ID: <54CA5E28.10005@labn.net> Date: Thu, 29 Jan 2015 11:22:00 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Zhangxian (Xian)" References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm>, <54CA58EC.6050108@labn.net> In-Reply-To: Content-Type: text/plain; charset=gbk 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: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 16:23:35 -0000 On 01/29/2015 11:17 AM, Zhangxian (Xian) wrote: > Hi, Lou, > > I support your proposal. > > Just a thought: given the massive support of Option 2 from WG, maybe > we can reconcile by moving the WG draft forward using either Option > 1/3, while writing a short draft to document the update needed to > match the to-be-updated G.874.1? So that once it is updated, we can > move the draft quickly. > Seems right to me (as contributor) Lou > Regards, > Xian > > ________________________________________ > 发件人: CCAMP [ccamp-bounces@ietf.org] 代表 Lou Berger [lberger@labn.net] > 发送时间: 2015年1月29日 23:59 > 收件人: Leeyoung; adrian@olddog.co.uk; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net; giomarti@cisco.com > 抄送: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > 主题: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode > > I thought it would be good to let things settle a bit before responding > as Shepherd. > > So option 1 (No definition of proprietary semantics and conflicts are > handled outside of the control plane, i.e., belong to operator) was the > intent of the WG at the time of publication request. This approach was > also aligned with the then, and actually current, state of the ITU-T > data plane (and management info) as discussed in our joint meeting. I > believe option 3 (dropping the vendor specific option) isn't in conflict > with this. > > There now seems to be support for changing the document to align it > with, what I understand is, a planned update to G.874.1. This of course > implies that such a change would result in this document being blocked > until that update is published in 6 months or so, and assumes no > substantive change its contents. > > Again with Shepherd hat on, I recommend avoiding the additional delay > and not tie this document to the planned G.874.1 update at this time, > i.e., by following option 1 (or even 3). This allows for a future > bis/update that is align with the expected update to G.874.1 once it is > published. > > Comments, objections, support? (AD, authors, chairs, wg, ...) > > Lou > > On 01/29/2015 09:51 AM, Leeyoung wrote: >> Hi, >> >> It seems like the world is against Option 1. No big deal, please provide relevant text to support Option 2. >> >> Young >> >> >> >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Thursday, January 29, 2015 7:24 AM >> To: Leeyoung; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net; giomarti@cisco.com >> Cc: paul.doolan@coriant.com; ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org >> Subject: RE: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode >> >> Hi again, >> >>> There is always a priori knowledge in optical network domain as to who >>> are you interfacing with. So you know which vendor you are interfacing. >>> If you do not know, then you are in trouble. >> >> Hmmm. It is exactly type of trouble we are trying to detect and protect against. >> >> I refute your statement of a priori knowledge. I think there is a priori intention, but not knowledge. Unless you have very good eyesight or someone at the other end of the fiber when you give it a tug, you don't know. And even then. Fibering errors happen from time to time. Consider, in particular a patch panel. >> >>> Now, what is the purpose of standard FECs and modulations in the AI? Given >>> several choices each vendor may support in its device, the path computation >>> would find a matched types for FEC and modulation for a given optical path. >>> This is what is intended when optical signal processing constraints were >>> proposed as part of path computation constraints in optical networks. >> >> >> The case you are making here is for no standard control plane! >> What is the point of standardising if there is never any interworking? >> But actually, we know about interworking at the physical layer, and (more important) we know about a single, end-to-end control plane that spans multiple vendor devices. It all exists. >> >> Of course, we can fall back into the old-style vendor islands, and many like to do so. But it is not a compulsory deployment model. >> >>> There is very little chance for vendor specific FECs and Modulations will match >>> even if they are identified with the OUI code. >> >> You have it the wrong way round! >> The OUI is largely to protect against expectations of interworking when none can exist. >> It might (much less frequently) be used to describe the way that vendorA and vendorB pick FECs and modulations in order to achieve interworking. >> >> Adrian >> >> _______________________________________________ >> 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 Jan 29 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 893061A874E for ; Thu, 29 Jan 2015 08:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, 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 BBVGWCAVOlGP for ; Thu, 29 Jan 2015 08:34:04 -0800 (PST) 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 4FB051A19FA for ; Thu, 29 Jan 2015 08:34:03 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-47-54ca60f92ac0 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8F.DB.04231.9F06AC45; Thu, 29 Jan 2015 17:34:01 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.154]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 17:34:00 +0100 From: Daniele Ceccarelli To: Lou Berger , "Zhangxian (Xian)" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyYU8oHKyXj2jUeONQmhoT7wnpzN2eyAgAAFu4CAAB6eAIADl18AgAQvtgCAAB3lAIAABoMAgAACnYCAAAM+AIAABtyAgAAF8oCAARIzgIAAGGgAgAATFwCAAAUVgIAAASkAgAASukA= Date: Thu, 29 Jan 2015 16:34:00 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se> References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm>, <54CA58EC.6050108@labn.net> <54CA5E28.10005@labn.net> In-Reply-To: <54CA5E28.10005@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RvdnwqkQg99T1SymHj3GZvFkzg0W i2kLT7FZdDS/ZbFYvK2TxYHVo+XIW1aPJUt+Mnl82NTM5vHl8me2AJYoLpuU1JzMstQifbsE rowf67uZCta5VNy61sXawHjGqYuRk0NCwETicfMmFghbTOLCvfVsXYxcHEICRxglWjsbGSGc JYwS3VNnsnYxcnCwCVhJPDnkA9IgIuAr8eH8UmaQGmaBq4wSZ+etYgSpERaIlnj4lAmiJkai +TvEAhGBeYwSrzcHg9gsAqoSd37tBSvnBZpz7A8XSFhI4BuzxJcXjCA2p4CaxIeuP2BjGAVk JSbsXgQWZxYQl7j1ZD4TxM0CEkv2nGeGsEUlXj7+xwphK0pcnb6cCaJeS2Jew28oW1FiSvdD dhCbV0BQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5da sokRGG8Ht/zW3cG4+rXjIUYBDkYlHl6DRSdDhFgTy4orcw8xSnOwKInz2hkfChESSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAyCx9vpzxoqXHk1nqRXW931Jq97G+t7/zwq+hbtuHEO+nattN Vu9eUPiqQ4DlQD7bpy8Cs817/W+fFdA23LV+yu1JPk7uxzknXP5UtKH2opuj1pUpQte3fTs+ bZ7sXNki1/CJTbact88/s75rbzO5nTmIP7RTKMaoekn1l2Qes3ds+7+1tTFxKLEUZyQaajEX FScCANX8GbGYAgAA Archived-At: Cc: "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 16:34:06 -0000 SSB0aGluayBYaWFuJ3MgcHJvcG9zYWwgbWFrZXMgc2Vuc2UuDQoNCkkgd291bGQgbGlrZSBub3Qg dG8gaG9sZCB0aGUgZHJhZnQgZm9yIDYgbW9yZSBtb250aHMuIA0KQXMgY2hhaXIgSSB3b3VsZCBz dWdnZXN0IHRvIGdvIGZvciBvcHRpb24gMSBvciAzIGFuZCB0aGVuIGdvIGZvciBhIGJpcyB3aGVu IEcuODc0LjEgd2lsbCBiZSBjb25zZW50ZWQuDQpBcyBjb250cmlidXRvciwgYW1vbmcgMSBhbmQg MyBJIHdvdWxkIHByZWZlciAxIGJ1dCBJIHRoaW5rIDMgbGVhdmVzIG1vcmUgcm9vbSBmb3IgYSBz aW1wbGUgYW5kIHN0cmFpZ2h0Zm9yd2FyZCBiaXMuDQoNCk9waW5pb25zIG9uIHRoaXMgbGFzdCBz dGF0ZW1lbnQ/DQoNCkJSDQpEYW5pZWxlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQ0NBTVAgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTG91IEJlcmdlcg0KPiBTZW50OiBnaW92ZWSorCAyOSBnZW5uYWlvIDIwMTUgMTc6MjINCj4g VG86IFpoYW5neGlhbiAoWGlhbikNCj4gQ2M6IGNjYW1wQGlldGYub3JnOyBjY2FtcC1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtcndhLQ0KPiB3c29uLWVuY29kZS5hbGxA dG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmljIEFw cGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC0NCj4gcndhLXdzb24tZW5jb2RlDQo+ IA0KPiBPbiAwMS8yOS8yMDE1IDExOjE3IEFNLCBaaGFuZ3hpYW4gKFhpYW4pIHdyb3RlOg0KPiA+ IEhpLCBMb3UsDQo+ID4NCj4gPiAgICBJIHN1cHBvcnQgeW91ciBwcm9wb3NhbC4NCj4gPg0KPiA+ IEp1c3QgYSB0aG91Z2h0OiBnaXZlbiB0aGUgbWFzc2l2ZSBzdXBwb3J0IG9mIE9wdGlvbiAyIGZy b20gV0csICBtYXliZQ0KPiA+IHdlIGNhbiByZWNvbmNpbGUgYnkgbW92aW5nIHRoZSBXRyBkcmFm dCBmb3J3YXJkIHVzaW5nIGVpdGhlciBPcHRpb24NCj4gPiAxLzMsIHdoaWxlIHdyaXRpbmcgYSBz aG9ydCBkcmFmdCB0byBkb2N1bWVudCB0aGUgdXBkYXRlIG5lZWRlZCB0bw0KPiA+IG1hdGNoIHRo ZSB0by1iZS11cGRhdGVkIEcuODc0LjE/IFNvIHRoYXQgb25jZSBpdCBpcyB1cGRhdGVkLCB3ZSBj YW4NCj4gPiBtb3ZlIHRoZSBkcmFmdCBxdWlja2x5Lg0KPiA+DQo+IA0KPiBTZWVtcyByaWdodCB0 byBtZSAoYXMgY29udHJpYnV0b3IpDQo+IA0KPiBMb3UNCj4gDQo+ID4gUmVnYXJkcywNCj4gPiBY aWFuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gt6K8/sjLOiBDQ0FNUCBbY2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMb3UgQmVyZ2Vy DQo+IFtsYmVyZ2VyQGxhYm4ubmV0XQ0KPiA+ILeiy83KsbzkOiAyMDE1xOox1MIyOcjVIDIzOjU5 DQo+ID4gytW8/sjLOiBMZWV5b3VuZzsgYWRyaWFuQG9sZGRvZy5jby51azsgJ1Zhcm1hLCBFdmUg TCAoRXZlKSc7DQo+ID4gZGIzNTQ2QGF0dC5jb207ICdMYW0sIEhpbmctS2FtIChLYW0pJzsgZ2dy YW1tZWxAanVuaXBlci5uZXQ7DQo+ID4gZ2lvbWFydGlAY2lzY28uY29tDQo+ID4gs63LzTogcGF1 bC5kb29sYW5AY29yaWFudC5jb207IGNjYW1wQGlldGYub3JnOw0KPiA+IGNjYW1wLWNoYWlyc0B0 b29scy5pZXRmLm9yZzsNCj4gPiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZS5hbGxA dG9vbHMuaWV0Zi5vcmcNCj4gPiDW98ziOiBSZTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBw bGljYXRpb24gQ29kZSBpbg0KPiA+IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlDQo+ ID4NCj4gPiBJIHRob3VnaHQgaXQgd291bGQgYmUgZ29vZCB0byBsZXQgdGhpbmdzIHNldHRsZSBh IGJpdCBiZWZvcmUNCj4gPiByZXNwb25kaW5nIGFzIFNoZXBoZXJkLg0KPiA+DQo+ID4gU28gb3B0 aW9uIDEgKE5vIGRlZmluaXRpb24gb2YgcHJvcHJpZXRhcnkgc2VtYW50aWNzIGFuZCBjb25mbGlj dHMgYXJlDQo+ID4gaGFuZGxlZCBvdXRzaWRlIG9mIHRoZSBjb250cm9sIHBsYW5lLCBpLmUuLCBi ZWxvbmcgdG8gb3BlcmF0b3IpIHdhcw0KPiA+IHRoZSBpbnRlbnQgb2YgdGhlIFdHIGF0IHRoZSB0 aW1lIG9mIHB1YmxpY2F0aW9uIHJlcXVlc3QuICBUaGlzDQo+ID4gYXBwcm9hY2ggd2FzIGFsc28g YWxpZ25lZCB3aXRoIHRoZSB0aGVuLCBhbmQgYWN0dWFsbHkgY3VycmVudCwgc3RhdGUNCj4gPiBv ZiB0aGUgSVRVLVQgZGF0YSBwbGFuZSAoYW5kIG1hbmFnZW1lbnQgaW5mbykgYXMgZGlzY3Vzc2Vk IGluIG91cg0KPiA+IGpvaW50IG1lZXRpbmcuIEkgYmVsaWV2ZSBvcHRpb24gMyAoZHJvcHBpbmcg dGhlIHZlbmRvciBzcGVjaWZpYw0KPiA+IG9wdGlvbikgaXNuJ3QgaW4gY29uZmxpY3Qgd2l0aCB0 aGlzLg0KPiA+DQo+ID4gVGhlcmUgbm93IHNlZW1zIHRvIGJlIHN1cHBvcnQgZm9yIGNoYW5naW5n IHRoZSBkb2N1bWVudCB0byBhbGlnbiBpdA0KPiA+IHdpdGgsIHdoYXQgSSB1bmRlcnN0YW5kIGlz LCBhIHBsYW5uZWQgdXBkYXRlIHRvIEcuODc0LjEuICBUaGlzIG9mDQo+ID4gY291cnNlIGltcGxp ZXMgdGhhdCBzdWNoIGEgY2hhbmdlIHdvdWxkIHJlc3VsdCBpbiB0aGlzIGRvY3VtZW50IGJlaW5n DQo+ID4gYmxvY2tlZCB1bnRpbCB0aGF0IHVwZGF0ZSBpcyBwdWJsaXNoZWQgaW4gNiBtb250aHMg b3Igc28sIGFuZCBhc3N1bWVzDQo+ID4gbm8gc3Vic3RhbnRpdmUgY2hhbmdlIGl0cyBjb250ZW50 cy4NCj4gPg0KPiA+IEFnYWluIHdpdGggU2hlcGhlcmQgaGF0IG9uLCBJIHJlY29tbWVuZCBhdm9p ZGluZyB0aGUgYWRkaXRpb25hbCBkZWxheQ0KPiA+IGFuZCBub3QgdGllIHRoaXMgZG9jdW1lbnQg dG8gdGhlIHBsYW5uZWQgRy44NzQuMSB1cGRhdGUgYXQgdGhpcyB0aW1lLA0KPiA+IGkuZS4sIGJ5 IGZvbGxvd2luZyBvcHRpb24gMSAob3IgZXZlbiAzKS4gIFRoaXMgYWxsb3dzIGZvciBhIGZ1dHVy ZQ0KPiA+IGJpcy91cGRhdGUgdGhhdCBpcyBhbGlnbiB3aXRoIHRoZSBleHBlY3RlZCB1cGRhdGUg dG8gRy44NzQuMSBvbmNlIGl0DQo+ID4gaXMgcHVibGlzaGVkLg0KPiA+DQo+ID4gQ29tbWVudHMs IG9iamVjdGlvbnMsIHN1cHBvcnQ/ICAoQUQsIGF1dGhvcnMsIGNoYWlycywgd2csIC4uLikNCj4g Pg0KPiA+IExvdQ0KPiA+DQo+ID4gT24gMDEvMjkvMjAxNSAwOTo1MSBBTSwgTGVleW91bmcgd3Jv dGU6DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBJdCBzZWVtcyBsaWtlIHRoZSB3b3JsZCBpcyBhZ2Fp bnN0IE9wdGlvbiAxLiBObyBiaWcgZGVhbCwgcGxlYXNlIHByb3ZpZGUNCj4gcmVsZXZhbnQgdGV4 dCB0byBzdXBwb3J0IE9wdGlvbiAyLg0KPiA+Pg0KPiA+PiBZb3VuZw0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBBZHJpYW4gRmFy cmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5jby51a10NCj4gPj4gU2VudDogVGh1cnNkYXksIEph bnVhcnkgMjksIDIwMTUgNzoyNCBBTQ0KPiA+PiBUbzogTGVleW91bmc7ICdWYXJtYSwgRXZlIEwg KEV2ZSknOyBkYjM1NDZAYXR0LmNvbTsgJ0xhbSwgSGluZy1LYW0NCj4gPj4gKEthbSknOyBnZ3Jh bW1lbEBqdW5pcGVyLm5ldDsgZ2lvbWFydGlAY2lzY28uY29tDQo+ID4+IENjOiBwYXVsLmRvb2xh bkBjb3JpYW50LmNvbTsgY2NhbXBAaWV0Zi5vcmc7DQo+ID4+IGNjYW1wLWNoYWlyc0B0b29scy5p ZXRmLm9yZzsNCj4gPj4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xz LmlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIFZlbmRvci1TcGVjaWZpYyBBcHBs aWNhdGlvbiBDb2RlIGluDQo+ID4+IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlDQo+ ID4+DQo+ID4+IEhpIGFnYWluLA0KPiA+Pg0KPiA+Pj4gVGhlcmUgaXMgYWx3YXlzIGEgcHJpb3Jp IGtub3dsZWRnZSBpbiBvcHRpY2FsIG5ldHdvcmsgZG9tYWluIGFzIHRvDQo+ID4+PiB3aG8gYXJl IHlvdSBpbnRlcmZhY2luZyB3aXRoLiBTbyB5b3Uga25vdyB3aGljaCB2ZW5kb3IgeW91IGFyZQ0K PiBpbnRlcmZhY2luZy4NCj4gPj4+IElmIHlvdSBkbyBub3Qga25vdywgdGhlbiB5b3UgYXJlIGlu IHRyb3VibGUuDQo+ID4+DQo+ID4+IEhtbW0uIEl0IGlzIGV4YWN0bHkgdHlwZSBvZiB0cm91Ymxl IHdlIGFyZSB0cnlpbmcgdG8gZGV0ZWN0IGFuZCBwcm90ZWN0DQo+IGFnYWluc3QuDQo+ID4+DQo+ ID4+IEkgcmVmdXRlIHlvdXIgc3RhdGVtZW50IG9mIGEgcHJpb3JpIGtub3dsZWRnZS4gSSB0aGlu ayB0aGVyZSBpcyBhIHByaW9yaQ0KPiBpbnRlbnRpb24sIGJ1dCBub3Qga25vd2xlZGdlLiBVbmxl c3MgeW91IGhhdmUgdmVyeSBnb29kIGV5ZXNpZ2h0IG9yDQo+IHNvbWVvbmUgYXQgdGhlIG90aGVy IGVuZCBvZiB0aGUgZmliZXIgd2hlbiB5b3UgZ2l2ZSBpdCBhIHR1ZywgeW91IGRvbid0DQo+IGtu b3cuIEFuZCBldmVuIHRoZW4uIEZpYmVyaW5nIGVycm9ycyBoYXBwZW4gZnJvbSB0aW1lIHRvIHRp bWUuIENvbnNpZGVyLCBpbg0KPiBwYXJ0aWN1bGFyIGEgcGF0Y2ggcGFuZWwuDQo+ID4+DQo+ID4+ PiBOb3csIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3RhbmRhcmQgRkVDcyBhbmQgbW9kdWxhdGlv bnMgaW4gdGhlIEFJPw0KPiA+Pj4gR2l2ZW4gc2V2ZXJhbCBjaG9pY2VzIGVhY2ggdmVuZG9yIG1h eSBzdXBwb3J0IGluIGl0cyBkZXZpY2UsIHRoZQ0KPiA+Pj4gcGF0aCBjb21wdXRhdGlvbiB3b3Vs ZCBmaW5kIGEgbWF0Y2hlZCB0eXBlcyBmb3IgRkVDIGFuZCBtb2R1bGF0aW9uDQo+IGZvciBhIGdp dmVuIG9wdGljYWwgcGF0aC4NCj4gPj4+IFRoaXMgaXMgd2hhdCBpcyBpbnRlbmRlZCB3aGVuIG9w dGljYWwgc2lnbmFsIHByb2Nlc3NpbmcgY29uc3RyYWludHMNCj4gPj4+IHdlcmUgcHJvcG9zZWQg YXMgcGFydCBvZiBwYXRoIGNvbXB1dGF0aW9uIGNvbnN0cmFpbnRzIGluIG9wdGljYWwNCj4gbmV0 d29ya3MuDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBjYXNlIHlvdSBhcmUgbWFraW5nIGhlcmUgaXMg Zm9yIG5vIHN0YW5kYXJkIGNvbnRyb2wgcGxhbmUhDQo+ID4+IFdoYXQgaXMgdGhlIHBvaW50IG9m IHN0YW5kYXJkaXNpbmcgaWYgdGhlcmUgaXMgbmV2ZXIgYW55IGludGVyd29ya2luZz8NCj4gPj4g QnV0IGFjdHVhbGx5LCB3ZSBrbm93IGFib3V0IGludGVyd29ya2luZyBhdCB0aGUgcGh5c2ljYWwg bGF5ZXIsIGFuZCAobW9yZQ0KPiBpbXBvcnRhbnQpIHdlIGtub3cgYWJvdXQgYSBzaW5nbGUsIGVu ZC10by1lbmQgY29udHJvbCBwbGFuZSB0aGF0IHNwYW5zDQo+IG11bHRpcGxlIHZlbmRvciBkZXZp Y2VzLiBJdCBhbGwgZXhpc3RzLg0KPiA+Pg0KPiA+PiBPZiBjb3Vyc2UsIHdlIGNhbiBmYWxsIGJh Y2sgaW50byB0aGUgb2xkLXN0eWxlIHZlbmRvciBpc2xhbmRzLCBhbmQgbWFueQ0KPiBsaWtlIHRv IGRvIHNvLiBCdXQgaXQgaXMgbm90IGEgY29tcHVsc29yeSBkZXBsb3ltZW50IG1vZGVsLg0KPiA+ Pg0KPiA+Pj4gVGhlcmUgaXMgdmVyeSBsaXR0bGUgY2hhbmNlIGZvciB2ZW5kb3Igc3BlY2lmaWMg RkVDcyBhbmQgTW9kdWxhdGlvbnMNCj4gPj4+IHdpbGwgbWF0Y2ggZXZlbiBpZiB0aGV5IGFyZSBp ZGVudGlmaWVkIHdpdGggdGhlIE9VSSBjb2RlLg0KPiA+Pg0KPiA+PiBZb3UgaGF2ZSBpdCB0aGUg d3Jvbmcgd2F5IHJvdW5kIQ0KPiA+PiBUaGUgT1VJIGlzIGxhcmdlbHkgdG8gcHJvdGVjdCBhZ2Fp bnN0IGV4cGVjdGF0aW9ucyBvZiBpbnRlcndvcmtpbmcgd2hlbg0KPiBub25lIGNhbiBleGlzdC4N Cj4gPj4gSXQgbWlnaHQgKG11Y2ggbGVzcyBmcmVxdWVudGx5KSBiZSB1c2VkIHRvIGRlc2NyaWJl IHRoZSB3YXkgdGhhdCB2ZW5kb3JBDQo+IGFuZCB2ZW5kb3JCIHBpY2sgRkVDcyBhbmQgbW9kdWxh dGlvbnMgaW4gb3JkZXIgdG8gYWNoaWV2ZSBpbnRlcndvcmtpbmcuDQo+ID4+DQo+ID4+IEFkcmlh bg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gPj4gQ0NBTVBAaWV0Zi5vcmcNCj4gPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiA+Pg0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBD Q0FNUCBtYWlsaW5nIGxpc3QNCj4gPiBDQ0FNUEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gPg0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCg== From nobody Thu Jan 29 09:18: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 EF7181A8547 for ; Thu, 29 Jan 2015 09:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.45 X-Spam-Level: X-Spam-Status: No, score=-99.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, 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 yMEY5n69pnjD for ; Thu, 29 Jan 2015 09:17:54 -0800 (PST) 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 BF4EA1A701E for ; Thu, 29 Jan 2015 09:17:53 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0THHpxd012569; Thu, 29 Jan 2015 17:17:51 GMT Received: from 950129200 (194-166-224-30.adsl.highway.telekom.at [194.166.224.30]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0THHlfs012474 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2015 17:17:50 GMT From: "Adrian Farrel" To: References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm>, <54CA58EC.6050108@labn.net> <54CA5E28.10005@labn.net> <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se> Date: Thu, 29 Jan 2015 17:17:45 -0000 Message-ID: <006101d03be7$82516180$86f42480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJJUQOjjDfAQ8oFRmu1FlrhpmJTlQFT1EnjAetg4z8CJ7+qqAFLKtJcAlkhiAcCIomVewG+WEREAgF2pA4B3gw5sZteyIeg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21292.001 X-TM-AS-Result: No--35.230-10.0-31-10 X-imss-scan-details: No--35.230-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtG+9Go4BgFPZrE4IzBBqenJveCbyZ3xax7deAKnvBMxfDt5 srv8z/2aHJg6MNOhyoHsUUZmBtLXVS9FtW7XfHueA9lly13c/gFVftPGBTR0rr0rWM4nIpJrcIa DpdIRhp06XjWVhznG94R6ktsj4/uorm3mcraXo0ORfvUfL+585sLiFiL0BG1uYrcY3gxKTqxgbu 9weiOWK8Sn3Mnad3/3EgzaIwkuq2OdLySUmQFkkqtWSWds/km2IZm2INWXDp7+lfDssyh86Neul 29/x8OD4OW+eedJy6KMxND4t+zSAxoeu+OCiwrS8eSmTJSmEv1R3sGN+j7mNO8r+DLQt6+yaBux LsECVpZy5OhXKYJ/x/AhDxMQoG8AUKy/w6wtmG6aVoAi2I40/b1bhFvvQSAEayjbe4qUImPhLW+ nuKkjluAve2ZfFr+nDY48dK45B3w0CYUOpITAYmA/V00XWjDtTPt84VW1BkIQ8QCSP+YM02/91t cqPFxkFPTdWb0B54ve7SIvqh7NRrpoSDOXAaIh/vIcMN/z71uOVtPg9ibsGnt4BUfB+P48/tR55 4lM1S12gzvDp637cCLMRa7gqiBwIaVPgU+koVHThGbP9qB93IBmvqGKeYuqmnnIaNaZOLEVjAea OyL90h1QXE+gJlXHQo0mAKckAx7G2nY1KR7wCW0PWqD0pliRhEIiqNvBrmOdI/DikZ1UPBJo5yr ADTARKYTUsamWzgzvAIaR9qqmkmTaT5Js0UdSJXKk/roE/RCPmFSaq6xM+GXczQlokCRZq+1liY blo0L9VVCUNaKG6nN8NpnKQPh3sk3Xm9yiC76eAiCmPx4NwLij7XOMI0NNooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: Cc: draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 17:17:58 -0000 Hi, It is worth looking at how you would do the bis. Option 1 says that an implementation can put absolutely anything in the = field under a single code point. If you want to bis that, you automatically make all implementations = broken unless you define a new OI so you would have ... 0 reserved 1 vendor-specific unknown format 2 (in the bis) vendor-specific with OUI Option 3 says that *today* there is no such thing as vendor-specific AI. = In that case the code point is not even seen and implementations today cannot do = vendor specific stuff. So you would have S=3D0 reserved And you would bis by S=3D1 means vendor-specific. Either approach works. Now, let's discuss existing implementations. AFAICS no-one is close to shipping product (please tell me if I am = wrong). So there is no rush. Now let's discuss timing. Option 1 and option 3 allow publication soon, with a bis later. The bis = would not happen until the ITU-T has finalised the format for vendor-specific = AIs Option 2 can be approached two ways a. *Guess* which way the ITU-T will define the vendor-specific AI b. Wait until the ITU-T has finalised the format for vendor-specific = AIs. I would like the chairs to help me and the shepherd understand the = preferred approach so that we can determine what to do with the document. Thanks, Adrian > -----Original Message----- > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele = Ceccarelli > Sent: 29 January 2015 16:34 > To: Lou Berger; Zhangxian (Xian) > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa-wson- > encode.all@tools.ietf.org > Subject: Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp-rwa- > wson-encode >=20 > I think Xian's proposal makes sense. >=20 > I would like not to hold the draft for 6 more months. > As chair I would suggest to go for option 1 or 3 and then go for a bis = when G. 874.1 > will be consented. > As contributor, among 1 and 3 I would prefer 1 but I think 3 leaves = more room for > a simple and straightforward bis. >=20 > Opinions on this last statement? >=20 > BR > Daniele >=20 > > -----Original Message----- > > From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > > Sent: gioved=A8=AC 29 gennaio 2015 17:22 > > To: Zhangxian (Xian) > > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; = draft-ietf-ccamp-rwa- > > wson-encode.all@tools.ietf.org > > Subject: Re: [CCAMP] Vendor-Specific Application Code in = draft-ietf-ccamp- > > rwa-wson-encode > > > > On 01/29/2015 11:17 AM, Zhangxian (Xian) wrote: > > > Hi, Lou, > > > > > > I support your proposal. > > > > > > Just a thought: given the massive support of Option 2 from WG, = maybe > > > we can reconcile by moving the WG draft forward using either = Option > > > 1/3, while writing a short draft to document the update needed to > > > match the to-be-updated G.874.1? So that once it is updated, we = can > > > move the draft quickly. > > > > > > > Seems right to me (as contributor) > > > > Lou > > > > > Regards, > > > Xian > > > > > > ________________________________________ > > > =B7=A2=BC=FE=C8=CB: CCAMP [ccamp-bounces@ietf.org] =B4=FA=B1=ED = Lou Berger > > [lberger@labn.net] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA1=D4=C229=C8=D5 23:59 > > > =CA=D5=BC=FE=C8=CB: Leeyoung; adrian@olddog.co.uk; 'Varma, Eve L = (Eve)'; > > > db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net; > > > giomarti@cisco.com > > > =B3=AD=CB=CD: paul.doolan@coriant.com; ccamp@ietf.org; > > > ccamp-chairs@tools.ietf.org; > > > draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > > > =D6=F7=CC=E2: Re: [CCAMP] Vendor-Specific Application Code in > > > draft-ietf-ccamp-rwa-wson-encode > > > > > > I thought it would be good to let things settle a bit before > > > responding as Shepherd. > > > > > > So option 1 (No definition of proprietary semantics and conflicts = are > > > handled outside of the control plane, i.e., belong to operator) = was > > > the intent of the WG at the time of publication request. This > > > approach was also aligned with the then, and actually current, = state > > > of the ITU-T data plane (and management info) as discussed in our > > > joint meeting. I believe option 3 (dropping the vendor specific > > > option) isn't in conflict with this. > > > > > > There now seems to be support for changing the document to align = it > > > with, what I understand is, a planned update to G.874.1. This of > > > course implies that such a change would result in this document = being > > > blocked until that update is published in 6 months or so, and = assumes > > > no substantive change its contents. > > > > > > Again with Shepherd hat on, I recommend avoiding the additional = delay > > > and not tie this document to the planned G.874.1 update at this = time, > > > i.e., by following option 1 (or even 3). This allows for a future > > > bis/update that is align with the expected update to G.874.1 once = it > > > is published. > > > > > > Comments, objections, support? (AD, authors, chairs, wg, ...) > > > > > > Lou > > > > > > On 01/29/2015 09:51 AM, Leeyoung wrote: > > >> Hi, > > >> > > >> It seems like the world is against Option 1. No big deal, please = provide > > relevant text to support Option 2. > > >> > > >> Young > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> Sent: Thursday, January 29, 2015 7:24 AM > > >> To: Leeyoung; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, = Hing-Kam > > >> (Kam)'; ggrammel@juniper.net; giomarti@cisco.com > > >> Cc: paul.doolan@coriant.com; ccamp@ietf.org; > > >> ccamp-chairs@tools.ietf.org; > > >> draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > > >> Subject: RE: [CCAMP] Vendor-Specific Application Code in > > >> draft-ietf-ccamp-rwa-wson-encode > > >> > > >> Hi again, > > >> > > >>> There is always a priori knowledge in optical network domain as = to > > >>> who are you interfacing with. So you know which vendor you are > > interfacing. > > >>> If you do not know, then you are in trouble. > > >> > > >> Hmmm. It is exactly type of trouble we are trying to detect and = protect > > against. > > >> > > >> I refute your statement of a priori knowledge. I think there is a = priori > > intention, but not knowledge. Unless you have very good eyesight or > > someone at the other end of the fiber when you give it a tug, you = don't > > know. And even then. Fibering errors happen from time to time. = Consider, in > > particular a patch panel. > > >> > > >>> Now, what is the purpose of standard FECs and modulations in the = AI? > > >>> Given several choices each vendor may support in its device, the > > >>> path computation would find a matched types for FEC and = modulation > > for a given optical path. > > >>> This is what is intended when optical signal processing = constraints > > >>> were proposed as part of path computation constraints in optical > > networks. > > >> > > >> > > >> The case you are making here is for no standard control plane! > > >> What is the point of standardising if there is never any = interworking? > > >> But actually, we know about interworking at the physical layer, = and (more > > important) we know about a single, end-to-end control plane that = spans > > multiple vendor devices. It all exists. > > >> > > >> Of course, we can fall back into the old-style vendor islands, = and many > > like to do so. But it is not a compulsory deployment model. > > >> > > >>> There is very little chance for vendor specific FECs and = Modulations > > >>> will match even if they are identified with the OUI code. > > >> > > >> You have it the wrong way round! > > >> The OUI is largely to protect against expectations of = interworking when > > none can exist. > > >> It might (much less frequently) be used to describe the way that = vendorA > > and vendorB pick FECs and modulations in order to achieve = interworking. > > >> > > >> Adrian > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > _______________________________________________ > > 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 Jan 29 09:33:39 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 9B3D61A8732 for ; Thu, 29 Jan 2015 09:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.172 X-Spam-Level: * X-Spam-Status: No, score=1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45] 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 EHRgP-Laz0WD for ; Thu, 29 Jan 2015 09:33:28 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75B91A873A for ; Thu, 29 Jan 2015 09:32:57 -0800 (PST) Received: from localhost ([::1]:58806 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YGsxc-00009q-Dr; Thu, 29 Jan 2015 20:32:56 +0300 Message-ID: <54CA6EC6.702@labn.net> Date: Thu, 29 Jan 2015 12:32:54 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, ccamp@ietf.org References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F37D@dfweml706-chm>, <54CA58EC.6050108@labn.net> <54CA5E28.10005@labn.net> <4A1562797D64E44993C5CBF38CF1BE481284DB62@ESESSMB301.ericsson.se> <006101d03be7$82516180$86f42480$@olddog.co.uk> In-Reply-To: <006101d03be7$82516180$86f42480$@olddog.co.uk> Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: lberger@labn.net List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 17:33:30 -0000 Adrian, > I would like the chairs to help me and the shepherd understand the preferred > approach so that we can determine what to do with the document. > I read your message as saying you think option 3 is the better way to go wrt a future bis. I see traffic on the list supporting this. As Shepherd I think this would be fine. Unless I'm misreading you, let's move forward with making the changes to the document to drop support for "vendor-specific unknown format". It will take a day or two for the authors to get the revision out, and this will give others a chance to chime in (i.e, oppose) this if they disagree. Thanks, Lou On 01/29/2015 12:17 PM, Adrian Farrel wrote: > Hi, > > It is worth looking at how you would do the bis. > > Option 1 says that an implementation can put absolutely anything in the field > under a single code point. > If you want to bis that, you automatically make all implementations broken > unless you define a new OI so you would have ... > 0 reserved > 1 vendor-specific unknown format > 2 (in the bis) vendor-specific with OUI > > Option 3 says that *today* there is no such thing as vendor-specific AI. In that > case the code point is not even seen and implementations today cannot do vendor > specific stuff. > So you would have S=0 reserved > And you would bis by S=1 means vendor-specific. > > Either approach works. > > > Now, let's discuss existing implementations. > AFAICS no-one is close to shipping product (please tell me if I am wrong). > So there is no rush. > > Now let's discuss timing. > Option 1 and option 3 allow publication soon, with a bis later. The bis would > not happen until the ITU-T has finalised the format for vendor-specific AIs > Option 2 can be approached two ways > a. *Guess* which way the ITU-T will define the vendor-specific AI > b. Wait until the ITU-T has finalised the format for vendor-specific AIs. > > I would like the chairs to help me and the shepherd understand the preferred > approach so that we can determine what to do with the document. > > Thanks, > Adrian > > > > > > > >> -----Original Message----- >> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli >> Sent: 29 January 2015 16:34 >> To: Lou Berger; Zhangxian (Xian) >> Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa-wson- >> encode.all@tools.ietf.org >> Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa- >> wson-encode >> >> I think Xian's proposal makes sense. >> >> I would like not to hold the draft for 6 more months. >> As chair I would suggest to go for option 1 or 3 and then go for a bis when G. > 874.1 >> will be consented. >> As contributor, among 1 and 3 I would prefer 1 but I think 3 leaves more room > for >> a simple and straightforward bis. >> >> Opinions on this last statement? >> >> BR >> Daniele >> >>> -----Original Message----- >>> From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger >>> Sent: giovedì 29 gennaio 2015 17:22 >>> To: Zhangxian (Xian) >>> Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org; draft-ietf-ccamp-rwa- >>> wson-encode.all@tools.ietf.org >>> Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp- >>> rwa-wson-encode >>> >>> On 01/29/2015 11:17 AM, Zhangxian (Xian) wrote: >>>> Hi, Lou, >>>> >>>> I support your proposal. >>>> >>>> Just a thought: given the massive support of Option 2 from WG, maybe >>>> we can reconcile by moving the WG draft forward using either Option >>>> 1/3, while writing a short draft to document the update needed to >>>> match the to-be-updated G.874.1? So that once it is updated, we can >>>> move the draft quickly. >>>> >>> >>> Seems right to me (as contributor) >>> >>> Lou >>> >>>> Regards, >>>> Xian >>>> >>>> ________________________________________ >>>> 发件人: CCAMP [ccamp-bounces@ietf.org] 代表 Lou Berger >>> [lberger@labn.net] >>>> 发送时间: 2015年1月29日 23:59 >>>> 收件人: Leeyoung; adrian@olddog.co.uk; 'Varma, Eve L (Eve)'; >>>> db3546@att.com; 'Lam, Hing-Kam (Kam)'; ggrammel@juniper.net; >>>> giomarti@cisco.com >>>> 抄送: paul.doolan@coriant.com; ccamp@ietf.org; >>>> ccamp-chairs@tools.ietf.org; >>>> draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org >>>> 主题: Re: [CCAMP] Vendor-Specific Application Code in >>>> draft-ietf-ccamp-rwa-wson-encode >>>> >>>> I thought it would be good to let things settle a bit before >>>> responding as Shepherd. >>>> >>>> So option 1 (No definition of proprietary semantics and conflicts are >>>> handled outside of the control plane, i.e., belong to operator) was >>>> the intent of the WG at the time of publication request. This >>>> approach was also aligned with the then, and actually current, state >>>> of the ITU-T data plane (and management info) as discussed in our >>>> joint meeting. I believe option 3 (dropping the vendor specific >>>> option) isn't in conflict with this. >>>> >>>> There now seems to be support for changing the document to align it >>>> with, what I understand is, a planned update to G.874.1. This of >>>> course implies that such a change would result in this document being >>>> blocked until that update is published in 6 months or so, and assumes >>>> no substantive change its contents. >>>> >>>> Again with Shepherd hat on, I recommend avoiding the additional delay >>>> and not tie this document to the planned G.874.1 update at this time, >>>> i.e., by following option 1 (or even 3). This allows for a future >>>> bis/update that is align with the expected update to G.874.1 once it >>>> is published. >>>> >>>> Comments, objections, support? (AD, authors, chairs, wg, ...) >>>> >>>> Lou >>>> >>>> On 01/29/2015 09:51 AM, Leeyoung wrote: >>>>> Hi, >>>>> >>>>> It seems like the world is against Option 1. No big deal, please provide >>> relevant text to support Option 2. >>>>> >>>>> Young >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>> Sent: Thursday, January 29, 2015 7:24 AM >>>>> To: Leeyoung; 'Varma, Eve L (Eve)'; db3546@att.com; 'Lam, Hing-Kam >>>>> (Kam)'; ggrammel@juniper.net; giomarti@cisco.com >>>>> Cc: paul.doolan@coriant.com; ccamp@ietf.org; >>>>> ccamp-chairs@tools.ietf.org; >>>>> draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org >>>>> Subject: RE: [CCAMP] Vendor-Specific Application Code in >>>>> draft-ietf-ccamp-rwa-wson-encode >>>>> >>>>> Hi again, >>>>> >>>>>> There is always a priori knowledge in optical network domain as to >>>>>> who are you interfacing with. So you know which vendor you are >>> interfacing. >>>>>> If you do not know, then you are in trouble. >>>>> >>>>> Hmmm. It is exactly type of trouble we are trying to detect and protect >>> against. >>>>> >>>>> I refute your statement of a priori knowledge. I think there is a priori >>> intention, but not knowledge. Unless you have very good eyesight or >>> someone at the other end of the fiber when you give it a tug, you don't >>> know. And even then. Fibering errors happen from time to time. Consider, in >>> particular a patch panel. >>>>> >>>>>> Now, what is the purpose of standard FECs and modulations in the AI? >>>>>> Given several choices each vendor may support in its device, the >>>>>> path computation would find a matched types for FEC and modulation >>> for a given optical path. >>>>>> This is what is intended when optical signal processing constraints >>>>>> were proposed as part of path computation constraints in optical >>> networks. >>>>> >>>>> >>>>> The case you are making here is for no standard control plane! >>>>> What is the point of standardising if there is never any interworking? >>>>> But actually, we know about interworking at the physical layer, and (more >>> important) we know about a single, end-to-end control plane that spans >>> multiple vendor devices. It all exists. >>>>> >>>>> Of course, we can fall back into the old-style vendor islands, and many >>> like to do so. But it is not a compulsory deployment model. >>>>> >>>>>> There is very little chance for vendor specific FECs and Modulations >>>>>> will match even if they are identified with the OUI code. >>>>> >>>>> You have it the wrong way round! >>>>> The OUI is largely to protect against expectations of interworking when >>> none can exist. >>>>> It might (much less frequently) be used to describe the way that vendorA >>> and vendorB pick FECs and modulations in order to achieve interworking. >>>>> >>>>> Adrian >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From nobody Thu Jan 29 10:57:32 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 15C481A1BED for ; Thu, 29 Jan 2015 10:57:31 -0800 (PST) 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 mzL3j_Rw74m1 for ; Thu, 29 Jan 2015 10:57:24 -0800 (PST) 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 5B0D71A1BDD for ; Thu, 29 Jan 2015 10:57:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOO46607; Thu, 29 Jan 2015 18:57:22 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 18:57:21 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 10:57:09 -0800 From: Leeyoung To: Gert Grammel , "adrian@olddog.co.uk" , "'Varma, Eve L (Eve)'" , "db3546@att.com" , "'Lam, Hing-Kam (Kam)'" , "giomarti@cisco.com" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyKmWicGibpQEGWYW2s/gCycJzOdnmAgAAengCAA5dgAIAEL7YA//+TloCAAJDSAP//e+qggACJ8QCAAAbcgP//fJJwADNyZIAABXMyAAAKs4pg Date: Thu, 29 Jan 2015 18:57:08 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7F574@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "paul.doolan@coriant.com" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 18:57:31 -0000 SGkgR2VydCwNCg0KWWVzLCB5b3UgaGl0IHRoZSBuYWlsIG9uIHRoZSBoZWFkLiBUaGFua3MuDQoN Ckl0IGxvb2tzIGxpa2Ugd2UgY2FuIG1vdmUgb24gdGhpcyBpc3N1ZSB3aXRoIHRoZSBsYXRlc3Qg ZGV2ZWxvcG1lbnQgaW4gdGhpcyB0aHJlYWQuDQoNCkJlc3QgcmVnYXJkcywNCllvdW5nDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHZXJ0IEdyYW1tZWwgW21haWx0bzpnZ3Jh bW1lbEBqdW5pcGVyLm5ldF0gDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyOSwgMjAxNSAxMDow MCBBTQ0KVG86IGFkcmlhbkBvbGRkb2cuY28udWs7IExlZXlvdW5nOyAnVmFybWEsIEV2ZSBMIChF dmUpJzsgZGIzNTQ2QGF0dC5jb207ICdMYW0sIEhpbmctS2FtIChLYW0pJzsgZ2lvbWFydGlAY2lz Y28uY29tDQpDYzogcGF1bC5kb29sYW5AY29yaWFudC5jb207IGNjYW1wQGlldGYub3JnOyBjY2Ft cC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2Rl LmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmlj IEFwcGxpY2F0aW9uIENvZGUgaW4gZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUNCg0K DQpIaSBMZWV5b3VuZywgDQoNCktlZXAgaW4gbWluZCB0aGF0IEcuNjk4LjIgYWxsb3dzIHRvIHVz ZSB0cmFuc2NlaXZlcnMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycywgYmFzZWQgb24gc3RhbmRhcmQg QUlzICg9QXBwbGljYXRpb24gQ29kZXMpLiBOb3cgaW4gY2FzZSBvZiBhIG11bHRpLXZlbmRvciBu ZXR3b3JrLCAqYWRkaXRpb25hbCogcHJvcHJpZXRhcnkgYXBwbGljYXRpb24gY29kZXMgY2FuIGJl IHVzZWQgaWYgdGhlcmUgaXMgYSBwcmUta25vd2xlZGdlIHRoYXQgdGhlIHByb3ByaWV0YXJ5IEFJ cyBtYXRjaC4gSSBiZWxpZXZlIHRoaXMgd2FzIG9uZSBjYXNlIHlvdSB3ZXJlIHJlZmVycmluZyB0 by4NClNvIGEgc2luZ2xlIHRyYW5zY2VpdmVyIEhXIGltcGxlbWVudGF0aW9uIHN1cHBvcnRpbmcg dGhlIHN0YW5kYXJkLUFJIHdpbGwgYWxtb3N0IGNlcnRhaW5seSBzdXBwb3J0IGFsc28gYSB2ZW5k b3ItQUkgZS5nLiwgIGlmIGEgaGlnaGVyIGxldmVsIG9mIE9TTlIgY2FuIGJlIHRvbGVyYXRlZCB0 aGFuIHRoZSBzdGFuZGFyZC1BSSBoYXMgZW5jb2RlZC4gSGVuY2Ugd2UgY2FuIGNvbmNsdWRlIHRo YXQgYSBzaW5nbGUgKHZlbmRvcikgdHJhbnNjZWl2ZXIgcG90ZW50aWFsbHkgc3VwcG9ydHMgYSBs aXN0IG9mIEFJcy4gU28gZXZlbiBieSBwaWNraW5nIE9wdGlvbiAyIHlvdXIgY2FzZSBjYW4gYmUg YWRkcmVzc2VkLg0KDQpIb3cgdG8gZW5jb2RlIHRob3NlIEFJcyBpcyBhbm90aGVyIG1hdHRlciBh cyBwcmludGFibGUgc3RyaW5ncyBhcmUgbm90IGFsd2F5cyB0aGUgYmVzdCBjaG9pY2UgdG8gdXNl LiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluZWxsaS13c29uLWludGVy ZmFjZS1jbGFzcy0wMyBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRoYXJp bmktbmV0bW9kLWctNjk4LTIteWFuZy0wMiBhbHJlYWR5IHByb3ZpZGUgc29tZSBlbmNvZGluZywg d2hlcmVieSBPVUkgd291bGQgbmVlZCB0byBiZSB3b3JrZWQgaW4uDQoNCkdlcnQNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRyaWFuIEZhcnJlbCBbbWFpbHRvOmFkcmlh bkBvbGRkb2cuY28udWtdIA0KU2VudDogMjkgSmFudWFyeSAyMDE1IDE0OjI0DQpUbzogJ0xlZXlv dW5nJzsgJ1Zhcm1hLCBFdmUgTCAoRXZlKSc7IGRiMzU0NkBhdHQuY29tOyAnTGFtLCBIaW5nLUth bSAoS2FtKSc7IEdlcnQgR3JhbW1lbDsgZ2lvbWFydGlAY2lzY28uY29tDQpDYzogcGF1bC5kb29s YW5AY29yaWFudC5jb207IGNjYW1wQGlldGYub3JnOyBjY2FtcC1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc7IGRyYWZ0LWlldGYtY2NhbXAtcndhLXdzb24tZW5jb2RlLmFsbEB0b29scy5pZXRmLm9yZw0K U3ViamVjdDogUkU6IFtDQ0FNUF0gVmVuZG9yLVNwZWNpZmljIEFwcGxpY2F0aW9uIENvZGUgaW4g ZHJhZnQtaWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUNCg0KSGkgYWdhaW4sDQoNCj4gVGhlcmUg aXMgYWx3YXlzIGEgcHJpb3JpIGtub3dsZWRnZSBpbiBvcHRpY2FsIG5ldHdvcmsgZG9tYWluIGFz IHRvIHdobyANCj4gYXJlIHlvdSBpbnRlcmZhY2luZyB3aXRoLiBTbyB5b3Uga25vdyB3aGljaCB2 ZW5kb3IgeW91IGFyZSBpbnRlcmZhY2luZy4NCj4gSWYgeW91IGRvIG5vdCBrbm93LCB0aGVuIHlv dSBhcmUgaW4gdHJvdWJsZS4NCg0KSG1tbS4gSXQgaXMgZXhhY3RseSB0eXBlIG9mIHRyb3VibGUg d2UgYXJlIHRyeWluZyB0byBkZXRlY3QgYW5kIHByb3RlY3QgYWdhaW5zdC4NCg0KSSByZWZ1dGUg eW91ciBzdGF0ZW1lbnQgb2YgYSBwcmlvcmkga25vd2xlZGdlLiBJIHRoaW5rIHRoZXJlIGlzIGEg cHJpb3JpIGludGVudGlvbiwgYnV0IG5vdCBrbm93bGVkZ2UuIFVubGVzcyB5b3UgaGF2ZSB2ZXJ5 IGdvb2QgZXllc2lnaHQgb3Igc29tZW9uZSBhdCB0aGUgb3RoZXIgZW5kIG9mIHRoZSBmaWJlciB3 aGVuIHlvdSBnaXZlIGl0IGEgdHVnLCB5b3UgZG9uJ3Qga25vdy4gQW5kIGV2ZW4gdGhlbi4gRmli ZXJpbmcgZXJyb3JzIGhhcHBlbiBmcm9tIHRpbWUgdG8gdGltZS4gQ29uc2lkZXIsIGluIHBhcnRp Y3VsYXIgYSBwYXRjaCBwYW5lbC4NCg0KPiBOb3csIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3Rh bmRhcmQgRkVDcyBhbmQgbW9kdWxhdGlvbnMgaW4gdGhlIEFJPyANCj4gR2l2ZW4gc2V2ZXJhbCBj aG9pY2VzIGVhY2ggdmVuZG9yIG1heSBzdXBwb3J0IGluIGl0cyBkZXZpY2UsIHRoZSBwYXRoIA0K PiBjb21wdXRhdGlvbiB3b3VsZCBmaW5kIGEgbWF0Y2hlZCB0eXBlcyBmb3IgRkVDIGFuZCBtb2R1 bGF0aW9uIGZvciBhIGdpdmVuIG9wdGljYWwgcGF0aC4NCj4gVGhpcyBpcyB3aGF0IGlzIGludGVu ZGVkIHdoZW4gb3B0aWNhbCBzaWduYWwgcHJvY2Vzc2luZyBjb25zdHJhaW50cyANCj4gd2VyZSBw cm9wb3NlZCBhcyBwYXJ0IG9mIHBhdGggY29tcHV0YXRpb24gY29uc3RyYWludHMgaW4gb3B0aWNh bCBuZXR3b3Jrcy4NCg0KDQpUaGUgY2FzZSB5b3UgYXJlIG1ha2luZyBoZXJlIGlzIGZvciBubyBz dGFuZGFyZCBjb250cm9sIHBsYW5lIQ0KV2hhdCBpcyB0aGUgcG9pbnQgb2Ygc3RhbmRhcmRpc2lu ZyBpZiB0aGVyZSBpcyBuZXZlciBhbnkgaW50ZXJ3b3JraW5nPw0KQnV0IGFjdHVhbGx5LCB3ZSBr bm93IGFib3V0IGludGVyd29ya2luZyBhdCB0aGUgcGh5c2ljYWwgbGF5ZXIsIGFuZCAobW9yZSBp bXBvcnRhbnQpIHdlIGtub3cgYWJvdXQgYSBzaW5nbGUsIGVuZC10by1lbmQgY29udHJvbCBwbGFu ZSB0aGF0IHNwYW5zIG11bHRpcGxlIHZlbmRvciBkZXZpY2VzLiBJdCBhbGwgZXhpc3RzLg0KDQpP ZiBjb3Vyc2UsIHdlIGNhbiBmYWxsIGJhY2sgaW50byB0aGUgb2xkLXN0eWxlIHZlbmRvciBpc2xh bmRzLCBhbmQgbWFueSBsaWtlIHRvIGRvIHNvLiBCdXQgaXQgaXMgbm90IGEgY29tcHVsc29yeSBk ZXBsb3ltZW50IG1vZGVsLg0KDQo+IFRoZXJlIGlzIHZlcnkgbGl0dGxlIGNoYW5jZSBmb3IgdmVu ZG9yIHNwZWNpZmljIEZFQ3MgYW5kIE1vZHVsYXRpb25zIA0KPiB3aWxsIG1hdGNoIGV2ZW4gaWYg dGhleSBhcmUgaWRlbnRpZmllZCB3aXRoIHRoZSBPVUkgY29kZS4NCg0KWW91IGhhdmUgaXQgdGhl IHdyb25nIHdheSByb3VuZCENClRoZSBPVUkgaXMgbGFyZ2VseSB0byBwcm90ZWN0IGFnYWluc3Qg ZXhwZWN0YXRpb25zIG9mIGludGVyd29ya2luZyB3aGVuIG5vbmUgY2FuIGV4aXN0Lg0KSXQgbWln aHQgKG11Y2ggbGVzcyBmcmVxdWVudGx5KSBiZSB1c2VkIHRvIGRlc2NyaWJlIHRoZSB3YXkgdGhh dCB2ZW5kb3JBIGFuZCB2ZW5kb3JCIHBpY2sgRkVDcyBhbmQgbW9kdWxhdGlvbnMgaW4gb3JkZXIg dG8gYWNoaWV2ZSBpbnRlcndvcmtpbmcuDQoNCkFkcmlhbg0KDQo= From nobody Thu Jan 29 11:11: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 606671A1BF8 for ; Thu, 29 Jan 2015 11:11:02 -0800 (PST) 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 8XMb5LlIOjNs for ; Thu, 29 Jan 2015 11:11:00 -0800 (PST) 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 B02DB1A1A66 for ; Thu, 29 Jan 2015 11:10:58 -0800 (PST) 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 BRW71520; Thu, 29 Jan 2015 19:10:57 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 19:10:56 +0000 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; Thu, 29 Jan 2015 11:10:51 -0800 From: Leeyoung To: "adrian@olddog.co.uk" , "'Varma, Eve L (Eve)'" , "db3546@att.com" , "'Lam, Hing-Kam (Kam)'" , "ggrammel@juniper.net" , "giomarti@cisco.com" Thread-Topic: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHQNyyKmWicGibpQEGWYW2s/gCycJzOdnmAgAAengCAA5dgAIAEL7YA//+TloCAAJDSAP//e+qggACJ8QCAAAbcgP//fJJwADNyZIAABPD9MA== Date: Thu, 29 Jan 2015 19:10:50 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7F587@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729C7F0A9@dfweml706-chm> <6D32668528F93D449A073F45707153D82C533567@US70UWXCHMBA03.zam.alcatel-lucent.com> <086901d03b3a$c7386c10$55a94430$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7F161@dfweml706-chm> <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> In-Reply-To: <00ff01d03bc6$d84bbcf0$88e336d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Do+p D2nk GH8r MMYw gLJU ni7u qP6a vst7 ABSiVQ== ABaTXA== AFdrNg== AFkPeA== AFtiyQ== AF+bEA== AGCDCw== AG4dXg==; 10; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGMAYwBhAG0AcAAtAGMAaABhAGkAcgBzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAYwBjAGEAbQBwAEAAaQBlAHQAZgAuAG8AcgBnADsAZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHIAdwBhAC0AdwBzAG8AbgAtAGUAbgBjAG8AZABlAC4AYQBsAGwAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBlAHYAZQAuAHYAYQByAG0AYQBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtADsAZwBnAHIAYQBtAG0AZQBsAEAAagB1AG4AaQBwAGUAcgAuAG4AZQB0ADsAZwBpAG8AbQBhAHIAdABpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBrAGEAbQAuAGwAYQBtAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0AOwBwAGEAdQBsAC4AZABvAG8AbABhAG4AQABjAG8AcgBpAGEAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {7475A0C5-66B1-4C6E-866C-A7C6FB8155FA}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 29 Jan 2015 19:10:35 GMT; UgBFADoAIABbAEMAQwBBAE0AUABdACAAVgBlAG4AZABvAHIALQBTAHAAZQBjAGkAZgBpAGMAIABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABDAG8AZABlACAAaQBuACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHIAdwBhAC0AdwBzAG8AbgAtAGUAbgBjAG8AZABlAA== x-cr-puzzleid: {7475A0C5-66B1-4C6E-866C-A7C6FB8155FA} x-originating-ip: [10.192.11.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "paul.doolan@coriant.com" , "ccamp@ietf.org" , "ccamp-chairs@tools.ietf.org" , "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" Subject: Re: [CCAMP] Vendor-Specific Application Code in draft-ietf-ccamp-rwa-wson-encode 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, 29 Jan 2015 19:11:02 -0000 SGkgQWRyaWFuLA0KDQpJIHRoaW5rIHlvdSBtaXNpbnRlcnByZXRlZCB3aGF0IHdhcyBzYWlkLiAN Cg0KPj4gTm93LCB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHN0YW5kYXJkIEZFQ3MgYW5kIG1vZHVs YXRpb25zIGluIHRoZSBBST8gR2l2ZW4NCj4+IHNldmVyYWwgY2hvaWNlcyBlYWNoIHZlbmRvciBt YXkgc3VwcG9ydCBpbiBpdHMgZGV2aWNlLCB0aGUgcGF0aCBjb21wdXRhdGlvbg0KPj4gd291bGQg ZmluZCBhIG1hdGNoZWQgdHlwZXMgZm9yIEZFQyBhbmQgbW9kdWxhdGlvbiBmb3IgYSBnaXZlbiBv cHRpY2FsIHBhdGguIA0KPj4gVGhpcyBpcyB3aGF0IGlzIGludGVuZGVkIHdoZW4gb3B0aWNhbCBz aWduYWwgcHJvY2Vzc2luZyBjb25zdHJhaW50cyB3ZXJlIA0KPj4gcHJvcG9zZWQgYXMgcGFydCBv ZiBwYXRoIGNvbXB1dGF0aW9uIGNvbnN0cmFpbnRzIGluIG9wdGljYWwgbmV0d29ya3MuIA0KDQo+ IFRoZSBjYXNlIHlvdSBhcmUgbWFraW5nIGhlcmUgaXMgZm9yIG5vIHN0YW5kYXJkIGNvbnRyb2wg cGxhbmUhDQo+IFdoYXQgaXMgdGhlIHBvaW50IG9mIHN0YW5kYXJkaXNpbmcgaWYgdGhlcmUgaXMg bmV2ZXIgYW55IGludGVyd29ya2luZz8NCj4gQnV0IGFjdHVhbGx5LCB3ZSBrbm93IGFib3V0IGlu dGVyd29ya2luZyBhdCB0aGUgcGh5c2ljYWwgbGF5ZXIsIGFuZCAobW9yZSBpbXBvcnRhbnQpIHdl IGtub3cgYWJvdXQgYSBzaW5nbGUsID4gZW5kLXRvLWVuZCBjb250cm9sIHBsYW5lIHRoYXQgc3Bh bnMgbXVsdGlwbGUgdmVuZG9yIGRldmljZXMuIEl0IGFsbCBleGlzdHMuDQoNClRoZSBzdGFuZGFy ZCBBSSBhbGxvd3MgdG8gbWF0Y2ggb3B0aWNhbCBwcm9jZXNzaW5nIGNvbnN0cmFpbnRzIChpbmNs dWRpbmcgRkVDcyBhbmQgTW9kdWxhdGlvbnMgaW1wbGllZCBpbiBhbiBBSSkuIFRoaXMgaW5mb3Jt YXRpb24gaXMgYWR2ZXJ0aXNlZCB0aGF0IGEgUENFIHdvdWxkIGJlIGFibGUgdG8gY29tcHV0ZSBh biBvcHRpY2FsIHBhdGggbWF0Y2hpbmcgQUlzIGZvciBhbGwgdGhlIGRldmljZXMgdG8gZGVydGVy bWluZSBhIGZlYXNpYmxlIHBhdGguIEkgYW0gdGFsa2luZyBhYm91dCB0aGlzIHN0YW5kYXJkIGNv bnRyb2wgcGxhbmUgd29yay4gVGhpcyBpcyB3aGF0IHdhcyBpbnRlbmRlZCBpbiB0aGUgZHJhZnQu IA0KDQpSZWdhcmRzLA0KWW91bmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEFkcmlhbiBGYXJyZWwgW21haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrXSANClNlbnQ6IFRodXJz ZGF5LCBKYW51YXJ5IDI5LCAyMDE1IDc6MjQgQU0NClRvOiBMZWV5b3VuZzsgJ1Zhcm1hLCBFdmUg TCAoRXZlKSc7IGRiMzU0NkBhdHQuY29tOyAnTGFtLCBIaW5nLUthbSAoS2FtKSc7IGdncmFtbWVs QGp1bmlwZXIubmV0OyBnaW9tYXJ0aUBjaXNjby5jb20NCkNjOiBwYXVsLmRvb2xhbkBjb3JpYW50 LmNvbTsgY2NhbXBAaWV0Zi5vcmc7IGNjYW1wLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQt aWV0Zi1jY2FtcC1yd2Etd3Nvbi1lbmNvZGUuYWxsQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBS RTogW0NDQU1QXSBWZW5kb3ItU3BlY2lmaWMgQXBwbGljYXRpb24gQ29kZSBpbiBkcmFmdC1pZXRm LWNjYW1wLXJ3YS13c29uLWVuY29kZQ0KDQpIaSBhZ2FpbiwNCg0KPiBUaGVyZSBpcyBhbHdheXMg YSBwcmlvcmkga25vd2xlZGdlIGluIG9wdGljYWwgbmV0d29yayBkb21haW4gYXMgdG8gd2hvIA0K PiBhcmUgeW91IGludGVyZmFjaW5nIHdpdGguIFNvIHlvdSBrbm93IHdoaWNoIHZlbmRvciB5b3Ug YXJlIGludGVyZmFjaW5nLiANCj4gSWYgeW91IGRvIG5vdCBrbm93LCB0aGVuIHlvdSBhcmUgaW4g dHJvdWJsZS4NCg0KSG1tbS4gSXQgaXMgZXhhY3RseSB0eXBlIG9mIHRyb3VibGUgd2UgYXJlIHRy eWluZyB0byBkZXRlY3QgYW5kIHByb3RlY3QgYWdhaW5zdC4NCg0KSSByZWZ1dGUgeW91ciBzdGF0 ZW1lbnQgb2YgYSBwcmlvcmkga25vd2xlZGdlLiBJIHRoaW5rIHRoZXJlIGlzIGEgcHJpb3JpIGlu dGVudGlvbiwgYnV0IG5vdCBrbm93bGVkZ2UuIFVubGVzcyB5b3UgaGF2ZSB2ZXJ5IGdvb2QgZXll c2lnaHQgb3Igc29tZW9uZSBhdCB0aGUgb3RoZXIgZW5kIG9mIHRoZSBmaWJlciB3aGVuIHlvdSBn aXZlIGl0IGEgdHVnLCB5b3UgZG9uJ3Qga25vdy4gQW5kIGV2ZW4gdGhlbi4gRmliZXJpbmcgZXJy b3JzIGhhcHBlbiBmcm9tIHRpbWUgdG8gdGltZS4gQ29uc2lkZXIsIGluIHBhcnRpY3VsYXIgYSBw YXRjaCBwYW5lbC4NCg0KPiBOb3csIHdoYXQgaXMgdGhlIHB1cnBvc2Ugb2Ygc3RhbmRhcmQgRkVD cyBhbmQgbW9kdWxhdGlvbnMgaW4gdGhlIEFJPyBHaXZlbg0KPiBzZXZlcmFsIGNob2ljZXMgZWFj aCB2ZW5kb3IgbWF5IHN1cHBvcnQgaW4gaXRzIGRldmljZSwgdGhlIHBhdGggY29tcHV0YXRpb24N Cj4gd291bGQgZmluZCBhIG1hdGNoZWQgdHlwZXMgZm9yIEZFQyBhbmQgbW9kdWxhdGlvbiBmb3Ig YSBnaXZlbiBvcHRpY2FsIHBhdGguIA0KPiBUaGlzIGlzIHdoYXQgaXMgaW50ZW5kZWQgd2hlbiBv cHRpY2FsIHNpZ25hbCBwcm9jZXNzaW5nIGNvbnN0cmFpbnRzIHdlcmUgDQo+IHByb3Bvc2VkIGFz IHBhcnQgb2YgcGF0aCBjb21wdXRhdGlvbiBjb25zdHJhaW50cyBpbiBvcHRpY2FsIG5ldHdvcmtz LiANCg0KDQpUaGUgY2FzZSB5b3UgYXJlIG1ha2luZyBoZXJlIGlzIGZvciBubyBzdGFuZGFyZCBj b250cm9sIHBsYW5lIQ0KV2hhdCBpcyB0aGUgcG9pbnQgb2Ygc3RhbmRhcmRpc2luZyBpZiB0aGVy ZSBpcyBuZXZlciBhbnkgaW50ZXJ3b3JraW5nPw0KQnV0IGFjdHVhbGx5LCB3ZSBrbm93IGFib3V0 IGludGVyd29ya2luZyBhdCB0aGUgcGh5c2ljYWwgbGF5ZXIsIGFuZCAobW9yZSBpbXBvcnRhbnQp IHdlIGtub3cgYWJvdXQgYSBzaW5nbGUsIGVuZC10by1lbmQgY29udHJvbCBwbGFuZSB0aGF0IHNw YW5zIG11bHRpcGxlIHZlbmRvciBkZXZpY2VzLiBJdCBhbGwgZXhpc3RzLg0KDQpPZiBjb3Vyc2Us IHdlIGNhbiBmYWxsIGJhY2sgaW50byB0aGUgb2xkLXN0eWxlIHZlbmRvciBpc2xhbmRzLCBhbmQg bWFueSBsaWtlIHRvIGRvIHNvLiBCdXQgaXQgaXMgbm90IGEgY29tcHVsc29yeSBkZXBsb3ltZW50 IG1vZGVsLg0KDQo+IFRoZXJlIGlzIHZlcnkgbGl0dGxlIGNoYW5jZSBmb3IgdmVuZG9yIHNwZWNp ZmljIEZFQ3MgYW5kIE1vZHVsYXRpb25zIHdpbGwgbWF0Y2gNCj4gZXZlbiBpZiB0aGV5IGFyZSBp ZGVudGlmaWVkIHdpdGggdGhlIE9VSSBjb2RlLiANCg0KWW91IGhhdmUgaXQgdGhlIHdyb25nIHdh eSByb3VuZCENClRoZSBPVUkgaXMgbGFyZ2VseSB0byBwcm90ZWN0IGFnYWluc3QgZXhwZWN0YXRp b25zIG9mIGludGVyd29ya2luZyB3aGVuIG5vbmUgY2FuIGV4aXN0Lg0KSXQgbWlnaHQgKG11Y2gg bGVzcyBmcmVxdWVudGx5KSBiZSB1c2VkIHRvIGRlc2NyaWJlIHRoZSB3YXkgdGhhdCB2ZW5kb3JB IGFuZCB2ZW5kb3JCIHBpY2sgRkVDcyBhbmQgbW9kdWxhdGlvbnMgaW4gb3JkZXIgdG8gYWNoaWV2 ZSBpbnRlcndvcmtpbmcuDQoNCkFkcmlhbg0KDQo= From nobody Thu Jan 29 23:45:39 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 EEAE61A899F; Thu, 29 Jan 2015 23:45:33 -0800 (PST) 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 T5yG1EKB2qWi; Thu, 29 Jan 2015 23:45:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6FD1A0055; Thu, 29 Jan 2015 23:45:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130074532.605.38714.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 23:45:32 -0800 Archived-At: Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-rsvp-te-ext-02.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: Fri, 30 Jan 2015 07:45:34 -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 : RSVP-TE Signaling Extensions in support of Flexible Grid Authors : Fatai Zhang Xian Zhang Adrian Farrel Oscar Gonzalez de Dios Daniele Ceccarelli Filename : draft-ietf-ccamp-flexible-grid-rsvp-te-ext-02.txt Pages : 12 Date : 2015-01-29 Abstract: This memo describes the extensions to the Resource reserVation Protocol Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexible-grid-rsvp-te-ext/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-rsvp-te-ext-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-flexible-grid-rsvp-te-ext-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 30 00:06: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 58BA71A89C5 for ; Fri, 30 Jan 2015 00:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lPlbmqjX2VGA for ; Fri, 30 Jan 2015 00:05:59 -0800 (PST) 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 7BC601A89B3 for ; Fri, 30 Jan 2015 00:05:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOO86922; Fri, 30 Jan 2015 08:05:58 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 Jan 2015 08:05:57 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.61]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Fri, 30 Jan 2015 16:05:51 +0800 From: "Zhangxian (Xian)" To: CCAMP Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-rsvp-te-ext-02.txt Thread-Index: AQHQPGDSjKmHYB3IqU+lBWhpaEaP8ZzYTfuA Date: Fri, 30 Jan 2015 08:05:51 +0000 Message-ID: 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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-flexible-grid-rsvp-te-ext-02.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: Fri, 30 Jan 2015 08:06:01 -0000 SGksIEFsbCwgDQoNCiAgSnVzdCB1cGRhdGUgdGhlIGRyYWZ0IHVzaW5nIFJGQzIxMTkgbGFuZ3Vh Z2U7IG5vIHRlY2huaWNhbCBjaGFuZ2UuIFJldmlldy9jb21tZW50cyBhcmUgd2VsY29tZSENCg0K UmVnYXJkcywNClhpYW4gKG9uIGJlaGFsZiBvZiBhbGwgYXV0aG9ycy9jb250cmlidXRvcnMpDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDQ0FNUCBbbWFpbHRvOmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNClNl bnQ6IDIwMTXE6jHUwjMwyNUgMTU6NDYNClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBj Y2FtcEBpZXRmLm9yZw0KU3ViamVjdDogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNj YW1wLWZsZXhpYmxlLWdyaWQtcnN2cC10ZS1leHQtMDIudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbW1vbiBDb250cm9s IGFuZCBNZWFzdXJlbWVudCBQbGFuZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAg ICAgIFRpdGxlICAgICAgICAgICA6IFJTVlAtVEUgU2lnbmFsaW5nIEV4dGVuc2lvbnMgaW4gc3Vw cG9ydCBvZiBGbGV4aWJsZSBHcmlkDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEZhdGFpIFpo YW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgIFhpYW4gWmhhbmcNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgQWRyaWFuIEZhcnJlbA0KICAgICAgICAgICAgICAgICAgICAgICAgICBPc2Nh ciBHb256YWxleiBkZSBEaW9zDQogICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbGUgQ2Vj Y2FyZWxsaQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtZmxleGlibGUtZ3Jp ZC1yc3ZwLXRlLWV4dC0wMi50eHQNCglQYWdlcyAgICAgICAgICAgOiAxMg0KCURhdGUgICAgICAg ICAgICA6IDIwMTUtMDEtMjkNCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gZGVzY3JpYmVzIHRo ZSBleHRlbnNpb25zIHRvIHRoZSBSZXNvdXJjZSByZXNlclZhdGlvbg0KICAgUHJvdG9jb2wgVHJh ZmZpYyBFbmdpbmVlcmluZyAoUlNWUC1URSkgc2lnbmFsaW5nIHByb3RvY29sIHRvIHN1cHBvcnQN CiAgIExhYmVsIFN3aXRjaGVkIFBhdGhzIChMU1BzKSBpbiBhIEdNUExTLWNvbnRyb2xsZWQgbmV0 d29yayB0aGF0DQogICBpbmNsdWRlcyBkZXZpY2VzIHVzaW5nIHRoZSBmbGV4aWJsZSBvcHRpY2Fs IGdyaWQuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJh ZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1w LWZsZXhpYmxlLWdyaWQtcnN2cC10ZS1leHQvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZl cnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1jY2FtcC1mbGV4aWJsZS1ncmlkLXJzdnAtdGUtZXh0LTAyDQoNCkEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtY2NhbXAtZmxleGlibGUtZ3JpZC1yc3ZwLXRlLWV4dC0wMg0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo=