From nobody Mon Jan 4 05:48:32 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4651A88C6 for ; Mon, 4 Jan 2016 05:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 KrynQbfb93Hd for ; Mon, 4 Jan 2016 05:48:29 -0800 (PST) Received: from mail-qg0-x263.google.com (mail-qg0-x263.google.com [IPv6:2607:f8b0:400d:c04::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD7A1A88CA for ; Mon, 4 Jan 2016 05:48:29 -0800 (PST) Received: by mail-qg0-x263.google.com with SMTP id 6so22730591qgy.1 for ; Mon, 04 Jan 2016 05:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:content-type :content-transfer-encoding:mime-version; bh=z9qGEQinLxZ5MFmJjpY+vV9o1hk289uQSW6xgb8MfCM=; b=fEduzK4E/s8DSXDOzSp9L6tPeDHv3wg2v5ztPiP6qBt2EG1Er2ygy8CmboK22Rsa7s ePriw0HdqnAoRYGz6OUCvpOmjQlTXAl5fbg4jBrHpQo4sjo1iSiSvaZ9nhIeTPFzfS+A EtJVyupbjNC+HiaSE1vZn5ASXYu1L/0MUv/BSyLeNIRl1hR5nXPGQtkaLuFF3YhQOkpn Nd2wiCC1RsyNf61PziUrVGdxdCvFkrWNnWnb66uFdheynIi24teCTpGM4PFUTsgwg4Gg YiwRVqTeAAsvOJqRAr6sDx8Sh0k1DjePV04TRJewIIvWjRlsLb7PfVIY94dBqQi6b1HH wYcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type :content-transfer-encoding:mime-version; bh=z9qGEQinLxZ5MFmJjpY+vV9o1hk289uQSW6xgb8MfCM=; b=PDrrrz7Jozoj8y7gG0RDxmepR9Ezc5D18xfxSSTC5llK9ym/yUJ08gDJe57k6R5Wjt EC9H+zjJs1hvRKA541H+5HKbzGO4xVPcPSw7nFab2QalRr/n5O2FNxJ6WFHf33vGaSOn aHhiUL8uULrGIIUOb2dTjOVilWRw9sSmXFynVSSCkGOv0J4ytISSLuhAwrmrkgIyH3/3 m1+20m1xTc/+MmCQ8x4BFWObF03gJQRnZk/uU7o/3swM7Rs5YilhtSLoPtK1TkBUtEMK 8FiYRF87xNs7rDkE6TtaV/e7yD2Kd5IVLMf5mHGxTGpRg0mYbMdg8G+HAUrijTeehR4+ x45A== X-Gm-Message-State: ALoCoQmGVUcMbXcwgv9Xt1L3+UOgfWAJH53U3wWSweq369nVzPXw+TcvZbDaP6e/AM0tZLTTYw2ziEWUIkVamnSdNz0GiyFzke0sEqCqi5jQ8Bs1TKH5dbI= X-Received: by 10.141.7.9 with SMTP id j9mr67854787qhd.71.1451915308871; Mon, 04 Jan 2016 05:48:28 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id x206sm10153385qka.10.2016.01.04.05.48.28 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 04 Jan 2016 05:48:28 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u04DmSEl026766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Jan 2016 08:48:28 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 4 Jan 2016 08:48:28 -0500 From: "Hollenbeck, Scott" To: "lager WG (lager@ietf.org)" Thread-Topic: Remaining Work Items Thread-Index: AdFG9pU7vXrWFZSdT+O8QYqozk+afg== Date: Mon, 4 Jan 2016 13:48:27 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A123C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Lager] Remaining Work Items X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 13:48:31 -0000 Happy New Year! Folks, we're currently behind schedule in terms of completing the work item= s specified in our charter: https://datatracker.ietf.org/wg/lager/charter/ We have three issues open in the datatracker: https://trac.tools.ietf.org/wg/lager/trac/report/1 These all look to be relatively simple to address, so let's get them done A= SAP. Document authors, is there anything holding you up? Scott From nobody Mon Jan 4 14:29:12 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58941AC427 for ; Mon, 4 Jan 2016 14:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 IaXGgI9ut3Pc for ; Mon, 4 Jan 2016 14:29:10 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB201A1A7B for ; Mon, 4 Jan 2016 14:29:10 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 4 Jan 2016 14:29:08 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Mon, 4 Jan 2016 14:29:08 -0800 From: Kim Davies To: "Hollenbeck, Scott" Thread-Topic: [Lager] Remaining Work Items Thread-Index: AdFG9pU7vXrWFZSdT+O8QYqozk+afgAi8qiA Date: Mon, 4 Jan 2016 22:29:06 +0000 Message-ID: <7E5B4D89-249D-43FE-A0DF-D9EB42DB3EFF@icann.org> References: <831693C2CDA2E849A7D7A712B24E257F4A123C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A123C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.35.2] Content-Type: multipart/signed; boundary="Apple-Mail=_9B5D8549-ED4D-4FF2-BBC8-E8F9387221C8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: "lager WG \(lager@ietf.org\)" Subject: Re: [Lager] Remaining Work Items X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 22:29:12 -0000 --Apple-Mail=_9B5D8549-ED4D-4FF2-BBC8-E8F9387221C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Scott, Hi all, > We have three issues open in the datatracker: >=20 > https://trac.tools.ietf.org/wg/lager/trac/report/1 >=20 > These all look to be relatively simple to address, so let's get them = done ASAP. Document authors, is there anything holding you up? For ticket 21, the only outstanding issue is who should be the Change = Controller in section 10.1, which is the media type registration form. = One interpretation of RFC 7303 could be that it should be the World Wide = Web Consortium as that stakes out their responsibility given it has a = =E2=80=9C+xml=E2=80=9D suffix. Specifically, section 4.2 reads that when = using the suffix, =E2=80=9C=E2=80=A6 the change controller has been = changed to be the World Wide Web Consortium (W3C)=E2=80=9D. An = alternative conclusion would be the change controller should be the IESG = given this is a Standards Track document. The latter seems more logical = to me given the W3C has had no role in this specification, but I am not = sure what the purpose of the language in RFC 7303 is intending to serve. = Hopefully there is someone we can consult with to seek clarification on = this item, but that is the issue at hand. For ticket 29, Asmus has proposed changing some references to the = Unicode specification to remove multiple different ways Unicode = properties could be expressed, to have a single canonical long- and = short-form way of representing them. I think this is a good idea and Wil = seems to have concurred. It needs some new text to be put in the next = edition. For ticket 30, Asmus posted about this to the list just prior to the = holiday break. I am not sure I=E2=80=99ve wrapped my head around the = pros and cons of adding =E2=80=9Cvalid=E2=80=9D as an additional core = disposition. I think it would be good to have some discussion about this = on the list before making a call on it. I think that=E2=80=99s it. With some additional feedback and a little = work hopefully we can turn around a new draft with no known issues in = the coming days. kim= --Apple-Mail=_9B5D8549-ED4D-4FF2-BBC8-E8F9387221C8 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILwDCCBWow ggRSoAMCAQICEAM3/aZ67iMUNwpbj+veFrowDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE1MDMzMTAwMDAwMFoXDTE4MDMzMTEy MDAwMFowgYsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMRMwEQYDVQQDEwpLaW0gRGF2aWVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAp0mVGngM3EAPrsiqD1RgMJfuk7PzpwaER7Th8+di8A6FLY7M1XNYYe2d5zVjHZ24 gATERV3ZSrw4Oy+UG/RUrHlGxaYlIkTA8ZB4HOFrYHaBTf2BVFZqsMecBzH0/+kZ0Rdc7odU+48i oi5NjpPNv7eOmSQlhQNOHRKm49htzKNlTons4LDv7Qkxzs2JBj1TzlEmXIhHmHPFLqqW64kFLWeW olwSoaJiZ3GsFLCwEKdGpIKAK5FFL3Uje0kmsUu+dbSk5yQzCf4NVr3HSp9ym97E7SctvzWyK9QD J0P6Ed88mt7qN1ntGyMyePTT2Xi69NOymtd16Qh/LZvGu+jfHQIDAQABo4IB7TCCAekwHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFHkeueu4UvC0be3qjbA4tsMzoHWb MAwGA1UdEwEB/wQCMAAwHwYDVR0RBBgwFoEUa2ltLmRhdmllc0BpY2Fubi5vcmcwDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHSAEPDA6MDgGCmCGSAGG /WwEAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCBiAYDVR0f BIGAMH4wPaA7oDmGN2h0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJBc3N1cmVk SURDQS1nMS5jcmwwPaA7oDmGN2h0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJB c3N1cmVkSURDQS1nMS5jcmwweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydFNIQTJBc3N1cmVkSURDQS5jcnQwDQYJKoZIhvcNAQELBQADggEBAJASl9oxRIgNxmHA RyAYkZWY17Hv02f09iA9AXhylr0eOEqZ96Cs/VWY+CZp8eDnyhokGYoXhv8rRFjV+vX1JS72a6kE mAhXy4h/aCq9KgzTpvoDW7uClk3iHYs56RN9pCidgq7G4m2a5JxVAeIep1iYDx5qE0GGtqqFHHZ2 iUvdKD19mc52cVcOKhmn4P0rl2oz7jSNjBqADpdS11mh3sgEQM/cAVmQecGV5cUlfRwEdA4DDhbz 5+ga8XXJUZy+Xm8yZXpqATzTamM7EXGuqW1DPqLSu748ZmQYjNFDdAMRwO267EXCRTyLIWb2BxzJ JknVXjSiAYXvJL0IMIvRGSAwggZOMIIFNqADAgECAhAErnlgZmaQGrnFf6ZsW9zNMA0GCSqGSIb3 DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0x MzExMDUxMjAwMDBaFw0yODExMDUxMjAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANz4ESM/arXv wCd5Gy0Fh6IQQzHfDtQVG093pCLOPoxw8L4Hjt0nKrwBHbYsCsrdaVgfQe1qBR/aY3hZHiIsK/i6 fsk1O1bxH3xCfiWwIxnGRTjXPUT5IHxgrhywWhgEvo8796nwlJqmDGNJtkEXU0AyvU/mUHpQHyVF 6PGJr83/Xv9Q8/AXEf+9xYn1vWK52PuORQSFbZnNxUhN/SarAjZF6jbXX2riGoJBCtzp2fWRF47G Ia04PBPmHn9mnNVN2Uba9s9Sp307JMO0wVE1xpvr1O9+5HsD4US9egs34E/LgooNcRjkpuCJLBvz snM8wbCSnhh9vat9xX0IoSzCn3MCAwEAAaOCAvgwggL0MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYD VR0PAQH/BAQDAgGGMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDCCAbMGA1UdIASCAaowggGmMIIBogYKYIZIAYb9bAACBDCCAZIwKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBz AGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkA dAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBD AGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAA YQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABp AGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQA IABoAGUAcgBlAGkAbgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYDVR0OBBYEFOcCI4AA T9jXvJQL2T90OUkyPIp5MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3 DQEBCwUAA4IBAQBO1Iknuf0dh3d+DygFkPEKL8k7Pr2TnJDGr/qRUYcyVGvoysFxUVyZjrX64GIZ maYHmnwTJ9vlAqKEEtkV9gpEV8Q0j21zHzrWoAE93uOC5EVrsusl/YBeHTmQvltC9s6RYOP5oFYM SBDOM2h7zZOr8GrLT1gPuXtdGwSBnqci4ldJJ+6Skwi+aQhTAjouXcgZ9FCATgLZsF2RtJOH+ZaW gVVAjmbtgti7KF/tTGHtBlgoGVMRRLxHICmyBGzYiVSZO3XbZ3gsHpJ4xlU9WBIRMm69QwxNNNt7 xkLb7L6rm2FMBpLjjt8hKlBXBMBgojXVJJ5mNwlJz9X4ZbPg4m7CMYIDGTCCAxUCAQEweTBlMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAM3/aZ67iMUNwpbj+ve FrowCQYFKw4DAhoFAKCCAXUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTYwMTA0MjIyOTA2WjAjBgkqhkiG9w0BCQQxFgQU+SWSx+Go7kK8dgiXwBN4PbkTYBQwgYgG CSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElE IENBAhADN/2meu4jFDcKW4/r3ha6MIGKBgsqhkiG9w0BCRACCzF7oHkwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhADN/2meu4jFDcKW4/r3ha6MA0GCSqGSIb3 DQEBAQUABIIBAHuJ5YimVtF3rSyLddhvhnDWLrRT+c6e2lCHMzgfpLKEBOMzL8ah6Kzc4A+8RkXg joEFW2fEipRols17yjx0Yisd2i8i/gCgQwb2yPMm8+EEeLuB2e4gvylPmS20zF+02aLDgyO74nUL thPphDActt8n6uGmiPzTQV3kleOOeg+7ThvlgVkl6ue+XNtkK7klsxlCc8Vf5J0IZ3K8QcUPmKQ/ Bl3k1v9+lV9FfqUJiqTUG39jx7bQm1DdebUvbfEcYtlQ2GB+RZiJhgmrYmy/DSm+M3YVqZehXlG8 sIJwpHRe50gaH0oaApUBf2geuqSLxVKt43Ou2FhW+dsOq0KrQgcAAAAAAAA= --Apple-Mail=_9B5D8549-ED4D-4FF2-BBC8-E8F9387221C8-- From nobody Mon Jan 4 17:44:45 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C761ACE42 for ; Mon, 4 Jan 2016 17:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 XSoDR8ZgG6ok for ; Mon, 4 Jan 2016 17:44:41 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0120.outbound.protection.outlook.com [104.47.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E12C1ACE40 for ; Mon, 4 Jan 2016 17:44:40 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0141.jpnprd01.prod.outlook.com (10.161.134.13) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 5 Jan 2016 01:44:33 +0000 To: Kim Davies , "Hollenbeck, Scott" References: <831693C2CDA2E849A7D7A712B24E257F4A123C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <7E5B4D89-249D-43FE-A0DF-D9EB42DB3EFF@icann.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <568B2000.9020707@it.aoyama.ac.jp> Date: Tue, 5 Jan 2016 10:44:32 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7E5B4D89-249D-43FE-A0DF-D9EB42DB3EFF@icann.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR0201CA0019.apcprd02.prod.outlook.com (25.164.90.157) To TY1PR01MB0141.jpnprd01.prod.outlook.com (25.161.134.13) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0141; 2:kKVajIhpI6yDUFNu61KoHTAzaXYih5s1L7baCyftYVDsDNMwCXczmqrUL9uaepT+SYLVq9FtXC5awxtvqDvPPzWGZSwtDC3rLw+o+sG06QWeDudfJQXxDMdAl14rt8tmMHLZ5PpYQx3ziPnTPKRhcQ==; 3:0xF46FP9ABS2LN+1fA6tM6O6IQpeljOlryQjQtTwQOWgeBMxtvrWRdsa31uVCmeDX7gKgzw1n+RltUQ66HvwCg+b7Ku1IVoMR5661sh5sT+C49hH7qXxmHOaH+/w718A; 25:RcmwVvs16DvMKY8ko4zmSxz8Xky8OC+a8HMAA8CnfYZUpzRkPUP8X75RTtNmee33WZIRpEc4NNBiXfMdGa2iO7mCgKEu+Y8zAgQt47+ojfYdizue6ObjhypHbxA7t9ByqUXVhSAO5//+5+tvmwJx2Cz+quJLPgdk8rYFox98RFyHUDhYq0VgTgZ96J8ol48IPNdMUoAIc539WFzSQ7c7KbzTOFdlf+sE4YGhFPODokOaQjNGjpydTyytIhnluF1zY3Gx/MPrOvLq/zlYmK19iw==; 4:d2jhBcw+yFJUA5TTqV6MiNP/7EzWm1jPtkhBIWg+gMhZ1WJ7PvtHKp9+sCxMPpdXkEYWbirCeBkLoNhTTbIBkyBbzyPj3+b/EkzjLwRBFO3elFJ31PcsWOp+SgyNPH5nWnWJ4tnk7TV7q8ABW2at7koOwmNclk+caGfly7jcLAm7+7+ViG4Fk95i/O9wkZjJnLYNIv6LX2E66+MqnGk3dA39RHabGYnE1KBJ22buV1AyA3IDDqFQ2pkP9SGSyD+lStbas7RyJHMt6YCEfsLij3BnTci9cO4k8djUA9RriHH4kLO8Zl/Ytmk0gZ44TttlTAXg86iUaDvc/mKUpMkZxVdOsNMu9vQ/J0RTMs+oLJK1dEZF9+VzazZAcu/LaUXe X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0141; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:TY1PR01MB0141; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0141; X-Forefront-PRVS: 0812095267 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(479174004)(53754006)(24454002)(199003)(65816999)(47776003)(33656002)(5008740100001)(189998001)(97736004)(5001960100002)(101416001)(105586002)(64126003)(5001770100001)(6116002)(586003)(50466002)(59896002)(50986999)(5004730100002)(74482002)(4001350100001)(1096002)(87266999)(92566002)(76176999)(87976001)(19580395003)(65806001)(2950100001)(42186005)(15975445007)(40100003)(4326007)(3846002)(80316001)(106356001)(16799955002)(122386002)(81156007)(66066001)(23676002)(83506001)(86362001)(65956001)(77096005)(54356999)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0141; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQxOzIzOk9BaFkxVGRzLzcwelFjc1FsYllVbUVSM3A4?= =?utf-8?B?UGl6SWVBS3NMWEoxSkhBWU5mQ0lQUkhzSnJlRW5NMkFBbmc0eHVjRWw4WEZP?= =?utf-8?B?UDNHOW5sQmRzNnBPTGNsbXNoTVQxTHd3MS9mdFh0S2RSTVZHZzhXcUxXZko0?= =?utf-8?B?T2RmQmc1WGN1NUM5QzVhUmVnb25zdDNra3h6WS8xWm9lMDFscC9FclBDK3JI?= =?utf-8?B?UmxwSW90NjNRemNnNmNTTEN3K3N4QUZqTmJnTW4xNFdzTnFieEllQW9vT0VC?= =?utf-8?B?NzhjNWZUSFhBK0Q3SFl4UXJMbWFrNnVMbU1QdEVHR2lRY0VoODlvY3Q5T1pO?= =?utf-8?B?aUVSRHU0MUViRTk0RHkrdHFNamtDVmtKTHRGMGRXckxkSmFHM3BiNm40Mnpx?= =?utf-8?B?YXczc3VISzJwZTE1WU9EdE5Uc3Q2RGh5WW9WK0dteHNSOUZHRjNlUGRrc3Vn?= =?utf-8?B?aHhzNXVuaTZyQ0FoNTk3cGJQaUtjYnl5dy9VaCtVZHdwL2hJL01icnB6NzRU?= =?utf-8?B?NFFwL3FvaWk5ek91Q05iSTVaSGt2aEc4UHgzanh4aG1sakxYMkJSNHJFSVdJ?= =?utf-8?B?b0lLMXlYRVBrd2J1NGljT2ZCUTVPVUU2VSs2a2d0UWMrQ2xXamM0UCs3eDlO?= =?utf-8?B?VFpPclRjS0NqalhTZmk2VHE1Nld4aXRHcGdsY0h6Q3ZnQzI2am0rbFpEQkNs?= =?utf-8?B?Y0dxblAzSjFrVUNMZ1laVVlPYlhkaElZU1hrUE1kNGZFSmk1eURKM0FidTNy?= =?utf-8?B?WjlFNisyTVVkTXFuelY4WnNtNC9CKzZLeHNIYUZWYXA3aTR6Tm5FQlB5Qlht?= =?utf-8?B?V3hkTWI5Rnl4T09IYytXTitlTjdvcWtrejlTSjRZNGtmcTBtZEcvbmdvZmc3?= =?utf-8?B?cjJSaFJxb1BwQmdJWEoyWkUyTDlMdkRoMWNkK05ESUZWMzliNy93THhzbmI3?= =?utf-8?B?eDY5TWZFVDV3QTZ0UGVSM25rWlpDY0pSVFhVR2d3aWhhV2x5RjVSTXI0bFlL?= =?utf-8?B?SC9MczdaSUxsR2FFNEY4TTZmZnhGVEJsbERpZVM3a1BiamYxdHU4ZVZMRXV4?= =?utf-8?B?ZmVOOUxNUktmQjIyODRrTmRpQ2x0aVhvVUJmWHViM1B3UjFGTHVDNXZZVTU0?= =?utf-8?B?NnFrUEZPNWFMMlgrWHYvWEdhMldOa1VkZytUQ014NDgzV21SWmVIaklOUEpJ?= =?utf-8?B?a2tmOEVjekFGaUVrYkdlR1JqNEZ2SXRCZ3BRaitWTW8rN3pZZzNrUE95YUIx?= =?utf-8?B?d2xheGkxRVFtZElCSEo1a3NURWh4Vkcxd1JzMEdTTHd4ay8zN3VKZzdXTjVF?= =?utf-8?B?c1YzUVhRdk5keWVLNlZPQk0zZVBWQm1DQzl6V3RBamdvK3ZUY0VNSlkyV25m?= =?utf-8?B?K2xKb1UvVi9SUWZxekp2ZUJRNkFJUlJ4S2YvamxOZSsxVkdReVlHakFLNy9m?= =?utf-8?B?eWFSaGxoTHRKK3VySUlzSEg1czNwRHR5RmhLMUtBSVZwYk44Yk8yemdqWE9t?= =?utf-8?B?UnMzeDB1QmgzNjBzM2ZwTzlDcTNqV2wrZUh0T1R2b2lmZStHYy9NZDNubUZp?= =?utf-8?B?YU1kNnRkcjFWUEpOK0M2UkZIVzZzU0dNbFJCVkxNYU05bjNkT05id0J3K09w?= =?utf-8?B?K1NMRkFTU3ZPZ1JpMllpRGN2b3VtYWNtWlJXN1MzOVF5OWRidVh5SFZUdi9W?= =?utf-8?B?MTMxalp4RUFucHkyeHJBb0xvbDc1YldqU2lDYXFBL05kVjVLWDArRC9HcE5m?= =?utf-8?B?Y0pMUmlVUW5Fc0xuUHg3OGNOR0VhdmEzYjUxZnllNjNldzdmbU1YMjdYR3hG?= =?utf-8?Q?jnTJOb2o93lze?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0141; 5:l+r2hzTk14pUj0xheDNpcokAUWKbgQB7iO7JJwHWDgBX4mdYgfCLfto1UpKgD7bdIuN9idBqURIsA+v/U9/aU5O1QrCGGMXfuecByVL5b4t0g0daG4lHi3gU66DPv12gvT5Wz9H/OniV3hIGyD2xDA==; 24:TDswTDPdTTCUuhn8/rbJW45hdI3LnKwPHIKxDFtdhlGJSdc1zwQ5m/gqgvtmrCO2vNwDbHXF/wjcZJ6oA2iSIR5TpNlDwN+gfYteoxrgzhM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2016 01:44:33.7257 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0141 Archived-At: Cc: "lager WG \(lager@ietf.org\)" Subject: Re: [Lager] Remaining Work Items X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 01:44:44 -0000 Hello Kim, others, Some comments from somebody who has extensively commented on drafts of RFC 7303 and its predecessor(s?) and has at one time been responsible for media registrations at W3C and W3C-IETF liaison. On 2016/01/05 07:29, Kim Davies wrote: > Hi Scott, Hi all, > >> We have three issues open in the datatracker: >> >> https://trac.tools.ietf.org/wg/lager/trac/report/1 >> >> These all look to be relatively simple to address, so let's get them done ASAP. Document authors, is there anything holding you up? > > For ticket 21, the only outstanding issue is who should be the Change Controller in section 10.1, which is the media type registration form. One interpretation of RFC 7303 could be that it should be the World Wide Web Consortium as that stakes out their responsibility given it has a “+xml” suffix. Specifically, section 4.2 reads that when using the suffix, “… the change controller has been changed to be the World Wide Web Consortium (W3C)”. This is an interesting misunderstanding. The last sentence of section 4.2, currently reading >>> In addition to the changes described above, the change controller has been changed to be the World Wide Web Consortium (W3C). >>> in more detail would read >>> In addition to the changes described above, the change controller for the '+xml' Structured Syntax Suffix has been changed to be the World Wide Web Consortium (W3C). >>> I have submited an erratum on this. (see https://www.rfc-editor.org/errata_search.php?eid=4578) An alternative conclusion would be the change controller should be the IESG given this is a Standards Track document. The latter seems more logical to me given the W3C has had no role in this specification, but I am not sure what the purpose of the language in RFC 7303 is intending to serve. Definitely more logical and the right thing to do. Hopefully there is someone we can consult with to seek clarification on this item, but that is the issue at hand. I hope you are satisfied with my explanations. Regards, Martin. From nobody Mon Jan 4 20:07:34 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1144E1AD074 for ; Mon, 4 Jan 2016 20:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwkEiJFzsBaM for ; Mon, 4 Jan 2016 20:07:29 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 05CFF1AD05B for ; Mon, 4 Jan 2016 20:07:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=XYF8BUrXYhZilA5YmyoYxO81Y0H/p+Tusgf6sEkmjPvpYi7s0x3AtKjk6B5TAZAv; h=Received:From:Subject:To:References:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [75.165.47.225] (helo=[192.168.0.4]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aGItx-0003wR-Tv for lager@ietf.org; Mon, 04 Jan 2016 23:07:18 -0500 From: Asmus Freytag To: lager@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F4A123C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <7E5B4D89-249D-43FE-A0DF-D9EB42DB3EFF@icann.org> Message-ID: <568B4176.9020902@ix.netcom.com> Date: Mon, 4 Jan 2016 20:07:18 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7E5B4D89-249D-43FE-A0DF-D9EB42DB3EFF@icann.org> Content-Type: multipart/alternative; boundary="------------010108070402020202000307" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2857e9f10d2205ddc26611f13170d1748f9b9d6eba658bb7f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.165.47.225 Archived-At: Subject: Re: [Lager] Remaining Work Items + 1 new question X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 04:07:32 -0000 This is a multi-part message in MIME format. --------------010108070402020202000307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/4/2016 2:29 PM, Kim Davies wrote: > Hi Scott, Hi all, > >> We have three issues open in the datatracker: >> >> https://trac.tools.ietf.org/wg/lager/trac/report/1 >> >> These all look to be relatively simple to address, so let's get them done ASAP. Document authors, is there anything holding you up? > For ticket 21, the only outstanding issue is who should be the Change Controller in section 10.1, which is the media type registration form. One interpretation of RFC 7303 could be that it should be the World Wide Web Consortium as that stakes out their responsibility given it has a “+xml” suffix. Specifically, section 4.2 reads that when using the suffix, “… the change controller has been changed to be the World Wide Web Consortium (W3C)”. An alternative conclusion would be the change controller should be the IESG given this is a Standards Track document. The latter seems more logical to me given the W3C has had no role in this specification, but I am not sure what the purpose of the language in RFC 7303 is intending to serve. Hopefully there is someone we can consult with to seek clarification on this item, but that is the issue at hand. Seems logical. But I'm no expert on RFC7303 > For ticket 29, Asmus has proposed changing some references to the Unicode specification to remove multiple different ways Unicode properties could be expressed, to have a single canonical long- and short-form way of representing them. I think this is a good idea and Wil seems to have concurred. It needs some new text to be put in the next edition. I will be able to put new text together (relatively) shortly. Let's say a week? > For ticket 30, Asmus posted about this to the list just prior to the holiday break. I am not sure I’ve wrapped my head around the pros and cons of adding “valid” as an additional core disposition. I think it would be good to have some discussion about this on the list before making a call on it. Yeah, I'd like to see some discussion as well. Also, Kim, if you have actual questions, I'd like to answer those as well. > I think that’s it. With some additional feedback and a little work hopefully we can turn around a new draft with no known issues in the coming days. I do have another issue. This one may or may not result in any changes in the spec, but I'd need some clarification on a question to know. Question: Specifically for scope="domain". Do people see the function of the LGR as describing all delegated plus the space of all (possible) future labels, or only the space of all future possible labels? Inevitably, there will be, somewhere, some change to an LGR that's not fully backwards compatible. This may not be something as crude as restricting the available repertoire, but could be as subtle as a change in the definition of variants that suddenly would result in two delegated labels being in "collision" under the LGR. (Hypothetical scenarios that would motivate such changes are near infinite, from the need to support new code points, new languages, a spelling reform... so let's just take it as given that sometime, somewhere this proves inescapable). If an LGR only applies to labels being applied for, then this is never an issue. The LGR is fine, the registry would contain the "grandfathered" delegations and nothing else needs to be done. If, however, there's an implied required for an LGR to always describe the total future namespace as well as any exceptions, then we would need to be sure to have a mechanism to capture such exceptions right in the definition of the LGR. For labels affected by a subset in the change in variants definition that causes them to collide under the updated LGR, there is a simple way to use WLE rules to explicitly declare exceptional labels as "valid" even before evaluating their variant mappings under the LGR. It's not even super inefficient in the XML, just a rule that matches a among all literal strings. That would bypass the collision. However, it's not a general enough mechanism, so, for example, it would not cover a scenario where an LGR has fewer code points than needed to cover existing labels. (This could happen, theoretically, in the root, as labels were delegated before adoption of an LGR with express promise that the LGR would not be bound by them as precedent). Hence my question. Is there a need to cover grandfathered labels? A./ PS: for any scope where no "registry" exists, clearly an LGR would have to always encompass all labels, but for "domain" we don't have that limitation, because there's always a way to know the actual delegation status of a label. > kim > > > _______________________________________________ > Lager mailing list > Lager@ietf.org > https://www.ietf.org/mailman/listinfo/lager --------------010108070402020202000307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/4/2016 2:29 PM, Kim Davies wrote:
Hi Scott, Hi all,


We have three issues open in the datatracker:

https://trac.tools.ietf.org/wg/lager/trac/report/1

These all look to be relatively simple to address, so let's get them done ASAP. Document authors, is there anything holding you up?

For ticket 21, the only outstanding issue is who should be the Change Controller in section 10.1, which is the media type registration form. One interpretation of RFC 7303 could be that it should be the World Wide Web Consortium as that stakes out their responsibility given it has a “+xml” suffix. Specifically, section 4.2 reads that when using the suffix, “… the change controller has been changed to be the World Wide Web Consortium (W3C)”. An alternative conclusion would be the change controller should be the IESG given this is a Standards Track document. The latter seems more logical to me given the W3C has had no role in this specification, but I am not sure what the purpose of the language in RFC 7303 is intending to serve. Hopefully there is someone we can consult with to seek clarification on this item, but that is the issue at hand.

Seems logical. But I'm no expert on RFC7303
For ticket 29, Asmus has proposed changing some references to the Unicode specification to remove multiple different ways Unicode properties could be expressed, to have a single canonical long- and short-form way of representing them. I think this is a good idea and Wil seems to have concurred. It needs some new text to be put in the next edition.

I will be able to put new text together (relatively) shortly. Let's say a week?
For ticket 30, Asmus posted about this to the list just prior to the holiday break. I am not sure I’ve wrapped my head around the pros and cons of adding “valid” as an additional core disposition. I think it would be good to have some discussion about this on the list before making a call on it.

Yeah, I'd like to see some discussion as well. Also, Kim, if you have actual questions, I'd like to answer those as well.
I think that’s it. With some additional feedback and a little work hopefully we can turn around a new draft with no known issues in the coming days.

I do have another issue. This one may or may not result in any changes in the spec, but I'd need some clarification on a question to know.

Question:

Specifically for scope="domain". Do people see the function of the LGR as describing all delegated plus the space of all (possible) future labels, or only the space of all future possible labels?

Inevitably, there will be, somewhere, some change to an LGR that's not fully backwards compatible. This may not be something as crude as restricting the available repertoire, but could be as subtle as a change in the definition of variants that suddenly would result in two delegated labels being in "collision" under the LGR. (Hypothetical scenarios that would motivate such changes are near infinite, from the need to support new code points, new languages, a spelling reform... so let's just take it as given that sometime, somewhere this proves inescapable).

If an LGR only applies to labels being applied for, then this is never an issue. The LGR is fine, the registry would contain the "grandfathered" delegations and nothing else needs to be done.

If, however, there's an implied required for an  LGR to always describe the total future namespace as well as any exceptions, then we would need to be sure to have a mechanism to capture such exceptions right in the definition of the LGR.

For labels affected by a subset in the change in variants definition that causes them to collide under the updated LGR, there is a simple way to use WLE rules to explicitly declare exceptional labels as "valid" even before evaluating their variant mappings under the LGR. It's not even super inefficient in the XML, just a rule that matches a <choice> among all literal strings. That would bypass the collision.

However, it's not a general enough mechanism, so, for example, it would not cover a scenario where an LGR has fewer code points than needed to cover existing labels. (This could happen, theoretically, in the root, as labels were delegated before adoption of an LGR with express promise that the LGR would not be bound by them as precedent).

Hence my question. Is there a need to cover grandfathered labels?

A./

PS: for any scope where no "registry" exists, clearly an LGR would have to always encompass all labels, but for "domain" we don't have that limitation, because there's always a way to know the actual delegation status of a label.

kim


_______________________________________________
Lager mailing list
Lager@ietf.org
https://www.ietf.org/mailman/listinfo/lager

--------------010108070402020202000307-- From nobody Tue Jan 5 04:42:22 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB5B1B2D47 for ; Tue, 5 Jan 2016 04:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FK_ZdMSlNnK for ; Tue, 5 Jan 2016 04:42:13 -0800 (PST) Received: from mail-oi0-x262.google.com (mail-oi0-x262.google.com [IPv6:2607:f8b0:4003:c06::262]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730B31B2D24 for ; Tue, 5 Jan 2016 04:42:13 -0800 (PST) Received: by mail-oi0-x262.google.com with SMTP id l9so37174619oia.1 for ; Tue, 05 Jan 2016 04:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=XUPITp81OuGxl+Sj0uw7d31LEoumdpUgSDtySB49w14=; b=uYrd1fGVUsNNlRPAOyRROfEnnYorkgRoQ+rRHZYUO8j2MsqLaoeTF44lHeItVzSYa1 CeKy2aPu0lnGXKr9U3tR3lC9bJdjfgf/51Bk5afhbCYl4qZW+xhdGi7S9KTgz7Hbm/H+ QXz6SmgL7mcej4Ix3T4PturpSBgDR5rddtsTh4kMUbmcfSj6OXGQub9+1ucP5TJkMTGR T0ikK3g6Sccf5JNpchSW7jzdcN3S4aao/6pNxyl0QDrr40kLTDBqQrhTKzJ7eisLQSLC OMY/TOgAELC0RhsqSGgi0ih0LzVzXLZnURE9GAOBjEwSwC+7aqK2DaGIw0OJU/oPWs+Y 99iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=XUPITp81OuGxl+Sj0uw7d31LEoumdpUgSDtySB49w14=; b=GfYychCZbd9W1E7ySeTz82d6nbjFS9gcOqfiWZN1C9J+QFA3oHBtRzo6Hy1oNbXTHR QbB2XfKSt5KvhKVsLd7YRerk2krhzNwpn7CWyo3FNWehD+orsUQH8PtMmmj75x2jnf2d 29S7t7LbR3HfLMstCAXXSe05hh1ZFKzPQ01wN4Z9x8vhquISGqJUak0wAgyMdcVKshDb lNiSumjX2EQ9KEr9JL8Qcx8T8uMWoVkSCQmCvv3vyPe/ozstlvIbRYYnc90wQ1pUVrvU J4ZmqtBVqT4SbZZYP3Z//sUnlTpKSlo2o/PeudRj/bX22VGNVScLP09/CnHD0QGEzO/z otMA== X-Gm-Message-State: ALoCoQkljY3sQaJ/NKmKcy6GTh5RdYFFVZUikIR7ChB6PVpXXQQvCJVEFs/zqprTdtsUsofYBC0QcESJdrFy9qPCOL4/7+Fv/rFnwjtrU0kjp2vMoObrjjY= X-Received: by 10.55.207.73 with SMTP id e70mr120898238qkj.77.1451997732857; Tue, 05 Jan 2016 04:42:12 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id y135sm12245073qky.9.2016.01.05.04.42.12 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 05 Jan 2016 04:42:12 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u05CgCkN007218 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2016 07:42:12 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 5 Jan 2016 07:42:12 -0500 From: "Hollenbeck, Scott" To: Asmus Freytag , "lager@ietf.org" Thread-Topic: [Lager] Remaining Work Items + 1 new question Thread-Index: AQHRR26cv2E+kUZR20O1o1rzsxjpWZ7s12Hw Date: Tue, 5 Jan 2016 12:42:10 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A1252EE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A123C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <7E5B4D89-249D-43FE-A0DF-D9EB42DB3EFF@icann.org> <568B4176.9020902@ix.netcom.com> In-Reply-To: <568B4176.9020902@ix.netcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4A1252EEBRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: Subject: Re: [Lager] Remaining Work Items + 1 new question X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 12:42:20 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4A1252EEBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTGFnZXIgW21haWx0bzpsYWdlci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QXNtdXMgRnJleXRhZw0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDA0LCAyMDE2IDExOjA3IFBNDQpU bzogbGFnZXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTGFnZXJdIFJlbWFpbmluZyBXb3JrIEl0 ZW1zICsgMSBuZXcgcXVlc3Rpb24NCg0KT24gMS80LzIwMTYgMjoyOSBQTSwgS2ltIERhdmllcyB3 cm90ZToNCg0KSGkgU2NvdHQsIEhpIGFsbCwNCg0KDQoNCldlIGhhdmUgdGhyZWUgaXNzdWVzIG9w ZW4gaW4gdGhlIGRhdGF0cmFja2VyOg0KDQoNCg0KaHR0cHM6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL2xhZ2VyL3RyYWMvcmVwb3J0LzENCg0KDQoNClRoZXNlIGFsbCBsb29rIHRvIGJlIHJlbGF0 aXZlbHkgc2ltcGxlIHRvIGFkZHJlc3MsIHNvIGxldCdzIGdldCB0aGVtIGRvbmUgQVNBUC4gRG9j dW1lbnQgYXV0aG9ycywgaXMgdGhlcmUgYW55dGhpbmcgaG9sZGluZyB5b3UgdXA/DQoNCkZvciB0 aWNrZXQgMjEsIHRoZSBvbmx5IG91dHN0YW5kaW5nIGlzc3VlIGlzIHdobyBzaG91bGQgYmUgdGhl IENoYW5nZSBDb250cm9sbGVyIGluIHNlY3Rpb24gMTAuMSwgd2hpY2ggaXMgdGhlIG1lZGlhIHR5 cGUgcmVnaXN0cmF0aW9uIGZvcm0uIE9uZSBpbnRlcnByZXRhdGlvbiBvZiBSRkMgNzMwMyBjb3Vs ZCBiZSB0aGF0IGl0IHNob3VsZCBiZSB0aGUgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSBhcyB0 aGF0IHN0YWtlcyBvdXQgdGhlaXIgcmVzcG9uc2liaWxpdHkgZ2l2ZW4gaXQgaGFzIGEg4oCcK3ht bOKAnSBzdWZmaXguIFNwZWNpZmljYWxseSwgc2VjdGlvbiA0LjIgcmVhZHMgdGhhdCB3aGVuIHVz aW5nIHRoZSBzdWZmaXgsIOKAnOKApiB0aGUgY2hhbmdlIGNvbnRyb2xsZXIgaGFzIGJlZW4gY2hh bmdlZCB0byBiZSB0aGUgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSAoVzNDKeKAnS4gQW4gYWx0 ZXJuYXRpdmUgY29uY2x1c2lvbiB3b3VsZCBiZSB0aGUgY2hhbmdlIGNvbnRyb2xsZXIgc2hvdWxk IGJlIHRoZSBJRVNHIGdpdmVuIHRoaXMgaXMgYSBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQuIFRo ZSBsYXR0ZXIgc2VlbXMgbW9yZSBsb2dpY2FsIHRvIG1lIGdpdmVuIHRoZSBXM0MgaGFzIGhhZCBu byByb2xlIGluIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IEkgYW0gbm90IHN1cmUgd2hhdCB0aGUg cHVycG9zZSBvZiB0aGUgbGFuZ3VhZ2UgaW4gUkZDIDczMDMgaXMgaW50ZW5kaW5nIHRvIHNlcnZl LiBIb3BlZnVsbHkgdGhlcmUgaXMgc29tZW9uZSB3ZSBjYW4gY29uc3VsdCB3aXRoIHRvIHNlZWsg Y2xhcmlmaWNhdGlvbiBvbiB0aGlzIGl0ZW0sIGJ1dCB0aGF0IGlzIHRoZSBpc3N1ZSBhdCBoYW5k Lg0KDQpTZWVtcyBsb2dpY2FsLiBCdXQgSSdtIG5vIGV4cGVydCBvbiBSRkM3MzAzDQoNCltTQUhd IE15IHRha2U6IHdlIHNob3VsZCB1c2Ug4oCcSUVTR+KAnSBmb3IgYW4gSUVURiBzdGFuZGFyZHMg dHJhY2sgZG9jdW1lbnQuDQoNClNlY3Rpb24gNC4yIG9mIFJGQyA3MzAzIG5vdGVzIHRoYXQg4oCc VGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGZvciBzcGVjaWZpYyAnK3htbCcgbWVkaWEgdHlwZXMg aXMgZGVzY3JpYmVkIGluIFtSRkM2ODM4XS4gIE5ldyBYTUwtYmFzZWQgbWVkaWEgdHlwZSByZWdp c3RyYXRpb25zIGluIHRoZSBJRVRGIG11c3QgZm9sbG93IHRoZXNlIGd1aWRlbGluZXPigJ0uIFNl Y3Rpb24gNC43IG9mIDY4Mzggc2F5cyDigJxUaGVyZSBhcmUgYSBudW1iZXIgb2YgYWRkaXRpb25h bCByZXF1aXJlbWVudHMgc3BlY2lmaWMgdG8gdGhlIHJlZ2lzdHJhdGlvbiBvZiBYTUwgbWVkaWEg dHlwZXMuICBUaGVzZSByZXF1aXJlbWVudHMgYXJlIHNwZWNpZmllZCBpbiBbUkZDMzAyM13igJ0u IFVuZm9ydHVuYXRlbHksIDMwMjMgd2FzIG9ic29sZXRlZCBieSA3MzAzLCBhbmQgd2UgaGF2ZSBh IGNpcmN1bGFyIHNldCBvZiByZWZlcmVuY2VzIGFuZCB3ZeKAmXJlIGJhY2sgdG8gNzMwMy4NCg0K SSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgd2hhdCDigJxJbiBhZGRpdGlvbiB0byB0aGUgY2hh bmdlcyBkZXNjcmliZWQgYWJvdmUsIHRoZSBjaGFuZ2UgY29udHJvbGxlciBoYXMgYmVlbiBjaGFu Z2VkIHRvIGJlIHRoZSBXb3JsZCBXaWRlIFdlYiBDb25zb3J0aXVtIChXM0Mp4oCdIGFwcGxpZXMg dG8uIElmIGl0IGFwcGxpZXMgdG8gdGhlIGxhc3QgZmV3IHNlbnRlbmNlcyBvZiB0aGUgcHJldmlv dXMgcGFyYWdyYXBoLCBpdOKAmXMgdGFsa2luZyBhYm91dCBub24tSUVURiByZWdpc3RyYXRpb25z LiBTbyBsZXTigJlzIGFzc3VtZSB0aGF0IGl0IGFwcGxpZXMgdG8gbm9uLUlFVEYgcmVnaXN0cmF0 aW9ucyBhbmQgbGV04oCZcyBsb29rIGF0IHRoZSByZWdpc3RyeSBmb3Igc29tZSByZWNlbnQg4oCc K3htbOKAnSBleGFtcGxlczoNCg0KYXRvbWNhdCt4bWwgKFJGQyA1MDIzKTogSUVTRw0KYXRvbWRl bGV0ZWQreG1sIChSRkMgNjcyMSk6IElFU0cNCmF1dGgtcG9saWN5K3htbCAoUkZDIDQ3NDUpOiBJ RVNHDQphcHBsaWNhdGlvbi9sb2FkLWNvbnRyb2wreG1sIChSRkMgNzIwMCk6IElFU0cNCnJmYyt4 bWwgKFJGQyBUQkQpOiBSRkMgRWRpdG9yICh0aGlzIGlzIHBvc3QtNzMwMyB3aXRoIGEgbm9uLVcz QyBjaGFuZ2UgY29udHJvbGxlcikNCnhtbC1wYXRjaCt4bWwgKFJGQyA3MzUxKTogSUVURiAodGhp cyBpcyBwb3N0LTczMDMgd2l0aCBhIG5vbi1XM0MgY2hhbmdlIGNvbnRyb2xsZXIpDQoNCkkgdGhp bmsgd2UgaGF2ZSBhIGNvbnNpc3RlbnQgcGF0dGVybi4gVXNlIOKAnElFU0figJ0uDQoNClNjb3R0 DQo= --_000_831693C2CDA2E849A7D7A712B24E257F4A1252EEBRN1WNEXMBX01vc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij4gTGFnZXIgW21haWx0bzpsYWdlci1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5Bc211cyBGcmV5dGFnPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgSmFudWFyeSAwNCwgMjAxNiAxMTowNyBQTTxicj4NCjxiPlRvOjwvYj4gbGFnZXJAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtMYWdlcl0gUmVtYWluaW5nIFdvcmsgSXRlbXMg JiM0MzsgMSBuZXcgcXVlc3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiAxLzQvMjAxNiAyOjI5IFBNLCBLaW0gRGF2aWVzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwcmU+SGkgU2NvdHQsIEhpIGFsbCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPldlIGhhdmUgdGhyZWUgaXNzdWVzIG9wZW4g aW4gdGhlIGRhdGF0cmFja2VyOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9s YWdlci90cmFjL3JlcG9ydC8xIj5odHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvbGFnZXIv dHJhYy9yZXBvcnQvMTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT5UaGVzZSBhbGwgbG9vayB0byBiZSByZWxhdGl2ZWx5IHNpbXBsZSB0byBh ZGRyZXNzLCBzbyBsZXQncyBnZXQgdGhlbSBkb25lIEFTQVAuIERvY3VtZW50IGF1dGhvcnMsIGlz IHRoZXJlIGFueXRoaW5nIGhvbGRpbmcgeW91IHVwPzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cHJlPkZvciB0aWNrZXQgMjEsIHRoZSBvbmx5IG91dHN0YW5kaW5nIGlzc3VlIGlz IHdobyBzaG91bGQgYmUgdGhlIENoYW5nZSBDb250cm9sbGVyIGluIHNlY3Rpb24gMTAuMSwgd2hp Y2ggaXMgdGhlIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9uIGZvcm0uIE9uZSBpbnRlcnByZXRhdGlv biBvZiBSRkMgNzMwMyBjb3VsZCBiZSB0aGF0IGl0IHNob3VsZCBiZSB0aGUgV29ybGQgV2lkZSBX ZWIgQ29uc29ydGl1bSBhcyB0aGF0IHN0YWtlcyBvdXQgdGhlaXIgcmVzcG9uc2liaWxpdHkgZ2l2 ZW4gaXQgaGFzIGEg4oCcJiM0Mzt4bWzigJ0gc3VmZml4LiBTcGVjaWZpY2FsbHksIHNlY3Rpb24g NC4yIHJlYWRzIHRoYXQgd2hlbiB1c2luZyB0aGUgc3VmZml4LCDigJzigKYgdGhlIGNoYW5nZSBj b250cm9sbGVyIGhhcyBiZWVuIGNoYW5nZWQgdG8gYmUgdGhlIFdvcmxkIFdpZGUgV2ViIENvbnNv cnRpdW0gKFczQynigJ0uIEFuIGFsdGVybmF0aXZlIGNvbmNsdXNpb24gd291bGQgYmUgdGhlIGNo YW5nZSBjb250cm9sbGVyIHNob3VsZCBiZSB0aGUgSUVTRyBnaXZlbiB0aGlzIGlzIGEgU3RhbmRh cmRzIFRyYWNrIGRvY3VtZW50LiBUaGUgbGF0dGVyIHNlZW1zIG1vcmUgbG9naWNhbCB0byBtZSBn aXZlbiB0aGUgVzNDIGhhcyBoYWQgbm8gcm9sZSBpbiB0aGlzIHNwZWNpZmljYXRpb24sIGJ1dCBJ IGFtIG5vdCBzdXJlIHdoYXQgdGhlIHB1cnBvc2Ugb2YgdGhlIGxhbmd1YWdlIGluIFJGQyA3MzAz IGlzIGludGVuZGluZyB0byBzZXJ2ZS4gSG9wZWZ1bGx5IHRoZXJlIGlzIHNvbWVvbmUgd2UgY2Fu IGNvbnN1bHQgd2l0aCB0byBzZWVrIGNsYXJpZmljYXRpb24gb24gdGhpcyBpdGVtLCBidXQgdGhh dCBpcyB0aGUgaXNzdWUgYXQgaGFuZC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KU2VlbXMgbG9naWNhbC4gQnV0IEknbSBubyBleHBl cnQgb24gUkZDNzMwMzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bU0FIXSBNeSB0YWtlOiB3ZSBzaG91bGQg dXNlIOKAnElFU0figJ0gZm9yIGFuIElFVEYgc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDQuMiBvZiBSRkMgNzMwMyBub3Rl cyB0aGF0IOKAnFRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBmb3Igc3BlY2lmaWMgJyYjNDM7eG1s JyBtZWRpYSB0eXBlcyBpcyBkZXNjcmliZWQgaW4gW1JGQzY4MzhdLiZuYnNwOyBOZXcgWE1MLWJh c2VkIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9ucyBpbiB0aGUgSUVURiBtdXN0DQogZm9sbG93IHRo ZXNlIGd1aWRlbGluZXPigJ0uIFNlY3Rpb24gNC43IG9mIDY4Mzggc2F5cyDigJxUaGVyZSBhcmUg YSBudW1iZXIgb2YgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgc3BlY2lmaWMgdG8gdGhlIHJlZ2lz dHJhdGlvbiBvZiBYTUwgbWVkaWEgdHlwZXMuJm5ic3A7IFRoZXNlIHJlcXVpcmVtZW50cyBhcmUg c3BlY2lmaWVkIGluIFtSRkMzMDIzXeKAnS4gVW5mb3J0dW5hdGVseSwgMzAyMyB3YXMgb2Jzb2xl dGVkIGJ5IDczMDMsIGFuZCB3ZSBoYXZlIGEgY2lyY3VsYXINCiBzZXQgb2YgcmVmZXJlbmNlcyBh bmQgd2XigJlyZSBiYWNrIHRvIDczMDMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgZG9u4oCZdCBxdWl0ZSB1bmRlcnN0YW5kIHdoYXQg4oCcSW4gYWRkaXRpb24gdG8gdGhlIGNo YW5nZXMgZGVzY3JpYmVkIGFib3ZlLCB0aGUgY2hhbmdlIGNvbnRyb2xsZXIgaGFzIGJlZW4gY2hh bmdlZCB0byBiZSB0aGUgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSAoVzNDKeKAnSBhcHBsaWVz IHRvLiBJZiBpdA0KIGFwcGxpZXMgdG8gdGhlIGxhc3QgZmV3IHNlbnRlbmNlcyBvZiB0aGUgcHJl dmlvdXMgcGFyYWdyYXBoLCBpdOKAmXMgdGFsa2luZyBhYm91dCBub24tSUVURiByZWdpc3RyYXRp b25zLiBTbyBsZXTigJlzIGFzc3VtZSB0aGF0IGl0IGFwcGxpZXMgdG8gbm9uLUlFVEYgcmVnaXN0 cmF0aW9ucyBhbmQgbGV04oCZcyBsb29rIGF0IHRoZSByZWdpc3RyeSBmb3Igc29tZSByZWNlbnQg 4oCcJiM0Mzt4bWzigJ0gZXhhbXBsZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PmF0b21jYXQmIzQzO3htbCAoUkZDIDUwMjMpOiBJRVNHPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hdG9tZGVsZXRl ZCYjNDM7eG1sIChSRkMgNjcyMSk6IElFU0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmF1dGgtcG9saWN5JiM0Mzt4 bWwgKFJGQyA0NzQ1KTogSUVTRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YXBwbGljYXRpb24vbG9hZC1jb250cm9s JiM0Mzt4bWwgKFJGQyA3MjAwKTogSUVTRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cmZjJiM0Mzt4bWwgKFJGQyBU QkQpOiBSRkMgRWRpdG9yICh0aGlzIGlzIHBvc3QtNzMwMyB3aXRoIGEgbm9uLVczQyBjaGFuZ2Ug Y29udHJvbGxlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnhtbC1wYXRjaCYjNDM7eG1sIChSRkMgNzM1MSk6IElF VEYgKHRoaXMgaXMgcG9zdC03MzAzIHdpdGggYSBub24tVzNDIGNoYW5nZSBjb250cm9sbGVyKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHdlIGhhdmUgYSBjb25zaXN0 ZW50IHBhdHRlcm4uIFVzZSDigJxJRVNH4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5TY290dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_831693C2CDA2E849A7D7A712B24E257F4A1252EEBRN1WNEXMBX01vc_-- From nobody Tue Jan 5 04:50:08 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BCA1A0126 for ; Tue, 5 Jan 2016 04:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_12=0.6] 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 0BZ1m8_cpEHV for ; Tue, 5 Jan 2016 04:50:05 -0800 (PST) Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F1C1A00F4 for ; Tue, 5 Jan 2016 04:50:04 -0800 (PST) Received: by mail-qg0-x261.google.com with SMTP id o11so31361363qge.3 for ; Tue, 05 Jan 2016 04:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=mAx7ZhglvYHLF68W1el5cgYR8AbYL/MQFCLkadGh6Zo=; b=Ne2/mR6Xtmt6HXWVaiYuUEuXgOZun+rQM5niF5vhzEBXwEQBapERJzx1uBuGvrU4mV sMjF5MSMXJWqRt0WIlJCZCAtzj5eewtfh+JIUPEjcV7h7uQtKjewyLMrAdZHP04FJ4Fi 0vK+5LWTpm5wqXDgu0k6Q21WrBVewhQ+vl7kyWqW+Z4h6/0LI9yj1qfU6wFDL9M8IRc/ gNp0/hA+Qv4cf6r7aCVC2yhc0Ja7yBwQGki87DCq8nor+q5k1/AUq8TirqBlEHvSoMNm Cb6VMyu/FE5oGbrOo7YqGVPvtvCjkUz7KH2eSCOwByLuyESfmV87DOH0c86heDaJlqnk C6TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=mAx7ZhglvYHLF68W1el5cgYR8AbYL/MQFCLkadGh6Zo=; b=eul081DF6xnAIpHmtGHNHagpxKdC5+CVe3p1eGLpJhGAXJWkCYlDQ+2ThXSHCoC4nC vbDt6IxdmaKszr5NYUnciMq7gu7mchhIfS0fCk72UiYyIP2PFKHwXYt2yM0m81Gwu1QK Yr0Tgew0qwpy6AlZ7FI/ae8HXX45gFmjzfQ9y4LP7McDFhQuFxDZUlaICYe/hl1sHtzR z73wxpsTNOkwdiYUd6drG4HGm9f/RJxnCBVHyQ6kxN9oHMthEpZJxZC7GVxCKpSQpb73 3Blf1p7MqTxQ4IAGcRi8bNsAdzbBiCrnUhYYVsGS3dfsZRX67DXjs/wFppPURcD4vaYX kw6Q== X-Gm-Message-State: ALoCoQlc3tNmMaCCw7lKlbZygPxOaR24qfldUe8Fkqvkhpg3QNogyPnZTktAQZbbk2v+zucS8KAdRJ1W/jespW/fU0eiydVX5izrdYY/po7xQKNW5HXzp8c= X-Received: by 10.55.80.131 with SMTP id e125mr46489597qkb.62.1451998204082; Tue, 05 Jan 2016 04:50:04 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id p25sm1032766qkl.13.2016.01.05.04.50.03 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 05 Jan 2016 04:50:04 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u05Co3VE008091 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Jan 2016 07:50:03 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 5 Jan 2016 07:50:03 -0500 From: "Hollenbeck, Scott" To: "lager WG (lager@ietf.org)" Thread-Topic: IETF 95 - Working Group/BOF/IRTF Scheduling Thread-Index: AQHRRzRaPKhturWwM0qSeROIrDdkGJ7s3+7g Date: Tue, 5 Jan 2016 12:50:02 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A1253A1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20160104211027.31672.13192.idtracker@ietfa.amsl.com> In-Reply-To: <20160104211027.31672.13192.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Lager] FW: IETF 95 - Working Group/BOF/IRTF Scheduling X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 12:50:07 -0000 SSBkb24ndCB0aGluayB3ZSdyZSBnb2luZyB0byBuZWVkIHRvIG1lZXQgYXQgSUVURiA5NSwgc28g YXMgb2YgcmlnaHQgbm93IEknbSBub3QgcGxhbm5pbmcgdG8gc3VibWl0IGEgbWVldGluZyByZXF1 ZXN0LiBJZiBhbnlvbmUgdGhpbmtzIGRpZmZlcmVudGx5IHBsZWFzZSBzYXkgc28sIGFuZCBwbGVh c2UgYmUgc3VyZSB0byBleHBsYWluIHdoYXQgd2lsbCBzdGlsbCBiZSB1bmRvbmUgYW5kIHdvcnRo eSBvZiBwcmVjaW91cyBtZWV0aW5nIHRpbWUgY29tZSBBcHJpbC4NCg0KU2NvdHQNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdHQ2hhaXJzIFttYWlsdG86d2djaGFpcnMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFVEYgQWdlbmRhDQpTZW50OiBNb25kYXksIEph bnVhcnkgMDQsIDIwMTYgNDoxMCBQTQ0KVG86IFdvcmtpbmcgR3JvdXAgQ2hhaXJzDQpTdWJqZWN0 OiBJRVRGIDk1IC0gV29ya2luZyBHcm91cC9CT0YvSVJURiBTY2hlZHVsaW5nDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpJRVRGIDk1IOKAkyBCdWVub3MgQWlyZXMsIEFyZ2VudGluYQ0KTWVldGluZyBEYXRlczogQXBy aWwgMy04LCAyMDE2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpXZSBhcmUgYWNjZXB0aW5nIHNjaGVkdWxpbmcgcmVx dWVzdHMgZm9yIGFsbCBXb3JraW5nIEdyb3VwcywgQk9GcywgYW5kIFJlc2VhcmNoIEdyb3VwcyBz dGFydGluZyB0b2RheS4gIA0KDQpUaGUgbWlsZXN0b25lcyBhbmQgZGVhZGxpbmVzIGZvciBzY2hl ZHVsaW5nLXJlbGF0ZWQgYWN0aXZpdGllcyBhcmUgYXMgZm9sbG93czoNCkN1dC1vZmYgZGF0ZXMg YXJlIHN1YmplY3QgdG8gY2hhbmdlLg0KDQrigKIJMjAxNi0wMS0wNCAoTW9uZGF5KTogV29ya2lu ZyBHcm91cCBhbmQgQk9GIHNjaGVkdWxpbmcgYmVnaW5zLiBUbyByZXF1ZXN0IGEgV29ya2luZyBH cm91cCBzZXNzaW9uLCB1c2UgdGhlIElFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVlc3QgVG9vbC4N CuKAogkyMDE2LTAyLTE5IChGcmlkYXkpOiBDdXQtb2ZmIGRhdGUgZm9yIHJlcXVlc3RzIHRvIHNj aGVkdWxlIFdvcmtpbmcgR3JvdXAgbWVldGluZ3MgYXQgVVRDIDIzOjU5LiBUbyByZXF1ZXN0IGEg V29ya2luZyBHcm91cCBzZXNzaW9uLCB1c2UgdGhlIElFVEYgTWVldGluZyBTZXNzaW9uIFJlcXVl c3QgVG9vbC4NCuKAogkyMDE2LTAyLTE5IChGcmlkYXkpOiBDdXQtb2ZmIGRhdGUgZm9yIEJPRiBw cm9wb3NhbCByZXF1ZXN0cyB0byBBcmVhIERpcmVjdG9ycyBhdCBVVEMgMjM6NTkuIFRvIHJlcXVl c3QgYSBCT0YsIHBsZWFzZSBzZWUgaW5zdHJ1Y3Rpb25zIG9uIFJlcXVlc3RpbmcgYSBCT0YuDQri gKIJMjAxNi0wMi0yNiAoRnJpZGF5KTogQ3V0LW9mZiBkYXRlIGZvciBBcmVhIERpcmVjdG9ycyB0 byBhcHByb3ZlIEJPRnMgYXQgVVRDIDIzOjU5Lg0K4oCiCTIwMTYtMDMtMDQgKEZyaWRheSk6IFBy ZWxpbWluYXJ5IGFnZW5kYSBwdWJsaXNoZWQgZm9yIGNvbW1lbnQuDQrigKIJMjAxNi0wMy0wOSAo V2VkbmVzZGF5KTogQ3V0LW9mZiBkYXRlIGZvciByZXF1ZXN0cyB0byByZXNjaGVkdWxlIFdvcmtp bmcgR3JvdXAgYW5kIEJPRiBtZWV0aW5ncyBVVEMgMjM6NTkuDQrigKIJMjAxNi0wMy0xMSAoRnJp ZGF5KTogRmluYWwgYWdlbmRhIHRvIGJlIHB1Ymxpc2hlZC4NCuKAogkyMDE2LTAzLTIxIChNb25k YXkpOiBEcmFmdCBXb3JraW5nIEdyb3VwIGFnZW5kYXMgZHVlIGJ5IFVUQyAyMzo1OSwgdXBsb2Fk IHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29sLg0K4oCiCTIwMTYt MDMtMjggKE1vbmRheSk6IFJldmlzZWQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSBVVEMg MjM6NTksIHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9v bC4NCuKAogkyMDE2LTA0LTI5IChGcmlkYXkpOiBQcm9jZWVkaW5ncyBzdWJtaXNzaW9uIGN1dG9m ZiBkYXRlIGJ5IFVUQyAyMzo1OSwgdXBsb2FkIHVzaW5nIElFVEYgTWVldGluZyBNYXRlcmlhbHMg TWFuYWdlbWVudCBUb29sLg0K4oCiCTIwMTYtMDUtMjcgKE1vbmRheSk6IFByb2NlZWRpbmdzIHN1 Ym1pc3Npb24gY29ycmVjdGlvbnMgY3V0b2ZmIGRhdGUgYnkgVVRDIDIzOjU5LCB1cGxvYWQgdXNp bmcgSUVURiBNZWV0aW5nIE1hdGVyaWFscyBNYW5hZ2VtZW50IFRvb2wuDQoNCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpD b21wcmVoZW5zaXZlIGluZm9ybWF0aW9uIG9uIHJlcXVlc3RpbmcgbWVldGluZyBzZXNzaW9ucyBp cyBiZWxvdzoNCg0KMS4gUmVxdWVzdHMgdG8gc2NoZWR1bGUgV29ya2luZyBHcm91cCBzZXNzaW9u cyBzaG91bGQgYmUgc3VibWl0dGVkIHVzaW5nIHRoZSAiSUVURiBNZWV0aW5nIFNlc3Npb24gUmVx dWVzdCBUb29sLCIgYSBXZWItYmFzZWQgdG9vbCBmb3Igc3VibWl0dGluZyBhbGwgb2YgdGhlIGlu Zm9ybWF0aW9uIHJlcXVpcmVkIGJ5IHRoZSBTZWNyZXRhcmlhdCB0byBzY2hlZHVsZSB5b3VyIHNl c3Npb25zLiAgVGhlIFVSTCBmb3IgdGhlIHRvb2wgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL3NlY3Ivc3JlcS8NCg0KSW5zdHJ1Y3Rpb25zIGZvciB1c2luZyB0aGUgdG9vbCBhcmUg YXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy93Zy9yZXF1ZXN0LXRvb2wtaW5zdHJ1 Y3Rpb25zLmh0bWwNCg0KSWYgeW91IHJlcXVpcmUgYW4gYWNjb3VudCBvbiB0aGlzIHRvb2wsIG9y IGFzc2lzdGFuY2UgaW4gdXNpbmcgaXQsIHRoZW4gcGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRvIGll dGYtYWN0aW9uQGlldGYub3JnLiAgSWYgeW91IGFyZSB1bmFibGUgdG8gdXNlIHRoZSB0b29sLCB0 aGVuIHlvdSBtYXkgc2VuZCB5b3VyIHJlcXVlc3QgdmlhIGUtbWFpbCB0byBhZ2VuZGFAaWV0Zi5v cmcsIHdpdGggYSBjb3B5IHRvIHRoZSBhcHByb3ByaWF0ZSBBcmVhIERpcmVjdG9yKHMpLg0KDQpS ZXF1ZXN0cyB0byBzY2hlZHVsZSBCT0Ygc2Vzc2lvbnMgbXVzdCBiZSBzZW50IHRvIGFnZW5kYUBp ZXRmLm9yZyB3aXRoIGEgY29weSB0byB0aGUgYXBwcm9wcmlhdGUgQXJlYSBEaXJlY3RvcihzKS4N Cg0KV2hlbiBzdWJtaXR0aW5nIGEgV29ya2luZyBHcm91cCBvciBCT0Ygc2Vzc2lvbiByZXF1ZXN0 IGJ5IGUtbWFpbCwgcGxlYXNlIGluY2x1ZGUgdGhlIFdvcmtpbmcgR3JvdXAgb3IgQk9GIGFjcm9u eW0gaW4gdGhlIFN1YmplY3QgbGluZS4NCg0KMi4gQk9GcyB3aWxsIE5PVCBiZSBzY2hlZHVsZWQg dW5sZXNzIHRoZSBBcmVhIERpcmVjdG9yIGFwcHJvdmVzIHRoZSBCT0YuIFRoZSBwcm9wb25lbnRz IGJlaGluZCBhIEJPRiBuZWVkIHRvIGNvbnRhY3QgYSByZWxldmFudCBBcmVhIERpcmVjdG9yLCBw cmVmZXJhYmx5IHdlbGwgaW4gYWR2YW5jZSBvZiB0aGUgQk9GIGFwcHJvdmFsIGRlYWRsaW5lIGRh dGUuIFRoZSBBRCBuZWVkcyB0byBoYXZlIHRoZSBmdWxsIG5hbWUgb2YgdGhlIEJPRiwgaXRzIGFj cm9ueW0sIHN1Z2dlc3RlZCBuYW1lcyBvZiBjaGFpcnMsIGFuIGFnZW5kYSwgZnVsbCBkZXNjcmlw dGlvbiBvZiB0aGUgQk9GIGFuZCB0aGUgaW5mb3JtYXRpb24gY292ZXJlZCBpbiBpdGVtIDQuIFBs ZWFzZSByZWFkIFJGQyA1NDM0IGZvciBpbnN0cnVjdGlvbnMgb24gaG93IHRvIGRyaXZlIGEgc3Vj Y2Vzc2Z1bCBCT0YgZWZmb3J0LiANCg0KMy4gQSBXb3JraW5nIEdyb3VwIG1heSByZXF1ZXN0IGVp dGhlciBvbmUgb3IgdHdvIHNlc3Npb25zLiAgSWYgeW91ciBXb3JraW5nIEdyb3VwIHJlcXVpcmVz IG1vcmUgdGhhbiB0d28gc2Vzc2lvbnMsIHRoZW4geW91ciByZXF1ZXN0IG11c3QgYmUgYXBwcm92 ZWQgYnkgYW4gQXJlYSBEaXJlY3Rvci4gIEFkZGl0aW9uYWwgc2Vzc2lvbnMgd2lsbCBiZSBhc3Np Z25lZCwgYmFzZWQgb24gYXZhaWxhYmlsaXR5LCBhZnRlciBXZWRuZXNkYXksIE1hcmNoIDl0aCwg MjAxNiwgdGhlIGN1dC1vZmYgZGF0ZSBmb3IgcmVxdWVzdHMgdG8gcmVzY2hlZHVsZSBhIHNlc3Np b24uDQoNCjQuIFlvdSBNVVNUIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiBiZWZv cmUgYSBXb3JraW5nIEdyb3VwIG9yIEJPRiBzZXNzaW9uIHdpbGwgYmUgc2NoZWR1bGVkOg0KDQph LiBXb3JraW5nIEdyb3VwIG9yIEJPRiBmdWxsIG5hbWUgd2l0aCBhY3JvbnltIGluIGJyYWNrZXRz OiANCmIuIEFSRUEgdW5kZXIgd2hpY2ggV29ya2luZyBHcm91cCBvciBCT0YgYXBwZWFyczoNCmMu IENPTkZMSUNUUyB5b3Ugd2lzaCB0byBhdm9pZCwgcGxlYXNlIGJlIGFzIHNwZWNpZmljIGFzIHBv c3NpYmxlOg0KZC4gRXhwZWN0ZWQgQXR0ZW5kYW5jZToNCmUuIFNwZWNpYWwgcmVxdWVzdHM6DQpm LiBOdW1iZXIgb2Ygc2Vzc2lvbnM6DQpnLiBMZW5ndGggb2Ygc2Vzc2lvbjogMSBob3VyLCAxLjUg aG91cnMsIDIgaG91cnMsIDIuNSBob3Vycw0KICAgICAgIAkJDQpGb3IgbW9yZSBpbmZvcm1hdGlv biBvbiBzY2hlZHVsaW5nIFdvcmtpbmcgR3JvdXAgYW5kIEJPRiBzZXNzaW9ucywgcGxlYXNlIHJl ZmVyIHRvIFJGQyAyNDE4IChCQ1AgMjUpLCAiSUVURiBXb3JraW5nIEdyb3VwIEd1aWRlbGluZXMg YW5kIFByb2NlZHVyZXMiIChodHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmMyNDE4LnR4dCkuDQoN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KDQpTdWJtaXR0aW5nIFNlc3Npb24gQWdlbmRhcw0KDQoNClBsZWFzZSBzdWJtaXQg dGhlIGFnZW5kYXMgZm9yIHlvdXIgV29ya2luZyBHcm91cCBzZXNzaW9ucyBhcyBlYXJseSBhcyBw b3NzaWJsZSB1c2luZyB0aGUgIklFVEYgTWVldGluZyBNYXRlcmlhbHMgTWFuYWdlbWVudCBUb29s LCIgYSBXZWItYmFzZWQgdG9vbCBmb3IgbWFraW5nIHlvdXIgbWVldGluZyBhZ2VuZGEsIG1pbnV0 ZXMsIGFuZCBwcmVzZW50YXRpb24gc2xpZGVzIGF2YWlsYWJsZSB0byB0aGUgY29tbXVuaXR5IGJl Zm9yZSwgZHVyaW5nLCBhbmQgYWZ0ZXIgYW4gSUVURiBtZWV0aW5nLiAgSWYgeW91IGFyZSBhIEJP RiBjaGFpciwgdGhlbiB5b3UgbWF5IHVzZSB0aGUgdG9vbCB0byBzdWJtaXQgYSByZXZpc2VkIGFn ZW5kYSBhcyB3ZWxsIGFzIG90aGVyIG1hdGVyaWFscyBmb3IgeW91ciBCT0Ygb25jZSB0aGUgQk9G IGhhcyBiZWVuIGFwcHJvdmVkLg0KDQpUaGUgVVJMIGZvciB0aGUgdG9vbCBpczoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvc2Vjci9wcm9jZWVkaW5ncy8NCg0KQWRkaXRpb25hbCBpbmZv cm1hdGlvbiBhYm91dCB0aGlzIHRvb2wgaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRm Lm9yZy93Zy9tZWV0aW5nLW1hdGVyaWFscy5odG1sDQoNCkFnZW5kYXMgc3VibWl0dGVkIHZpYSB0 aGUgdG9vbCB3aWxsIGJlIGF2YWlsYWJsZSB0byB0aGUgcHVibGljIG9uIHRoZSAiSUVURiBNZWV0 aW5nIE1hdGVyaWFscyIgd2VicGFnZSBhcyBzb29uIGFzIHRoZXkgYXJlIHN1Ym1pdHRlZC4NCg0K VGhlIFVSTCBmb3IgdGhlICJJRVRGIDk1IE1lZXRpbmcgTWF0ZXJpYWxzIiBXZWIgcGFnZSBpczoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85NS9tYXRlcmlhbHMuaHRtbA0K DQpJZiB5b3UgYXJlIGEgV29ya2luZyBHcm91cCBjaGFpciwgdGhlbiB5b3UgYWxyZWFkeSBoYXZl IGFjY291bnRzIG9uIHRoZSAiSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sIiBhbmQg dGhlICJJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4iICBUaGUgc2FtZSBV c2VyIElEIGFuZCBwYXNzd29yZCB3aWxsIHdvcmsgZm9yIGJvdGggdG9vbHMuICBJZiB5b3UgYXJl IGEgQk9GIGNoYWlyIHdobyBpcyBub3QgYWxzbyBhIFdvcmtpbmcgR3JvdXAgY2hhaXIsIHRoZW4g eW91IHdpbGwgYmUgZ2l2ZW4gYW4gYWNjb3VudCBvbiB0aGUgIklFVEYgTWVldGluZyBNYXRlcmlh bHMgTWFuYWdlbWVudCBUb29sIiB3aGVuIHlvdXIgQk9GIGhhcyBiZWVuIGFwcHJvdmVkLiAgSWYg eW91IHJlcXVpcmUgYXNzaXN0YW5jZSBpbiB1c2luZyBlaXRoZXIgdG9vbCwgb3Igd2lzaCB0byBy ZXBvcnQgYSBidWcsIHRoZW4gcGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRvOiBpZXRmLWFjdGlvbkBp ZXRmLm9yZy4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpGb3IgeW91ciBjb252ZW5pZW5jZSBwbGVhc2UgZmluZCBhIGxp c3Qgb2YgdGhlIElFVEYgQXJlYSBEaXJlY3RvcnMgd2l0aCB0aGVpciBlLW1haWwgYWRkcmVzc2Vz IGJlbG93Og0KDQpJRVRGIENoYWlyIA0KSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+ DQoNCkFwcGxpY2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWEgKGFydCkNCkJlbiBDYW1wYmVsbCA8 YmVuQG5vc3RydW0uY29tPg0KQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+DQpCYXJy eSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQoNCkludGVybmV0IEFyZWEgKGludCkg DQpCcmlhbiBIYWJlcm1hbiA8YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0PiANClRlcnJ5IE1hbmRl cnNvbiA8dGVycnkubWFuZGVyc29uQGljYW5uLm9yZz4NCg0KT3BlcmF0aW9ucyAmIE1hbmFnZW1l bnQgQXJlYSAob3BzKSANCkJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiANCkpvZWwg SmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT4NCg0KUm91dGluZyBBcmVhIChydGcpIA0KQWxpYSBB dGxhcyA8YWthdGxhcytpZXNnQGdtYWlsLmNvbT4NCkRlYm9yYWggQnJ1bmdhcmQgPGRicnVuZ2Fy ZEBhdHQuY29tPg0KQWx2YXJvIFJldGFuYSA8YXJldGFuYUBjaXNjby5jb20+DQoNClNlY3VyaXR5 IEFyZWEgKHNlYykgDQpTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+ DQpLYXRobGVlbiBNb3JpYXJ0eSA8S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+ICAN Cg0KVHJhbnNwb3J0IEFyZWEgKHRzdikgDQpTcGVuY2VyIERhd2tpbnMgIDxzcGVuY2VyZGF3a2lu cy5pZXRmQGdtYWlsLmNvbT4NCk1hcnRpbiBTdGllbWVybGluZyA8bWFydGluLnN0aWVtZXJsaW5n QG5lY2xhYi5ldT4gDQoNCiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KSUVURiA5NCBNZWV0aW5nIEF0dGVuZGFuY2UgTnVtYmVycw0K DQo2bG8g4oCTIDgyDQo2bWFuIC0gMTAyDQo2dGlzY2gg4oCTIDQyDQphY2UgLSA3Nw0KYWNtZSAt IDY3DQphbmltYSDigJMgOTENCmFuaW1hICgybmQgc2Vzc2lvbikgLSA1Mw0KYXZ0Y29yZSAtIDI0 DQphdnRleHQg4oCTIDMyDQpiZXNzIOKAkyA2OA0KYmZkIC0gNTgNCmJpZXIgLSA1Nw0KYm13ZyDi gJMgMzENCmNjYW1wIC0gNTINCmNkbmkg4oCTIDMyDQpjZnJnIC0gOTYNCmNsdWUg4oCTIDIyDQpj b3JlIC0gNzUNCmNvcmUgKDJuZCBzZXNzaW9uKSDigJMgNjANCmNvc2UgLSA1MA0KZGJvdW5kIOKA kyA0Mg0KZGV0bmV0IChCb0YpIC0gODENCmRoYyDigJMgNDgNCmRpbWUgLSAxOQ0KZGlzcGF0Y2gg LSA3MA0KZG1tIOKAkyAzMg0KZG5zb3AgLSAxMDkNCmRuc3NkIOKAkyA5NQ0KZG90cyAtIDExNg0K ZHByaXZlIOKAkyAxMzgNCmR0biDigJMgNDENCmVjcml0IC0gMjYNCmVwcGV4dCDigJMgMzkNCmdy b3cgLSA0Mw0KaG9tZW5ldCDigJMgMTE3DQpob3BzcmcgKFBSRykg4oCTIDE2Nw0KaHJwYyAtIDk3 DQpodHRwYmlzIOKAkyAxMTQNCmkybnNmIC0gODQNCmkycnMg4oCTIDY5DQppY2UgLSA1NQ0KaWNu cmcgKFJHKSAtIDY5DQppZHIg4oCTIDgzDQppbnRhcmVhIChBRykgLSA5MQ0KaXBwbSDigJMgNjIN CmlydGZvcGVuIC0gMTc0DQppc2lzIOKAkyAzMw0KaXNzIChCb0YpIC0gOTUNCmwzc20g4oCTIDUz DQpsYWdlciAtIDM2DQpsaW1lIC0gNDcNCmxpc3AgLSAzNg0KbG1hcCDigJMgNDUNCm1ib25lZCAt IDE5DQptaWYgLSA1NQ0KbWlsZSAtIDQzDQptbXVzaWMgLSA0Ng0KbW9kZXJuIC0gMjQNCm1wbHMg LSA1Ng0KbXBscyAoMm5kIHNlc3Npb24pIOKAkyA2NA0KbXB0Y3AgLSA2Nw0KbmV0Y29uZiAtIDY5 DQpuZXRtb2Qg4oCTIDc4DQpuZXRtb2QgKDJuZCBzZXNzaW9uKSDigJMgODQNCm5ldHZjIOKAkyA2 Mw0KbmV0dmMgKDJuZCBzZXNzaW9uKSAtIDQ5DQpuZnZyZyDigJMgMTE4DQpubWxyZyAtIDExMg0K bm1yZyAtIDU5DQpudHAgKGNvbWJpbmVkIHdpdGggdGljdG9jKSAtIDI4DQpudm8zIOKAkyAxMTEN Cm9hdXRoIOKAkyA2OQ0Kb3BlbnBncCDigJMgMjcNCm9wc2F3Zy9vcHNhcmVhIOKAkyA0OA0Kb3Nw ZiDigJMgNDcNCnBhbHMg4oCTIDMzDQpwYXlsb2FkIC0gNDINCnBjZSDigJMgNzENCnBlcmMgLSAz NQ0KcGltIC0gMjgNCnJhZGV4dCAtIDE0DQpybWNhdCDigJMgNTUNCnJtY2F0ICgybmQgc2Vzc2lv bikgLSAzMw0Kcm9sbCAtIDMyDQpydGN3ZWIgLSA3NQ0KcnRjd2ViICgybmQgc2Vzc2lvbikgLSA4 MA0KcnRnYXJlYSAtIDk1DQpydGd3ZyDigJMgOTkNCnJ0Z3dnICgybmQgc2Vzc2lvbikgLSA3Mw0K c2FhZyAtIDE4OA0Kc2FjbSAtIDQ4DQpzYWNtICgybmQgc2Vzc2lvbikgLSAzNw0Kc2RucmcgKFJH KSDigJMgMTQ1DQpzZmMgLSAxMjMNCnNpZHIg4oCTIDYxDQpzaWRyICgybmQgc2Vzc2lvbikgLSA0 Nw0Kc29mdHdpcmUg4oCTIDMyDQpzcHJpbmcg4oCTIDk0DQpzdGlyIOKAkyAzNg0Kc3VwYSAoQm9G KSDigJMgNzcNCnQydHJnIChQUkcpIOKAkyBkaWQgbm90IHJldHVybg0KdGFwcyAtIDU0DQp0Y3Bp bmMgLSAxMTENCnRjcG0g4oCTIDgwDQp0ZWFzIC0gNzYNCnRpY3RvYyAoY29tYmluZWQgd2l0aCBu dHApIC0gMjgNCnRscyDigJMgMTAwDQp0bHMgKDJuZCBzZXNzaW9uKSAtIDEwOA0KdG9rYmluZCAt IDQ4DQp0cmFtIOKAkyAzOA0KdHJhbnMgLSA0Mw0KdHJpbGwg4oCTIDI2DQp0cmlsbCAoMm5kIHNl c3Npb24pIC0gOQ0KdHN2d2cgLSA5OQ0KdHN2d2cgKDJuZCBzZXNzaW9uKSAtIDkzDQp2Nm9wcyAt IDgyDQp2Nm9wcyDigJMgNzUNCndlYnB1c2gg4oCTIDc1DQp4cmJsb2NrIC0gMTANCg0K From nobody Tue Jan 5 07:07:49 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037121A87A4 for ; Tue, 5 Jan 2016 07:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pA6GYb2gjSvf for ; Tue, 5 Jan 2016 07:07:46 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9751A87A2 for ; Tue, 5 Jan 2016 07:07:46 -0800 (PST) Received: from localhost ([::1]:39706 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aGTD5-0000Pd-B9; Tue, 05 Jan 2016 07:07:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "lager issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com, wil@cloudregistry.net X-Trac-Project: lager Date: Tue, 05 Jan 2016 15:07:43 -0000 X-URL: https://tools.ietf.org/lager/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lager/trac/ticket/29#comment:3 Message-ID: <077.c0267460955144c672e731d865322917@tools.ietf.org> References: <062.fecc66d22b4261614434355b286a48dc@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <062.fecc66d22b4261614434355b286a48dc@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com, wil@cloudregistry.net, lager@ietf.org X-SA-Exim-Mail-From: trac+lager@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-lager-specification@ietf.org Resent-Message-Id: <20160105150746.3E9751A87A2@ietfa.amsl.com> Resent-Date: Tue, 5 Jan 2016 07:07:46 -0800 (PST) Resent-From: trac+lager@tools.ietf.org Archived-At: Cc: lager@ietf.org Subject: Re: [Lager] [lager] #29 (specification): Referencing the Unicode Character Database X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 15:07:47 -0000 #29: Referencing the Unicode Character Database Comment (by asmusf@ix.netcom.com): I've uploaded suggested text to the github. This text includes mention of UAX44 where appropriate, and also includes a tighter specification of the intended values of the "property" attribute. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-lager- wil@cloudregistry.net | specification@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: specification | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: lager From nobody Tue Jan 5 07:11:27 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C4F1A87AC for ; Tue, 5 Jan 2016 07:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 EgHuKYoLS7VM for ; Tue, 5 Jan 2016 07:11:25 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7401A87AB for ; Tue, 5 Jan 2016 07:11:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=O1ikhHT6gfeXXZYk2/wu6f2QxyhusuHRZwBBnfkqYSr2BxXNwExiSX/BXKCeEImz; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [75.165.47.225] (helo=[192.168.0.4]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aGTGU-0000ac-FP for lager@ietf.org; Tue, 05 Jan 2016 10:11:14 -0500 To: lager@ietf.org References: <831693C2CDA2E849A7D7A712B24E257F4A123C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <7E5B4D89-249D-43FE-A0DF-D9EB42DB3EFF@icann.org> From: Asmus Freytag Message-ID: <568BDD12.2010409@ix.netcom.com> Date: Tue, 5 Jan 2016 07:11:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <7E5B4D89-249D-43FE-A0DF-D9EB42DB3EFF@icann.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 464f085de979d7246f36dc87813833b2857e9f10d2205ddcc1c0ff7717119263a07531f1588008e8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.165.47.225 Archived-At: Subject: Re: [Lager] Remaining Work Items X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 15:11:26 -0000 On 1/4/2016 2:29 PM, Kim Davies wrote: > Hi Scott, Hi all, > >> We have three issues open in the datatracker: >> >> https://trac.tools.ietf.org/wg/lager/trac/report/1 >> >> These all look to be relatively simple to address, so let's get them done ASAP. Document authors, is there anything holding you up? > > > For ticket 29, Asmus has proposed changing some references to the Unicode specification to remove multiple different ways Unicode properties could be expressed, to have a single canonical long- and short-form way of representing them. I think this is a good idea and Wil seems to have concurred. It needs some new text to be put in the next edition. Text pushed to git-hub. As far as I am concerned, this is done, except for review by Kim and others. > For ticket 30, Asmus posted about this to the list just prior to the holiday break. I am not sure I’ve wrapped my head around the pros and cons of adding “valid” as an additional core disposition. I think it would be good to have some discussion about this on the list before making a call on it. > > I still believe this needs to be done, but I am waiting on discussion on the list. A./ From nobody Tue Jan 12 22:48:08 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099D81A6FB7 for ; Tue, 12 Jan 2016 22:48:06 -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, RP_MATCHES_RCVD=-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 CuDTSR7Ve7hR for ; Tue, 12 Jan 2016 22:48:04 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7A71A6F58 for ; Tue, 12 Jan 2016 22:48:04 -0800 (PST) Received: from localhost ([::1]:43775 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aJFDv-0000dX-Fm; Tue, 12 Jan 2016 22:48:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "lager issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com X-Trac-Project: lager Date: Wed, 13 Jan 2016 06:48:03 -0000 X-URL: https://tools.ietf.org/lager/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lager/trac/ticket/31 Message-ID: <061.3a5afe4e1901d5f174aaae42cc7ff31d@tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com, lager@ietf.org X-SA-Exim-Mail-From: trac+lager@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-lager-specification@ietf.org Resent-Message-Id: <20160113064804.AC7A71A6F58@ietfa.amsl.com> Resent-Date: Tue, 12 Jan 2016 22:48:04 -0800 (PST) Resent-From: trac+lager@tools.ietf.org Archived-At: Cc: lager@ietf.org Subject: [Lager] [lager] #31 (specification): Requested clarifications X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 06:48:06 -0000 #31: Requested clarifications Request received off-list Here are a couple of points you may want to consider next time you review this document: 1. It is not clear what is the default disposition of a code point which is declared without a type. Some text around it would be useful. 2. In many examples, same tag, class name and rule name are used, which makes the reading a bit confusing. It would be useful to make these different either arbitrarily or by suggesting an optional convention, e.g. tpreferred vs. cpreferred, rpreferred to differentiate them. 3. The example rule just before 5.3.5 seems to be missing the line -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-lager- asmusf@ix.netcom.com | specification@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: | Version: specification | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: lager From nobody Tue Jan 12 22:54:06 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A63D1A702A for ; Tue, 12 Jan 2016 22:54:05 -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, RP_MATCHES_RCVD=-0.001] 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 IrpUGZBRIXOk for ; Tue, 12 Jan 2016 22:54:04 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4DE1A701A for ; Tue, 12 Jan 2016 22:54:04 -0800 (PST) Received: from localhost ([::1]:44069 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aJFJj-0002c0-Qo; Tue, 12 Jan 2016 22:54:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "lager issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com X-Trac-Project: lager Date: Wed, 13 Jan 2016 06:54:03 -0000 X-URL: https://tools.ietf.org/lager/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lager/trac/ticket/31#comment:1 Message-ID: <076.cd63803e4afff84a5e2a0055bec877df@tools.ietf.org> References: <061.3a5afe4e1901d5f174aaae42cc7ff31d@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <061.3a5afe4e1901d5f174aaae42cc7ff31d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com, lager@ietf.org X-SA-Exim-Mail-From: trac+lager@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-lager-specification@ietf.org Resent-Message-Id: <20160113065404.1D4DE1A701A@ietfa.amsl.com> Resent-Date: Tue, 12 Jan 2016 22:54:04 -0800 (PST) Resent-From: trac+lager@tools.ietf.org Archived-At: Cc: lager@ietf.org Subject: Re: [Lager] [lager] #31 (specification): Requested clarifications X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 06:54:05 -0000 #31: Requested clarifications Comment (by asmusf@ix.netcom.com): The default disposition was clearly specified as "allocatable" and is derived from a catch-all action (so variant types, present or missing, are ignored). However, as noted in ticket #30 it is unsatisfactory to have the catch-all label assign any disposition that matches a variant type, such as "allocatable". Instead, a better choice is to simply use "valid", indicating that the label passed all constraints on repertoire and did not trigger any actions with more specific dispositions. As a result, I've created draft language that combines the text for item 1 of this ticket and ticket #30 and pushed that up to the github. Item 2 is unclear to me - I would need a more concrete instance. Item 3 is a minor clarification. I rolled that up, together with a few other editorial nits on my list in the same draft. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-lager- asmusf@ix.netcom.com | specification@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: | Version: specification | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: lager From nobody Fri Jan 29 12:08:09 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615E21B32C9 for ; Fri, 29 Jan 2016 12:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 cmXAX9-CjEk2 for ; Fri, 29 Jan 2016 12:08:06 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id BC5D91B32AB for ; Fri, 29 Jan 2016 12:08:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Co2ya+0Um1msBTlX7xwSDUTeg5/JLpkfkksYKuWxlFGYPZNSpQ4ldBGxwrntOJH4; h=Received:Subject:References:To:From:X-Forwarded-Message-Id:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [75.165.41.40] (helo=[192.168.0.4]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aPFKg-0007Cd-Rv for lager@ietf.org; Fri, 29 Jan 2016 15:07:51 -0500 References: <56A83DBC.30309@ix.netcom.com> To: lager@ietf.org From: Asmus Freytag X-Forwarded-Message-Id: <56A83DBC.30309@ix.netcom.com> Message-ID: <56ABC697.5080602@ix.netcom.com> Date: Fri, 29 Jan 2016 12:07:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A83DBC.30309@ix.netcom.com> Content-Type: multipart/alternative; boundary="------------000806070806040701030702" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2857e9f10d2205ddc6708ccd161547b17cf4828e252911c0e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.165.41.40 Archived-At: Subject: [Lager] Fwd: When are sequences valid in an LGR X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:08:08 -0000 This is a multi-part message in MIME format. --------------000806070806040701030702 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All, in pursuing the root zone LGR work, we have stumbled across a small ambiguity in treating sequences of code points. We had resolved how to treat this case before in internal discussion, but apparently not updated the language of the specification. This is the first of three forwarded messages that discusses how to remove the ambiguity from the specification by clarifying the text in section 7. A./ -------- Forwarded Message -------- Subject: When are sequences valid in an LGR Date: Tue, 26 Jan 2016 19:47:08 -0800 From: Asmus Freytag To: Wil Tan , Kim Davies Let's take the case of an LGR as follows: a b ab when=x and a label "ab". How do we evaluate whether this label is valid: We have, in Section 7.1 of XML-LGR the following: In order to test a specific label for membership in the LGR, a consumer of the LGR must iterate through each code point within a given label, and test that each code point *is a member* of the LGR. If any code point is not a member of the LGR, the label shall be deemed as invalid. An individual code point *is deemed a member* of the LGR when it is listed using a "char" element, or is part of a range defined with a "range" element, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied. Alternatively, a code point is*also deemed a membe*r of the LGR when it forms part of a sequence that corresponds to a sequence listed using a "char" element for which the "cp" attribute defines a sequence, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied. Clearly, we have a = member b = member ab: if ab satisfies x, then a and b are members else neither a or b are members Now, what is not fully resolved in this specification is whether in the case of !x, the not-member status of the elements of a,b, overrides their individual statuses as members of the LGR by virtue of being listed by themselves. What is also not resolved is how to determine the variants for this label. a -> c b -> d ab -> ef do we assume (a)(b) and map to (c),(d) (as well as to ad and cb)? or do we assume (ab) and map to (ef), or do we do both? I believe what we want to add is this paragraph: "In determining eligibility, the longest possible sequence of code points is evaluated first. If it satisfies any required context, its constituent code points are deemed members of the LGR and evaluation proceeds with the next code point following the sequence. If the sequence does not satisfy the required context, successively shorter sequences are evaluated, until only a single code point remains, the eligibility of which is determined as described above for an individual code point." For variants, we do need to process all possible partitions of the label: "In determining the permuted set of variant labels, all eligible partitions into sequences must be mapped. A label "ab", that matches a sequence "ab" defined in the LGR as well as the sequence of individual code points "a" and "b" (both defined in the LGR), must be permuted using any defined variant mappings for "ab", "a" and "b"." This language needs to go in the specification of the variants processing. If we don't add this, the coexistence of sequences and individual constituents thereof will be undefined. A./ --------------000806070806040701030702 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit All,

in pursuing the root zone LGR work, we have stumbled across a small ambiguity in treating sequences of code points. We had resolved how to treat this case before in internal discussion, but apparently not updated the language of the specification.

This is the first of three forwarded messages that discusses how to remove the ambiguity from the specification by clarifying the text in section 7.

A./


-------- Forwarded Message --------
Subject: When are sequences valid in an LGR
Date: Tue, 26 Jan 2016 19:47:08 -0800
From: Asmus Freytag <asmusf@ix.netcom.com>
To: Wil Tan <wil@cloudregistry.net>, Kim Davies <kim.davies@icann.org>


Let's take the case of an LGR as follows:

a
b
ab when=x

and a label "ab".

How do we evaluate whether this label is valid:

We have, in Section 7.1 of XML-LGR the following:

In order to test a specific label for membership in the LGR, a consumer of the LGR must iterate through each code point within a given label, and test that each code point is a member of the LGR. If any code point is not a member of the LGR, the label shall be deemed as invalid.

An individual code point is deemed a member of the LGR when it is listed using a "char" element, or is part of a range defined with a "range" element, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied.

Alternatively, a code point is also deemed a member of the LGR when it forms part of a sequence that corresponds to a sequence listed using a "char" element for which the "cp" attribute defines a sequence, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied.

Clearly, we have

a = member
b = member
ab:
     if ab satisfies x, then a and b are members
     else neither a or b are members

Now, what is not fully resolved in this specification is whether in the case of !x, the not-member status of the elements of a,b, overrides their individual statuses as members of the LGR by virtue of being listed by themselves.

What is also not resolved is how to determine the variants for this label.

a -> c
b -> d
ab -> ef

do we assume (a)(b) and map to (c),(d) (as well as to ad and cb)?
or do we assume (ab) and map to (ef),
or do we do both?

I believe what we want to add is this paragraph:

"In determining eligibility, the longest possible sequence of code points is evaluated first. If it satisfies any required context, its constituent code points are deemed members of the LGR and evaluation proceeds with the next code point following the sequence. If the sequence does not satisfy the required context, successively shorter sequences are evaluated, until only a single code point remains, the eligibility of which is determined as described above for an individual code point."

For variants, we do need to process all possible partitions of the label:

"In determining the permuted set of variant labels, all eligible partitions into sequences must be mapped. A label "ab", that matches a sequence "ab" defined in the LGR as well as the sequence of individual code points "a" and "b" (both defined in the LGR), must be permuted using any defined variant mappings for "ab", "a" and "b"."

This language needs to go in the specification of the variants processing. If we don't add this, the coexistence of sequences and individual constituents thereof will be undefined.

A./


--------------000806070806040701030702-- From nobody Fri Jan 29 12:08:29 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0601B32C1 for ; Fri, 29 Jan 2016 12:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 0ogAXvyqn3Me for ; Fri, 29 Jan 2016 12:08:26 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B05181B32AB for ; Fri, 29 Jan 2016 12:08:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=h45O5IdboLvlTAko7CvwGGyzPKEDhqfR8Dyc7UqsChvhjRuT896XvAruUNAN91af; h=Received:Subject:References:To:From:X-Forwarded-Message-Id:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [75.165.41.40] (helo=[192.168.0.4]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aPFLA-0007Cv-0L for lager@ietf.org; Fri, 29 Jan 2016 15:08:20 -0500 References: To: lager@ietf.org From: Asmus Freytag X-Forwarded-Message-Id: Message-ID: <56ABC6B5.6030209@ix.netcom.com> Date: Fri, 29 Jan 2016 12:08:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020802080104070505070203" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2857e9f10d2205ddc0449e07006a60188af053d22b4d9b8cd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.165.41.40 Archived-At: Subject: [Lager] Fwd: Re: When are sequences valid in an LGR X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:08:27 -0000 This is a multi-part message in MIME format. --------------020802080104070505070203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Second forwarded message. -------- Forwarded Message -------- Subject: Re: When are sequences valid in an LGR Date: Wed, 27 Jan 2016 16:35:56 +1100 From: Wil Tan To: Asmus Freytag CC: Kim Davies Hi Asmus, I have run into this ambiguity as well. Please see my comments inline.. On Wed, Jan 27, 2016 at 2:47 PM, Asmus Freytag > wrote: Let's take the case of an LGR as follows: a b ab when=x and a label "ab". How do we evaluate whether this label is valid: We have, in Section 7.1 of XML-LGR the following: In order to test a specific label for membership in the LGR, a consumer of the LGR must iterate through each code point within a given label, and test that each code point *is a member* of the LGR. If any code point is not a member of the LGR, the label shall be deemed as invalid. An individual code point *is deemed a member* of the LGR when it is listed using a "char" element, or is part of a range defined with a "range" element, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied. Alternatively, a code point is*also deemed a membe*r of the LGR when it forms part of a sequence that corresponds to a sequence listed using a "char" element for which the "cp" attribute defines a sequence, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied. Actually, I find that the phrase: "individual code point is deemed a member of the LGR" reads a bit like: "individual code point is deemed part of the repertoire of the LGR" Perhaps it would be better to say: "individual code point /instance/ is deemed a member of the LGR" to make it clear that we are talking about an /instance/ of the code point occurring within the label being tested. Clearly, we have a = member b = member ab: if ab satisfies x, then a and b are members else neither a or b are members Now, what is not fully resolved in this specification is whether in the case of !x, the not-member status of the elements of a,b, overrides their individual statuses as members of the LGR by virtue of being listed by themselves. What is also not resolved is how to determine the variants for this label. a -> c b -> d ab -> ef do we assume (a)(b) and map to (c),(d) (as well as to ad and cb)? or do we assume (ab) and map to (ef), or do we do both? I believe what we want to add is this paragraph: "In determining eligibility, the longest possible sequence of code points is evaluated first. If it satisfies any required context, its constituent code points are deemed members of the LGR and evaluation proceeds with the next code point following the sequence. If the sequence does not satisfy the required context, successively shorter sequences are evaluated, until only a single code point remains, the eligibility of which is determined as described above for an individual code point." This looks good, except "constituent code points" => "constituent code point instances"? For variants, we do need to process all possible partitions of the label: "In determining the permuted set of variant labels, all eligible partitions into sequences must be mapped. A label "ab", that matches a sequence "ab" defined in the LGR as well as the sequence of individual code points "a" and "b" (both defined in the LGR), must be permuted using any defined variant mappings for "ab", "a" and "b"." Looks good too. This language needs to go in the specification of the variants processing. If we don't add this, the coexistence of sequences and individual constituents thereof will be undefined. Agreed that this would tighten up the spec, and avoid interoperability issues. .wil --------------020802080104070505070203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Second forwarded message.

-------- Forwarded Message --------
Subject: Re: When are sequences valid in an LGR
Date: Wed, 27 Jan 2016 16:35:56 +1100
From: Wil Tan <wil@cloudregistry.net>
To: Asmus Freytag <asmusf@ix.netcom.com>
CC: Kim Davies <kim.davies@icann.org>


Hi Asmus,

I have run into this ambiguity as well. Please see my comments inline..

On Wed, Jan 27, 2016 at 2:47 PM, Asmus Freytag <asmusf@ix.netcom.com> wrote:
Let's take the case of an LGR as follows:

a
b
ab when=x

and a label "ab".

How do we evaluate whether this label is valid:

We have, in Section 7.1 of XML-LGR the following:

In order to test a specific label for membership in the LGR, a consumer of the LGR must iterate through each code point within a given label, and test that each code point is a member of the LGR. If any code point is not a member of the LGR, the label shall be deemed as invalid.

An individual code point is deemed a member of the LGR when it is listed using a "char" element, or is part of a range defined with a "range" element, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied.

Alternatively, a code point is also deemed a member of the LGR when it forms part of a sequence that corresponds to a sequence listed using a "char" element for which the "cp" attribute defines a sequence, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied.


Actually, I find that the phrase: 

"individual code point is deemed a member of the LGR" 

reads a bit like:

"individual code point is deemed part of the repertoire of the LGR"

Perhaps it would be better to say:

"individual code point instance is deemed a member of the LGR"

to make it clear that we are talking about an instance of the code point occurring within the label being tested.


Clearly, we have

a = member
b = member
ab:
     if ab satisfies x, then a and b are members
     else neither a or b are members

Now, what is not fully resolved in this specification is whether in the case of !x, the not-member status of the elements of a,b, overrides their individual statuses as members of the LGR by virtue of being listed by themselves.

What is also not resolved is how to determine the variants for this label.

a -> c
b -> d
ab -> ef

do we assume (a)(b) and map to (c),(d) (as well as to ad and cb)?
or do we assume (ab) and map to (ef),
or do we do both?

I believe what we want to add is this paragraph:

"In determining eligibility, the longest possible sequence of code points is evaluated first. If it satisfies any required context, its constituent code points are deemed members of the LGR and evaluation proceeds with the next code point following the sequence. If the sequence does not satisfy the required context, successively shorter sequences are evaluated, until only a single code point remains, the eligibility of which is determined as described above for an individual code point."

This looks good, except "constituent code points" => "constituent code point instances"?


For variants, we do need to process all possible partitions of the label:

"In determining the permuted set of variant labels, all eligible partitions into sequences must be mapped. A label "ab", that matches a sequence "ab" defined in the LGR as well as the sequence of individual code points "a" and "b" (both defined in the LGR), must be permuted using any defined variant mappings for "ab", "a" and "b"."


Looks good too.
 
This language needs to go in the specification of the variants processing. If we don't add this, the coexistence of sequences and individual constituents thereof will be undefined.


Agreed that this would tighten up the spec, and avoid interoperability issues.

.wil 


--------------020802080104070505070203-- From nobody Fri Jan 29 12:10:25 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869F41B32C1 for ; Fri, 29 Jan 2016 12:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8a7AEEI7izW for ; Fri, 29 Jan 2016 12:10:21 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFCC1B32AB for ; Fri, 29 Jan 2016 12:10:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=YrPQAU8nEzD6V1MTW9qJ/QIsrT8IbibmMOCNe/hHxwcOlmphscw/LqK1k/bLtZu0; h=Received:Subject:References:To:From:X-Forwarded-Message-Id:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [75.165.41.40] (helo=[192.168.0.4]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aPFMw-0001CV-Bn for lager@ietf.org; Fri, 29 Jan 2016 15:10:10 -0500 References: <56A8F59D.8000205@ix.netcom.com> To: lager@ietf.org From: Asmus Freytag X-Forwarded-Message-Id: <56A8F59D.8000205@ix.netcom.com> Message-ID: <56ABC723.6040802@ix.netcom.com> Date: Fri, 29 Jan 2016 12:10:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A8F59D.8000205@ix.netcom.com> Content-Type: multipart/alternative; boundary="------------090004020400060109010107" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2857e9f10d2205ddc978d37fe3d301411fe8a5148feee3b13350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 75.165.41.40 Archived-At: Subject: [Lager] Fwd: Re: when sequences are valid in the LGR X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:10:24 -0000 This is a multi-part message in MIME format. --------------090004020400060109010107 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Final forwarded message with final proposed text. I will add this text in the tracker and integrate it in the sources for the next revision of the draft. A./ -------- Forwarded Message -------- Subject: Re: when sequences are valid in the LGR Date: Wed, 27 Jan 2016 08:51:41 -0800 From: Asmus Freytag To: Wil Tan , Kim Davies Wil, I like your suggestion. The alternative would have been to refer to "at that position" a lot. Please have a look at this suggested text and see whether it's ready to go to the lager group. (I've marked changes manually with color). A./ 7.1. Determining Eligibility for a Label In order to test a specific label for membership in the LGR, a consumer of the LGR must iterate through each code point within a given label, and test that each instance of a code point is a member of the LGR. If any instance of a code point is not a member of the LGR, the label shall be deemed as invalid. An individual instance of a code point is deemed a member of the LGR when the code point is listed using a "char" element, or is part of a range defined with a "range" element, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied for that instance. Alternatively, an instance of a code point is also deemed a member of the LGR when it forms part of a sequence that corresponds to a sequence listed using a "char" element for which the "cp" attribute defines a sequence, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied for that instance of the sequence. In determining eligibility, at each position the longest possible sequence of code points is evaluated first. If that sequence matches a sequence defined in the LGR and satisfies any required context at that position, the instances of its constituent code points are deemed members of the LGR and evaluation proceeds with the next code point following the sequence. If the sequence does not satisfy the required context, successively shorter sequences are evaluated, until only a single code point remains. The eligibility of that code point is determined as described above for an individual code point instance. A label must also not trigger any action that results in a disposition of "invalid", otherwise it is deemed not eligible. (This step may need to be deferred, until variant code point dispositions have been determined). For LGRs that contain reflexive variant mappings (defined in Section 4.3.4 ), the final evaluation of eligibility for the label must be deferred until variants are generated. In essence, LGRs that use this feature treat the original label as the (identity) variant of itself. For such LGRs, the ordinary iteration over code points would generally only exclude a subset of invalid labels, but it could be used effectively as a pre-screening. To check the validity of a label with reflexive mappings, it is not necessary to generate all variant labels. Only a single variant needs to be created, where for each code point, any reflexive variants are applied, and the label disposition is evaluated. A disposition of "invalid" results in the label being not eligible. (In the exceptional case where context rules are present on reflexive mappings, multiple reflexive variants may be defined, but for each original label, at most one of these can be valid at each code position. However, see Section 7.4 ). 7.2. Determining Variants for a Label For a given eligible label, the set of variant labels is deemed to consist of each possible permutation of original code points and substituted code points or sequences defined in "var" elements, whereby all "when" and "not-when" attributes are correctly satisfied for each "char" or "var" element in the given permutation and all applicable whole label evaluation rules are satisfied as follows: 1. Create each possible permutation of a label, by substituting each code point or code point sequence in turn by any defined variant mapping (including any reflexive mappings) 2. Apply variant mappings with "when" or "not-when" attributes only if the conditions are satisfied; otherwise they are not defined 3. Record each of the "type" values on the variant mappings used in creating a given variant label in a disposition set; for any unmapped code point record the "type" value of any reflexive variant (see Section 4.3.4 ) 4. Determine the disposition for each variant label per Section 7.3 5. If the disposition is "invalid", remove the label from the set 6. If final evaluation of the disposition for the unpermuted label per Section 7.3 results in a disposition of "invalid", remove all associated variant labels from the set. The number of potential permutations can be very large. In practice, implementations would use suitable optimizations to avoid having to actually create all permutations. In determining the permuted set of variant labels in step (1) above, all eligible partitions into sequences must be evalluated. A label "ab", that matches a sequence "ab" defined in the LGR as well as the sequence of individual code points "a" and "b" (both defined in the LGR), must be permuted using any defined variant mappings for "ab", "a" and "b". --------------090004020400060109010107 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Final forwarded message with final proposed text.

I will add this text in the tracker and integrate it in the sources for the next revision of the draft.

A./

-------- Forwarded Message --------
Subject: Re: when sequences are valid in the LGR
Date: Wed, 27 Jan 2016 08:51:41 -0800
From: Asmus Freytag <asmusf@ix.netcom.com>
To: Wil Tan <wil@cloudregistry.net>, Kim Davies <kim.davies@icann.org>


Wil,

I like your suggestion. The alternative would have been to refer to "at that position" a lot. Please have a look at this suggested text and see whether it's ready to go to the lager group. (I've marked changes manually with color).

A./

7.1. Determining Eligibility for a Label

In order to test a specific label for membership in the LGR, a consumer of the LGR must iterate through each code point within a given label, and test that each instance of a code point is a member of the LGR. If any instance of a code point is not a member of the LGR, the label shall be deemed as invalid.

An individual instance of a code point is deemed a member of the LGR when the code point is listed using a "char" element, or is part of a range defined with a "range" element, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied for that instance.

Alternatively, an instance of a code point is also deemed a member of the LGR when it forms part of a sequence that corresponds to a sequence listed using a "char" element for which the "cp" attribute defines a sequence, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied for that instance of the sequence.

In determining eligibility, at each position the longest possible sequence of code points is evaluated first. If that sequence matches a sequence defined in the LGR and satisfies any required context at that position, the instances of its constituent code points are deemed members of the LGR and evaluation proceeds with the next code point following the sequence. If the sequence does not satisfy the required context, successively shorter sequences are evaluated, until only a single code point remains. The eligibility of that code point is determined as described above for an individual code point instance.

A label must also not trigger any action that results in a disposition of "invalid", otherwise it is deemed not eligible. (This step may need to be deferred, until variant code point dispositions have been determined).

For LGRs that contain reflexive variant mappings (defined in Section 4.3.4), the final evaluation of eligibility for the label must be deferred until variants are generated. In essence, LGRs that use this feature treat the original label as the (identity) variant of itself. For such LGRs, the ordinary iteration over code points would generally only exclude a subset of invalid labels, but it could be used effectively as a pre-screening.

To check the validity of a label with reflexive mappings, it is not necessary to generate all variant labels. Only a single variant needs to be created, where for each code point, any reflexive variants are applied, and the label disposition is evaluated. A disposition of "invalid" results in the label being not eligible. (In the exceptional case where context rules are present on reflexive mappings, multiple reflexive variants may be defined, but for each original label, at most one of these can be valid at each code position. However, see Section 7.4).

7.2. Determining Variants for a Label

For a given eligible label, the set of variant labels is deemed to consist of each possible permutation of original code points and substituted code points or sequences defined in "var" elements, whereby all "when" and "not-when" attributes are correctly satisfied for each "char" or "var" element in the given permutation and all applicable whole label evaluation rules are satisfied as follows:

  1. Create each possible permutation of a label, by substituting each code point or code point sequence in turn by any defined variant mapping (including any reflexive mappings)
  2. Apply variant mappings with "when" or "not-when" attributes only if the conditions are satisfied; otherwise they are not defined
  3. Record each of the "type" values on the variant mappings used in creating a given variant label in a disposition set; for any unmapped code point record the "type" value of any reflexive variant (see Section 4.3.4)
  4. Determine the disposition for each variant label per Section 7.3
  5. If the disposition is "invalid", remove the label from the set
  6. If final evaluation of the disposition for the unpermuted label per Section 7.3 results in a disposition of "invalid", remove all associated variant labels from the set.

The number of potential permutations can be very large. In practice, implementations would use suitable optimizations to avoid having to actually create all permutations.

In determining the permuted set of variant labels in step (1) above, all eligible partitions into sequences must be evalluated. A label "ab", that matches a sequence "ab" defined in the LGR as well as the sequence of individual code points "a" and "b" (both defined in the LGR), must be permuted using any defined variant mappings for "ab", "a" and "b".



--------------090004020400060109010107-- From nobody Fri Jan 29 12:12:20 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553BE1B32F1 for ; Fri, 29 Jan 2016 12:12:18 -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, RP_MATCHES_RCVD=-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 dc34euQOGF5S for ; Fri, 29 Jan 2016 12:12:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD561B32E5 for ; Fri, 29 Jan 2016 12:12:17 -0800 (PST) Received: from localhost ([::1]:53312 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aPFOy-0004hW-7J; Fri, 29 Jan 2016 12:12:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "lager issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com X-Trac-Project: lager Date: Fri, 29 Jan 2016 20:12:16 -0000 X-URL: https://tools.ietf.org/lager/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lager/trac/ticket/32 Message-ID: <061.6e4007b4034ec38c17029842a67983c4@tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com, lager@ietf.org X-SA-Exim-Mail-From: trac+lager@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-lager-specification@ietf.org Resent-Message-Id: <20160129201217.1FD561B32E5@ietfa.amsl.com> Resent-Date: Fri, 29 Jan 2016 12:12:17 -0800 (PST) Resent-From: trac+lager@tools.ietf.org Archived-At: Cc: lager@ietf.org Subject: [Lager] [lager] #32 (specification): Remove ambiguity about processing sequences X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:12:18 -0000 #32: Remove ambiguity about processing sequences The existing text of sections 7.1 and 7.2 can be interpreted ambiguously, as regards the processing of code point sequences defined in an LGR. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-lager- asmusf@ix.netcom.com | specification@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: specification | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: lager From nobody Fri Jan 29 12:15:22 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973211B330D for ; Fri, 29 Jan 2016 12:15:21 -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, RP_MATCHES_RCVD=-0.001] 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 81fdrMHopSDm for ; Fri, 29 Jan 2016 12:15:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45E01B3310 for ; Fri, 29 Jan 2016 12:15:18 -0800 (PST) Received: from localhost ([::1]:53355 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aPFRu-0000zA-Iq; Fri, 29 Jan 2016 12:15:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "lager issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com X-Trac-Project: lager Date: Fri, 29 Jan 2016 20:15:18 -0000 X-URL: https://tools.ietf.org/lager/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/lager/trac/ticket/32#comment:1 Message-ID: <076.cee75cc2a72a66950e4033296226043c@tools.ietf.org> References: <061.6e4007b4034ec38c17029842a67983c4@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <061.6e4007b4034ec38c17029842a67983c4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-lager-specification@tools.ietf.org, asmusf@ix.netcom.com, lager@ietf.org X-SA-Exim-Mail-From: trac+lager@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-lager-specification@ietf.org Resent-Message-Id: <20160129201518.D45E01B3310@ietfa.amsl.com> Resent-Date: Fri, 29 Jan 2016 12:15:18 -0800 (PST) Resent-From: trac+lager@tools.ietf.org Archived-At: Cc: lager@ietf.org Subject: Re: [Lager] [lager] #32 (specification): Remove ambiguity about processing sequences X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.15 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:15:21 -0000 #32: Remove ambiguity about processing sequences Comment (by asmusf@ix.netcom.com): This proposed text removes the ambiguity. The fourth paragraph of 7.1 and the last paragraph of 7.2 are new text. The remaining text in 7.1 has been modified to refer to "instances of" code points and sequences, to clarify that what matters is a particular code point value at a particular position in the label. 7.1. Determining Eligibility for a Label In order to test a specific label for membership in the LGR, a consumer of the LGR must iterate through each code point within a given label, and test that each instance of a code point is a member of the LGR. If any instance of a code point is not a member of the LGR, the label shall be deemed as invalid. An individual instance of a code point is deemed a member of the LGR when the code point is listed using a "char" element, or is part of a range defined with a "range" element, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied for that instance. Alternatively, an instance of a code point is also deemed a member of the LGR when it forms part of a sequence that corresponds to a sequence listed using a "char" element for which the "cp" attribute defines a sequence, and all necessary condition in any "when" or "not-when" attributes are correctly satisfied for that instance of the sequence. In determining eligibility, at each position the longest possible sequence of code points is evaluated first. If that sequence matches a sequence defined in the LGR and satisfies any required context at that position, the instances of its constituent code points are deemed members of the LGR and evaluation proceeds with the next code point following the sequence. If the sequence does not satisfy the required context, successively shorter sequences are evaluated, until only a single code point remains. The eligibility of that code point is determined as described above for an individual code point instance. A label must also not trigger any action that results in a disposition of "invalid", otherwise it is deemed not eligible. (This step may need to be deferred, until variant code point dispositions have been determined). For LGRs that contain reflexive variant mappings (defined in Section 4.3.4), the final evaluation of eligibility for the label must be deferred until variants are generated. In essence, LGRs that use this feature treat the original label as the (identity) variant of itself. For such LGRs, the ordinary iteration over code points would generally only exclude a subset of invalid labels, but it could be used effectively as a pre-screening. To check the validity of a label with reflexive mappings, it is not necessary to generate all variant labels. Only a single variant needs to be created, where for each code point, any reflexive variants are applied, and the label disposition is evaluated. A disposition of "invalid" results in the label being not eligible. (In the exceptional case where context rules are present on reflexive mappings, multiple reflexive variants may be defined, but for each original label, at most one of these can be valid at each code position. However, see Section 7.4). 7.2. Determining Variants for a Label For a given eligible label, the set of variant labels is deemed to consist of each possible permutation of original code points and substituted code points or sequences defined in "var" elements, whereby all "when" and "not-when" attributes are correctly satisfied for each "char" or "var" element in the given permutation and all applicable whole label evaluation rules are satisfied as follows: Create each possible permutation of a label, by substituting each code point or code point sequence in turn by any defined variant mapping (including any reflexive mappings) Apply variant mappings with "when" or "not-when" attributes only if the conditions are satisfied; otherwise they are not defined Record each of the "type" values on the variant mappings used in creating a given variant label in a disposition set; for any unmapped code point record the "type" value of any reflexive variant (see Section 4.3.4) Determine the disposition for each variant label per Section 7.3 If the disposition is "invalid", remove the label from the set If final evaluation of the disposition for the unpermuted label per Section 7.3 results in a disposition of "invalid", remove all associated variant labels from the set. The number of potential permutations can be very large. In practice, implementations would use suitable optimizations to avoid having to actually create all permutations. In determining the permuted set of variant labels in step (1) above, all eligible partitions into sequences must be evalluated. A label "ab", that matches a sequence "ab" defined in the LGR as well as the sequence of individual code points "a" and "b" (both defined in the LGR), must be permuted using any defined variant mappings for "ab", "a" and "b". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-lager- asmusf@ix.netcom.com | specification@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: | Version: specification | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: lager