From nobody Mon Mar 1 06:49:16 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE613A1D77; Mon, 1 Mar 2021 06:49:05 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK8hBrmxA_dA; Mon, 1 Mar 2021 06:49:02 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C263A1D75; Mon, 1 Mar 2021 06:49:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.81,215,1610406000"; d="p7s'?scan'208";a="495482332" Received: from adsl-46-161-92090.crnagora.net (HELO [192.168.100.4]) ([46.161.92.90]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 01 Mar 2021 15:48:58 +0100 User-Agent: Microsoft-MacOutlook/10.11.0.180909 Date: Mon, 01 Mar 2021 15:48:56 +0100 From: =?UTF-8?B?TWFsacWhYQ==?= =?UTF-8?B?IFZ1xI1pbmnEhw==?= To: Benjamin Kaduk CC: , , , Message-ID: <45ED078E-4F15-430F-A6BC-2C0691EDD9B4@inria.fr> Thread-Topic: Secdir last call review of draft-ietf-curdle-ssh-kex-sha2-14 References: <161426245763.32636.14586046669535474103@ietfa.amsl.com> <20210228010137.GU21@kduck.mit.edu> In-Reply-To: <20210228010137.GU21@kduck.mit.edu> Mime-version: 1.0 Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3697458536_1444056079" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-curdle-ssh-kex-sha2-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 14:49:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3697458536_1444056079 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thanks Ben, a couple of comments inline, enclosed within [MV] ... [/MV]. Mali=C5=A1a =EF=BB=BFOn 28/02/2021 02:01, "Benjamin Kaduk" wrote: Hi Mali=C5=A1a, =20 Thanks for the detailed review! =20 I can only answer for some of the points, so hopefully Mark can chime i= n as needed. =20 On Thu, Feb 25, 2021 at 06:14:18AM -0800, Mali=C5=A1a Vu=C4=8Dini=C4=87 via Datatra= cker wrote: > Reviewer: Mali=C5=A1a Vu=C4=8Dini=C4=87 > Review result: Has Issues >=20 > I reviewed this document as part of the Security Directorate's ongoin= g effort > to review all IETF documents being processed by the IESG. These comm= ents were > written primarily for the benefit of the Security Area Directors. Do= cument > authors, document editors, and WG chairs should treat these comments = just like > any other IETF Last Call comments. >=20 > I have found this document to have several issues related to the norm= ative > language, imprecise wording, and inconsistent structure. Security > Considerations section is too generic and needs to detail the conside= rations of > using specific methods. My detailed comments are given below and I wo= uld > suggest a major editorial pass over the document. >=20 > Technical comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Section 1.2.2. > =E2=80=9CThe minimum MODP group that MAY be used is the 2048-bit MODP group= 14. > Implementations SHOULD support a 3072-bit MODP group or larger.=E2=80=9D - = The use of > RFC2119 keywords here does not seem appropriate. These are the guidin= g > principles for specifying requirement levels of specific key exchange= methods, > which are given in Section 3. >=20 > Section 1.2.3: > =E2=80=9CThe use of a SHA-2 Family hash with RSA 2048-bit keys has sufficie= nt security.=E2=80=9D > - Please define =E2=80=9Csufficient=E2=80=9D security >=20 > =E2=80=9CThe rsa1024-sha1 key exchange has less than 2048 bits and MUST NOT= be > implemented.=E2=80=9D - My view of Sections 1.2.1, 1.2.2 and 1.2.3 is that= they give a > recap of public-key approaches with corresponding security levels whe= n used > with different parameters. II am missing how a normative text on rsa1= 024-sha1 > key exchange belongs here, and not to Section 3.4. Only in this secti= on > (compared to 1.2.1 and 1.2.2) you reference specific SSH key exchange= methods. > What does the security strength column in Table 3 refer to? The secur= ity level > of the RSA variant or of the hash function? Please make this consiste= nt with > 1.2.1 and 1.2.2. =20 It seems that an overarching consideration here is that we only need to make any given normative statement once in the document, and can refer = to it or make other supporting statements as needed in other parts of the document. I probably didn't pay as much care to this point in my revie= w as I could have... [MV] Agreed. [/MV] =20 > Section 3.1: > =E2=80=9CAll of the key exchanges using the SHA-1 hashing algorithm should = be > deprecated and phased out of use because SHA-1 has security concerns,= as > documented in [RFC6194].=E2=80=9D "It is reasonable to retain the > diffie-hellman-group14-sha1 exchange for interoperability with legacy > implementations. The diffie-hellman-group14-sha1 key exchange MAY be > implemented.=E2=80=9D - This text is conflicting with the statement just ab= ove that > SHA-1 should be deprecated, as you keep SHA1-based method as MAY for = legacy > interop. Could you point me to the relevant discussion in the working= group > where this decision has been made? Could you comment in the text on s= ecurity > properties of the construct. =20 The concern here is that diffie-hellman-group14-sha1 was one of only tw= o "MUST implement" algorithms in the previous version of the spec, and th= at both (1) moving directly from "MUST" to "MUST NOT" is a huge leap that requires correspondingly strong justification; and (2) there was desire preserve the option to have backwards compatibility with non-updated implementations that, for example, only had the old MTI key-exchange method. =20 There's some more extensive text discussing this that was produced in response to the genart review; the last consolidated version is at https://mailarchive.ietf.org/arch/msg/gen-art/GSb7vxgIDwu8ocOfiFwTRhTso= F0/ but a few more edits were suggested in follow-up messages. =20 [MV] Thanks for the pointer and detailing the reasoning! [/MV] > =E2=80=9CThe SHA-2 Family of hashes [RFC6234] is the only one which is more= secure than > SHA-1 and has been standardized for use with SSH key exchanges.=E2=80=9D - = =E2=80=9Cis the only > one which is more secure than SHA-1=E2=80=9D seems too general of a stateme= nt, what > about SHA3? =20 SHA3 is not standardized for use with SSH key exchange (yet). The opti= ons are pretty limited when we limit it to just standardized ones. [MV]=20 This was really a subtle editorial comment: the statement read to me as (1)= "SHA-2 is the only hash function which is more secure than SHA-1"; (2) "SHA= -2 has in addition been standardized for use with SSH key exchanges". My com= ment was referring to (1).=20 To me, one simple "that" would make a difference: [OLD] The SHA-2 family of hashes [RFC6234] is the only one which is more se= cure than SHA-1 and has been standardized for use with SSH key exchanges. [/= OLD] [NEW] The SHA-2 family of hashes [RFC6234] is the only one which is more se= cure than SHA-1 and that has been standardized for use with SSH key exchange= s. [/NEW] I am not a native speaker so please feel free to disregard if this doesn't = make any sense :) [/MV] =20 > Section 3.2.3: > - Title of the section got me confused. Sections 3.2.2 and 3.2.1 alre= ady > discuss ECDH-based key exchange methods. Could you make a clear diffe= rentiation > between the methods referenced in this section in terms of their cryp= tographic > core from those discussed in 3.2.2 and 3.2.1 >=20 > =E2=80=9CAll of the NISTP curves named therein are mandatory to implement i= f any of > that RFC is implemented.=E2=80=9D - Since this document does not update RFC= 5656, I am > missing how it is appropriate to make this statement. =20 My reading of this statement is that it is already a requirement of RFC 5656 =C2=A710.1: =20 Every SSH ECC implementation MUST support the named curves below. [table including nistp256, nistp384, and nistp521] [MV] In the sense that the statement is just reiterating the requirement of= RFC 5656 ? Sounds good. [/MV] =20 > Section 3.3.1: > =E2=80=9CThis random selection from a set of pre-generated moduli for key e= xchange uses > SHA2-256 as defined in [RFC4419].=E2=80=9D - RFC 4491 defines two key excha= nge methods, > diffie-hellman-group-exchange-sha1 using SHA1, and > diffie-hellman-group-exchange-sha256 using SHA-256. In this section y= ou do not > mention the former. Phrasing =E2=80=9CThis key exchange MAY be used.=E2=80=9D lea= ves ambiguity > which of the two methods you refer to. >=20 > Section 6: > - Security Considerations section is extremely generic and needs to b= e > improved. Referencing security considerations of the SSH protocol in = RFC 4251 > is appropriate, but since the point of this document is the update of= the > requirement level of key exchange methods, the last paragraph should = be > extended and more specific. While the discussion in Section 1.1 gives= details > on the attacks on SHA-1, which can be referenced here, I would sugges= t > reiterating in the Security Considerations the practical consequences= of using > the SHA-1 -based methods that are listed as SHOULD NOT, but also the > rsa1024-sha1 method that is listed as MUST NOT. Please stress the sec= urity > considerations of using diffie-hellman-group14-sha1 which is still a = MAY. >=20 > Editorial comments and nits > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > - Please explicitly reference each table in the text. I would further= suggest > adding a table in each section discussing new requirement levels of s= pecific > key exchange methods, even if it would consist of a single entry, in = order to > have a consistent structure. >=20 > Section 1: > =E2=80=9CThis document updates [RFC4250] [RFC4253] [RFC4432] [RFC4462] by c= hanging the > requirement level ("MUST" moving to "SHOULD" or "MAY" or "SHOULD NOT"= , and > "MAY" moving to "MUST" or "SHOULD" or "SHOULD NOT" or "MUST NOT") of = various > key-exchange mechanisms.=E2=80=9D - The specific updates to these documents= are spread > out throughout the text and pretty hard to grasp. It would be nice to= see Table > 6 updated, by adding the reference RFC that is being updated, alongsi= de the RFC > specifying the key exchange method, and maybe an old requirement leve= l. >=20 > Section 1.1: > - introduce protocol parameters I_C and I_S =20 These are standard protocol elements from RFC 4253; we should probably = have a note at the top of the document that we freely use the terminology fr= om that document. [MV] Works for me, but adding "protocol parameters" in that sentence wouldn= 't hurt either. [/MV] =20 -Ben =20 > Section 3: > =E2=80=9Cand provides a suggested suitability for implementation of MUST, S= HOULD, > SHOULD NOT, and MUST NOT. Any method not explicitly listed MAY be > implemented.=E2=80=9D - there are some explicit MAYs in the document, yet M= AY is not > listed here. >=20 > Section 3.2.1: > =E2=80=9CThe use of SHA2-256 (also known as SHA-256 and sha256) as defined = in [RFC6234] > for integrity is a reasonable one for this method=E2=80=9D - =E2=80=9Cthis=E2=80=9D met= hod not clear. > Be explicit and mention curve25519-sha256 key exchange method. >=20 > "it shares the same performance and security characteristics as curve= 25519-sha2=E2=80=9D > - the key exchange method as standardized seems to be curve25519-sha2= 56. >=20 > Section 3.2.2: > =E2=80=9CIt uses SHA2-512 (also known as SHA-512) defined in [RFC6234] for = integrity.=E2=80=9D > - =E2=80=9Cit=E2=80=9D refers to the curve, not to the key exchange method. Rephr= ase to e.g. > corresponding key exchange method(s) >=20 > Section 3.2.1 and 3.2.2: > - Shuffle the content in these sections, first introduce the key exch= ange > methods, then talk about curves and hash function they use >=20 > Section 3.2.3: > - s/The are described in /These are described in > - s/Diffie Hellman/Diffie-Hellman > - s/elliptic curve Diffie Hellman/Elliptic-curve Diffie-Hellman >=20 > Section 3.3.1: > - You open a section with =E2=80=9CThis=E2=80=9D which is confusing. Please rephr= ase. > - Add a table summarizing the requirement level per method, even if i= t consists > of a single method, in order to be consistent with other sections. >=20 > Section 3.3.2 > - Please add some context and differentiation from Section 3.3.1 > - Can you reference the RFC that specifies the methods discussed in t= his > section? >=20 > Section 3.5 > =E2=80=9CThere are two key exchange methods, ext-info-c and ext-info-s, def= ined in > [RFC8308] which are not actually key exchanges.=E2=80=9D - s/two key exchan= ge > methods/two methods >=20 >=20 >=20 =20 --B_3697458536_1444056079 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIILTgYJKoZIhvcNAQcCoIILPzCCCzsCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggnaMIIDwTCCA2egAwIBAgIQFw7Jpec0JGSP/7v+wSA+ZDAKBggqhkjOPQQDAjBKMQsw CQYDVQQGEwJOTDEZMBcGA1UEChMQR0VBTlQgVmVyZW5pZ2luZzEgMB4GA1UEAxMXR0VBTlQg UGVyc29uYWwgRUNDIENBIDQwHhcNMjAxMDAyMDAwMDAwWhcNMjExMDAyMjM1OTU5WjCBzDEe MBwGA1UECRMVTEEgUExBSU5FIERFIFZPTFVDRUFVMSAwHgYDVQQHExdMZSBDaGVzbmF5LVJv Y3F1ZW5jb3VydDEXMBUGA1UECAwOw45sZS1kZS1GcmFuY2UxCzAJBgNVBAYTAkZSMUkwRwYD VQQKE0BJTlNUSVRVVCBOQVRJT05BTCBERSBSRUNIRVJDSEUgRU4gSU5GT1JNQVRJUVVFIEVU IEVOIEFVVE9NQVRJUVVFMRcwFQYDVQQDEw5NYWxpc2EgVlVDSU5JQzBZMBMGByqGSM49AgEG CCqGSM49AwEHA0IABOgTX1QaaAdnbMSyFV36oSCYnvUSIGms7n6NP7b4xoPRfpCBdb4TBIp+ rlfVgPE90EzFyhcq/DmB84EYDTTBUhejggGqMIIBpjAfBgNVHSMEGDAWgBSoLW2BMmSN5rJP rP4R8mWZhROpbjAdBgNVHQ4EFgQUETLUJLJ/r0A+S5e2/V5e0Ra4jf0wDgYDVR0PAQH/BAQD AgeAMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMD8GA1Ud IAQ4MDYwNAYLKwYBBAGyMQECAk8wJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNv bS9DUFMwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL0dFQU5ULmNybC5zZWN0aWdvLmNvbS9H RUFOVFBlcnNvbmFsRUNDQ0E0LmNybDB7BggrBgEFBQcBAQRvMG0wQAYIKwYBBQUHMAKGNGh0 dHA6Ly9HRUFOVC5jcnQuc2VjdGlnby5jb20vR0VBTlRQZXJzb25hbEVDQ0NBNC5jcnQwKQYI KwYBBQUHMAGGHWh0dHA6Ly9HRUFOVC5vY3NwLnNlY3RpZ28uY29tMCIGA1UdEQQbMBmBF21h bGlzYS52dWNpbmljQGlucmlhLmZyMAoGCCqGSM49BAMCA0gAMEUCIHXUNnrIiwXzauU5YsFE 4oaoXTlVaVKSikMkFYqQPi7KAiEAo8/aIJP6t0aHy0gtDQgUy6Kpzm4SFhODSYWHACtoZZww ggN+MIIDBKADAgECAhB2kCF9/l3WwsRQJ8Xc0VomMAoGCCqGSM49BAMDMIGIMQswCQYDVQQG EwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNV BAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IEVDQyBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0yMDAyMTgwMDAwMDBaFw0zMzA1MDEyMzU5NTlaMEox CzAJBgNVBAYTAk5MMRkwFwYDVQQKExBHRUFOVCBWZXJlbmlnaW5nMSAwHgYDVQQDExdHRUFO VCBQZXJzb25hbCBFQ0MgQ0EgNDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABBhnZxHg7m19 2ySDY02jfjo2jKh6dCNaFZASVNBD5uuYzGvmV5bUB+kAn1uxpRp2wIkmcDnJwUhNiNd+X9e9 8+SjggGLMIIBhzAfBgNVHSMEGDAWgBQ64QmG1M8ZwpZ2dEl23OA1xmNjmjAdBgNVHQ4EFgQU qC1tgTJkjeayT6z+EfJlmYUTqW4wDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDgGA1UdIAQxMC8wLQYEVR0gADAl MCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzBQBgNVHR8ESTBHMEWgQ6BB hj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0RUNDQ2VydGlmaWNhdGlvbkF1 dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0RUNDQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0 dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wCgYIKoZIzj0EAwMDaAAwZQIxAIJfo/faijtGIAiT UMh6RkycUZnBj7EmhnkfIKEZzU1y66meHsTO6SvUScv4zICE1wIwPoOVIxYTkj744G/OedfW emO+e0twqiACsA+MuCUYZ7KYW3hTql3Lv8LT+aIcI+4MMIICjzCCAhWgAwIBAgIQXIuZxVqU xdJxVt7NiYDMJjAKBggqhkjOPQQDAzCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBK ZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBFQ0MgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw HhcNMTAwMjAxMDAwMDAwWhcNMzgwMTE4MjM1OTU5WjCBiDELMAkGA1UEBhMCVVMxEzARBgNV BAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF UlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBFQ0MgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQarFRaqfloI+d61SRvU8Za2EurxtW2 0eZzca7dnNYMYf3boIkDuAUU7FfO7l0/4iGzzvfUinngo4N+LZfQYcTxmdwlkWOrfzCjtHDi x6EznPO/LlxTsV+zfTJ/ijTjeXmjQjBAMB0GA1UdDgQWBBQ64QmG1M8ZwpZ2dEl23OA1xmNj mjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAKBggqhkjOPQQDAwNoADBlAjA2 Z6EWCNzklwBBHU6+4WMBzzuqQhFkoJ2UOQIReVx7Hfpkue4WQrO/isIJxOzksU0CMQDpKmFH jFJKS04YcPbWRNZu9YO6bVi9JNlWSOrvxKJGgYhqOkbRqZtNyWHa0V1XahgxggE4MIIBNAIB ATBeMEoxCzAJBgNVBAYTAk5MMRkwFwYDVQQKExBHRUFOVCBWZXJlbmlnaW5nMSAwHgYDVQQD ExdHRUFOVCBQZXJzb25hbCBFQ0MgQ0EgNAIQFw7Jpec0JGSP/7v+wSA+ZDANBglghkgBZQME AgEFAKBpMC8GCSqGSIb3DQEJBDEiBCBMVbfXSCOK5HPzXm7GUANhVT3oRcLAEiTuOw0Btu7l VzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAzMDExNDQ4 NTZaMAsGByqGSM49AgEFAARIMEYCIQC8TUtyBlp/JID3jdMJbWXbCxp/vqHHMWUJY8LDGzZf UgIhALMulLTMaZTxJBh6F2mcmirJOnOaSaiSaR9nPXZlfx/F --B_3697458536_1444056079-- From nobody Mon Mar 1 06:59:15 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2233A1D9D; Mon, 1 Mar 2021 06:59:13 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99mCnchjsOw9; Mon, 1 Mar 2021 06:59:11 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E648C3A1D9E; Mon, 1 Mar 2021 06:59:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.81,215,1610406000"; d="p7s'?scan'208";a="495484503" Received: from adsl-46-161-92090.crnagora.net (HELO [192.168.100.4]) ([46.161.92.90]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 01 Mar 2021 15:59:07 +0100 User-Agent: Microsoft-MacOutlook/10.11.0.180909 Date: Mon, 01 Mar 2021 15:59:06 +0100 From: =?UTF-8?B?TWFsacWhYQ==?= =?UTF-8?B?IFZ1xI1pbmnEhw==?= To: "Mark D. Baushke" , Benjamin Kaduk , Rene Struik CC: , , Message-ID: <49916660-F237-4BE9-94ED-DE7E41D1B195@inria.fr> Thread-Topic: Secdir last call review of draft-ietf-curdle-ssh-kex-sha2-14 References: <161426245763.32636.14586046669535474103@ietfa.amsl.com> <20210228010137.GU21@kduck.mit.edu> <87903.1614533390@eng-mail03> In-Reply-To: <87903.1614533390@eng-mail03> Mime-version: 1.0 Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3697459146_865446808" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-curdle-ssh-kex-sha2-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 14:59:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3697459146_865446808 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Mark, Thanks, see a couple of comments inline, enclosed within [MV] ... [/MV]. Mali=C5=A1a =EF=BB=BFOn 28/02/2021 18:26, "Mark D. Baushke" wrote: [CC- last-call@ietf.org] This message really only addresses specific review comments... =20 Hi Ben and Mali=C5=A1a and Rene, =20 Benjamin Kaduk writes: =20 > Hi=20 >=20 > Thanks for the detailed review! >=20 > I can only answer for some of the points, so hopefully Mark can chime= in as > needed. =20 I will do what I can to address the points raised by everyone. =20 I do not believe that I can introduce anything about SHA-3 hashing as that is not being used by Secure Shell key exchanges today and this is really only a survey of the existing key exchanges. [MV] The comment on SHA-3 was really of an editorial nature as the sentence= read too general, see the response to Ben for an easy resolution. [/MV] =20 I will try to do a better job about the objective requirements. =20 For example, the use of a 2048-bit MODP group with 112 bits of security is fine to protect a 3des-cbc 112 bits of security symmetric cipher. However, it is not sufficient to protect an aes128 bit key with 128 bit= s of security. Likewise, a SHA-1 hash with 80 bits or less of security is not really good to protect even the 3des-cbc cipher. =20 The reason I recommended that a 3072-bit MODP group be used was to protect aes128 keys. I will try to make that point more explicit. =20 Thank you for all of the comments. I have to find time to incorporate them. =20 With regard to Rene's question about changing Table 6... =20 Rene wrote: =20 > Section 1: =E2=80=9CThis document updates [RFC4250] [RFC4253] [RFC4432] > [RFC4462] by changing the requirement level ("MUST" moving to "SHOULD= " > or "MAY" or "SHOULD NOT", and "MAY" moving to "MUST" or "SHOULD" or > "SHOULD NOT" or "MUST NOT") of various key-exchange mechanisms.=E2=80=9D - = The > specific updates to these documents are spread out throughout the tex= t > and pretty hard to grasp. It would be nice to see Table 6 updated, by > adding the reference RFC that is being updated, alongside the RFC > specifying the key exchange method, and maybe an old requirement > level. =20 Table 6 presently has the kex name, RFC reference, and the implementation guidance for the method. This is intended to be what becomes the IANA table for key exchange method names. I am not entirely sure I understand what is desired. Some methods do not have any languag= e about MUST, SHOULD, or MAY implement. So, the previous history is not really defined. This is how the table might look if I list "none" for those that are not called out in their RFCs: [MV]=20 I believe this was a comment I made. The underlying issue here is that when= I was going through the doc, I had a hard time understanding the specific u= pdates to the referenced RFCs. The proposal above was a means to resolve tha= t. If you find that too clumsy, feel free to propose any other way of making= it explicit what exactly is being updated within those documents. [/MV] =20 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | Key Exchange Method | Reference | Previous | Implement = | | Name | | Recommendation | = | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | curve25519-sha256 | RFC8731 | none | SHOULD = | +--------------------------+-----------+----------------+-----------= + | curve448-sha512 | RFC8731 | none | MAY = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman-group- | RFC4419 | none | SHOULD = | | exchange-sha1 | RFC8270 | | NOT = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman-group- | RFC4419 | none | MAY = | | exchange-sha256 | RFC8720 | | = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman- | RFC4253 | MUST | SHOULD = | | group1-sha1 | | | NOT = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman- | RFC4253 | MUST | MAY = | | group14-sha1 | | | = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman- | RFC8268 | none | MUST = | | group14-sha256 | | | = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman- | RFC8268 | none | MAY = | | group15-sha512 | | | = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman- | RFC8268 | none | SHOULD = | | group16-sha512 | | | = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman- | RFC8268 | none | MAY = | | group17-sha512 | | | = | +--------------------------+-----------+----------------+-----------= + | diffie-hellman- | RFC8268 | none | MAY = | | group18-sha512 | | | = | +--------------------------+-----------+----------------+-----------= + | ecdh-sha2-* | RFC5656 | MAY | MAY = | +--------------------------+-----------+----------------+-----------= + | ecdh-sha2-nistp256 | RFC5656 | MUST | SHOULD = | +--------------------------+-----------+----------------+-----------= + | ecdh-sha2-nistp384 | RFC5656 | MUST | SHOULD = | +--------------------------+-----------+----------------+-----------= + | ecdh-sha2-nistp521 | RFC5656 | MUST | SHOULD = | +--------------------------+-----------+----------------+-----------= + | ecmqv-sha2 | RFC5656 | MAY | MAY = | +--------------------------+-----------+----------------+-----------= + | ext-info-c | RFC8308 | SHOULD | SHOULD = | +--------------------------+-----------+----------------+-----------= + | ext-info-s | RFC8308 | SHOULD | SHOULD = | +--------------------------+-----------+----------------+-----------= + | gss-* | RFC4462 | none | MAY = | +--------------------------+-----------+----------------+-----------= + | gss- | RFC8732 | SHOULD | SHOULD = | | curve25519-sha256-* | | | = | +--------------------------+-----------+----------------+-----------= + | gss-curve448-sha512-* | RFC8732 | MAY | MAY = | +--------------------------+-----------+----------------+-----------= + | gss-gex-sha1-* | RFC4462 | none | SHOULD = | | | | | NOT = | +--------------------------+-----------+----------------+-----------= + | gss-group1-sha1-* | RFC4462 | none | SHOULD = | | | | | NOT = | +--------------------------+-----------+----------------+-----------= + | gss-group14-sha256-* | RFC8732 | none | SHOULD = | +--------------------------+-----------+----------------+-----------= + | gss-group15-sha512-* | RFC8732 | none | MAY = | +--------------------------+-----------+----------------+-----------= + | gss-group16-sha512-* | RFC8732 | none | MAY = | +--------------------------+-----------+----------------+-----------= + | gss-group17-sha512-* | RFC8732 | none | MAY = | +--------------------------+-----------+----------------+-----------= + | gss-group18-sha512-* | RFC8732 | none | MAY = | +--------------------------+-----------+----------------+-----------= + | gss-nistp256-sha256-* | RFC8732 | none | SHOULD = | +--------------------------+-----------+----------------+-----------= + | gss-nistp384-sha384-* | RFC8732 | none | SHOULD = | +--------------------------+-----------+----------------+-----------= + | gss-nistp521-sha512-* | RFC8732 | none | SHOULD = | +--------------------------+-----------+----------------+-----------= + | rsa1024-sha1 | RFC4432 | none | MUST NOT = | +--------------------------+-----------+----------------+-----------= + | rsa2048-sha256 | RFC4432 | none | MAY = | +--------------------------+-----------+----------------+-----------= + =20 I am not sure if this table is now too busy to be in the IANA table or not and ask for suggestions to make the IANA table more useful. =20 My goal is to upload a -15 revision of the document on or soon after March 8th when submissions are open again. [MV] Great, thanks! [/MV] =20 Be safe, stay healthy, -- Mark =20 --B_3697459146_865446808 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIILTQYJKoZIhvcNAQcCoIILPjCCCzoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggnaMIIDwTCCA2egAwIBAgIQFw7Jpec0JGSP/7v+wSA+ZDAKBggqhkjOPQQDAjBKMQsw CQYDVQQGEwJOTDEZMBcGA1UEChMQR0VBTlQgVmVyZW5pZ2luZzEgMB4GA1UEAxMXR0VBTlQg UGVyc29uYWwgRUNDIENBIDQwHhcNMjAxMDAyMDAwMDAwWhcNMjExMDAyMjM1OTU5WjCBzDEe MBwGA1UECRMVTEEgUExBSU5FIERFIFZPTFVDRUFVMSAwHgYDVQQHExdMZSBDaGVzbmF5LVJv Y3F1ZW5jb3VydDEXMBUGA1UECAwOw45sZS1kZS1GcmFuY2UxCzAJBgNVBAYTAkZSMUkwRwYD VQQKE0BJTlNUSVRVVCBOQVRJT05BTCBERSBSRUNIRVJDSEUgRU4gSU5GT1JNQVRJUVVFIEVU IEVOIEFVVE9NQVRJUVVFMRcwFQYDVQQDEw5NYWxpc2EgVlVDSU5JQzBZMBMGByqGSM49AgEG CCqGSM49AwEHA0IABOgTX1QaaAdnbMSyFV36oSCYnvUSIGms7n6NP7b4xoPRfpCBdb4TBIp+ rlfVgPE90EzFyhcq/DmB84EYDTTBUhejggGqMIIBpjAfBgNVHSMEGDAWgBSoLW2BMmSN5rJP rP4R8mWZhROpbjAdBgNVHQ4EFgQUETLUJLJ/r0A+S5e2/V5e0Ra4jf0wDgYDVR0PAQH/BAQD AgeAMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMD8GA1Ud IAQ4MDYwNAYLKwYBBAGyMQECAk8wJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNv bS9DUFMwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL0dFQU5ULmNybC5zZWN0aWdvLmNvbS9H RUFOVFBlcnNvbmFsRUNDQ0E0LmNybDB7BggrBgEFBQcBAQRvMG0wQAYIKwYBBQUHMAKGNGh0 dHA6Ly9HRUFOVC5jcnQuc2VjdGlnby5jb20vR0VBTlRQZXJzb25hbEVDQ0NBNC5jcnQwKQYI KwYBBQUHMAGGHWh0dHA6Ly9HRUFOVC5vY3NwLnNlY3RpZ28uY29tMCIGA1UdEQQbMBmBF21h bGlzYS52dWNpbmljQGlucmlhLmZyMAoGCCqGSM49BAMCA0gAMEUCIHXUNnrIiwXzauU5YsFE 4oaoXTlVaVKSikMkFYqQPi7KAiEAo8/aIJP6t0aHy0gtDQgUy6Kpzm4SFhODSYWHACtoZZww ggN+MIIDBKADAgECAhB2kCF9/l3WwsRQJ8Xc0VomMAoGCCqGSM49BAMDMIGIMQswCQYDVQQG EwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNV BAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IEVDQyBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0yMDAyMTgwMDAwMDBaFw0zMzA1MDEyMzU5NTlaMEox CzAJBgNVBAYTAk5MMRkwFwYDVQQKExBHRUFOVCBWZXJlbmlnaW5nMSAwHgYDVQQDExdHRUFO VCBQZXJzb25hbCBFQ0MgQ0EgNDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABBhnZxHg7m19 2ySDY02jfjo2jKh6dCNaFZASVNBD5uuYzGvmV5bUB+kAn1uxpRp2wIkmcDnJwUhNiNd+X9e9 8+SjggGLMIIBhzAfBgNVHSMEGDAWgBQ64QmG1M8ZwpZ2dEl23OA1xmNjmjAdBgNVHQ4EFgQU qC1tgTJkjeayT6z+EfJlmYUTqW4wDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDgGA1UdIAQxMC8wLQYEVR0gADAl MCMGCCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzBQBgNVHR8ESTBHMEWgQ6BB hj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0RUNDQ2VydGlmaWNhdGlvbkF1 dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVNFUlRydXN0RUNDQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0 dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wCgYIKoZIzj0EAwMDaAAwZQIxAIJfo/faijtGIAiT UMh6RkycUZnBj7EmhnkfIKEZzU1y66meHsTO6SvUScv4zICE1wIwPoOVIxYTkj744G/OedfW emO+e0twqiACsA+MuCUYZ7KYW3hTql3Lv8LT+aIcI+4MMIICjzCCAhWgAwIBAgIQXIuZxVqU xdJxVt7NiYDMJjAKBggqhkjOPQQDAzCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBK ZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBFQ0MgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw HhcNMTAwMjAxMDAwMDAwWhcNMzgwMTE4MjM1OTU5WjCBiDELMAkGA1UEBhMCVVMxEzARBgNV BAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF UlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMTJVVTRVJUcnVzdCBFQ0MgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQarFRaqfloI+d61SRvU8Za2EurxtW2 0eZzca7dnNYMYf3boIkDuAUU7FfO7l0/4iGzzvfUinngo4N+LZfQYcTxmdwlkWOrfzCjtHDi x6EznPO/LlxTsV+zfTJ/ijTjeXmjQjBAMB0GA1UdDgQWBBQ64QmG1M8ZwpZ2dEl23OA1xmNj mjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAKBggqhkjOPQQDAwNoADBlAjA2 Z6EWCNzklwBBHU6+4WMBzzuqQhFkoJ2UOQIReVx7Hfpkue4WQrO/isIJxOzksU0CMQDpKmFH jFJKS04YcPbWRNZu9YO6bVi9JNlWSOrvxKJGgYhqOkbRqZtNyWHa0V1XahgxggE3MIIBMwIB ATBeMEoxCzAJBgNVBAYTAk5MMRkwFwYDVQQKExBHRUFOVCBWZXJlbmlnaW5nMSAwHgYDVQQD ExdHRUFOVCBQZXJzb25hbCBFQ0MgQ0EgNAIQFw7Jpec0JGSP/7v+wSA+ZDANBglghkgBZQME AgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDDL7FVCCHSMZZAmwFz9wLE6x4RT4zGdNtIVG3hi2E6 BjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAzMDExNDU5 MDZaMAsGByqGSM49AgEFAARHMEUCIFbHBTsrgrx7BigZ6xWmVHwB5FCmdMoT5Ne/8ibRqjZS AiEApIXpZAmC4yPiJv/FT+Zid+9R0uzhOXIExHd7yrcZaaQ= --B_3697459146_865446808-- From nobody Wed Mar 3 16:20:37 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0FB3A0B58; Wed, 3 Mar 2021 16:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.599, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bud1J81LYo1a; Wed, 3 Mar 2021 16:20:33 -0800 (PST) Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC56B3A0B55; Wed, 3 Mar 2021 16:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7hXBi6Vf5erdVBw0ZTCVJfISa7oarnuDUuiGQufRBGY=; b=aNgvxeL3PESX5sCotYcxyYor6 vnHD+kZL1PR6tmUGgPsXlSKtLyyUwUKqPq2Sh8c9R7cM5DoIwkF/24e7X0QeunrH90wYALJL4t2mv qz48IK6o6piAFQ8H3Pbrf3zM6UhJO9tREIql9wEi14fiPBlhBZ6bcr8JCeWRa/g4MJNo1RY+LJG5F DXiHiAZrr2qXi+pfS/2y5kLTGcrbbcBH/gcp72nnNHhHtM9tPuEf7lBVbSF/82IUSRnfjWzPjOAeQ Vq5BR3/GrOQBztD097j807PYci7kYxzkrBmWfjv7BpMN4y+rDx4iagfVZ5y/GqPvYmPifORC3wtVE ZJqfsEP/A==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52520 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lHbj9-002Zun-07; Wed, 03 Mar 2021 19:20:32 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Joseph Touch In-Reply-To: <3780299D-34DB-4B6D-ABA4-BA579C946CA5@redhoundsoftware.com> Date: Wed, 3 Mar 2021 16:20:26 -0800 Cc: secdir@ietf.org, "iesg@ietf.org" , draft-ietf-tcpm-2140bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <80AF628E-962C-4F87-B9D6-D14B50AD2F97@strayalpha.com> References: <3780299D-34DB-4B6D-ABA4-BA579C946CA5@redhoundsoftware.com> To: Carl Wallace X-Mailer: Apple Mail (2.3654.60.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tcpm-2140bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 00:20:35 -0000 Hi, Carl, Many thanks for the review! Joe > On Feb 22, 2021, at 3:43 AM, Carl Wallace = wrote: >=20 > I reviewed this document as part of the Security Directorate's ongoing = effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the Security Area = Directors. Document authors, document editors, and WG chairs should = treat these comments just like any other IETF Last Call comments. >=20 > This document obsoletes RFC 2140. It provides a description of = interdependent TCP control blocks and the ways that part of TCP state = can be shared among similar concurrent or consecutive connections. TCP = state includes a combination of parameters, such as connection state, = current round-trip time estimates, congestion control information, and = process information.=20 >=20 > I found no issues or nits with the document. The document is ready.=20 >=20 >=20 >=20 >=20 From nobody Thu Mar 4 06:00:23 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9593A0A3E for ; Thu, 4 Mar 2021 06:00:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <161486642115.2627.6663721087772908990@ietfa.amsl.com> Date: Thu, 04 Mar 2021 06:00:21 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 14:00:21 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-03-25 Reviewer LC end Draft Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Nancy Cam-Winget 2021-03-16 draft-ietf-acme-authority-token-tnauthlist Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Linda Dunbar 2021-03-23 draft-ietf-ecrit-location-profile-registry-policy Donald Eastlake 2021-03-22 draft-ietf-dots-rfc8782-bis Steve Hanna RNone draft-ietf-sfc-nsh-integrity Leif Johansson None draft-ietf-netconf-crypto-types Aanchal Malhotra 2021-01-26 draft-ietf-mpls-lsp-ping-registries-update Kathleen Moriarty 2021-02-05 draft-ietf-detnet-ip-over-tsn Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Tim Polk None draft-ietf-opsawg-finding-geofeeds Sean Turner 2021-02-25 draft-ietf-ntp-port-randomization Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Brian Weis R2020-12-02 draft-ietf-core-dev-urn Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Christopher Wood 2021-03-17 draft-ietf-core-yang-cbor Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Tina Tsou 2021-02-15 draft-ietf-idr-eag-distribution Paul Wouters 2021-02-19 draft-ietf-idr-bgp-ls-app-specific-attr Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson From nobody Thu Mar 4 19:49:43 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FCF3A1CEE; Thu, 4 Mar 2021 19:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHVDGljVYLdt; Thu, 4 Mar 2021 19:49:34 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF363A1CED; Thu, 4 Mar 2021 19:49:34 -0800 (PST) Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DsD9Y5fpcz67vPx; Fri, 5 Mar 2021 11:43:45 +0800 (CST) Received: from fraeml734-chm.china.huawei.com (10.206.15.215) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 5 Mar 2021 04:49:32 +0100 Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Fri, 5 Mar 2021 04:49:31 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.62]) by dggemm422-hub.china.huawei.com ([169.254.138.104]) with mapi id 14.03.0509.000; Fri, 5 Mar 2021 11:49:26 +0800 From: "Liubing (Remy)" To: Robert Sparks , "secdir@ietf.org" CC: "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-plc.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6lo-plc-05 Thread-Index: AdcRbH4t9b7VIKbJQXuL7t+1wklN7A== Date: Fri, 5 Mar 2021 03:49:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.242.194] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-plc-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 03:49:37 -0000 SGVsbG8gUm9iZXJ0LA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLiBJ dCBoZWxwcyBhIGxvdC4NCg0KUGxlYXNlIHNlZSBvdXIgcmVzcG9uc2UgaW5saW5lLg0KDQpCZXN0 IHJlZ2FyZHMsDQpSZW15DQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IFJvYmVy dCBTcGFya3MgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10gDQrlj5Hp gIHml7bpl7Q6IDIwMjHlubQy5pyIMTXml6UgNjo1MA0K5pS25Lu25Lq6OiBzZWNkaXJAaWV0Zi5v cmcNCuaKhOmAgTogNmxvQGlldGYub3JnOyBkcmFmdC1pZXRmLTZsby1wbGMuYWxsQGlldGYub3Jn OyBsYXN0LWNhbGxAaWV0Zi5vcmcNCuS4u+mimDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi02bG8tcGxjLTA1DQoNClJldmlld2VyOiBSb2JlcnQgU3BhcmtzDQpSZXZpZXcg cmVzdWx0OiBIYXMgSXNzdWVzDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3 IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNv bW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1 cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3Vs ZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21t ZW50cy4NCg0KVGhpcyBkb2N1bWVudCBoYXMgaXNzdWVzIHRoYXQgc2hvdWxkIGJlIGFkZHJlc3Nl ZCBiZWZvcmUgcHVibGljYXRpb24gYXMgUHJvcG9zZWQgU3RhbmRhcmQgUkZDLg0KDQpEb2N1bWVu dCByZXZpZXdlZDogZHJhZnQtaWV0Zi02bG8tcGxjLTA1DQoNClRoaXMgZG9jdW1lbnQncyBwcmlt YXJ5IHBvaW50IGlzIHRvIHN0YW5kYXJkaXplIG1hcHBpbmdzIG9mIGlwdjYgaWRlbnRpZmllcnMg Zm9yIHVzaW5nIGlwdjYgb3ZlciBJRUVFIDE5MDEuMSwgMTkwMS4yLCBhbmQgSVQtVCBHLjk5MDMg bmV0d29ya3MuDQoNClRob3NlIHN0YW5kYXJkcyBhcmUgbm90IHB1YmxpY3kgYXZhaWxhYmxlLCBh bmQgSSBoYXZlIG5vdCByZXZpZXdlZCBob3cgdGhlc2UgbWFwcGluZ3MgYW5kIHRoZSBzZWN1cml0 eSBtZWNoYW5pc21zIGluIHRob3NlIHByb3RvY29scyBpbnRlcmFjdC4NCg0KVGhlIGRvY3VtZW50 IGhhcyBjb250ZW50IHRoYXQgaXMgbm90IG5lZWRlZCBmb3IgaXRzIHB1cnBvc2UuIFNlY3Rpb24g NSBpbiBwYXJ0aWN1bGFyIG1pZ2h0IGJlIHVzZWZ1bCBpbiBhbiBpbmZvcm1hdGlvbmFsIFJGQywg YnV0IGlzIGhhcyBubyBpbXBhY3Qgb24gc29tZW9uZSBpbXBsZW1lbnRpbmcgd2hhdCB0aGlzIGRv Y3VtZW50IGlzIHRyeWluZyB0byBzdGFuZGFyZGl6ZS4NCltSZW15XSBZZXMsIHRoaXMgc2VjdGlv biBpcyBtb3JlIGxpa2UgaW5mb3JtYXRpb25hbC4gV2UnbGwgYXNrIHRoZSBXRyBpZiB3ZSBzaG91 bGQgcmVtb3ZlIGl0IG9yIG5vdC4gDQoNClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0 aW9uIHNwZWFrcyBwcmltYXJpbHkgdG8gZ2VuZXJpYyBjb25zaWRlcmF0aW9ucyBmb3IgNmxvLWxp a2UgbmV0d29ya3MuIFRoZXJlIGlzIG5vIHNwZWNpZmljIGRpc2N1c3Npb24gb2YgdGhlIGltcGFj dCBvZiB0aGUgaWRlbnRpZmllciBtYXBwaW5ncyB3aXRoIHRoZSB1bmRlcmx5aW5nIHByb3RvY29s cywgaW4gcGFydGljdWxhciB0aGUgY29uc3RyYWludHMgdGhhdCBkb24ndCBhbGxvdyB1c2luZyB0 aGUgZnVsbCBudW1iZXIgb2YgYml0cyBvZiBlbnRyb3B5IGluIHRoZSBpZGVudGlmaWVycyBpbiB0 aG9zZSB1bmRlcmx5aW5nIHByb3RvY29scy4gVGhlcmUgaXMgb25seSBhIHBhc3NpbmcgbWVudGlv biBvZiBSRkM4MDY1Lg0KW1JlbXldIFdlIHdvdWxkIGxpa2UgdG8gZXh0ZW5kIHRoZSBkZXNjcmlw dGlvbiBhcyBmb2xsb3dzOiBSRkM4MDY1IGRpc2N1c3NlcyB0aGUgcHJpdmFjeSB0aHJlYXRzIHdo ZW4gaW50ZXJmYWNlIGlkZW50aWZpZXJzIChJSUQpIGFyZSBnZW5lcmF0ZWQgd2l0aG91dCBzdWZm aWNpZW50IGVudHJvcHksIGluY2x1ZGluZyBjb3JyZWxhdGlvbiBvZiBhY3Rpdml0aWVzIG92ZXIg dGltZSwgbG9jYXRpb24gdHJhY2tpbmcsIGRldmljZS1zcGVjaWZpYyB2dWxuZXJhYmlsaXR5IGV4 cGxvaXRhdGlvbiwgYW5kIGFkZHJlc3Mgc2Nhbm5pbmcuIFNjaGVtZXMgc3VjaCBhcyBsaW1pdGVk IGxlYXNlIHBlcmlvZCBpbiBESENQdjYgW1JGQzMzMTVdIENyeXB0b2dyYXBoaWNhbGx5IEdlbmVy YXRlZCBBZGRyZXNzZXMgKENHQXMpIFtSRkMzOTcyXSwgcHJpdmFjeSBleHRlbnNpb25zIFtSRkM0 OTQxXSwgSGFzaC1CYXNlZCBBZGRyZXNzZXMgKEhCQXMpIFtSRkM1NTM1XSwgb3Igc2VtYW50aWNh bGx5IG9wYXF1ZSBhZGRyZXNzZXMgW1JGQzcyMTddIFNIT1VMRCBiZSBjb25zaWRlcmVkIHRvIGVu aGFuY2UgdGhlIElJRCBwcml2YWN5LiBBcyBwZXIgUkZDODA2NSwgd2hlbiBzaG9ydCBhZGRyZXNz ZXMgYXJlIHVzZWQgb24gUExDIGxpbmtzLCBhIHNoYXJlZCBzZWNyZXQga2V5IG9yIHZlcnNpb24g bnVtYmVyIGZyb20gdGhlIEF1dGhvcml0YXRpdmUgQm9yZGVyIFJvdXRlciBPcHRpb24gW1JGQzY3 NzVdIGNhbiBiZSB1c2VkIHRvIGltcHJvdmUgdGhlIGVudHJvcHkgb2YgdGhlIGhhc2ggaW5wdXQs IHRodXMgdGhlIGdlbmVyYXRlZCBJSUQgY2FuIGJlIHNwcmVhZCBvdXQgdG8gdGhlIGZ1bGwgcmFu Z2Ugb2YgdGhlIElJRCBhZGRyZXNzIHNwYWNlIHdoaWxlIHN0YXRlbGVzcyBhZGRyZXNzIGNvbXBy ZXNzaW9uIGlzIHN0aWxsIGFsbG93ZWQuDQpEbyB5b3UgdGhpbmsgaXQgc29sdmVzIHRoZSBpc3N1 ZT8NCg0KSW1wbGVtZW50b3JzIGFyZSBhZHZpc2VkIHRvICJsb29rIGF0IiBSRkM4NjA0IHdoZW4g Y29uc2lkZXJpbmcgYnVpbGRpbmcgc3RhYmxlIGFkZHJlc3NlcywgYnV0IHRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIGRvaW5nIHRoaW5ncyB0aGF0IFJGQzg2MDQgcmVjb21tZW5kcyBhZ2FpbnN0IChz ZWUgdGhlIHVzZSBvZiBSRkMyNDY0LCBmb3IgZXhhbXBsZSkuIE1vcmUgZGlzY3Vzc2lvbiBzZWVt cyB3YXJyYW50ZWQuDQpbUmVteV0gSW4gdGhlIHNhbWUgcGFyYWdyYXBoIHdlIHJlZmVyZW5jZSBS RkM4NjA0LCB3ZSBsaW1pdCB0aGUgdXNhZ2Ugb2YgTUFDIGdlbmVyYXRlZCBJSUQgYXMgcGVyIFJG QzI0NjQgaW4gbGluay1sb2NhbCBhZGRyZXNzIGNvbmZpZ3VyYXRpb24uDQoNClRoZXJlIGlzIGEg c2hvcnQgbWVudGlvbiBvZiB0aGUgcG9zc2liaWxpdHkgb2YgYWNxdWlyaW5nIGEgbmV0d29yayBl bmNyeXB0aW9uIGtleSBkdXJpbmcgb25ib2FyZGluZyBidXQgdGhlcmUncyBubyBkaXNjdXNzaW9u IGFib3V0IHdoYXQgdGhhdCBtZWFucyBmb3IgdGhlc2Ugc3BlY2lmaWMgbGF5ZXItMiBwcm90b2Nv bHMuDQpbUmVteV0gVGhlIGFjcXVpcmVtZW50IG9mIGxheWVyLTIgZW5jcnlwdGlvbiBrZXkgaXMg c3BlY2lmaWVkIGluIHRoZSBJRUVFIGFuZCBJVFUtVCBzdGFuZGFyZHMgYW5kIG5vdCByZWxhdGVk IHRvIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZXNzIGluIHRoZSBzYW1lIHBhcmFncmFwaC4gVGh1 cyB0aGlzIHBocmFzZSBpcyByZWR1bmRhbnQsIGFuZCB3ZSBwcmVmZXIgdG8gcmVtb3ZlIHRoaXMg cGhyYXNlLg0KDQoNCkVkaXRvcmlhbCBjb21tZW50czoNCg0KQXQgc2VjdGlvbiA0LjYsIHRoZSBm aXJzdCBwYXJhZ3JhcGggY2FuIG1ha2UgaXRzIHBvaW50IG1vcmUgY2xlYXJseS4gQWxsIHRoYXQn cyBuZWVkZWQgdG8gc2F5IGlzIHRoYXQgdGhlIGxvd2VyIGxheWVycyBoYW5kbGUgc2VnbWVudGF0 aW9uIGFuZCByZWFzc2VtYmx5LCBidXQgdGhlIGFkYXB0YXRpb24gbGF5ZXIgc3RpbGwgbmVlZHMg dG8gYmUgcmVhZHkgdG8gZG8gc28gaW4gdGhlIGxvd2VyIGxheWVyIGNhbnQgaGFuZGxlIHRoZSAx MjgwIG9jdGV0IE1UVS4gQXQgdGhlIGxhc3QgcGFyYWdyYXBoLCB3aGVuIHlvdSBzYXkgInJlZmVy cmluZyB0byINCmRvIHlvdSBtZWFuICJhcyBzcGVjaWZpZWQgaW4iPw0KW1JlbXldIFRoYXQncyBh IGdvb2QgcG9pbnQuIFdlIHdvdWxkIGxpa2UgdG8gc2ltcGxpZnkgdGhlIGZpcnN0IHBhcmFncmFw aCBvZiB0aGUgc2VjdGlvbiA0LjYgYXMgZm9sbG93czogUExDIE1BQyBsYXllciBwcm92aWRlcyB0 aGUgZnVuY3Rpb24gb2Ygc2VnbWVudGF0aW9uIGFuZCByZWFzc2VtYmx5LCBob3dldmVyLCBGcmFn bWVudGF0aW9uIGFuZCByZWFzc2VtYmx5IGlzIHN0aWxsIHJlcXVpcmVkIGF0IHRoZSBhZGFwdGF0 aW9uIGxheWVyLCBpZiB0aGUgTUFDIGxheWVyIGNhbm5vdCBzdXBwb3J0IHRoZSBtaW5pbXVtIE1U VSBkZW1hbmRlZCBieSBJUHY2LCB3aGljaCBpcyAxMjgwIG9jdGV0cy4NClllcywgd2Ugd2lsbCBj aGFuZ2UgaXQgdG8gImFzIHNwZWNpZmllZCBpbiIuDQoNCkF0IHNlY3Rpb24gNywgIkZvciBzZWN1 cml0eSBjb25zaWRlcmF0aW9uLCBsaW5rIGxheWVyIHNlY3VyaXR5IGlzIGd1YXJhbnRlZWQgaW4g ZXZlcnkgUExDIHRlY2hub2xvZ3kuIiBuZWVkcyBjbGFyaWZpY2F0aW9uLiBEbyB5b3UgbWVhbiB0 aGUgdGhyZWUgcHJvdG9jb2xzIGRpc2N1c3NlZCBoZXJlIHByb3ZpZGUgbGluayBsYXllciBzZWN1 cml0eT8gT3IgZG8geW91IG1lYW4gdG8gc2F5IHRoYXQgaWYgYW55b25lIHBsYW5zIHRvIHByb3Zp ZGUgYW4gYWRhcHRhdGlvbiBsYXllciB0byBzb21lIG90aGVyIFBMQyBwcm90b2NvbCwgdGhhdCBp dCBtdXN0IHByb3ZpZGUgbGluayBsYXllciBzZWN1cml0eT8gT3IgZG8geW91IG1lYW4gc29tZXRo aW5nIGVsc2U/DQpbUmVteV0gV2UgbWVhbnQgdGhhdCBsaW5rIGxheWVyIHNlY3VyaXR5IG1lY2hh bmlzbXMgYXJlIGRlc2lnbmVkIGluIHRoZXNlIHRocmVlIFBMQyB0ZWNobm9sb2dpZXMuIFdlIHdp bGwgcmVwaHJhc2UgaXQuIA0KTml0OiBFeHBhbmQgTExOIG9uIGZpcnN0IHVzZS4NCltSZW15XSBX aWxsIHVwZGF0ZSBpdC4NCg0K From nobody Fri Mar 5 07:58:07 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F243A2722; Fri, 5 Mar 2021 07:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReetF_o6-qx2; Fri, 5 Mar 2021 07:57:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C677C3A2712; Fri, 5 Mar 2021 07:57:54 -0800 (PST) Received: from unformal.local ([47.186.1.92]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 125Fvb7f000698 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Mar 2021 09:57:38 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1614959858; bh=J8GtWsrykqh5KX48LqhwTFAgeAAkipcYOWHmKn7SR3Y=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=qUlkYrLUobc21HFobG/zC0DKvxq/KGx8KBv+A/OTaDNEVTJp+5eTz16wVO+XP+JNP ND4jYr0rnHKZIS4QUfb0w3LUF98m2fbklswNCVgygIFAhvAZbtjtqVFpxXxPjny7Uc ynk+QTMSkYHimyhoYMvHhejVOB3foc41ieHFFwz4= X-Authentication-Warning: raven.nostrum.com: Host [47.186.1.92] claimed to be unformal.local To: "Liubing (Remy)" , "secdir@ietf.org" Cc: "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-plc.all@ietf.org" , "last-call@ietf.org" References: From: Robert Sparks Message-ID: <39b86d13-4e48-75bd-e85b-d5231740369a@nostrum.com> Date: Fri, 5 Mar 2021 09:57:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-plc-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 15:57:57 -0000 Inline. On 3/4/21 9:49 PM, Liubing (Remy) wrote: > Hello Robert, > > Thank you very much for your comments. It helps a lot. > > Please see our response inline. > > Best regards, > Remy > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Robert Sparks via Datatracker [mailto:nore= ply@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B42=E6=9C=8815=E6=97=A5= 6:50 > =E6=94=B6=E4=BB=B6=E4=BA=BA: secdir@ietf.org > =E6=8A=84=E9=80=81: 6lo@ietf.org; draft-ietf-6lo-plc.all@ietf.org; last= -call@ietf.org > =E4=B8=BB=E9=A2=98: Secdir last call review of draft-ietf-6lo-plc-05 > > Reviewer: Robert Sparks > Review result: Has Issues > > I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. The= se comments were written primarily for the benefit of the security area d= irectors. Document editors and WG chairs should treat these comments just= like any other last call comments. > > This document has issues that should be addressed before publication as= Proposed Standard RFC. > > Document reviewed: draft-ietf-6lo-plc-05 > > This document's primary point is to standardize mappings of ipv6 identi= fiers for using ipv6 over IEEE 1901.1, 1901.2, and IT-T G.9903 networks. > > Those standards are not publicy available, and I have not reviewed how = these mappings and the security mechanisms in those protocols interact. > > The document has content that is not needed for its purpose. Section 5 = in particular might be useful in an informational RFC, but is has no impa= ct on someone implementing what this document is trying to standardize. > [Remy] Yes, this section is more like informational. We'll ask the WG i= f we should remove it or not. > > The security considerations section speaks primarily to generic conside= rations for 6lo-like networks. There is no specific discussion of the imp= act of the identifier mappings with the underlying protocols, in particul= ar the constraints that don't allow using the full number of bits of entr= opy in the identifiers in those underlying protocols. There is only a pas= sing mention of RFC8065. > [Remy] We would like to extend the description as follows: RFC8065 disc= usses the privacy threats when interface identifiers (IID) are generated = without sufficient entropy, including correlation of activities over time= , location tracking, device-specific vulnerability exploitation, and addr= ess scanning. Schemes such as limited lease period in DHCPv6 [RFC3315] Cr= yptographically Generated Addresses (CGAs) [RFC3972], privacy extensions = [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], or semantically opaque = addresses [RFC7217] SHOULD be considered to enhance the IID privacy. As p= er RFC8065, when short addresses are used on PLC links, a shared secret k= ey or version number from the Authoritative Border Router Option [RFC6775= ] can be used to improve the entropy of the hash input, thus the generate= d IID can be spread out to the full range of the IID address space while = stateless address compression is still allowed. > Do you think it solves the issue? It's better, yes, but I hope people with more expertise and experience=20 with the recommendations than me look closely at it. > > Implementors are advised to "look at" RFC8604 when considering building= stable addresses, but this document specifies doing things that RFC8604 = recommends against (see the use of RFC2464, for example). More discussion= seems warranted. > [Remy] In the same paragraph we reference RFC8604, we limit the usage o= f MAC generated IID as per RFC2464 in link-local address configuration. Well, that's my point - I think RFC8064 (sorry for my original typo=20 above) recommends NOT to do the things in 2464 that you are saying to=20 do. I could be wrong. But having clearer text noting how what you are=20 requiring avoids the issues 8064 brings up would help. Again, I hope=20 people with more expertise than me look closely here. > > There is a short mention of the possibility of acquiring a network encr= yption key during onboarding but there's no discussion about what that me= ans for these specific layer-2 protocols. > [Remy] The acquirement of layer-2 encryption key is specified in the IE= EE and ITU-T standards and not related to the authentication process in t= he same paragraph. Thus this phrase is redundant, and we prefer to remove= this phrase. > > > Editorial comments: > > At section 4.6, the first paragraph can make its point more clearly. Al= l that's needed to say is that the lower layers handle segmentation and r= eassembly, but the adaptation layer still needs to be ready to do so in t= he lower layer cant handle the 1280 octet MTU. At the last paragraph, whe= n you say "referring to" > do you mean "as specified in"? > [Remy] That's a good point. We would like to simplify the first paragra= ph of the section 4.6 as follows: PLC MAC layer provides the function of = segmentation and reassembly, however, Fragmentation and reassembly is sti= ll required at the adaptation layer, if the MAC layer cannot support the = minimum MTU demanded by IPv6, which is 1280 octets. > Yes, we will change it to "as specified in". > > At section 7, "For security consideration, link layer security is guara= nteed in every PLC technology." needs clarification. Do you mean the thre= e protocols discussed here provide link layer security? Or do you mean to= say that if anyone plans to provide an adaptation layer to some other PL= C protocol, that it must provide link layer security? Or do you mean some= thing else? > [Remy] We meant that link layer security mechanisms are designed in the= se three PLC technologies. We will rephrase it. > Nit: Expand LLN on first use. > [Remy] Will update it. > From nobody Sat Mar 6 18:27:43 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 895B03A19B7; Thu, 4 Mar 2021 03:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1614858429; bh=g/9i+V7LvYctCwovvKR+sARTsHGSYXdRxu44D9Ma72Y=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=BbYlWNrSA0qL7UstQHnYF2h1idVlzJtDMEuRUG6msRm951XspR3Kv/ileuZDabpSd ABmkq5xxywohaCwDC6Jdnyl/W4EIxlqxGR11B7Un3tN6aWXcVzXaSWn/mQ1inD01wE 2HkSe/VbXGW9jkX5wxgjEfpjkLri1iVD5EWcFDdE= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Mar 4 03:47:09 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E83F43A19AF; Thu, 4 Mar 2021 03:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1614858429; bh=g/9i+V7LvYctCwovvKR+sARTsHGSYXdRxu44D9Ma72Y=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=BbYlWNrSA0qL7UstQHnYF2h1idVlzJtDMEuRUG6msRm951XspR3Kv/ileuZDabpSd ABmkq5xxywohaCwDC6Jdnyl/W4EIxlqxGR11B7Un3tN6aWXcVzXaSWn/mQ1inD01wE 2HkSe/VbXGW9jkX5wxgjEfpjkLri1iVD5EWcFDdE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2253D3A19AF for ; Thu, 4 Mar 2021 03:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89m3kaISUEFC for ; Thu, 4 Mar 2021 03:47:05 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422F63A19AC for ; Thu, 4 Mar 2021 03:47:05 -0800 (PST) Received: from [89.187.161.155] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lHmRb-0002UC-K8 for new-work@ietf.org; Thu, 04 Mar 2021 11:47:03 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Thu, 4 Mar 2021 19:47:00 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 06 Mar 2021 18:27:41 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web & Networks Interest Group (until 2021-04-02/03) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 11:47:11 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBXZWIgJiBO ZXR3b3JrcyBJbnRlcmVzdCBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDIxLzAzL3By b3Bvc2VkLXdlYi1uZXR3b3Jrcy1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhh dCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRy YWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmll dyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAwMzo1OSBVVEMg b24gMjAyMS0wNC0wMwooMjM6NTksIEVhc3Rlcm4gdGltZSBvbiAyMDIxLTA0LTAyKcKgIG9uIHRo ZSBwcm9wb3NlZCBjaGFydGVyLgpQbGVhc2Ugc2VuZCBjb21tZW50cyB0byBwdWJsaWMtbmV3LXdv cmtAdzMub3JnLAp3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9saXN0cy53 My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVu dHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVw cmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRz LiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91 ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBG b3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlz IGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVm ZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ug c2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBs ZWFzZQpjb250YWN0IERvbWluaXF1ZSBIYXphZWwtTWFzc2lldXgsIFRlYW0gQ29udGFjdCBmb3Ig dGhlCldlYiAmIE5ldHdvcmtzIEludGVyZXN0IEdyb3VwIDxkb21AdzMub3JnPi4KClRoYW5rIHlv dSwKClh1ZXl1YW4gSmlhLMKgIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0 dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5l dy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3 LXdvcmsK From nobody Mon Mar 8 04:37:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A4D3A0E4F; Mon, 8 Mar 2021 04:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1615206744; bh=f2GvP6Fdke2VliKI38BdAeKH3d6jDX8LereJMxM7wfI=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=E3NRNkljTjGZJOrSvn6m7izGg6xZHrUITNa6iQS0avoWRg3vkx8oaq35gNa8iM/u6 ludt+aglca+tcBSUt3C5Cg55hpwAYvryMGpeaaORmec5Kn4fXAh8Q4y1fXtmb5tcvK iwVq4HzX7vo8tRgrKQYTz5t+6DfVr1OOaMcjZcnA= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Mar 8 04:32:18 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 345BD3A0E49; Mon, 8 Mar 2021 04:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1615206738; bh=f2GvP6Fdke2VliKI38BdAeKH3d6jDX8LereJMxM7wfI=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=RepbD4jAQi8U1KClaHWr7wgbGuagE45X4dRrnYNSriDlBUVjGlz+8571slGLDmgJN TBNBaZQXCPVh4gWWZf1VcYB8LV2JTAAbaYCbGYTvtscr4MLS6VAhot5T7vdmOQt7i9 MxOEUEYdiicgydbh8epoKWHxwY+7IL909kS6erIE= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A86E3A0DC5 for ; Mon, 8 Mar 2021 04:32:10 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <161520673022.27571.10336322111769707446@ietfa.amsl.com> Date: Mon, 08 Mar 2021 04:32:10 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 08 Mar 2021 04:37:02 -0800 Subject: [secdir] [new-work] WG Review: QUIC (quic) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 12:32:30 -0000 The QUIC (quic) WG in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-03-18. QUIC (quic) ----------------------------------------------------------------------- Current status: Active WG Chairs: Lucas Pardue Lars Eggert Matt Joras Assigned Area Director: Magnus Westerlund Transport Area Directors: Magnus Westerlund Martin Duke Mailing list: Address: quic@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/quic Archive: https://mailarchive.ietf.org/arch/browse/quic/ Group page: https://datatracker.ietf.org/group/quic/ Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/ The QUIC WG originated the specifications describing version 1 of QUIC, a UDP-based, stream-multiplexing, encrypted transport protocol. The WG acts as the focal point for any QUIC-related work in the IETF. It is chartered to pursue work in the areas detailed below: 1. The first area of work is maintenance and evolution of the existing QUIC specifications: * Maintenance and evolution of the QUIC base specifications that describe its invariants, core transport mechanisms, security and privacy properties, loss detection and recovery, congestion control, version and extension negotiation, etc. This includes the specification of new versions of QUIC. * Maintenance and evolution of the existing QUIC extensions specified by the WG. WG adoption of work items falling into this first area of work needs to be strongly motivated by existing or ongoing production deployments of QUIC at scale, and needs to carefully consider its impact on the applications that have adopted QUIC as a transport. 2. The second area of work is supporting the deployability of QUIC, which includes specifications and documents such as applicability and manageability statements, improved operation with load balancers, the specification of a logging format, and more. 3. The third area of work is the specification of new extensions to QUIC. The WG will primarily focus on extensions to the QUIC transport layer, i.e., extensions to QUIC that have broad applicability to multiple application protocols. The WG may also publish specifications to publicly document deployed proprietary extensions or to enable wider experimentation with proposed new protocol features. Specifications describing how new or existing application protocols use the QUIC transport layer, called application protocol mappings below, need not be specified in the QUIC WG, although they can. The QUIC WG will collaborate with other groups that define such application protocols that intend to use QUIC. New application protocol mappings might require QUIC extensions and it may be efficient to define these alongside the mapping specifications. Groups that define application protocols using QUIC, or extensions to QUIC in support of those protocols, are strongly requested to consult with the QUIC WG and seek early and ongoing review of and collaboration on proposals. This is intended to reduce the possibility of duplicate work and/or conflicts with other extensions. The QUIC WG originated HTTP/3, the mapping of HTTP to QUIC, and the QPACK header compression scheme. These specifications are now maintained in the HTTP WG. Defining new congestion control schemes is explicitly out of scope for the WG. However, new QUIC extensions that support development and experimentation with new congestion control schemes may fall under the third work area. Milestones: May 2021 - QUIC Applicability and Manageability Statement to IESG Jun 2021 - Datagram Extension to IESG Sep 2021 - Version Negotiation Extension to IESG Sep 2021 - QUIC-LB: Generating Routable QUIC Connection IDs to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Mar 8 19:30:59 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647B03A0CD6; Mon, 8 Mar 2021 19:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qkimt4yzLNq; Mon, 8 Mar 2021 19:30:46 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602063A0B68; Mon, 8 Mar 2021 19:30:46 -0800 (PST) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DvgYs69Tnz67wwV; Tue, 9 Mar 2021 11:24:49 +0800 (CST) Received: from dggpeml100009.china.huawei.com (7.185.36.95) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 9 Mar 2021 04:30:44 +0100 Received: from dggpeml500011.china.huawei.com (7.185.36.84) by dggpeml100009.china.huawei.com (7.185.36.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 9 Mar 2021 11:30:42 +0800 Received: from dggpeml500011.china.huawei.com ([7.185.36.84]) by dggpeml500011.china.huawei.com ([7.185.36.84]) with mapi id 15.01.2106.013; Tue, 9 Mar 2021 11:30:42 +0800 From: "Liubing (Remy)" To: Robert Sparks , "secdir@ietf.org" CC: "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-plc.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-6lo-plc-05 Thread-Index: AdcUk3r8tBzJOp7BSmadmQkBLMQkcw== Date: Tue, 9 Mar 2021 03:30:42 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.242.194] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-plc-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 03:30:49 -0000 SGVsbG8gUm9iZXJ0LA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuIFBsZWFzZSBmaW5kIG15 IHRleHQgaW5saW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQpSZW15DQotLS0tLemCruS7tuWOn+S7ti0t LS0tDQrlj5Hku7bkuro6IFJvYmVydCBTcGFya3MgW21haWx0bzpyanNwYXJrc0Bub3N0cnVtLmNv bV0gDQrlj5HpgIHml7bpl7Q6IDIwMjHlubQz5pyINeaXpSAyMzo1OA0K5pS25Lu25Lq6OiBMaXVi aW5nIChSZW15KSA8cmVteS5saXViaW5nQGh1YXdlaS5jb20+OyBzZWNkaXJAaWV0Zi5vcmcNCuaK hOmAgTogNmxvQGlldGYub3JnOyBkcmFmdC1pZXRmLTZsby1wbGMuYWxsQGlldGYub3JnOyBsYXN0 LWNhbGxAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtNmxvLXBsYy0wNQ0KDQpJbmxpbmUuDQoNCk9uIDMvNC8yMSA5OjQ5IFBNLCBMaXVi aW5nIChSZW15KSB3cm90ZToNCj4gSGVsbG8gUm9iZXJ0LA0KPg0KPiBUaGFuayB5b3UgdmVyeSBt dWNoIGZvciB5b3VyIGNvbW1lbnRzLiBJdCBoZWxwcyBhIGxvdC4NCj4NCj4gUGxlYXNlIHNlZSBv dXIgcmVzcG9uc2UgaW5saW5lLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFJlbXkNCj4gLS0tLS3p gq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IFJvYmVydCBTcGFya3MgdmlhIERhdGF0cmFj a2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4g5Y+R6YCB5pe26Ze0OiAyMDIx5bm0Muac iDE15pelIDY6NTANCj4g5pS25Lu25Lq6OiBzZWNkaXJAaWV0Zi5vcmcNCj4g5oqE6YCBOiA2bG9A aWV0Zi5vcmc7IGRyYWZ0LWlldGYtNmxvLXBsYy5hbGxAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRm Lm9yZw0KPiDkuLvpopg6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtNmxv LXBsYy0wNQ0KPg0KPiBSZXZpZXdlcjogUm9iZXJ0IFNwYXJrcw0KPiBSZXZpZXcgcmVzdWx0OiBI YXMgSXNzdWVzDQo+DQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2Yg dGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJ RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRz IHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVh dCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4N Cj4NCj4gVGhpcyBkb2N1bWVudCBoYXMgaXNzdWVzIHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZCBi ZWZvcmUgcHVibGljYXRpb24gYXMgUHJvcG9zZWQgU3RhbmRhcmQgUkZDLg0KPg0KPiBEb2N1bWVu dCByZXZpZXdlZDogZHJhZnQtaWV0Zi02bG8tcGxjLTA1DQo+DQo+IFRoaXMgZG9jdW1lbnQncyBw cmltYXJ5IHBvaW50IGlzIHRvIHN0YW5kYXJkaXplIG1hcHBpbmdzIG9mIGlwdjYgaWRlbnRpZmll cnMgZm9yIHVzaW5nIGlwdjYgb3ZlciBJRUVFIDE5MDEuMSwgMTkwMS4yLCBhbmQgSVQtVCBHLjk5 MDMgbmV0d29ya3MuDQo+DQo+IFRob3NlIHN0YW5kYXJkcyBhcmUgbm90IHB1YmxpY3kgYXZhaWxh YmxlLCBhbmQgSSBoYXZlIG5vdCByZXZpZXdlZCBob3cgdGhlc2UgbWFwcGluZ3MgYW5kIHRoZSBz ZWN1cml0eSBtZWNoYW5pc21zIGluIHRob3NlIHByb3RvY29scyBpbnRlcmFjdC4NCj4NCj4gVGhl IGRvY3VtZW50IGhhcyBjb250ZW50IHRoYXQgaXMgbm90IG5lZWRlZCBmb3IgaXRzIHB1cnBvc2Uu IFNlY3Rpb24gNSBpbiBwYXJ0aWN1bGFyIG1pZ2h0IGJlIHVzZWZ1bCBpbiBhbiBpbmZvcm1hdGlv bmFsIFJGQywgYnV0IGlzIGhhcyBubyBpbXBhY3Qgb24gc29tZW9uZSBpbXBsZW1lbnRpbmcgd2hh dCB0aGlzIGRvY3VtZW50IGlzIHRyeWluZyB0byBzdGFuZGFyZGl6ZS4NCj4gW1JlbXldIFllcywg dGhpcyBzZWN0aW9uIGlzIG1vcmUgbGlrZSBpbmZvcm1hdGlvbmFsLiBXZSdsbCBhc2sgdGhlIFdH IGlmIHdlIHNob3VsZCByZW1vdmUgaXQgb3Igbm90Lg0KPg0KPiBUaGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBzcGVha3MgcHJpbWFyaWx5IHRvIGdlbmVyaWMgY29uc2lkZXJhdGlv bnMgZm9yIDZsby1saWtlIG5ldHdvcmtzLiBUaGVyZSBpcyBubyBzcGVjaWZpYyBkaXNjdXNzaW9u IG9mIHRoZSBpbXBhY3Qgb2YgdGhlIGlkZW50aWZpZXIgbWFwcGluZ3Mgd2l0aCB0aGUgdW5kZXJs eWluZyBwcm90b2NvbHMsIGluIHBhcnRpY3VsYXIgdGhlIGNvbnN0cmFpbnRzIHRoYXQgZG9uJ3Qg YWxsb3cgdXNpbmcgdGhlIGZ1bGwgbnVtYmVyIG9mIGJpdHMgb2YgZW50cm9weSBpbiB0aGUgaWRl bnRpZmllcnMgaW4gdGhvc2UgdW5kZXJseWluZyBwcm90b2NvbHMuIFRoZXJlIGlzIG9ubHkgYSBw YXNzaW5nIG1lbnRpb24gb2YgUkZDODA2NS4NCj4gW1JlbXldIFdlIHdvdWxkIGxpa2UgdG8gZXh0 ZW5kIHRoZSBkZXNjcmlwdGlvbiBhcyBmb2xsb3dzOiBSRkM4MDY1IGRpc2N1c3NlcyB0aGUgcHJp dmFjeSB0aHJlYXRzIHdoZW4gaW50ZXJmYWNlIGlkZW50aWZpZXJzIChJSUQpIGFyZSBnZW5lcmF0 ZWQgd2l0aG91dCBzdWZmaWNpZW50IGVudHJvcHksIGluY2x1ZGluZyBjb3JyZWxhdGlvbiBvZiBh Y3Rpdml0aWVzIG92ZXIgdGltZSwgbG9jYXRpb24gdHJhY2tpbmcsIGRldmljZS1zcGVjaWZpYyB2 dWxuZXJhYmlsaXR5IGV4cGxvaXRhdGlvbiwgYW5kIGFkZHJlc3Mgc2Nhbm5pbmcuIFNjaGVtZXMg c3VjaCBhcyBsaW1pdGVkIGxlYXNlIHBlcmlvZCBpbiBESENQdjYgW1JGQzMzMTVdIENyeXB0b2dy YXBoaWNhbGx5IEdlbmVyYXRlZCBBZGRyZXNzZXMgKENHQXMpIFtSRkMzOTcyXSwgcHJpdmFjeSBl eHRlbnNpb25zIFtSRkM0OTQxXSwgSGFzaC1CYXNlZCBBZGRyZXNzZXMgKEhCQXMpIFtSRkM1NTM1 XSwgb3Igc2VtYW50aWNhbGx5IG9wYXF1ZSBhZGRyZXNzZXMgW1JGQzcyMTddIFNIT1VMRCBiZSBj b25zaWRlcmVkIHRvIGVuaGFuY2UgdGhlIElJRCBwcml2YWN5LiBBcyBwZXIgUkZDODA2NSwgd2hl biBzaG9ydCBhZGRyZXNzZXMgYXJlIHVzZWQgb24gUExDIGxpbmtzLCBhIHNoYXJlZCBzZWNyZXQg a2V5IG9yIHZlcnNpb24gbnVtYmVyIGZyb20gdGhlIEF1dGhvcml0YXRpdmUgQm9yZGVyIFJvdXRl ciBPcHRpb24gW1JGQzY3NzVdIGNhbiBiZSB1c2VkIHRvIGltcHJvdmUgdGhlIGVudHJvcHkgb2Yg dGhlIGhhc2ggaW5wdXQsIHRodXMgdGhlIGdlbmVyYXRlZCBJSUQgY2FuIGJlIHNwcmVhZCBvdXQg dG8gdGhlIGZ1bGwgcmFuZ2Ugb2YgdGhlIElJRCBhZGRyZXNzIHNwYWNlIHdoaWxlIHN0YXRlbGVz cyBhZGRyZXNzIGNvbXByZXNzaW9uIGlzIHN0aWxsIGFsbG93ZWQuDQo+IERvIHlvdSB0aGluayBp dCBzb2x2ZXMgdGhlIGlzc3VlPw0KSXQncyBiZXR0ZXIsIHllcywgYnV0IEkgaG9wZSBwZW9wbGUg d2l0aCBtb3JlIGV4cGVydGlzZSBhbmQgZXhwZXJpZW5jZSB3aXRoIHRoZSByZWNvbW1lbmRhdGlv bnMgdGhhbiBtZSBsb29rIGNsb3NlbHkgYXQgaXQuDQo+DQo+IEltcGxlbWVudG9ycyBhcmUgYWR2 aXNlZCB0byAibG9vayBhdCIgUkZDODYwNCB3aGVuIGNvbnNpZGVyaW5nIGJ1aWxkaW5nIHN0YWJs ZSBhZGRyZXNzZXMsIGJ1dCB0aGlzIGRvY3VtZW50IHNwZWNpZmllcyBkb2luZyB0aGluZ3MgdGhh dCBSRkM4NjA0IHJlY29tbWVuZHMgYWdhaW5zdCAoc2VlIHRoZSB1c2Ugb2YgUkZDMjQ2NCwgZm9y IGV4YW1wbGUpLiBNb3JlIGRpc2N1c3Npb24gc2VlbXMgd2FycmFudGVkLg0KPiBbUmVteV0gSW4g dGhlIHNhbWUgcGFyYWdyYXBoIHdlIHJlZmVyZW5jZSBSRkM4NjA0LCB3ZSBsaW1pdCB0aGUgdXNh Z2Ugb2YgTUFDIGdlbmVyYXRlZCBJSUQgYXMgcGVyIFJGQzI0NjQgaW4gbGluay1sb2NhbCBhZGRy ZXNzIGNvbmZpZ3VyYXRpb24uDQoNCldlbGwsIHRoYXQncyBteSBwb2ludCAtIEkgdGhpbmsgUkZD ODA2NCAoc29ycnkgZm9yIG15IG9yaWdpbmFsIHR5cG8NCmFib3ZlKSByZWNvbW1lbmRzIE5PVCB0 byBkbyB0aGUgdGhpbmdzIGluIDI0NjQgdGhhdCB5b3UgYXJlIHNheWluZyB0byBkby4gSSBjb3Vs ZCBiZSB3cm9uZy4gQnV0IGhhdmluZyBjbGVhcmVyIHRleHQgbm90aW5nIGhvdyB3aGF0IHlvdSBh cmUgcmVxdWlyaW5nIGF2b2lkcyB0aGUgaXNzdWVzIDgwNjQgYnJpbmdzIHVwIHdvdWxkIGhlbHAu IEFnYWluLCBJIGhvcGUgcGVvcGxlIHdpdGggbW9yZSBleHBlcnRpc2UgdGhhbiBtZSBsb29rIGNs b3NlbHkgaGVyZS4NCg0KW1JlbXldIFRoZSBwcm9ibGVtIGhhcyBiZWVuIHNvbHZlZCBpbiBSRkM4 MDY1IChkZXNpZ25lZCBpbiA2bG8pLCB3aGVuIHNob3J0IGFkZHJlc3NlcyAodGhlIDE2IG9yIDEy IGJpdHMgbGluayBsYXllciBhZGRyZXNzKSBhcmUgdXNlZCBvbiBQTEMgbGlua3MsIGEgc2hhcmVk IHNlY3JldCBrZXkgb3IgdmVyc2lvbiBudW1iZXIgZnJvbSB0aGUgQXV0aG9yaXRhdGl2ZSBCb3Jk ZXIgUm91dGVyIE9wdGlvbiBbUkZDNjc3NV0gY2FuIGJlIHVzZWQgdG8gaW1wcm92ZSB0aGUgZW50 cm9weSBvZiB0aGUgaGFzaCBpbnB1dCwgdGh1cyB0aGUgZ2VuZXJhdGVkIElJRCBjYW4gYmUgc3By ZWFkIG91dCB0byB0aGUgZnVsbCByYW5nZSBvZiB0aGUgSUlEIGFkZHJlc3Mgc3BhY2Ugd2hpbGUg c3RhdGVsZXNzIGFkZHJlc3MgY29tcHJlc3Npb24gaXMgc3RpbGwgYWxsb3dlZC4gV2Ugd2lsbCB1 cGRhdGUgdGhlIGRyYWZ0IHRvIGNoYW5nZSB0aGUgcmVmZXJlbmNlIHRvIFJGQzgwNjQgaW50byB0 aGUgcmVmZXJlbmNlIHRvIFJGQzgwNjUsIGFuZCBzcGVjaWZ5IHRoZSBzb2x1dGlvbiBpbiBzZWN0 aW9uIDQuMSBpbnN0ZWFkIG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCj4NCj4gVGhl cmUgaXMgYSBzaG9ydCBtZW50aW9uIG9mIHRoZSBwb3NzaWJpbGl0eSBvZiBhY3F1aXJpbmcgYSBu ZXR3b3JrIGVuY3J5cHRpb24ga2V5IGR1cmluZyBvbmJvYXJkaW5nIGJ1dCB0aGVyZSdzIG5vIGRp c2N1c3Npb24gYWJvdXQgd2hhdCB0aGF0IG1lYW5zIGZvciB0aGVzZSBzcGVjaWZpYyBsYXllci0y IHByb3RvY29scy4NCj4gW1JlbXldIFRoZSBhY3F1aXJlbWVudCBvZiBsYXllci0yIGVuY3J5cHRp b24ga2V5IGlzIHNwZWNpZmllZCBpbiB0aGUgSUVFRSBhbmQgSVRVLVQgc3RhbmRhcmRzIGFuZCBu b3QgcmVsYXRlZCB0byB0aGUgYXV0aGVudGljYXRpb24gcHJvY2VzcyBpbiB0aGUgc2FtZSBwYXJh Z3JhcGguIFRodXMgdGhpcyBwaHJhc2UgaXMgcmVkdW5kYW50LCBhbmQgd2UgcHJlZmVyIHRvIHJl bW92ZSB0aGlzIHBocmFzZS4NCj4NCj4NCj4gRWRpdG9yaWFsIGNvbW1lbnRzOg0KPg0KPiBBdCBz ZWN0aW9uIDQuNiwgdGhlIGZpcnN0IHBhcmFncmFwaCBjYW4gbWFrZSBpdHMgcG9pbnQgbW9yZSBj bGVhcmx5LiBBbGwgdGhhdCdzIG5lZWRlZCB0byBzYXkgaXMgdGhhdCB0aGUgbG93ZXIgbGF5ZXJz IGhhbmRsZSBzZWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHksIGJ1dCB0aGUgYWRhcHRhdGlvbiBs YXllciBzdGlsbCBuZWVkcyB0byBiZSByZWFkeSB0byBkbyBzbyBpbiB0aGUgbG93ZXIgbGF5ZXIg Y2FudCBoYW5kbGUgdGhlIDEyODAgb2N0ZXQgTVRVLiBBdCB0aGUgbGFzdCBwYXJhZ3JhcGgsIHdo ZW4geW91IHNheSAicmVmZXJyaW5nIHRvIg0KPiBkbyB5b3UgbWVhbiAiYXMgc3BlY2lmaWVkIGlu Ij8NCj4gW1JlbXldIFRoYXQncyBhIGdvb2QgcG9pbnQuIFdlIHdvdWxkIGxpa2UgdG8gc2ltcGxp ZnkgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgc2VjdGlvbiA0LjYgYXMgZm9sbG93czogUExD IE1BQyBsYXllciBwcm92aWRlcyB0aGUgZnVuY3Rpb24gb2Ygc2VnbWVudGF0aW9uIGFuZCByZWFz c2VtYmx5LCBob3dldmVyLCBGcmFnbWVudGF0aW9uIGFuZCByZWFzc2VtYmx5IGlzIHN0aWxsIHJl cXVpcmVkIGF0IHRoZSBhZGFwdGF0aW9uIGxheWVyLCBpZiB0aGUgTUFDIGxheWVyIGNhbm5vdCBz dXBwb3J0IHRoZSBtaW5pbXVtIE1UVSBkZW1hbmRlZCBieSBJUHY2LCB3aGljaCBpcyAxMjgwIG9j dGV0cy4NCj4gWWVzLCB3ZSB3aWxsIGNoYW5nZSBpdCB0byAiYXMgc3BlY2lmaWVkIGluIi4NCj4N Cj4gQXQgc2VjdGlvbiA3LCAiRm9yIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24sIGxpbmsgbGF5ZXIg c2VjdXJpdHkgaXMgZ3VhcmFudGVlZCBpbiBldmVyeSBQTEMgdGVjaG5vbG9neS4iIG5lZWRzIGNs YXJpZmljYXRpb24uIERvIHlvdSBtZWFuIHRoZSB0aHJlZSBwcm90b2NvbHMgZGlzY3Vzc2VkIGhl cmUgcHJvdmlkZSBsaW5rIGxheWVyIHNlY3VyaXR5PyBPciBkbyB5b3UgbWVhbiB0byBzYXkgdGhh dCBpZiBhbnlvbmUgcGxhbnMgdG8gcHJvdmlkZSBhbiBhZGFwdGF0aW9uIGxheWVyIHRvIHNvbWUg b3RoZXIgUExDIHByb3RvY29sLCB0aGF0IGl0IG11c3QgcHJvdmlkZSBsaW5rIGxheWVyIHNlY3Vy aXR5PyBPciBkbyB5b3UgbWVhbiBzb21ldGhpbmcgZWxzZT8NCj4gW1JlbXldIFdlIG1lYW50IHRo YXQgbGluayBsYXllciBzZWN1cml0eSBtZWNoYW5pc21zIGFyZSBkZXNpZ25lZCBpbiB0aGVzZSB0 aHJlZSBQTEMgdGVjaG5vbG9naWVzLiBXZSB3aWxsIHJlcGhyYXNlIGl0Lg0KPiBOaXQ6IEV4cGFu ZCBMTE4gb24gZmlyc3QgdXNlLg0KPiBbUmVteV0gV2lsbCB1cGRhdGUgaXQuDQo+DQoNCg== From nobody Tue Mar 9 07:36:27 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30703A1048; Tue, 9 Mar 2021 07:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GknoJy1czxzz; Tue, 9 Mar 2021 07:36:21 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8D33A1184; Tue, 9 Mar 2021 07:36:03 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8A1B728B003D; Tue, 9 Mar 2021 10:36:02 -0500 (EST) Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 208281F8051; Tue, 9 Mar 2021 10:36:02 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9348C84D-68E1-4908-B312-BABF21189F69" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Russ Mundy In-Reply-To: Date: Tue, 9 Mar 2021 10:36:01 -0500 Cc: Russ Mundy , =?utf-8?Q?G=C3=B6ran_Selander?= , Francesca Palombini , Stefanie Gerdes , Olaf Bergmann , "draft-ietf-ace-oauth-authz@ietf.org" , Loganaden Velvindron , Ace Wg , secdir@ietf.org X-Mao-Original-Outgoing-Id: 636996959.971387-e4099882303f1aa64eee4664cb2bcf54 Message-Id: <47316501-9633-4C6B-B9B2-5471C4153C3C@tislabs.com> References: <871rdqihww.fsf@wangari> <9911269D-AA7F-458C-AA1A-2D59A79C5A00@ericsson.com> <026242c2-2c6a-485b-cb51-34b2b2d70975@tzi.de> <6b5368a6-b8ba-81eb-0c10-6a052fcbad67@tzi.de> <2C5A1AA5-6124-407B-A342-AA367CB6D536@tislabs.com> <87v9a94m60.fsf@wangari> <1932F1CD-7296-4266-B234-1FD30A019522@ericsson.com> <0C8BC190-95F3-4A88-B683-09E22EBD54AB@ericsson.com> To: Daniel Migault X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [secdir] [Ace] secdir review of draft-ietf-ace-dtls-authorize-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 15:36:26 -0000 --Apple-Mail=_9348C84D-68E1-4908-B312-BABF21189F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, thanks very much to everyone that contributed to resolving this = issue. I agree with Daniel that the issue can be closed, i.e., the = issue I raised in my secdir review has been satisfactorily addressed and = resolved. Regards, Russ > On Mar 8, 2021, at 7:13 AM, Daniel Migault > wrote: >=20 > Thanks Goran, It looks good to me. I believe that a new version can be = published to reflect the changes and close this issue.=20 >=20 > Yours,=20 > Daniel=20 >=20 > On Mon, Mar 8, 2021 at 2:35 AM G=C3=B6ran Selander = > = wrote: > Hi Daniel, >=20 > Here is a proposed changed to the last sentence: >=20 > Section 5: > OLD > "Profiles MUST specify a communication security protocol that = provides the features required above." >=20 > NEW > "Profiles MUST specify a communication security protocol = between client and RS that provides the features required above. = Profiles MUST specify a communication security protocol RECOMMENDED to = be used between client and AS that provides the features required above. = Profiles MUST specify for introspection a communication security = protocol RECOMMENDED to be used between RS and AS that provides the = features required above. These recommendations enable interoperability = between different implementations without the need to define a new = profile if the communication between C and AS, or between RS and AS, is = protected with a different security protocol complying with the security = requirements above." >=20 >=20 > G=C3=B6ran >=20 >=20 > =EF=BB=BFOn 2021-03-05, 22:23, "Daniel Migault" > wrote: >=20 > Thanks. "C/RS and AS" may not be very clear as it seems - at least = to me - to include the communication between the client and the RS. It = seems to me that only communications between Client and AS as well as = between AS and RS are in scope. If that is correct, I would suggest = expanding "C/RS and AS" accordingly. > Yours,=20 > Daniel >=20 >=20 > On Fri, Mar 5, 2021 at 11:03 AM Francesca Palombini = > wrote: >=20 >=20 > Hi, >=20 > (Adding back the ace ml that was dropped at some point) >=20 > Here is a proposal for the paragraph in Section 5 with a different = last sentence to hopefully clarify the need for recommendations but not = mandate only one sec protocol per profile: >=20 > Section 5: > OLD > "Profiles MUST specify a communication security protocol that = provides the features required above." >=20 > NEW > "Profiles MUST specify a communication security protocol = between client and RS that provides the features required above. = Profiles MUST specify a communication security protocol RECOMMENDED to = be used between client and AS that provides the features required above. = Profiles MUST specify for introspection a communication security = protocol RECOMMENDED to be used between RS and AS that provides the = features required above. These recommendations enable interoperability = between different implementations, without the need to define a new = profile if the communication between C/RS and AS is protected with a = different security protocol complying with the security requirements = above." >=20 >=20 > The proposal for the other section looks good to me. > Francesca >=20 > From: Daniel Migault > > Date: Thursday, 4 March 2021 at 17:49 > To: G=C3=B6ran Selander > > Cc: Stefanie Gerdes >, Olaf = Bergmann >, Francesca = Palombini >, Russ Mundy = >, = "draft-ietf-ace-oauth-authz@ietf.org = " = >, Loganaden Velvindron = > > Subject: Re: [Ace] secdir review of = draft-ietf-ace-dtls-authorize-14 >=20 >=20 >=20 > HI Goran,=20 >=20 >=20 >=20 > sure any wordsmithing / alternative are fine to me. For the second = alternative the repetition of "with" may sound to me a bit strange. >=20 >=20 > Unless anyone objects that would be greatly appreciate to have a = new version submitted. Thanks! >=20 >=20 >=20 > Yours,=20 > Daniel=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Mar 4, 2021 at 11:12 AM G=C3=B6ran Selander = > = wrote: >=20 >=20 > Hi Daniel, >=20 > The proposal coincides with the text I proposed Feb 22 except for = one sentence: >=20 > "Such recommendations are expected, among others, to guarantee = independent implementations interoperate." >=20 > This sentence does not read well to me, perhaps we can change it? = For example: >=20 > "These recommendations are expected to enable interoperability = between independent implementations."=20 >=20 > . . . or even add the reason why it is only a recommendation: >=20 > "These recommendations are expected to enable interoperability = between independent implementations, without preventing this profile to = be used with other security protocols with the AS complying with the = security requirements." >=20 > I can make the changes and submit a new version of = draft-ietf-ace-oauth-authz in the beginning of next week when ID = submission has reopened. >=20 > Regards > G=C3=B6ran >=20 >=20 >=20 > On 2021-03-04, 15:54, "Daniel Migault" > wrote: >=20 >=20 > Hi all,=20 > I know everyone is very busy by now, but I am wondering if you = could provide your input so that we can think of closing this issue = before the IETF 110 - or at least as soon as possible. Our initial = milestones were to send these doc in February ;-) >=20 > Yours,=20 > Logan and Daniel > ---------- Forwarded message --------- > From: Daniel Migault > > Date: Tue, Mar 2, 2021 at 11:09 PM > Subject: Re: [Ace] secdir review of = draft-ietf-ace-dtls-authorize-14 > To: Olaf Bergmann > > Cc: G=C3=B6ran Selander >, Olaf Bergmann >, Russ Mundy >, ace@ietf.org = >, Stefanie Gerdes >, Francesca Palombini = >, Daniel Migault = > >=20 >=20 >=20 > Thanks for the feedbacks Olaf. So I understand why we need = such flexibility on the client side. The main reason seems that the = communication with the AS is seen as bootstrapping the communication = between the client and the RS and as such we would like to keep them as = independent as possible.=20 > I see interoperability being achieved when a) client, RS, and = AS implemented by independent vendors and b) all three follow the = framework and the given profile is sufficient to make them work = together. Currently the client - RS communication is well defined, but = the client AS communication is left to a RECOMMENDATION.=20 >=20 > RFC2119 defines RECOMMEND as follows: > SHOULD This word, or the adjective "RECOMMENDED", mean that = there > may exist valid reasons in particular circumstances to = ignore a > particular item, but the full implications must be = understood and > carefully weighed before choosing a different course. > The question becomes how RECOMMENDED is sufficient or not.=20 >=20 >=20 >=20 >=20 > It seems to me the definition above makes it clear that the = recommended protocol is expected to be supported, and AS or clients that = are independently developed are expected to support the recommended = protocol. To ensure the implementers are well aware of the consequences = of the implication we could clarify this explicitly. Of course this does = not provide a formal proof for interoperability, but this seems = acceptable in the scope of a framework.=20 >=20 > =46rom the latest suggestion, I would propose the following = changes, - that I expect will reach consensus. Please let us know by = Friday March 5 if you agree or disagree with the proposed changes. >=20 >=20 > Section 5: > OLD > "Profiles MUST specify a communication security protocol that = provides the features required above." >=20 > NEW > "Profiles MUST specify a communication security protocol = between client and RS that provides the features required above. = Profiles MUST specify a communication security protocol RECOMMENDED to = be used between client and AS that provides the features required above. = Profiles MUST specify for introspection a communication security = protocol RECOMMENDED to be used between RS and AS that provides the = features required above. Such recommendations are expected, among = others, to guarantee independent implementations interoperate." >=20 > Section 6.2: > OLD > "Profiles MUST specify how communication security according > to the requirements in Section 5 is provided." > NEW > "The requirements for communication security of profiles are = specified > in Section 5." >=20 >=20 > Yours,=20 > Daniel =20 >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, Mar 2, 2021 at 10:20 AM Olaf Bergmann = > wrote: >=20 >=20 > Hi Daniel, >=20 > On 2021-03-02, Daniel Migault > wrote: >=20 > > This is just a follow-up. I would like to be able to close = this issue > > by the end of the week, and so far I have not heard any = issues for > > profile mandating a protocol. On the other hand, not = mandating a > > specific protocol comes with interoperability issues. So = unless more > > feed back is provided, I am currently leaning toward = ensuring > > interoperability. > > > > It would be good for me to hear from the WG and understand = what concrete deployment > > issues the two statements below would raise: > > * OSCORE profile mandating the AS to support OSCORE and = have the C <-> AS using > > OSCORE.=20 > > * DTLS profile mandating the AS to support DTLS and have = the C <-> AS using DTLS.=20 >=20 > I think the major issue is that a client that implements both = OSCORE and > DTLS cannot just switch from one mechanism to the other = because it must > stick to either one or the other. This also raises the = question what > happens if an AS is contacted by the client via OSCORE but the = RS only > supports DTLS: Is the client allowed to switch from OSCORE to = DTLS if > the AS says so? >=20 > Another aspect is that we would need to add another = specification if a > client implementing the DTLS profile wants to contact the AS = via TLS. As > CoAP over TLS is well-defined, this would not make any = difference > regarding the security or the handling in the application, but = mandating > DTLS in the profile would currently preclude the use of TLS. >=20 > Gr=C3=BC=C3=9Fe > Olaf >=20 >=20 >=20 >=20 >=20 > --=20 > Daniel Migault >=20 > Ericsson >=20 >=20 >=20 >=20 >=20 > --=20 > Daniel Migault >=20 > Ericsson >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Daniel Migault >=20 > Ericsson >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Daniel Migault >=20 > Ericsson >=20 >=20 >=20 > --=20 > Daniel Migault > Ericsson --Apple-Mail=_9348C84D-68E1-4908-B312-BABF21189F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All, = thanks very much to everyone that contributed to resolving this issue. =  I agree with Daniel that the issue can be closed, i.e., the issue = I raised in my secdir review has been satisfactorily addressed and = resolved.

Regards,
Russ

On Mar = 8, 2021, at 7:13 AM, Daniel Migault <mglt.ietf@gmail.com>= wrote:

Thanks Goran, It looks good to me. I believe that = a new version can be published to reflect the changes and close this = issue. 

Yours, 
Daniel 

On Mon, Mar 8, 2021 at 2:35 AM G=C3=B6ran Selander = <goran.selander@ericsson.com> wrote:
Hi Daniel,

Here is a proposed changed to the last sentence:

    Section 5:
    OLD
        "Profiles MUST specify a communication = security protocol that provides the features required above."

      NEW
        "Profiles MUST specify a communication = security protocol between client and RS that provides the features = required above. Profiles MUST  specify a communication security = protocol RECOMMENDED to be used between client and AS that provides the = features required above. Profiles MUST  specify for introspection a = communication security protocol RECOMMENDED to be used between RS and AS = that provides the features required above. These recommendations enable = interoperability between different implementations without the need to = define a new profile if the communication between C and AS, or between = RS and AS, is protected with a different security protocol complying = with the security requirements above."


G=C3=B6ran


=EF=BB=BFOn 2021-03-05, 22:23, "Daniel Migault" <mglt.ietf@gmail.com> wrote:

    Thanks. "C/RS and AS" may not be very clear as it seems - = at least to me -  to include the communication between the client = and the RS. It seems to me that  only communications between Client = and AS as well as between AS and RS are in scope. If that is correct, I = would suggest expanding "C/RS and AS" accordingly.
    Yours,
    Daniel


    On Fri, Mar 5, 2021 at 11:03 AM Francesca Palombini <francesca.palombini@ericsson.com> wrote:


    Hi,

    (Adding back the ace ml that was dropped at some point)

    Here is a proposal for the paragraph in Section 5 with a = different last sentence to hopefully clarify the need for = recommendations but not mandate only one sec protocol per profile:

    Section 5:
    OLD
        "Profiles MUST specify a communication = security protocol that provides the features required above."

      NEW
        "Profiles MUST specify a communication = security protocol between client and RS that provides the features = required above. Profiles MUST  specify a communication security = protocol RECOMMENDED to be used between client and AS that provides the = features required above. Profiles MUST  specify for introspection a = communication security protocol RECOMMENDED to be used between RS and AS = that provides the features required above. These recommendations enable = interoperability between different implementations, without the need to = define a new profile if the communication between C/RS and AS is = protected with a different security protocol complying with the security = requirements above."


    The proposal for the other section looks good to me.
    Francesca

    From: Daniel Migault <mglt.ietf@gmail.com>
    Date: Thursday, 4 March 2021 at 17:49
    To: G=C3=B6ran Selander <goran.selander@ericsson.com>
    Cc: Stefanie Gerdes <gerdes@tzi.de>, Olaf Bergmann <bergmann@tzi.org>, Francesca Palombini <francesca.palombini@ericsson.com>, Russ Mundy <mundy@tislabs.com>, "draft-ietf-ace-oauth-authz@ietf.org" <draft-ietf-ace-oauth-authz@ietf.org>, Loganaden = Velvindron <loganaden@gmail.com>
    Subject: Re: [Ace] secdir review of = draft-ietf-ace-dtls-authorize-14



    HI Goran,



    sure any wordsmithing / alternative are fine to me. For = the second alternative the repetition of "with" may sound to me a bit = strange.


    Unless anyone objects that would be greatly appreciate to = have a new version submitted. Thanks!



    Yours,
    Daniel







    On Thu, Mar 4, 2021 at 11:12 AM G=C3=B6ran Selander <goran.selander@ericsson.com> wrote:


    Hi Daniel,

    The proposal coincides with the text I proposed Feb 22 = except for one sentence:

    "Such recommendations are expected, among others, to = guarantee independent implementations interoperate."

    This sentence does not read well to me, perhaps we can = change it? For example:

    "These recommendations are expected to enable = interoperability between independent implementations."

     . . . or even add the reason why it is only a = recommendation:

    "These recommendations are expected to enable = interoperability between independent implementations, without preventing = this profile to be used with other security protocols with the AS = complying with the security requirements."

    I can make the changes and submit a new version of = draft-ietf-ace-oauth-authz in the beginning of next week when ID = submission has reopened.

    Regards
    G=C3=B6ran



    On 2021-03-04, 15:54, "Daniel Migault" <mglt.ietf@gmail.com> wrote:


        Hi all,
        I know everyone is very busy by now, but I = am wondering if you could provide your input so that we can think of = closing this issue before the IETF 110 - or at least as soon as = possible. Our initial milestones were to send these doc in February = ;-)

        Yours,
        Logan and Daniel
        ---------- Forwarded message ---------
        From: Daniel Migault <mglt.ietf@gmail.com>
        Date: Tue, Mar 2, 2021 at 11:09 PM
        Subject: Re: [Ace] secdir review of = draft-ietf-ace-dtls-authorize-14
        To: Olaf Bergmann <bergmann@tzi.org>
        Cc: G=C3=B6ran Selander <goran.selander@ericsson.com>, Olaf Bergmann <bergmann@tzi.org>, Russ Mundy <mundy@tislabs.com>, ace@ietf.org <ace@ietf.org>, Stefanie Gerdes <gerdes@tzi.de>, Francesca Palombini <francesca.palombini@ericsson.com>, Daniel Migault = <daniel.migault=3D40ericsson.com@dmarc.ietf.org>



        Thanks for the feedbacks Olaf. So I = understand why we need such flexibility on the client side. The main = reason seems that the communication with the AS is seen as bootstrapping = the communication between the client and the RS and as such we would = like to keep them as independent as possible.
        I see interoperability being achieved when = a) client, RS, and AS implemented by independent vendors and b) all = three follow the framework and the given profile is sufficient to make = them work together. Currently the client - RS communication is well = defined, but the client AS communication is left to a RECOMMENDATION. =

        RFC2119 defines RECOMMEND as follows:
        SHOULD   This word, or the = adjective "RECOMMENDED", mean that there
           may exist valid reasons in = particular circumstances to ignore a
           particular item, but the full = implications must be understood and
           carefully weighed before = choosing a different course.
        The question becomes how RECOMMENDED is = sufficient or not.




        It seems to me the definition above makes it = clear that the recommended protocol is expected to be supported, and AS = or clients that are independently developed are expected to support the = recommended protocol. To ensure the implementers are well aware of the = consequences of the implication we could clarify this explicitly. Of = course this does not provide a formal proof for interoperability, but = this seems acceptable in the scope of a framework.

        =46rom the latest suggestion, I would = propose the following changes, - that I expect will reach consensus. = Please let us know by Friday  March 5 if you agree or disagree with = the proposed changes.


         Section 5:
        OLD
        "Profiles MUST specify a communication = security protocol that provides the features required above."

        NEW
        "Profiles MUST specify a communication = security protocol between client and RS that provides the features = required above. Profiles MUST  specify a communication security = protocol RECOMMENDED to be used between client and AS that provides the = features required above. Profiles MUST  specify for introspection a = communication security protocol RECOMMENDED to be used between RS and AS = that provides the features required above. Such recommendations are = expected, among others, to guarantee independent implementations = interoperate."

        Section 6.2:
        OLD
          "Profiles MUST specify how = communication security according
           to the requirements in Section = 5 is provided."
        NEW
        "The requirements for communication security = of profiles are specified
        in Section 5."


        Yours,
        Daniel 






        On Tue, Mar 2, 2021 at 10:20 AM Olaf = Bergmann <bergmann@tzi.org> wrote:


        Hi Daniel,

        On 2021-03-02, Daniel Migault <mglt.ietf@gmail.com> wrote:

        > This is just a follow-up. I would like = to be able to close this issue
        > by the end of the week, and so far I = have not heard any issues for
        > profile mandating a protocol. On the = other hand, not mandating a
        > specific protocol comes with = interoperability issues. So unless more
        > feed back is provided, I am currently = leaning toward ensuring
        > interoperability.
        >
        > It  would be good for me to hear = from the WG and understand what concrete deployment
        > issues the two statements below would = raise:
        >     * OSCORE profile = mandating the AS to support OSCORE and have the C <-> AS using
        > OSCORE.
        >     * DTLS profile = mandating the AS to support DTLS and have the C <-> AS using DTLS. =

        I think the major issue is that a client = that implements both OSCORE and
        DTLS cannot just switch from one mechanism = to the other because it must
        stick to either one or the other. This also = raises the question what
        happens if an AS is contacted by the client = via OSCORE but the RS only
        supports DTLS: Is the client allowed to = switch from OSCORE to DTLS if
        the AS says so?

        Another aspect is that we would need to add = another specification if a
        client implementing the DTLS profile wants = to contact the AS via TLS. As
        CoAP over TLS is well-defined, this would = not make any difference
        regarding the security or the handling in = the application, but mandating
        DTLS in the profile would currently preclude = the use of TLS.

        Gr=C3=BC=C3=9Fe
        Olaf





        --
        Daniel Migault

        Ericsson





        --
        Daniel Migault

        Ericsson







    --
    Daniel Migault

    Ericsson










    --
    Daniel Migault

    Ericsson



--
Daniel Migault
Ericsson

= --Apple-Mail=_9348C84D-68E1-4908-B312-BABF21189F69-- From nobody Tue Mar 9 07:52:07 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDAC3A10F3; Tue, 9 Mar 2021 07:52:00 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh0vIjvRPVyN; Tue, 9 Mar 2021 07:51:59 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA323A10F2; Tue, 9 Mar 2021 07:51:58 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 129Fplwq019303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Mar 2021 10:51:52 -0500 Date: Tue, 9 Mar 2021 07:51:46 -0800 From: Benjamin Kaduk To: Russ Mundy Cc: Daniel Migault , Loganaden Velvindron , secdir@ietf.org, Olaf Bergmann , "draft-ietf-ace-oauth-authz@ietf.org" , Ace Wg , Stefanie Gerdes , =?iso-8859-1?Q?G=F6ran?= Selander Message-ID: <20210309155146.GD56617@kduck.mit.edu> References: <87v9a94m60.fsf@wangari> <1932F1CD-7296-4266-B234-1FD30A019522@ericsson.com> <0C8BC190-95F3-4A88-B683-09E22EBD54AB@ericsson.com> <47316501-9633-4C6B-B9B2-5471C4153C3C@tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47316501-9633-4C6B-B9B2-5471C4153C3C@tislabs.com> Archived-At: Subject: Re: [secdir] [Ace] secdir review of draft-ietf-ace-dtls-authorize-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 15:52:01 -0000 On Tue, Mar 09, 2021 at 10:36:01AM -0500, Russ Mundy wrote: > All, thanks very much to everyone that contributed to resolving this issue. I agree with Daniel that the issue can be closed, i.e., the issue I raised in my secdir review has been satisfactorily addressed and resolved. Hi Russ, A big thank-you to you as well for doing the review and following-up about it! I think the document suite ended up in a better place as a result, and I'm glad to hear that you agree that the issue is resolved. Thanks again, Ben From nobody Tue Mar 9 10:36:33 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19ADF3A1638; Tue, 9 Mar 2021 10:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DN0oEz5w-WBH; Tue, 9 Mar 2021 10:36:26 -0800 (PST) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 AF0AE3A1635; Tue, 9 Mar 2021 10:36:26 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id s8so7317906vsc.8; Tue, 09 Mar 2021 10:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rfz2ecXm+Itcu5NQdDkBQObNWTltPiKHW2kuJsC9xvU=; b=HwpEC9rjxNX8G0+I2yBoEAjB1S4b8WuyfOXtH/HV5j0sPEQjI3qAo56CNA0kLlr3gO 6pd3ROwYVGbIsbilvne7G/y3vTvlBxHiEXZEtAL5smgJRZ3+TdYqXDWROny03CJRz1Ac ax1wEizoU3n5A1JdOUsUZ5EICkYUVaIOtsNB15yfD79rNcuuzK6jFnln+HSu+8o+EtX3 I1tA42eAh1Nn1cI/MMIgJQriYQ/57d6weBQKL6zmYcwT2B/aLiCFXYa82Iq5+x7Ga5pJ xdjv7rkmTnJ7Qo2AwKd4xUJvElOfNVChNXUoXbNntJ/g6efwjuAVj5iuZ1Fhm1gbbMb6 WARA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rfz2ecXm+Itcu5NQdDkBQObNWTltPiKHW2kuJsC9xvU=; b=YCm3hw46g3zyS+rMYU6hZR3eWE2RkvwB25qmrwhbJJ9zkbnVvfOg/8CH44gCiEdMow so087xz9CWfhd+68sT8DaRmaLM3EAh8kfP5aG3sEh9QhnF3fx2Mri/X/W2inpDNNI9Mb 4ppCQUta7NWt2zVh8IgZAE0HIs8u3a9yTl35fXIaGXKEo+v3uMrg1fBPabfQ8HVZMLWU +TTdcj6wQxSOp4WgNicujixbfhAGUO/NMvQ0ycJnHG67YT2YBZpEb0UrcuD1TNQU5BeT 4J2oe7DjUvD63eb0Lflxorg1sQozf26MzaJNIAfzMrR3G9lfxOhknE8I8n/2byjoT48B Su5w== X-Gm-Message-State: AOAM533jKzzqRXK+XqiGPHZjn2MczmHJwG+TCqw0gMdYJ0b5ZCdSk2dx VrvCD9qpOYaFWiEP4ef7z6i+DXdxhR7s9i1eMTk= X-Google-Smtp-Source: ABdhPJxPlMHetUkY/cdx9Hi3bpCeBkxwaU6CTa2aAzhXk4lTsvNxX5y3POXuAnJ9ir1yza5mORkHP9AnFmygKeRWMgA= X-Received: by 2002:a67:f04d:: with SMTP id q13mr6355770vsm.40.1615314984852; Tue, 09 Mar 2021 10:36:24 -0800 (PST) MIME-Version: 1.0 References: <87v9a94m60.fsf@wangari> <1932F1CD-7296-4266-B234-1FD30A019522@ericsson.com> <0C8BC190-95F3-4A88-B683-09E22EBD54AB@ericsson.com> <47316501-9633-4C6B-B9B2-5471C4153C3C@tislabs.com> <20210309155146.GD56617@kduck.mit.edu> In-Reply-To: <20210309155146.GD56617@kduck.mit.edu> From: Daniel Migault Date: Tue, 9 Mar 2021 13:36:13 -0500 Message-ID: To: Benjamin Kaduk Cc: Russ Mundy , Loganaden Velvindron , secdir@ietf.org, Olaf Bergmann , "draft-ietf-ace-oauth-authz@ietf.org" , Ace Wg , Stefanie Gerdes , =?UTF-8?Q?G=C3=B6ran_Selander?= Content-Type: multipart/alternative; boundary="000000000000df5eb505bd1ed377" Archived-At: Subject: Re: [secdir] [Ace] secdir review of draft-ietf-ace-dtls-authorize-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 18:36:28 -0000 --000000000000df5eb505bd1ed377 Content-Type: text/plain; charset="UTF-8" Hi Russ, Thanks Russ for raising this issue and doing the followup. I am glad we clarified it. Yours, Daniel On Tue, Mar 9, 2021 at 10:51 AM Benjamin Kaduk wrote: > On Tue, Mar 09, 2021 at 10:36:01AM -0500, Russ Mundy wrote: > > All, thanks very much to everyone that contributed to resolving this > issue. I agree with Daniel that the issue can be closed, i.e., the issue I > raised in my secdir review has been satisfactorily addressed and resolved. > > Hi Russ, > > A big thank-you to you as well for doing the review and following-up about > it! I think the document suite ended up in a better place as a result, and > I'm glad to hear that you agree that the issue is resolved. > > Thanks again, > > Ben > -- Daniel Migault Ericsson --000000000000df5eb505bd1ed377 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,=C2=A0

Thanks Russ for ra= ising this issue and doing the followup. I am glad we clarified it.=C2=A0
Yours,=C2=A0
Daniel

On Tue, Mar 9, 2021 at 10:51 = AM Benjamin Kaduk <kaduk@mit.edu>= ; wrote:
On Tue,= Mar 09, 2021 at 10:36:01AM -0500, Russ Mundy wrote:
> All, thanks very much to everyone that contributed to resolving this i= ssue.=C2=A0 I agree with Daniel that the issue can be closed, i.e., the iss= ue I raised in my secdir review has been satisfactorily addressed and resol= ved.

Hi Russ,

A big thank-you to you as well for doing the review and following-up about<= br> it!=C2=A0 I think the document suite ended up in a better place as a result= , and
I'm glad to hear that you agree that the issue is resolved.

Thanks again,

Ben


--
Daniel Migault
Ericsson
--000000000000df5eb505bd1ed377-- From nobody Tue Mar 9 20:00:12 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8713A19B4; Tue, 9 Mar 2021 19:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1615348718; bh=E01KulDHo/CDwRmT6jKK9lH7R/U54duPS5sixYM4lA0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ibRmByO505c6KnY2yFQwo3kf2qMxc16cycLbgJxw57tKrBrAU9yTQ3k4Uh3mmkE2K fJvgmmfElonfx6HvdQTPp6/yUX7x1bX0f/e3AXlkHV/eG8VK3v4mlloR/e9eN2xup9 /mST3I6aYHzJDSgKbSl1pz8Btxxl+lQf/fE/+CzQ= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Mar 9 19:58:37 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 925523A19AD; Tue, 9 Mar 2021 19:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1615348717; bh=E01KulDHo/CDwRmT6jKK9lH7R/U54duPS5sixYM4lA0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=RSkxx5j9S5be/lcrM0zPdbJJ7eOrAcb373uDzlF9KlAYsmcv99aUOHu9ghzWh/vaL oF/jAdD04164c4hMl2NgsLz/qC6V1djosIUftI8w17bhVgFSSXaNfWLsSNjYTKaGeJ KTr4fEFruQDHjXqD7ekX1Pr/DmT9h2I41gjNOUDM= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8D73A19AE for ; Tue, 9 Mar 2021 19:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lrWQe0qQ1BW for ; Tue, 9 Mar 2021 19:58:33 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5C43A19AD for ; Tue, 9 Mar 2021 19:58:33 -0800 (PST) Received: from [89.187.161.155] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lJpzS-0005Pt-JK for new-work@ietf.org; Wed, 10 Mar 2021 03:58:30 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Wed, 10 Mar 2021 11:58:27 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 09 Mar 2021 20:00:11 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Payment Security Interest Group (until 2021-04-07/08) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 03:58:39 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBXZWIgUGF5 bWVudCBTZWN1cml0eSBJbnRlcmVzdCBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy9zZWN1 cmVwYXkvY2hhcnRlci0yMDIxMDMuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBj b21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hh cnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlv ZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDAzOjU5IFVUQyBvbiA4IEFw cmlsIDIwMjEKKDIzOjU5LCBFYXN0ZXJuIHRpbWUgb24gNyBBcHJpbCkgb24gdGhlIHByb3Bvc2Vk IGNoYXJ0ZXIuClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHB1YmxpYy1uZXctd29ya0B3My5vcmcs CndoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xpc3RzLnczLm9yZy9BcmNo aXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50IGlu IGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlvdSB3 b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNvbW1lbnRz IHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpleGFtcGxl LCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlzdCBhbmQK aGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBpdCBm cm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KClRoZSBncm91cCdzIGN1cnJl bnQgY2hhcnRlciBpcyBleHRlbmRlZCB1bnRpbCAzMCBBcHJpbCB0byBhY2NvbW1vZGF0ZQp0aGUg Y2hhcnRlciByZXZpZXcgcGVyaW9kLgpodHRwczovL3d3dy53My5vcmcvc2VjdXJlcGF5L2NoYXJ0 ZXIKCklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZv cm1hdGlvbiwgcGxlYXNlCmNvbnRhY3QgSWFuIEphY29icywgV2ViIFBheW1lbnQgU2VjdXJpdHkg SW50ZXJlc3QgR3JvdXAgVGVhbSBDb250YWN0LCAKPGlqQHczLm9yZz4uCgpUaGFuayB5b3UsCgpY dWV5dWFuIEppYSzCoCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRwOi8v d3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Wed Mar 10 22:41:53 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D14F3A12BC; Wed, 10 Mar 2021 22:41:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Shawn Emery via Datatracker To: Cc: core@ietf.org, draft-ietf-core-yang-cbor.all@ietf.org, last-call@ietf.org, semery@uccs.edu X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161544490805.3198.4896668099907204116@ietfa.amsl.com> Reply-To: Shawn Emery Date: Wed, 10 Mar 2021 22:41:48 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-core-yang-cbor-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 06:41:48 -0000 Reviewer: Shawn Emery Review result: Has Nits This standards track draft specifies YANG modules for Concise Binary Object Representation (CBOR) encodings. The security considerations section does exist and refers to RFCs 8949 and 7950 for underlying security issues. It continues that there are no additional security concerns introduced by this draft outside of any specific context or protocol. I agree with this assertion. I also don't know how pedantic we should be in including the YANG module security considerations template to a draft that does not specify modules specific to a protocol, i.e. writable nodes, sensitive readable nodes, and RPC operations. I defer this decision to the security ADs. General comments: None. Editorial comments: None. From nobody Fri Mar 12 06:09:17 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8593A105A for ; Fri, 12 Mar 2021 06:09:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <161555815548.20071.1612766663696104260@ietfa.amsl.com> Date: Fri, 12 Mar 2021 06:09:15 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 14:09:16 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-03-25 Reviewer LC end Draft Linda Dunbar 2021-03-23 draft-ietf-ecrit-location-profile-registry-policy Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Charlie Kaufman R2019-12-13 draft-ietf-ace-oauth-params Russ Mundy R2020-07-20 draft-ietf-ace-dtls-authorize Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Nancy Cam-Winget 2021-03-16 draft-ietf-acme-authority-token-tnauthlist Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Linda Dunbar 2021-03-23 draft-ietf-ecrit-location-profile-registry-policy Donald Eastlake 2021-03-22 draft-ietf-dots-rfc8782-bis Stephen Farrell 2021-03-29 draft-ietf-lsr-ospf-prefix-originator Daniel Franke 2021-03-28 draft-ietf-tls-dtls-connection-id Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Steve Hanna RNone draft-ietf-sfc-nsh-integrity Dan Harkins 2021-03-22 draft-ietf-6man-spring-srv6-oam Russ Housley 2021-03-22 draft-ietf-acme-star-delegation Leif Johansson None draft-ietf-netconf-crypto-types Charlie Kaufman R2019-12-13 draft-ietf-ace-oauth-params Russ Mundy R2020-07-20 draft-ietf-ace-dtls-authorize Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Tim Polk None draft-ietf-opsawg-finding-geofeeds Sean Turner 2021-02-25 draft-ietf-ntp-port-randomization Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Christian Huitema 2021-03-26 draft-ietf-dtn-bpsec-default-sc Scott Kelly 2021-04-01 draft-ietf-tcpm-accurate-ecn Tina Tsou 2021-02-15 draft-ietf-idr-eag-distribution Paul Wouters 2021-02-19 draft-ietf-idr-bgp-ls-app-specific-attr Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Tero Kivinen Watson Ladd Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Adam Montville Kathleen Moriarty From nobody Fri Mar 12 20:29:37 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FCB3A1575; Fri, 12 Mar 2021 20:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqROGYr09ONp; Fri, 12 Mar 2021 20:29:29 -0800 (PST) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam08olkn2059.outbound.protection.outlook.com [40.92.46.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED69B3A1573; Fri, 12 Mar 2021 20:29:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d2MxBqv7+IIUtoVwr306hfakhGjLYdejLpHHmJOxIUROdEa+ZIkGYRHosFNDmfKfYNUt2kAGugwuV6e11B9eRPjkkAJrnthD1D9MzbeVX+fFTDlQqpEmz4ZjOSd35gVFO8av0hTSxPmcTcCpUKyGtxS731oxRXKZyx1xeVqCdLuwnwU9PdhdDC09CSpKcaJ1qPRFAHqd4JPWxdgxfme2fdoa2jdTmWrqz9dQpURZm46jBlikJSXFAz8qEwToGwifiiiLs9xflUh+poHx04H3xMOOV+wNbgu0/H3pUti8u4NuBICCRQi6unIfTjKeLFOMn32oR5/u+GIcVeA1Olew+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WEPAcaKPAS95ojrnYM0W735AMdK4oL4LarJ89aBVvMg=; b=huOUFeBIkP9d29FpKcBDBWSxsezMid/1OVB3bFzDuUy/YJMcq2o6hbrZQQS+jEIlAh8csZmI2gVOLYG08eE8k+/Ddjs3kFHzJZw49K9J/AtyAdUw/FEfaC+Ktn6/kjFPtfUb7JVTQWomBgOZ27ARpYFugJWwTLZyW4SekZx3XgSQ1GUo06FN+1U3R0RzCu+bJHrTzd4QkXPFkmny/gPReYOzf37yRiB5RXrlxMxQRkDpp/lQmLoiyIA/MaLYBa6RQY83TmLANpmOA8YnN2gooIWaJPVOtEWWKkGcMN52SA5HI8UQTxpTWMeRgvwekYxccQ+PVx3AeRUdoKqmdBrcsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WEPAcaKPAS95ojrnYM0W735AMdK4oL4LarJ89aBVvMg=; b=IGLHJss6pRaBvVyjylvFPHJrnoqsjDr/4W6uBQxMKq4lgPWmTSeWJO78kBbWvobR9TFbC2hFqZXFXmbBeljZUkZ/MCwi4wo7ESAextubDXaRe9Jt2mxN4HJD9679U9xaNvv7uZtpMCP6vt1XEl8EBpSeKROz1u1QO4/W2itmarnX/OTkpoKpHJLGCapEYcO+2YWLIBekSUiDXFbVxlqbqQm4ClvJUdPiQBIhQU2YO1RsYRKQM0mVPzvuffoeOYed3jRlAjiqIm3kUUBxMn2x61YfNhYwpfmyCPb/pFz6FjXJOGS+ZBWb2L65Cks5TKAnElkKUjD1xrni7aa2+eEbQQ== Received: from BN3NAM04FT034.eop-NAM04.prod.protection.outlook.com (10.152.92.59) by BN3NAM04HT115.eop-NAM04.prod.protection.outlook.com (10.152.93.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Sat, 13 Mar 2021 04:29:27 +0000 Received: from SN6PR1901MB4688.namprd19.prod.outlook.com (2a01:111:e400:7e4e::51) by BN3NAM04FT034.mail.protection.outlook.com (2a01:111:e400:7e4e::65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32 via Frontend Transport; Sat, 13 Mar 2021 04:29:27 +0000 Received: from SN6PR1901MB4688.namprd19.prod.outlook.com ([fe80::2da4:eb7e:cc30:8f3f]) by SN6PR1901MB4688.namprd19.prod.outlook.com ([fe80::2da4:eb7e:cc30:8f3f%5]) with mapi id 15.20.3933.031; Sat, 13 Mar 2021 04:29:27 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ace-oauth-params.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-ace-oauth-params-13 Thread-Index: AQHXF8FApysIqRVVz0KRxyy3XqpVkQ== Date: Sat, 13 Mar 2021 04:29:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:12E21027A80D1307F9F597636D78D000E73C04BE1C8D8C8BE922BE4C3C37DF3D; UpperCasedChecksum:C825C78DE14A194F912171D9F3330275C79F0A5D3CF66120A73E263AC6E34F00; SizeAsReceived:6798; Count:41 x-tmn: [wZNJzNDiX7xlgXkTSpRUkWI8RboLFaon] x-ms-publictraffictype: Email x-incomingheadercount: 41 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 697a0a7e-c51c-463d-1c52-08d8e5d89672 x-ms-traffictypediagnostic: BN3NAM04HT115: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PgDmjSwg/xV6JqPsHCAFiS3Wzi/FnUxPaTe+YAy40kI168j6VQPJ9Yb/BtB/vbqQEAPHQPhCBfZ/l/lv1Xe4CrD29Fkybt5LBue3RaOCWl3dY4vM9FHDnHmYFl0mDYWlfGrdpQSVAYtlg00CsxxS71rTC8wQguNk7SedSqhwixSVfRDC1fOiwL0JaqVzQI+8fePW/EK2SJw1Yvm0MiBsPRI8m/d6VDuccAwS0VZkNIW3HmT7jIb9hk9rOiq0Ebk0n22FgkooveHOZ9F7XN0HSwhpA2TpmBt/LjLg1sWN7aQcPdnMnc/v7MQ2KXiMmjtluw+0tYomlihWioMbzbRnJZETDYvsjPqp4MGLW0tKY16DzlANc0Dypsj3BgTcz1kxWNSEZui8smiU4/NoLGNERA== x-ms-exchange-antispam-messagedata: bvPiwkEzl4ysd97f4AmchSd7oSYBDPP9jmm2TpcPk7gos+Yuc9PgkKSLZtmWixM+7cj7jRLnKzQJh5dWPA7TdL2HCfC4p0uzGl7EW8KWBzBoX6Weqtg3ZPDUEEZWGwc7t0DTgDQej2XgAkv6fhv1Fg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR1901MB4688950673A7C5EC65A4BC89DF6E9SN6PR1901MB4688_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: BN3NAM04FT034.eop-NAM04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 697a0a7e-c51c-463d-1c52-08d8e5d89672 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2021 04:29:27.2272 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT115 Archived-At: Subject: [secdir] Secdir review of draft-ietf-ace-oauth-params-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 04:29:31 -0000 --_000_SN6PR1901MB4688950673A7C5EC65A4BC89DF6E9SN6PR1901MB4688_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This is a re-review; I reviewed version -06 in December 2019. In the intervening versions, the specification was simplified somewhat at t= he cost of removing support for key rollover of asymmetric keys in certain = scenarios. A section was added "Requirements when using asymmetric keys" wh= ich contained what I considered a confusing reference to DTLS, but it does = not make the spec ambiguous. This is a small extension to [I-D.ietf-ace-oauth-authz] and is separate fro= m that document for technical reasons that I don't understand but which see= m plausible. The security considerations section says simply (and I agree): This document is an extension to [I-D.ietf-ace-oauth-authz]. All security c= onsiderations from that document apply here as well. All of the nits mentioned in the previous review have been corrected. --_000_SN6PR1901MB4688950673A7C5EC65A4BC89DF6E9SN6PR1901MB4688_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG.  The= se comments were written primarily for the benefit of the security area dir= ectors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This is a re-review; I reviewed version -06 in December 2019.

In the intervening versions, the specification was simplified somewhat= at the cost of removing support for key rollover of asymmetric keys in cer= tain scenarios. A section was added "Requirements when using asymmetri= c keys" which contained what I considered a confusing reference to DTLS, but it does not make the spec ambiguous.

This is a small extension to [I-D.ietf-ace-oauth-authz] and is separat= e from that document for technical reasons that I don't understand but whic= h seem plausible.

The security considerations section says simply (and I agree):

This document is an extension to [I-D.ietf-ace-oauth-authz]. All secur= ity considerations from that document apply here as well.

All of the nits mentioned in the previous review have been corrected.<= /div>
--_000_SN6PR1901MB4688950673A7C5EC65A4BC89DF6E9SN6PR1901MB4688_-- From nobody Sun Mar 14 13:22:35 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D333A1488; Sun, 14 Mar 2021 13:22:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Steve Hanna via Datatracker To: Cc: draft-ietf-sfc-nsh-integrity.all@ietf.org, last-call@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161575334102.7815.17455725704291920094@ietfa.amsl.com> Reply-To: Steve Hanna Date: Sun, 14 Mar 2021 13:22:21 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sfc-nsh-integrity-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2021 20:22:21 -0000 Reviewer: Steve Hanna Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds integrity and optional encryption of sensitive metadata directly to the Network Service Header (NSH) protocol defined in RFC 8300, thus reducing or eliminating several attack vectors against Service Function Chaining (SFC). The document is well written and seems adequate for the goals articulated here and elsewhere in the SFC document suite. All of the issues, questions, and nits that I raised in my earlier secdir review (https://datatracker.ietf.org/doc/review-ietf-sfc-nsh-integrity-01-secdir-early-hanna-2020-12-24) have been well addressed in draft-ietf-sfc-nsh-integrity-04. From my perspective (as a security expert who has not previously worked with SFC), this latest version of that document seems to address all relevant security issues in an appropriate manner. I have no remaining concerns regarding this document and support its approval. From nobody Sun Mar 14 13:45:21 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9A03A1506; Sun, 14 Mar 2021 13:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRRfslofk9HC; Sun, 14 Mar 2021 13:45:16 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539643A1504; Sun, 14 Mar 2021 13:45:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DzBQ11dgfz6G99X; Sun, 14 Mar 2021 13:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1615754713; bh=PMHsi5ww9P9bwOpfFJp26xUVj7TI/K99sGQLHNJSH1M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FOMlomNz+lsjMr90q9/6hmGEQrnU4ZP+rHWHJN8JH3XnGn2iHS3W/390Lzlp7HPIG 0DkncjXEJFZQpCf6tPZH6KhSXHgivGptLZg0NGkZsuypZm1bAErigxehDtiWmcVzKK iRXa885nnpRmnQ+3G0iIvkL7Pfbm2sz6fyidk0nU= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DzBQ03Lm4z6G7Yk; Sun, 14 Mar 2021 13:45:12 -0700 (PDT) To: Steve Hanna , secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-sfc-nsh-integrity.all@ietf.org, sfc@ietf.org References: <161575334102.7815.17455725704291920094@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <84648dcd-4318-f411-82ed-6eea0d5c37ac@joelhalpern.com> Date: Sun, 14 Mar 2021 16:45:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <161575334102.7815.17455725704291920094@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-sfc-nsh-integrity-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2021 20:45:18 -0000 Thank you Steve. Joel On 3/14/2021 4:22 PM, Steve Hanna via Datatracker wrote: > Reviewer: Steve Hanna > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > This document adds integrity and optional encryption of sensitive metadata > directly to the Network Service Header (NSH) protocol defined in RFC 8300, thus > reducing or eliminating several attack vectors against Service Function > Chaining (SFC). The document is well written and seems adequate for the goals > articulated here and elsewhere in the SFC document suite. > > All of the issues, questions, and nits that I raised in my earlier secdir > review > (https://datatracker.ietf.org/doc/review-ietf-sfc-nsh-integrity-01-secdir-early-hanna-2020-12-24) > have been well addressed in draft-ietf-sfc-nsh-integrity-04. From my > perspective (as a security expert who has not previously worked with SFC), this > latest version of that document seems to address all relevant security issues > in an appropriate manner. I have no remaining concerns regarding this document > and support its approval. > > > From nobody Sun Mar 14 15:01:53 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 297893A1674; Sun, 14 Mar 2021 15:01:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: acme@ietf.org, draft-ietf-acme-star-delegation.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161575930310.2025.16866904323712710819@ietfa.amsl.com> Reply-To: Russ Housley Date: Sun, 14 Mar 2021 15:01:43 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-acme-star-delegation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2021 22:01:43 -0000 Reviewer: Russ Housley Review result: Not Ready I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-acme-star-delegation-06 Reviewer: Russ Housley Review Date: 2021-03-14 IETF LC End Date: 2021-03-22 IESG Telechat date: unknown Summary: Not Ready Major Concerns: Abstract: It says: "... party access to a certificate associated with said identifier." This is odd wording, and it is incorrect. The party needs access to the private key that corresponds to the public key in the certificate, and the certificate needs to contain the subject for "said identifier". Clearly, all of that should not go in the Abstract, but what does appear in the Abstract needs to be technically accurate. Section 1 says: "... name matches the authority ...". I find this description confusing. I think it would be more clear to say that the cache server needs to present a certificate whose subject name matches the domain name of the URL that is requested. The current wording is very easy to confuse name of the Certification Authority. Section 1 says: While the primary use case we address is delegation of STAR certificates, the mechanism proposed here accommodates any certificate managed with the ACME protocol. See Section 2.4 for details. This is not much of a hint that long-term certificates are supported in addition to STAR certificates. Further, a hint about the handling of revocation is appropriate here. Support for long-lived certificates is in conflict with the title of the document. Please adjust the title of the document accordingly. Section 2.3.2 says: "Besides, when delegation is for a STAR certificate, ..." (in four places in this section). I find this part of the document structure a bit confusing. Maybe it is the lask ot adequate warning about support for long-lived certificates. Maybe it the the mixing of STAR certificate and long-lived certificate processing in one section. I suggest that separate sections be used to present STAR certificate and long-lived certificate processing In Section 2.3.4, the text is begging for one more sentence. Please say something about the fact that the STAR certificate will expire shortly after the automatic renewal process is stopped by the IdO. Section 2.4 is not sufficient to explain the revocation processing. Only the NDC has the private key needed to make the ACME revocation request, but this does not get stated in the text. Also, it is not clear to me how the NDC knows where to send the revocation request since the IdO is the ACME account owner. In addition, the phrase "would create a self-inflicted DoS" needs more explanation. Section 5.6 registers a string name for each extendedKeyUsage OID. There should be a way to provide the OID in dotted decimal format as well. New OIDs are being assigned all the time, and some of them may not be registered with IANA. Section 5.6 registers a string name for each type of subjectAltName. This include otherName, which are identified by an OID. New OIDs are being assigned all the time. For example, draft-ietf-anima-autonomic- control-plane-30 creates a new otherName. There should be a way to provide the the otherName OID in dotted decimal format as well. Minor Concerns: Abstract: Please spell out ACME, CDN, and STAR. These are not marked as "well known" in the RFC Editor abbreviation expansion list. Section 1 describes [I-D.mglt-lurk-tls13] as an ongoing effort. This is not accurate. The LURK BoF did not lead to a WG or an effort in an existing WG. I think the best way forward is to drop this reference. Section 1.1: Please change CA to "Certification Authority". See Section 3 of RFC 5280. This changes is also needed elsewhere in the document. Section 1.1: Please add CDNI, uCDN, dCDN, PASSPorT, CSR and FQDN to the list of terms. Nits: Section 2 says: "... in this draft ...". Please use a work that will still be appropriate when this document becomes an RFC. Section 2.4: s/Sec. 7.6/Section 7.6/ (and many other places) IDnits reports: ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. [I suspect these are not IPv4 addresses, but OIDs in dotted decimal.] From nobody Sun Mar 14 15:59:17 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545C83A00E5; Sun, 14 Mar 2021 15:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=8AcHFQEM; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=8AcHFQEM 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 PsUHg2WjI34T; Sun, 14 Mar 2021 15:59:05 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2055.outbound.protection.outlook.com [40.107.20.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3833A006A; Sun, 14 Mar 2021 15:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qKItXiKc4WIC8fShJmG24EgfDCKAbm41aC89SEBCwsU=; b=8AcHFQEMhNE6mxglKf3r/BR0IfeuUejGSDg72NhPqXMiVExT+65Xu4cHcIGkItI0YZmg6ooIbL7KRsfNsooUdxrFwM2WxCzo/Hfbn9eWtLvOjRVzNZD6obyMXs3+VhjhQSJL/HoOCpHbt8o/xpo1QKXuKd8FPJGypws0CD6BdIs= Received: from AM0PR03CA0106.eurprd03.prod.outlook.com (2603:10a6:208:69::47) by AM8PR08MB5714.eurprd08.prod.outlook.com (2603:10a6:20b:1dd::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Sun, 14 Mar 2021 22:58:59 +0000 Received: from VE1EUR03FT033.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:69:cafe::70) by AM0PR03CA0106.outlook.office365.com (2603:10a6:208:69::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32 via Frontend Transport; Sun, 14 Mar 2021 22:58:59 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT033.mail.protection.outlook.com (10.152.18.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31 via Frontend Transport; Sun, 14 Mar 2021 22:58:58 +0000 Received: ("Tessian outbound 67e186bef91c:v71"); Sun, 14 Mar 2021 22:58:58 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2f4e3cf752f0ecdc X-CR-MTA-TID: 64aa7808 Received: from fbc11addd1f9.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 27282B09-20F8-4D10-A490-D01900969C7C.1; Sun, 14 Mar 2021 22:58:52 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fbc11addd1f9.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sun, 14 Mar 2021 22:58:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RfHzpgfchD+3DpWjsRYYoJbkm90uZX8aeHUKb3m7yjUu/+DScPMntKTUdGWxxnoOS8FJAzOquB3jwSPlGf0iOJqytMWG0zh1THn2iEZoZnsqWhwtigcMZ3sIDl0H7imKHMlk//tJ9MLCHbm8rAP+DIquwR9SFnlCpwvKFBQpmRP9dY0KkrmoYagBQi7vU9GNHS9gtdPFHZJ2tPJzL5jKWMERukHFrNE5caHHOigiknYjj3a6j3TfCoG+OUPnNCKRB64aMCSQzytQFlRWZDmV1VpIb2Ac3Z62oAujRFP5dSJ1+/SrE96i1oNObqu51lkWLpAsXWUk3lla66R/bbjxIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qKItXiKc4WIC8fShJmG24EgfDCKAbm41aC89SEBCwsU=; b=DbKNDR1HghAfFfAvmq//SwrBfBYK7my0VA15D0qj9xmdMa8Knf8/R6IEvrN/iwrdcHMJ590hGvO8/Vxhxzvqtw4oHJZfo9GBjWsmhBv3sVHgiag+Orghh8rG15eWNk39ueouoVL2V42Qtp6n4r5PbDiOeIo5fa3gfRlbTzbmr7Jtr3PdM2Eb4lbWNQQBqcsv0m2J0gvarxG15VhDNl/ACLbDO6M91vUPnbw3yO5CEQf7FXbnY9BSTUQMwFaxd8FImzmR54jyT1rJ/lBHhEL2Z7L5VeUa9c0Va+ZRds9v4s5R4f1mm3FjVwM1e/tmKuJYDVWpYCXd3dJCKnExIn0gUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qKItXiKc4WIC8fShJmG24EgfDCKAbm41aC89SEBCwsU=; b=8AcHFQEMhNE6mxglKf3r/BR0IfeuUejGSDg72NhPqXMiVExT+65Xu4cHcIGkItI0YZmg6ooIbL7KRsfNsooUdxrFwM2WxCzo/Hfbn9eWtLvOjRVzNZD6obyMXs3+VhjhQSJL/HoOCpHbt8o/xpo1QKXuKd8FPJGypws0CD6BdIs= Received: from DB9PR08MB6524.eurprd08.prod.outlook.com (2603:10a6:10:251::8) by DB9PR08MB6841.eurprd08.prod.outlook.com (2603:10a6:10:2a9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Sun, 14 Mar 2021 22:58:50 +0000 Received: from DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::1f5:375c:310f:7df5]) by DB9PR08MB6524.eurprd08.prod.outlook.com ([fe80::1f5:375c:310f:7df5%4]) with mapi id 15.20.3933.032; Sun, 14 Mar 2021 22:58:50 +0000 From: Thomas Fossati To: Russ Housley , "secdir@ietf.org" CC: "acme@ietf.org" , "draft-ietf-acme-star-delegation.all@ietf.org" , "last-call@ietf.org" , Thomas Fossati Thread-Topic: Secdir last call review of draft-ietf-acme-star-delegation-06 Thread-Index: AQHXGR2r2oa7NsdVgEiTKC6gi2ySeKqEGPKA Date: Sun, 14 Mar 2021 22:58:50 +0000 Message-ID: <3DDC13CC-4789-459D-9DA2-E023BC372D8C@arm.com> References: <161575930310.2025.16866904323712710819@ietfa.amsl.com> In-Reply-To: <161575930310.2025.16866904323712710819@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 Authentication-Results-Original: vigilsec.com; dkim=none (message not signed) header.d=none; vigilsec.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.12.10.179] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 67ebd943-b39d-47fc-fc5e-08d8e73cc0bf x-ms-traffictypediagnostic: DB9PR08MB6841:|AM8PR08MB5714: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: rWiCMWJTslK8J25h+g5UMDn4MRWINSK0QaDTN3QaJbf9jLW8wun9jLI/rwQ6EiWE5KOKirKeYayZSRJjQZlChXfFHTGN+BhZ/uoat8jOx7HdZ1RT5MMNopV5N6F3eYSlyh74Zm5vA2FUb/ZgtwdfebqrM7cNZQ9uerezu0jqcUvc7IihBUhb+HUTl11jlZO/JuMoxjru5sTs4vORaOLpUL74tuU/Sl1Gtv9DpErHiaWTOrp0WA+QFjbWyhj8KQ20VDtnyOx+e9Uhv+BoVrU2xCr6QPi+scQJ9yixuS4m5Fz8IrCZuD9TJAkpJlESEphccvjYgIn9U67zieKOUPoNZuN6xK58p1xMFT8K5IkAxKwRFEyI8Y48UIk+RdIl2HKc+AOOrUkfclkoWBuXQHzVg/pzjdRIfyRxNa+L3wcyzTZOuVNh3EhIMTQ/XO26gveaUwqX31OCv0qzHwxx3zw0e2DJr/1qKUiB/f1DNwaP+tyDgN2KhdRA92CzcKR3MBPVNIvElILiOoCfnWLKjptCBz0TT6YXH0eSXWqAsyqNHjeL8JN5C8aebMTKYZwX2UskMipP9n4+NMPM+1fJijIGnL9KadrAT8MiaIVjM73TZuV/i+1HkzF48VbT0uaa/VI+euTs7lspySxH2Q9fNYhXDpzIS52PCES5P0/kZSflhdINljcxypHVAkHMxMAiUUB6JJUvUJDjlL0niLj+Zebxkw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR08MB6524.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(376002)(136003)(396003)(39860400002)(186003)(26005)(316002)(86362001)(966005)(66946007)(2906002)(66476007)(54906003)(110136005)(71200400001)(5660300002)(91956017)(76116006)(8936002)(4326008)(6506007)(6486002)(8676002)(33656002)(478600001)(6512007)(66446008)(64756008)(53546011)(2616005)(36756003)(83380400001)(66556008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eWF5R2tlVnM1UVRjR3ZBT3JLanpIL2huazY2WnlkNnAyVERKSFBwZkJxTWpQ?= =?utf-8?B?VVlndXBWSFNkeCt0SVVJOHFlRklYKy9oUDB0R2pOSzBEYTMzSitlbDREQ0U3?= =?utf-8?B?aUlPOWxSQWR6L1Vrdk1JQUx4WmY2eFU2REVnb20ydDdUN3gvYURzejBOUTBV?= =?utf-8?B?c1ZuRkcybkt2cDVpU2RBbDhzZmx1akQvZHg4SUgwWnZRbklzd1FoZzFkOThG?= =?utf-8?B?d3o3WTdTcGc0bnU2d01XWEUvcllRVzdOVlRNTkEycVhYeTh4REJrR0c2ajVw?= =?utf-8?B?YWV1MnlIejJCNkRFbjRvNmNuMVdZQ3FXRTJYRTY5NUdLMkxrUDUxdDhvcXFC?= =?utf-8?B?SDYyOTc0RjVYdFpXdnZlZDltWTZkYUdNTnBOU1pDODlsUHkrMW1EWU1lYzMv?= =?utf-8?B?c285THpKRG9nV2pQSVZuTDdsQ05zczdiRmc2dlpHYld0dUtVRENPSDdKVnEw?= =?utf-8?B?OUFIdjRxL1JUYUVySzBkYU9NeUZ4K0JkeGRoUUxwUXQwaDU4b3M4TXhUdVV5?= =?utf-8?B?aDJJVm55TTM5NzVmajhHeCtlc09QN2VBMTBOdVYyMUc4L0gyOHR6NWlxeTBJ?= =?utf-8?B?V0FUbWI1QVZmN3N3NW1ick9odUUrMGUvb3ZyZURGdGgrN1hYSUtORGg1d0Rw?= =?utf-8?B?MkdZdTJkNklFZ2VhMWZmVU41ZHE5cERnOVZQMXhGRVRaZmJYZXBlUWF3T1Ix?= =?utf-8?B?WDlsOWlHdlFvRml3WTF5cHFRMHc0SVoyTU54SkppdElqdXkzWkp3cC9uMi93?= =?utf-8?B?a0lmRFJIZk8xWHVIUEUxTUxUeHhreGVQNS9aRlJZRFRVWUc1MzFkaUVKRVll?= =?utf-8?B?b2JJZnhhcTlxT2tNRjV3QnFjTTQzdXY3d3BKMm5xNXRlenVsVXZGSmp6Tm85?= =?utf-8?B?TFlZaHZxajZ5Rlg5VXFhRkNSNU0xeVpYVzlMQWRDT1BkZ1FRUzNuTUhzQTBM?= =?utf-8?B?dllwbVNobUpDT2NoUll2U2dldnBLakxKVFZtVEJZUEordGlxVGdIclo3SXZW?= =?utf-8?B?STA4U2FnOHR2a0FPMy8rUUlMaGFWSXAxamh1QlFXWGt5dVJueE9wbERFK1F3?= =?utf-8?B?aHZudmkyc3JFZWtSNXhjSi9iSVFjVHBqTS90eC9ZY3VPN0dsSkZBSzdHVlYv?= =?utf-8?B?eUNQQUU3U0JpeVgvWVpmclpUQ0lGQVZ2dW5DdnplZmZJaVNCdC9xN1B5UE9K?= =?utf-8?B?ZmJJbHJ2TWhzeCttYk85V09GNmNIRHJuZGx0RjY4Y003OWZTZndrS2s5Q1ly?= =?utf-8?B?Wno3ODhVZWwweWtPZzd4ckFEdks2RitSVi9QTUpNNVBqZDNqWm9aZm12NXNz?= =?utf-8?B?QUZQWjZwWHVRU0dvaXI3RVpJSlQ1clJGSGVvUHVaWFF4ZXdCY0pWSWU1aTJr?= =?utf-8?B?N2JWZmwyZ0thcnh1bzFtVWFzVXI5cVM0TmdEdzAxbC9XOVVEVWhzL21qT2Mr?= =?utf-8?B?dTRxdGg3S21sek1MV2paQnQxTnVEaGlZb0xEL3QxYnA0ZnJwOUkwOVQ3b01T?= =?utf-8?B?TmxpdDJuQ0lGZXd4d3pMMzh5Y0FyWWZpdXN3eWw1UXdCcFpHOE8wam5INnlZ?= =?utf-8?B?d1J5bGszWWVKdS92N3hBanNBY0ltQUVDdmpLcXFHR0FYUUU5OXpxd3p0Wmc4?= =?utf-8?B?NkdVVnhrbjljY1FLT0JNMXRGTmcveERac0U2clIvaG8wbzU2dDZMQU94NTl3?= =?utf-8?B?TzFQc3pBemYrUlc4UnpKY3BJaENBa0FKMExWMXN1MEpZcVV4bkRMTXR0MENk?= =?utf-8?Q?VhvH/KfGx1B9bVqI3HgMWsg3GbGk9A2Mt1wGZpt?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6841 Original-Authentication-Results: vigilsec.com; dkim=none (message not signed) header.d=none; vigilsec.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT033.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 2053cbf6-b4cb-479b-9546-08d8e73cbbbb X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vtHR5dp6pbpMeUkGY37RzxsBbFjWb2qXJKvsaSGg55jeHuKFO2rZZcLj3orxCdbWM2rOJ9k+wZ3P4CIb6BdOy4Bbw+WEU56XGm+qY3InH5AiP6RzVxwZMq5F9gk/WRjI0Vc2UX94kbQ2VNWeU9gi4HlgMMcKndMrJ7MAi0vVNmE1IWn81ivvcPgNUH6DCK+7R/V6S5mMkc50A/TxNeYLLZYRQSvACy42TPqAs0bvt11ThhsnnMKkACCGWnnHyskRHpeDET7Vy2/GcRcUC7+SSAWcDQxPOcFt3AMeh6//K/HzBz/xpKnxFP4u1GOvtm5PIQaw4D0Agj2dHrvHDvu2/Np03iLs/7g6b+jxH6Y7iBqzSVVojfo6WTko2zGF6/xHT2eXS4v8ialkT1mrZymVuTZpy/UpqXI4cR/4f8yJoDnPe3LG00M+JJ7Kp9jhFKG0e3XYmklS/xzWeReglrcxxUiLrIz5fPqFUmKf/0OF2vQKRARE17ywL/YsLkLZTgzUFe6BMWjYcAuPMMCR05pfH+ZEZP+bcfQaaJvQO+rimvC8pVSOAbhp6k7hEfpwSnpVei1ooG6v+tFZX6cm/f4P/02aSBwQX6HWerewTQiP6l46fhT4aCv/v5B1FUJUt4KNa9OxQwQxViDoPpCR/lR0UKz44s0y3/laRbOSe825soqD8nlK0wnn/w4vz8LNmWpt8nDpFI8wdau0XniGllKMfNTOBmpQtj75vwWFJ1ZGEZ8= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(136003)(39860400002)(376002)(396003)(36840700001)(46966006)(966005)(26005)(316002)(5660300002)(6506007)(53546011)(110136005)(2906002)(186003)(54906003)(478600001)(70206006)(2616005)(4326008)(86362001)(8936002)(8676002)(6512007)(6486002)(83380400001)(81166007)(36756003)(36860700001)(336012)(70586007)(450100002)(47076005)(82740400003)(33656002)(82310400003)(356005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2021 22:58:58.8227 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 67ebd943-b39d-47fc-fc5e-08d8e73cc0bf X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT033.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5714 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-acme-star-delegation-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2021 22:59:09 -0000 SGkgUnVzcywNCg0KVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBjbGVhciBhbmQgdGhvcm91Z2gg cmV2aWV3IQ0KDQpZb3VyIGNvbW1lbnRzIGFyZSBub3cgdHJhY2tlZCBpbiB0aGUgZm9sbG93aW5n IHRpY2tldHM6DQoNCk9uIDE0LzAzLzIwMjEsIDIyOjAyLCAiUnVzcyBIb3VzbGV5IHZpYSBEYXRh dHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPiBBYnN0cmFjdDogSXQgc2F5czog Ii4uLiAgcGFydHkgYWNjZXNzIHRvIGEgY2VydGlmaWNhdGUgYXNzb2NpYXRlZCB3aXRoDQo+IHNh aWQgaWRlbnRpZmllci4iICBUaGlzIGlzIG9kZCB3b3JkaW5nLCBhbmQgaXQgaXMgaW5jb3JyZWN0 LiAgVGhlDQo+IHBhcnR5IG5lZWRzIGFjY2VzcyB0byB0aGUgcHJpdmF0ZSBrZXkgdGhhdCBjb3Jy ZXNwb25kcyB0byB0aGUgcHVibGljDQo+IGtleSBpbiB0aGUgY2VydGlmaWNhdGUsIGFuZCB0aGUg Y2VydGlmaWNhdGUgbmVlZHMgdG8gY29udGFpbiB0aGUNCj4gc3ViamVjdCBmb3IgInNhaWQgaWRl bnRpZmllciIuICBDbGVhcmx5LCBhbGwgb2YgdGhhdCBzaG91bGQgbm90IGdvIGluDQo+IHRoZSBB YnN0cmFjdCwgYnV0IHdoYXQgZG9lcyBhcHBlYXIgaW4gdGhlIEFic3RyYWN0IG5lZWRzIHRvIGJl DQo+IHRlY2huaWNhbGx5IGFjY3VyYXRlLg0KDQpodHRwczovL2dpdGh1Yi5jb20veWFyb25mL0kt RC9pc3N1ZXMvMTM5DQoNCj4gU2VjdGlvbiAxIHNheXM6ICIuLi4gICBuYW1lIG1hdGNoZXMgdGhl IGF1dGhvcml0eSAuLi4iLiAgSSBmaW5kIHRoaXMNCj4gZGVzY3JpcHRpb24gY29uZnVzaW5nLiAg SSB0aGluayBpdCB3b3VsZCBiZSBtb3JlIGNsZWFyIHRvIHNheSB0aGF0IHRoZQ0KPiBjYWNoZSBz ZXJ2ZXIgbmVlZHMgdG8gcHJlc2VudCBhIGNlcnRpZmljYXRlIHdob3NlIHN1YmplY3QgbmFtZSBt YXRjaGVzDQo+IHRoZSBkb21haW4gbmFtZSBvZiB0aGUgVVJMIHRoYXQgaXMgcmVxdWVzdGVkLiAg VGhlIGN1cnJlbnQgd29yZGluZyBpcw0KPiB2ZXJ5IGVhc3kgdG8gY29uZnVzZSBuYW1lIG9mIHRo ZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eS4NCg0KaHR0cHM6Ly9naXRodWIuY29tL3lhcm9uZi9J LUQvaXNzdWVzLzE0MA0KDQo+IFNlY3Rpb24gMSBzYXlzOg0KPg0KPiAgICBXaGlsZSB0aGUgcHJp bWFyeSB1c2UgY2FzZSB3ZSBhZGRyZXNzIGlzIGRlbGVnYXRpb24gb2YgU1RBUg0KPiAgICBjZXJ0 aWZpY2F0ZXMsIHRoZSBtZWNoYW5pc20gcHJvcG9zZWQgaGVyZSBhY2NvbW1vZGF0ZXMgYW55DQo+ ICAgIGNlcnRpZmljYXRlIG1hbmFnZWQgd2l0aCB0aGUgQUNNRSBwcm90b2NvbC4gIFNlZSBTZWN0 aW9uIDIuNCBmb3INCj4gICAgZGV0YWlscy4NCj4NCj4gVGhpcyBpcyBub3QgbXVjaCBvZiBhIGhp bnQgdGhhdCBsb25nLXRlcm0gY2VydGlmaWNhdGVzIGFyZSBzdXBwb3J0ZWQNCj4gaW4gYWRkaXRp b24gdG8gU1RBUiBjZXJ0aWZpY2F0ZXMuICBGdXJ0aGVyLCBhIGhpbnQgYWJvdXQgdGhlIGhhbmRs aW5nDQo+IG9mIHJldm9jYXRpb24gaXMgYXBwcm9wcmlhdGUgaGVyZS4gIFN1cHBvcnQgZm9yIGxv bmctbGl2ZWQNCj4gY2VydGlmaWNhdGVzIGlzIGluIGNvbmZsaWN0IHdpdGggdGhlIHRpdGxlIG9m IHRoZSBkb2N1bWVudC4gIFBsZWFzZQ0KPiBhZGp1c3QgdGhlIHRpdGxlIG9mIHRoZSBkb2N1bWVu dCBhY2NvcmRpbmdseS4NCg0KaHR0cHM6Ly9naXRodWIuY29tL3lhcm9uZi9JLUQvaXNzdWVzLzE0 MQ0KDQo+IFNlY3Rpb24gMi4zLjIgc2F5czogIkJlc2lkZXMsIHdoZW4gZGVsZWdhdGlvbiBpcyBm b3IgYSBTVEFSDQo+IGNlcnRpZmljYXRlLCAuLi4iIChpbiBmb3VyIHBsYWNlcyBpbiB0aGlzIHNl Y3Rpb24pLiAgSSBmaW5kIHRoaXMgcGFydA0KPiBvZiB0aGUgZG9jdW1lbnQgc3RydWN0dXJlIGEg Yml0IGNvbmZ1c2luZy4gIE1heWJlIGl0IGlzIHRoZSBsYXNrIG90DQo+IGFkZXF1YXRlIHdhcm5p bmcgYWJvdXQgc3VwcG9ydCBmb3IgbG9uZy1saXZlZCBjZXJ0aWZpY2F0ZXMuICBNYXliZSBpdA0K PiB0aGUgdGhlIG1peGluZyBvZiBTVEFSIGNlcnRpZmljYXRlIGFuZCBsb25nLWxpdmVkIGNlcnRp ZmljYXRlDQo+IHByb2Nlc3NpbmcgaW4gb25lIHNlY3Rpb24uICBJIHN1Z2dlc3QgdGhhdCBzZXBh cmF0ZSBzZWN0aW9ucyBiZSB1c2VkDQo+IHRvIHByZXNlbnQgU1RBUiBjZXJ0aWZpY2F0ZSBhbmQg bG9uZy1saXZlZCBjZXJ0aWZpY2F0ZSBwcm9jZXNzaW5nDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS95 YXJvbmYvSS1EL2lzc3Vlcy8xNDINCg0KPiBJbiBTZWN0aW9uIDIuMy40LCB0aGUgdGV4dCBpcyBi ZWdnaW5nIGZvciBvbmUgbW9yZSBzZW50ZW5jZS4gIFBsZWFzZQ0KPiBzYXkgc29tZXRoaW5nIGFi b3V0IHRoZSBmYWN0IHRoYXQgdGhlIFNUQVIgY2VydGlmaWNhdGUgd2lsbCBleHBpcmUNCj4gc2hv cnRseSBhZnRlciB0aGUgYXV0b21hdGljIHJlbmV3YWwgcHJvY2VzcyBpcyBzdG9wcGVkIGJ5IHRo ZSBJZE8uDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS95YXJvbmYvSS1EL2lzc3Vlcy8xNDMNCg0KPiBT ZWN0aW9uIDIuNCBpcyBub3Qgc3VmZmljaWVudCB0byBleHBsYWluIHRoZSByZXZvY2F0aW9uIHBy b2Nlc3NpbmcuDQo+IE9ubHkgdGhlIE5EQyBoYXMgdGhlIHByaXZhdGUga2V5IG5lZWRlZCB0byBt YWtlIHRoZSBBQ01FIHJldm9jYXRpb24NCj4gcmVxdWVzdCwgYnV0IHRoaXMgZG9lcyBub3QgZ2V0 IHN0YXRlZCBpbiB0aGUgdGV4dC4gIEFsc28sIGl0IGlzIG5vdA0KPiBjbGVhciB0byBtZSBob3cg dGhlIE5EQyBrbm93cyB3aGVyZSB0byBzZW5kIHRoZSByZXZvY2F0aW9uIHJlcXVlc3QNCj4gc2lu Y2UgdGhlIElkTyBpcyB0aGUgQUNNRSBhY2NvdW50IG93bmVyLiAgSW4gYWRkaXRpb24sIHRoZSBw aHJhc2UNCj4gIndvdWxkIGNyZWF0ZSBhIHNlbGYtaW5mbGljdGVkIERvUyIgbmVlZHMgbW9yZSBl eHBsYW5hdGlvbi4NCg0KaHR0cHM6Ly9naXRodWIuY29tL3lhcm9uZi9JLUQvaXNzdWVzLzE0NA0K DQo+IFNlY3Rpb24gNS42IHJlZ2lzdGVycyBhIHN0cmluZyBuYW1lIGZvciBlYWNoIGV4dGVuZGVk S2V5VXNhZ2UgT0lELg0KPiBUaGVyZSBzaG91bGQgYmUgYSB3YXkgdG8gcHJvdmlkZSB0aGUgT0lE IGluIGRvdHRlZCBkZWNpbWFsIGZvcm1hdCBhcw0KPiB3ZWxsLiAgTmV3IE9JRHMgYXJlIGJlaW5n IGFzc2lnbmVkIGFsbCB0aGUgdGltZSwgYW5kIHNvbWUgb2YgdGhlbSBtYXkNCj4gbm90IGJlIHJl Z2lzdGVyZWQgd2l0aCBJQU5BLg0KDQpodHRwczovL2dpdGh1Yi5jb20veWFyb25mL0ktRC9pc3N1 ZXMvMTQ1DQoNCj4gU2VjdGlvbiA1LjYgcmVnaXN0ZXJzIGEgc3RyaW5nIG5hbWUgZm9yIGVhY2gg dHlwZSBvZiBzdWJqZWN0QWx0TmFtZS4NCj4gVGhpcyBpbmNsdWRlIG90aGVyTmFtZSwgd2hpY2gg YXJlIGlkZW50aWZpZWQgYnkgYW4gT0lELiAgTmV3IE9JRHMgYXJlDQo+IGJlaW5nIGFzc2lnbmVk IGFsbCB0aGUgdGltZS4gIEZvciBleGFtcGxlLCBkcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy0N Cj4gY29udHJvbC1wbGFuZS0zMCBjcmVhdGVzIGEgbmV3IG90aGVyTmFtZS4gIFRoZXJlIHNob3Vs ZCBiZSBhIHdheSB0bw0KPiBwcm92aWRlIHRoZSB0aGUgb3RoZXJOYW1lIE9JRCBpbiBkb3R0ZWQg ZGVjaW1hbCBmb3JtYXQgYXMgd2VsbC4NCg0KaHR0cHM6Ly9naXRodWIuY29tL3lhcm9uZi9JLUQv aXNzdWVzLzE0Ng0KDQo+IE1pbm9yIENvbmNlcm5zOg0KPg0KPiBBYnN0cmFjdDogUGxlYXNlIHNw ZWxsIG91dCBBQ01FLCBDRE4sIGFuZCBTVEFSLiAgVGhlc2UgYXJlIG5vdCBtYXJrZWQNCj4gYXMg IndlbGwga25vd24iIGluIHRoZSBSRkMgRWRpdG9yIGFiYnJldmlhdGlvbiBleHBhbnNpb24gbGlz dC4NCj4NCj4gU2VjdGlvbiAxLjE6IFBsZWFzZSBjaGFuZ2UgQ0EgdG8gIkNlcnRpZmljYXRpb24g QXV0aG9yaXR5Ii4gIFNlZQ0KPiBTZWN0aW9uIDMgb2YgUkZDIDUyODAuICBUaGlzIGNoYW5nZXMg aXMgYWxzbyBuZWVkZWQgZWxzZXdoZXJlIGluIHRoZQ0KPiBkb2N1bWVudC4NCj4NCj4gU2VjdGlv biAxLjE6IFBsZWFzZSBhZGQgQ0ROSSwgdUNETiwgZENETiwgUEFTU1BvclQsIENTUiBhbmQgRlFE TiB0bw0KPiB0aGUgbGlzdCBvZiB0ZXJtcy4NCg0KaHR0cHM6Ly9naXRodWIuY29tL3lhcm9uZi9J LUQvaXNzdWVzLzE0Nw0KDQo+IFNlY3Rpb24gMSBkZXNjcmliZXMgW0ktRC5tZ2x0LWx1cmstdGxz MTNdIGFzIGFuIG9uZ29pbmcgZWZmb3J0LiAgVGhpcw0KPiBpcyBub3QgYWNjdXJhdGUuICBUaGUg TFVSSyBCb0YgZGlkIG5vdCBsZWFkIHRvIGEgV0cgb3IgYW4gZWZmb3J0IGluIGFuDQo+IGV4aXN0 aW5nIFdHLiAgSSB0aGluayB0aGUgYmVzdCB3YXkgZm9yd2FyZCBpcyB0byBkcm9wIHRoaXMgcmVm ZXJlbmNlLg0KDQpodHRwczovL2dpdGh1Yi5jb20veWFyb25mL0ktRC9pc3N1ZXMvMTQ4DQoNCj4g Tml0czoNCj4NCj4gU2VjdGlvbiAyIHNheXM6ICIuLi4gaW4gdGhpcyBkcmFmdCAuLi4iLiAgUGxl YXNlIHVzZSBhIHdvcmsgdGhhdCB3aWxsDQo+IHN0aWxsIGJlIGFwcHJvcHJpYXRlIHdoZW4gdGhp cyBkb2N1bWVudCBiZWNvbWVzIGFuIFJGQy4NCj4NCj4gU2VjdGlvbiAyLjQ6IHMvU2VjLiA3LjYv U2VjdGlvbiA3LjYvICAoYW5kIG1hbnkgb3RoZXIgcGxhY2VzKQ0KDQpodHRwczovL2dpdGh1Yi5j b20veWFyb25mL0ktRC9pc3N1ZXMvMTQ5DQoNCj4gSURuaXRzIHJlcG9ydHM6DQo+DQo+ICAgKiog VGhlcmUgYXJlIDMgaW5zdGFuY2VzIG9mIHRvbyBsb25nIGxpbmVzIGluIHRoZSBkb2N1bWVudCwg dGhlDQo+ICAgICAgbG9uZ2VzdCBvbmUgIGJlaW5nIDQgY2hhcmFjdGVycyBpbiBleGNlc3Mgb2Yg NzIuDQo+DQo+ICAgPT0gVGhlcmUgYXJlIDQgaW5zdGFuY2VzIG9mIGxpbmVzIHdpdGggbm9uLVJG QzY4OTAtY29tcGxpYW50IElQdjQNCj4gICAgICBhZGRyZXNzZXMgaW4gdGhlIGRvY3VtZW50LiAg SWYgdGhlc2UgYXJlIGV4YW1wbGUgYWRkcmVzc2VzLCB0aGV5DQo+ICAgICAgc2hvdWxkIGJlIGNo YW5nZWQuDQo+DQo+IFtJIHN1c3BlY3QgdGhlc2UgYXJlIG5vdCBJUHY0IGFkZHJlc3NlcywgYnV0 IE9JRHMgaW4gZG90dGVkIGRlY2ltYWwuXQ0KDQpodHRwczovL2dpdGh1Yi5jb20veWFyb25mL0kt RC9pc3N1ZXMvMTUwDQoNCldlJ2xsIGJlIGJhY2sgdG8geW91IGFzIHNvb24gYXMgd2UgaGF2ZSBh ZGRyZXNzZWQgdGhlbSBvciBmb3IgZnVydGhlcg0KY2xhcmlmaWNhdGlvbnMsIGlmIG5lZWRlZC4N Cg0KQ2hlZXJzLCBhbmQgdGhhbmtzIGFnYWluLg0KDQoNCg0KDQoNCg0KSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Tue Mar 16 09:34:34 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 292B13A1355; Tue, 16 Mar 2021 09:34:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161591246412.5771.17798271339560020312@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Tue, 16 Mar 2021 09:34:24 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 16:34:24 -0000 Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document doesn't seem to be complete. The document claims that it changes the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identify which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Best Regards, Linda Dunbar From nobody Tue Mar 16 09:46:12 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8543A1397; Tue, 16 Mar 2021 09:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeu2rGHPflVv; Tue, 16 Mar 2021 09:46:10 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 4563A3A136F; Tue, 16 Mar 2021 09:46:07 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id a15so18573918vsi.7; Tue, 16 Mar 2021 09:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7C0ttR8QuAiy0YEW0QIA2O5At4LSxXSwBz4eVQZRWhQ=; b=VetK5BZYAKalt1jBojPQ5tKKZKuGkdKRn4i+FwibhnVQozZbxMWvZTWN/6Bbg+aLDT /oL5nbRIbQMmtMX0gJU4I25TYQOhTnTyN6gQ6Bj97fV7PxAcF04pdFEsIOL3eIDMV91b q/a1vxTTtWjLP3HPXdsDyziVrzxElxjPUzcBV0hYdW8SsRpOBrSCCxvvdrbH61II3h+A zDM6nkYJykM+C7OdbrZeKdW/77SVGluoO+5mikP8Jku2V8OEBSpxtYZUJrR+578jk5GM 0vhGnemTG77mYn0BGtpwDf1l77Yaoa3yzdF4X3V6KNUoeMe8QwdylgtRAENnE3l0IT/P E3GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7C0ttR8QuAiy0YEW0QIA2O5At4LSxXSwBz4eVQZRWhQ=; b=NGOwRYRstTqSvYX+/2RDMvTaJ/Ho/yA5jE8/Z1tB2rWj4TjHMEzO3B17BukZvFWRT3 E9KArRrdPyI5qNrrwz2nX590TsEdqiO7pe5BYQrgIKwWh01dn+/qbcBZENzzm9zeOPsj lg0vN2KvCDbGdUtQAp1bWgw1v/RaS88VyjnxlQJI2wuUFQve0hJENJ07FxKq8TMH7gbO /XPBmFfhqKZKaF7oafTtGo1KySHWSieIUhCb76NY1/6wyfOTzMNSm3Nk8dlyxbyWH3Of ApTRb7J2gyQ4xERWDnoSdMCW/kLoI2SZvHcH8XnaIj/pEpvCkM1fBDdoVjtRM1sX5wQs hDlA== X-Gm-Message-State: AOAM531nixisZAic9zRxHAZ0nt3apxwCqGU26tXvL0hmqi6b+JdIrKw3 u3KFLWYmCirczHzToZPWLkcSlwfFbr07H3n44as= X-Google-Smtp-Source: ABdhPJzUegZfolxQT3jPpVjX7ajZC7YU+G6fDa4ciUzCXd2ZpQ32fShXFqH1OsKEGmhy5CKV5+Dbhva3D5XQUaZCJpk= X-Received: by 2002:a67:f04d:: with SMTP id q13mr623997vsm.40.1615913165434; Tue, 16 Mar 2021 09:46:05 -0700 (PDT) MIME-Version: 1.0 References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> In-Reply-To: <161591246412.5771.17798271339560020312@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Tue, 16 Mar 2021 09:45:54 -0700 Message-ID: To: Linda Dunbar Cc: secdir@ietf.org, draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="00000000000036b3d605bdaa1ace" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 16:46:12 -0000 --00000000000036b3d605bdaa1ace Content-Type: text/plain; charset="UTF-8" Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker < noreply@ietf.org> wrote: > This document doesn't seem to be complete. The document claims that it > changes > the policy of the Location-to-Service Translation (LoST) Location Profile > registry from Standards Action to Specification Required, but it doesn't > specify what is the new procedure. It says allowing other SDOs to change > or > add values. But which SDOs are allowed? Are there any procedures to > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add or > delete the values? > Specification Required is defined in RFC 8162. The IESG will be tasked with appointing a designated expert (DE) to review registration requests against the published specification. The DE will have discretion to determine whether an application should be accepted. The document contains no guidance about particular SDOs, so the DE is left to decide whether to factor the source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the call about "legitimate". -MSK --00000000000036b3d605bdaa1ace Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Linda, thanks for your review.=C2=A0 C= omments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatrac= ker <noreply@ietf.org> wrote:=
This document d= oesn't seem to be complete. The document claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn'= t
specify what is the new procedure.=C2=A0 It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

Specification Requir= ed is defined in RFC 8162.=C2=A0 The IESG will be tasked with appointing a = designated expert (DE) to review registration requests against the publishe= d specification.=C2=A0 The DE will have discretion to determine whether an = application should be accepted.=C2=A0 The document contains no guidance abo= ut particular SDOs, so the DE is left to decide whether to factor the sourc= e into the approval or rejection of the request.

S= o any SDO can make a request to update the registry.=C2=A0 The DE makes the= call about "legitimate".

-MSK
=
--00000000000036b3d605bdaa1ace-- From nobody Tue Mar 16 10:13:08 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C218C3A1486; Tue, 16 Mar 2021 10:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9-uAjKA6XCU; Tue, 16 Mar 2021 10:12:57 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2093.outbound.protection.outlook.com [40.107.92.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A723A1485; Tue, 16 Mar 2021 10:12:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CRpCOv9CHSzVQw1i4+5j1/C96JAmedtvecRoxLq+0BOV3niqepetJvqUxAKYE6Dk7PJKhuGNlo2OzwyUP7KAiq1sgrflfMpHHQR+fTARxWbNfdXf5XqcIfxULMKgd34fJPiIheQpKHv3F45MC2QAplr7zISFY1Yiics5rDPeUq2lyLNT7HNSDdo6CB8QegPWuKcDjawHDVYz+l1VA2zHBijL/hDMkq5GhSuRDIrRuV4sIZrUaMfBzi7rSUs4maSgYItPOg/NHL+jP+5TZ9n8MwSojSizpBEjeu3fQXlklfRrcMZzR8lRinHFEDiaDhcrxI+fuEFjYJJVj/f0deRwWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1respnJ+oo6qBo94fNKNE1AbNb4bHHnwF+nEXVKv2yc=; b=MAK/NNNU9rO1bru4FbzZIEq8fUnQj3ZvcjLg/k4ZJqTJfPeDAaxK4Pb2RetERcuZlvcKT9537gc2KklYXucD+uYX6TSrxYs2j0ybLG8A2Vn/wkplMrJP3/30SA+Xpwnaz1INfi9DBImjIUdf/oov2cz1KvpUL7t0UeMDYq6D6c5S86JHCtJWdRd4Ly2F3BcrLgVSQqNfc5+2qdqf8noH+CKse5y+C8rCoB9BD7JWKKt5dTp1hCcfBHkVejnBaYrzhyvcHzL4W3k167V6uqfUCB2dzhIb/RFwrN6mKUUX42DFTTPOpgvgaInMhwUJ7hDVsBVehLA6pIW6GIvG2zScUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1respnJ+oo6qBo94fNKNE1AbNb4bHHnwF+nEXVKv2yc=; b=CO6Z4R5hfOgLmHNk3ZsfbixbX0hKJLaP4Fr1zmSqc4uXBFDpJONjvcvAEfKPV6ahIMH/fOztgeogna6DrtbzCGTlihqYzktL9dhDU+sDnNoQiZRDqnQTrneF+2WoAZz+WDAjb5sncwXm8tVlInuEy4j/1/B1uf3cyIPGVxloT+c= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB4287.namprd13.prod.outlook.com (2603:10b6:805:ea::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11; Tue, 16 Mar 2021 17:12:53 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a%6]) with mapi id 15.20.3955.013; Tue, 16 Mar 2021 17:12:53 +0000 From: Linda Dunbar To: "Murray S. Kucherawy" CC: "secdir@ietf.org" , "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" , "ecrit@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 Thread-Index: AQHXGoPdDsBYgrP5+UeHrEXFqCO1yqqG2bew Date: Tue, 16 Mar 2021 17:12:52 +0000 Message-ID: References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f592f03e-b4b0-4b34-ce58-08d8e89ebc0f x-ms-traffictypediagnostic: SN6PR13MB4287: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fnjt1G13/+xAkJRbHhe8Tnzji+zjMFWZaLqcWQqwIHaeibzE16J6To4O/bPNMycy+e0//yPUKiH6lgdKK2s/Bz6iSeCUq4+Et8hTJdJZjVuXzRNoYEr6s/6HqbBFUmk5j2qc5hmO0/8faUqTb43weu5bGupWwpoUJt4CH8ez7I1fVMUbbhKoAw8wUhwH+v84dtqCKo/nRb9oHn84hjxb1inc8DdEPtYerYnKKYZVzhUEuhjRbyMlER3ZyGodErAuUr9PrANO3ADgovhfgN3eGoQOOEzmiMf05OT01t5z3DrAStnBjcnl178vglay/IyD2dg0YcarfwP0KFwDafm/eoNcJg2G5C3sLS0WpCuGqN8DBmYreAiqSQuLaMLij0KPG7AEz9wLU9p1MDiIiiOQiK9YghECV4hkLUPK+sJRax+P94KnSBLtVBm5BqgjIlkczYGe0NJ8N89Ty2sALkhWZlLKKGEm291dKsjHCDYEAlQFEehTrply2PhJkqhEzwTWFg1Bn5+Vyjd6CmjYmTrZAncWR1DW8UlO4UD3/hMUND6ux8H4mpmuWajC5E3xNm6/ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(376002)(366004)(39840400004)(136003)(52536014)(33656002)(55016002)(64756008)(76116006)(6506007)(26005)(86362001)(8676002)(4326008)(71200400001)(44832011)(6916009)(83380400001)(316002)(9686003)(186003)(66946007)(8936002)(66556008)(66446008)(5660300002)(478600001)(7696005)(54906003)(66476007)(2906002)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?S2toOHhBSmJXZEJKeDZSazdjZE96Y0lOVXhsV1ZacVhKQ3VwbDFOWlpkdlZQ?= =?utf-8?B?UnZBejJ2eVNQVy9GamN4ZEp0cTdVeVBtaSswNzBkZkdpeWRJdU9iREt4bU1O?= =?utf-8?B?WGJoSURFUEtsZGdNQWlyTkdNMTFHRTJyWHFkUEZmTFJJNjFXdEZFbGtZSlJQ?= =?utf-8?B?Nlk5bnNCQ3BVeVNaVHdUaG9MbXZtQnE4elROWUNzQWgyMmFmZ0dndjA4eVFx?= =?utf-8?B?Z2dNbFc3eFRJU2Z5QWZRRnZrbDZXY2QxQ3RLQkFadndScEY2aDMrREJxNFFy?= =?utf-8?B?KzJTZ2xmU3E5ajJ1U2Rpb2lLeXFEN1VuQnFvVnJMU21lN2ZtdTVlRG1tanlr?= =?utf-8?B?K3E3djRCNHl1T0xQdnF5RWYrZlBFbnFHNFpEWThPNmwrVml0MExockhUTzFE?= =?utf-8?B?SCt5NVUxMHZpZGhvY3JiL2RTUFE0ZVFHMmNlMTdjeFpkbDVEUWt2NG5ISVdR?= =?utf-8?B?anRPL1R1TnBjcDV1cTBtaE5tYUpMOEM5aWJnejMvZSt0QkVQdFFRR3p4emZV?= =?utf-8?B?ZldFdlJ2U0c4dzd6KzdaWTJWRm9iQ0M0bVlJVDVuNUFseUFlbjJMTGlsRjMx?= =?utf-8?B?MFJMNW5hVllBUWJLMzMvVVlsY2lkRUJUenFYeitIV1FyeEgveUU1TDFLWlNy?= =?utf-8?B?ZjBBRkZlZm5VNHBnb0tITlduZDlIK2xPbEgzSlN3SThMODljc3hMMnNtd2V3?= =?utf-8?B?L0x3amF3NngrSTQwQ0FGV1NNUmxBMXU4RzRyd3ZwQ1lGL1VBSHFwY0lnTmZC?= =?utf-8?B?bU5aVEV5bzkycWpOM09JMkRVZ2dZbDRCbStWMkF1YzJHUGVuc0Fwa3JxRjgr?= =?utf-8?B?NFRnQ1dRRkJqRGlvWEp5K0NSRTBmT0p6d3g2enFmMjVVakQzeVN6ckIzK0hT?= =?utf-8?B?UEYzU2VWRDN2ajFpTE8yYjEwdER3K2lJTnNUVjZwMVU3cHoyYzhLVUFGMk1P?= =?utf-8?B?SytIcnFZc1hFSm9TUXFqMDNvQVJidXNwUHRvTU1WdnpVdDF5MFdjb2ZML0Rv?= =?utf-8?B?dHEvaHNaT2F5alN5VzhOOVpDZ2QxcEJZZmpDcEc1cFN5czBxRXNaUExQRzRH?= =?utf-8?B?Y0hmdnVWWmRMU3NvVHJmcFd3em9VRzdVSzlxSkFxY3pVRy9tT09FTGlBb3p6?= =?utf-8?B?dHRnM1pTbHlPMjdoK2RFV1k4b1VqQUxTWUp6dTNJYStlajQ4d3BGeEdTY0h6?= =?utf-8?B?eXMxdnRORGFiTE5FTWZMMkkzOHhpTmVFZklWVmM0K2d0cnR1VWExVmwzeENt?= =?utf-8?B?NFo4bGo5MTBBbk9IVnN1NVlETG0ybGxEVWxtQjNFbzgwc3llUGpsVXdybFZl?= =?utf-8?B?bGNRSm9hWE40ZlpjNmc0c1V3T09jaXVIVmVWN3ZZYmpxTWo0WTQ1ZnNkbFkv?= =?utf-8?B?MW5zWjlOeHFOdC9CWlkvSUZ4aGl2SmJ1RnNGSzZIZG5rczk4Ynl2aTFQS2kw?= =?utf-8?B?WlBJMHpIcVlEVzloVFBwZHVvKzd0Z1lYeU5nb3haekFybmxiNFFkelFkSGMw?= =?utf-8?B?eTk5NnZqMktNazJUL3ArRTAwdTJpYzZ6VW1MRU1OUUtReUtaQk8vMGxHbzd6?= =?utf-8?B?RVVkWi9QTDlMUTYrMDBwU1ZZdTB4VS8xTUxPY1Vpc3diYnFtbzkybENuRWVB?= =?utf-8?B?ekFRaFBCTGFxY1NLSXZNQjVhSTdmSytxKzFoVUNYR25JUnFVMW1iVFJ1aS9T?= =?utf-8?B?MU50ZUJnNTA5SDdTT0c3N0pnMm5sNncrTWVLRzhKVnVWcDViTlJYaHI0Z1Nu?= =?utf-8?Q?GiaZIVMQEjuC1CQ41U=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR13MB2334DCB45EB76B47C19AFDEE856B9SN6PR13MB2334namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f592f03e-b4b0-4b34-ce58-08d8e89ebc0f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2021 17:12:52.9305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LhickHhNIEiEQfVQYBt+ZcveisKYyyj2/2y9m+MgJmK6A9rau0r5KgoJ1H4Zq1rSmgJOhT7ZmpN5gp3U4pPcOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB4287 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 17:12:59 -0000 --_000_SN6PR13MB2334DCB45EB76B47C19AFDEE856B9SN6PR13MB2334namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXVycmF5LA0KDQpUaGVuIHdoeSBuZWVkIHRoaXMgZG9jdW1lbnQ/DQpJc27igJl0IGl0IGFscmVh ZHkgdGhlIHByYWN0aWNlIHRoYXQg4oCcVGhlIElFU0cgd2lsbCBiZSB0YXNrZWQgd2l0aCBhcHBv aW50aW5nIGEgZGVzaWduYXRlZCBleHBlcnQgKERFKSB0byByZXZpZXcgcmVnaXN0cmF0aW9uIHJl cXVlc3RzIGFnYWluc3QgdGhlIHB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9u4oCdPw0KDQpMaW5kYQ0K DQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPg0KU2VudDog VHVlc2RheSwgTWFyY2ggMTYsIDIwMjEgMTE6NDYgQU0NClRvOiBMaW5kYSBEdW5iYXIgPGxpbmRh LmR1bmJhckBmdXR1cmV3ZWkuY29tPg0KQ2M6IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1l Y3JpdC1sb2NhdGlvbi1wcm9maWxlLXJlZ2lzdHJ5LXBvbGljeS5hbGxAaWV0Zi5vcmc7IGVjcml0 QGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTZWNkaXIgbGFzdCBj YWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWVjcml0LWxvY2F0aW9uLXByb2ZpbGUtcmVnaXN0cnkt cG9saWN5LTAxDQoNCkhpIExpbmRhLCB0aGFua3MgZm9yIHlvdXIgcmV2aWV3LiAgQ29tbWVudHMg YmVsb3cuDQoNCk9uIFR1ZSwgTWFyIDE2LCAyMDIxIGF0IDk6MzQgQU0gTGluZGEgRHVuYmFyIHZp YSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+ IHdyb3RlOg0KVGhpcyBkb2N1bWVudCBkb2Vzbid0IHNlZW0gdG8gYmUgY29tcGxldGUuIFRoZSBk b2N1bWVudCBjbGFpbXMgdGhhdCBpdCBjaGFuZ2VzDQp0aGUgcG9saWN5IG9mIHRoZSBMb2NhdGlv bi10by1TZXJ2aWNlIFRyYW5zbGF0aW9uIChMb1NUKSBMb2NhdGlvbiBQcm9maWxlDQpyZWdpc3Ry eSBmcm9tIFN0YW5kYXJkcyBBY3Rpb24gdG8gU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCwgYnV0IGl0 IGRvZXNuJ3QNCnNwZWNpZnkgd2hhdCBpcyB0aGUgbmV3IHByb2NlZHVyZS4gIEl0IHNheXMgYWxs b3dpbmcgb3RoZXIgU0RPcyB0byBjaGFuZ2Ugb3INCmFkZCB2YWx1ZXMuIEJ1dCB3aGljaCBTRE9z IGFyZSBhbGxvd2VkPyBBcmUgdGhlcmUgYW55IHByb2NlZHVyZXMgdG8gaWRlbnRpZnkNCndoaWNo IFNET3MgYXJlIGxlZ2l0aW1hdGU/IGNhbiBhbnkgb3JnYW5pemF0aW9ucywgc2F5IFhZWiwgY2hh bmdlLCBhZGQgb3INCmRlbGV0ZSB0aGUgdmFsdWVzPw0KDQpTcGVjaWZpY2F0aW9uIFJlcXVpcmVk IGlzIGRlZmluZWQgaW4gUkZDIDgxNjIuICBUaGUgSUVTRyB3aWxsIGJlIHRhc2tlZCB3aXRoIGFw cG9pbnRpbmcgYSBkZXNpZ25hdGVkIGV4cGVydCAoREUpIHRvIHJldmlldyByZWdpc3RyYXRpb24g cmVxdWVzdHMgYWdhaW5zdCB0aGUgcHVibGlzaGVkIHNwZWNpZmljYXRpb24uICBUaGUgREUgd2ls bCBoYXZlIGRpc2NyZXRpb24gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYW4gYXBwbGljYXRpb24gc2hv dWxkIGJlIGFjY2VwdGVkLiAgVGhlIGRvY3VtZW50IGNvbnRhaW5zIG5vIGd1aWRhbmNlIGFib3V0 IHBhcnRpY3VsYXIgU0RPcywgc28gdGhlIERFIGlzIGxlZnQgdG8gZGVjaWRlIHdoZXRoZXIgdG8g ZmFjdG9yIHRoZSBzb3VyY2UgaW50byB0aGUgYXBwcm92YWwgb3IgcmVqZWN0aW9uIG9mIHRoZSBy ZXF1ZXN0Lg0KDQpTbyBhbnkgU0RPIGNhbiBtYWtlIGEgcmVxdWVzdCB0byB1cGRhdGUgdGhlIHJl Z2lzdHJ5LiAgVGhlIERFIG1ha2VzIHRoZSBjYWxsIGFib3V0ICJsZWdpdGltYXRlIi4NCg0KLU1T Sw0K --_000_SN6PR13MB2334DCB45EB76B47C19AFDEE856B9SN6PR13MB2334namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NdXJyYXksIDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVuIHdoeSBuZWVkIHRoaXMgZG9jdW1lbnQ/IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXNu4oCZdCBpdCBhbHJlYWR5IHRoZSBwcmFjdGljZSB0 aGF0IOKAnDxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGUgSUVTRyB3aWxsIGJlIHRh c2tlZCB3aXRoIGFwcG9pbnRpbmcgYSBkZXNpZ25hdGVkIGV4cGVydCAoREUpIHRvIHJldmlldyBy ZWdpc3RyYXRpb24gcmVxdWVzdHMgYWdhaW5zdCB0aGUgcHVibGlzaGVkIHNwZWNpZmljYXRpb27i gJ0/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaW5kYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTXVycmF5IFMuIEt1Y2hlcmF3 eSAmbHQ7c3VwZXJ1c2VyQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IE1hcmNoIDE2LCAyMDIxIDExOjQ2IEFNPGJyPg0KPGI+VG86PC9iPiBMaW5kYSBEdW5iYXIgJmx0 O2xpbmRhLmR1bmJhckBmdXR1cmV3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2VjZGlyQGll dGYub3JnOyBkcmFmdC1pZXRmLWVjcml0LWxvY2F0aW9uLXByb2ZpbGUtcmVnaXN0cnktcG9saWN5 LmFsbEBpZXRmLm9yZzsgZWNyaXRAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1l Y3JpdC1sb2NhdGlvbi1wcm9maWxlLXJlZ2lzdHJ5LXBvbGljeS0wMTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTGluZGEsIHRoYW5rcyBmb3IgeW91ciBy ZXZpZXcuJm5ic3A7IENvbW1lbnRzIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXIgMTYsIDIwMjEgYXQgOTozNCBBTSBMaW5kYSBE dW5iYXIgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9y ZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVudCBkb2Vzbid0 IHNlZW0gdG8gYmUgY29tcGxldGUuIFRoZSBkb2N1bWVudCBjbGFpbXMgdGhhdCBpdCBjaGFuZ2Vz PGJyPg0KdGhlIHBvbGljeSBvZiB0aGUgTG9jYXRpb24tdG8tU2VydmljZSBUcmFuc2xhdGlvbiAo TG9TVCkgTG9jYXRpb24gUHJvZmlsZTxicj4NCnJlZ2lzdHJ5IGZyb20gU3RhbmRhcmRzIEFjdGlv biB0byBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkLCBidXQgaXQgZG9lc24ndDxicj4NCnNwZWNpZnkg d2hhdCBpcyB0aGUgbmV3IHByb2NlZHVyZS4mbmJzcDsgSXQgc2F5cyBhbGxvd2luZyBvdGhlciBT RE9zIHRvIGNoYW5nZSBvcjxicj4NCmFkZCB2YWx1ZXMuIEJ1dCB3aGljaCBTRE9zIGFyZSBhbGxv d2VkPyBBcmUgdGhlcmUgYW55IHByb2NlZHVyZXMgdG8gaWRlbnRpZnk8YnI+DQp3aGljaCBTRE9z IGFyZSBsZWdpdGltYXRlPyBjYW4gYW55IG9yZ2FuaXphdGlvbnMsIHNheSBYWVosIGNoYW5nZSwg YWRkIG9yPGJyPg0KZGVsZXRlIHRoZSB2YWx1ZXM/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVjaWZpY2F0aW9uIFJlcXVpcmVk IGlzIGRlZmluZWQgaW4gUkZDIDgxNjIuJm5ic3A7IFRoZSBJRVNHIHdpbGwgYmUgdGFza2VkIHdp dGggYXBwb2ludGluZyBhIGRlc2lnbmF0ZWQgZXhwZXJ0IChERSkgdG8gcmV2aWV3IHJlZ2lzdHJh dGlvbiByZXF1ZXN0cyBhZ2FpbnN0IHRoZSBwdWJsaXNoZWQgc3BlY2lmaWNhdGlvbi4mbmJzcDsg VGhlIERFIHdpbGwgaGF2ZSBkaXNjcmV0aW9uIHRvIGRldGVybWluZSB3aGV0aGVyIGFuIGFwcGxp Y2F0aW9uDQogc2hvdWxkIGJlIGFjY2VwdGVkLiZuYnNwOyBUaGUgZG9jdW1lbnQgY29udGFpbnMg bm8gZ3VpZGFuY2UgYWJvdXQgcGFydGljdWxhciBTRE9zLCBzbyB0aGUgREUgaXMgbGVmdCB0byBk ZWNpZGUgd2hldGhlciB0byBmYWN0b3IgdGhlIHNvdXJjZSBpbnRvIHRoZSBhcHByb3ZhbCBvciBy ZWplY3Rpb24gb2YgdGhlIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGFueSBTRE8gY2FuIG1ha2UgYSByZXF1ZXN0IHRvIHVw ZGF0ZSB0aGUgcmVnaXN0cnkuJm5ic3A7IFRoZSBERSBtYWtlcyB0aGUgY2FsbCBhYm91dCAmcXVv dDtsZWdpdGltYXRlJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tTVNLPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN6PR13MB2334DCB45EB76B47C19AFDEE856B9SN6PR13MB2334namp_-- From nobody Tue Mar 16 10:39:39 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB073A1511; Tue, 16 Mar 2021 10:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8QHB6Z5tZuW; Tue, 16 Mar 2021 10:39:31 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8A23A1512; Tue, 16 Mar 2021 10:39:31 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12GHdMMt022522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Mar 2021 13:39:26 -0400 Date: Tue, 16 Mar 2021 10:39:21 -0700 From: Benjamin Kaduk To: Linda Dunbar Cc: "Murray S. Kucherawy" , "last-call@ietf.org" , "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" , "ecrit@ietf.org" , "secdir@ietf.org" Message-ID: <20210316173921.GG79563@kduck.mit.edu> References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 17:39:34 -0000 Hi Linda, The current registration procedure (visible at https://www.iana.org/assignments/lost-location-profiles/lost-location-profiles.xhtml) of Standards Action only requires a standards-track RFC to get an allocation; there is no designated expert involved in that procedure. RFC 8126 again remains a good reference for these registration policies. Thanks, Ben On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: > Murray, > > Then why need this document? > Isn’t it already the practice that “The IESG will be tasked with appointing a designated expert (DE) to review registration requests against the published specification”? > > Linda > > From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM > To: Linda Dunbar > Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org > Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 > > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: > This document doesn't seem to be complete. The document claims that it changes > the policy of the Location-to-Service Translation (LoST) Location Profile > registry from Standards Action to Specification Required, but it doesn't > specify what is the new procedure. It says allowing other SDOs to change or > add values. But which SDOs are allowed? Are there any procedures to identify > which SDOs are legitimate? can any organizations, say XYZ, change, add or > delete the values? > > Specification Required is defined in RFC 8162. The IESG will be tasked with appointing a designated expert (DE) to review registration requests against the published specification. The DE will have discretion to determine whether an application should be accepted. The document contains no guidance about particular SDOs, so the DE is left to decide whether to factor the source into the approval or rejection of the request. > > So any SDO can make a request to update the registry. The DE makes the call about "legitimate". > > -MSK > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Tue Mar 16 10:40:54 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D973A1511; Tue, 16 Mar 2021 10:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4SGDcWDyJNo; Tue, 16 Mar 2021 10:40:51 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 3DB963A14FE; Tue, 16 Mar 2021 10:40:51 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id m18so18701323vsa.1; Tue, 16 Mar 2021 10:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oZGnTSLJ0d/OVLtQLfrMwpRtm0fCQyymSkYFwGQmu6g=; b=Cwwz7ILW494pEJmYOHhRrv515J+MMxe09px/HGq1Au2hbtFH6SkVXoBZ6Hor53KHq+ KKgaMG14xAefLZj6NBgvMIux0d99/O+XfP3MRrvk3u2rzkN4ep7/vyzt3Hhb017xSxia pjB5CalXtz+HzCyZd6KTtSxl0LOIrB/RZYwXXaDBZtW4zaML17bTegEjnqh7jKakE3n2 G7uE42o76nvb2jTmUoODH+yd+gWa48TAe3CaJm/D3kQKXulqQ3KcDrGCVQMi2QbeUomp jBULU45DpnHtee+iiSAIMhIp8wkT/xYFkH+YjO0dyjBJ4elZJzIoEdWJgnCuECflAvJF YGTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oZGnTSLJ0d/OVLtQLfrMwpRtm0fCQyymSkYFwGQmu6g=; b=mjxt++ERCjJCTROm2Ov0wZSDsNBQNkfJMdAqnHpX+Rk3lZ8HN4vLgLZPcRno+zl7n2 XUoaRuYfAnLSZ1pvW/LsBtwpYhwgaZ8j+4zTx2O1f0yQkL3utHp9hZgwBE0mnPc4Eooc 0dAzNPZhrN/QzCByM/Sr8b9uepeu/c19h/BUBFKQ/LbwE7nP5EgDqnObimsmB0eKvSyu 0Fxqio0l3e2XmCUtvM89S0ZGUsiciSB52OV+9BcJ33u1sfo7WqCsg6i7gdXsH7duM9vN 8LA8mevgkESzoQI/1UZ0k7jyCChN/mNIjOkS2yD2U/WfbARghdrM54hItC8Og/IEstRj Y/zQ== X-Gm-Message-State: AOAM530s82C4erjmbiKJtOhnEWifsc/AQYIWKIuT+sKVOG2O7cXUq4YO CW3MaPoGu76VQk7TJ3n/PP/C5tRwSpcTG//i8YvflFyM X-Google-Smtp-Source: ABdhPJy9Cmw726xQjpfH5t2bYKexBWyVLMqTqx38oh7aIyT33bxK9WmcUc2+tJv6CW3G8BVB0JZdspksXEzcYU13aco= X-Received: by 2002:a67:c09b:: with SMTP id x27mr777275vsi.33.1615916449303; Tue, 16 Mar 2021 10:40:49 -0700 (PDT) MIME-Version: 1.0 References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 16 Mar 2021 10:40:37 -0700 Message-ID: To: Linda Dunbar Cc: "secdir@ietf.org" , "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" , "ecrit@ietf.org" , "last-call@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f290c005bdaadd51" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 17:40:53 -0000 --000000000000f290c005bdaadd51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar wrote: > Then why need this document? > > Isn=E2=80=99t it already the practice that =E2=80=9C*The IESG will be tas= ked with > appointing a designated expert (DE) to review registration requests again= st > the published specification=E2=80=9D? * > No, the current rules for that registry are specified by Standards Action (Section 4.9 of RFC 8126), which requires a standards track RFC. There's no designated expert in that model. The working group wants to change the policy to the less restrictive model that allows for specifications published outside of the IETF to qualify, subject to expert review. -MSK --000000000000f290c005bdaadd51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 16, 2021 at 10:12 AM Linda Du= nbar <linda.dunbar@futurew= ei.com> wrote:
Then why need this d= ocument?=20

Isn=E2=80=99t it already the practice that =E2=80=9C= The IESG will be tasked with appoin= ting a designated expert (DE) to review registration requests against the p= ublished specification=E2=80=9D?


No, the current rules for that= registry are specified by Standards Action (Section 4.9 of RFC 8126), whic= h requires a standards track RFC.=C2=A0 There's no designated expert in= that model.=C2=A0 The working group wants to change the policy to the less= restrictive model that allows for specifications published outside of the = IETF to qualify, subject to expert review.

-MSK
--000000000000f290c005bdaadd51-- From nobody Tue Mar 16 14:01:20 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCC43A0E7E; Tue, 16 Mar 2021 14:01:10 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKwEDIQvgHbl; Tue, 16 Mar 2021 14:01:09 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D841E3A0E04; Tue, 16 Mar 2021 14:01:09 -0700 (PDT) Received: from [169.254.151.95] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 16 Mar 2021 14:01:05 -0700 From: "Randall Gellens" To: "Murray S. Kucherawy" Cc: "Linda Dunbar" , secdir@ietf.org, draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org Date: Tue, 16 Mar 2021 14:01:07 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 21:01:11 -0000 I just want to add that the document currently does contain some guidance. Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall From nobody Wed Mar 17 14:48:05 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0BF3A15CB; Wed, 17 Mar 2021 14:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.338 X-Spam-Level: X-Spam-Status: No, score=-7.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2efQKYP5CHw5; Wed, 17 Mar 2021 14:47:51 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650101.outbound.protection.outlook.com [40.107.65.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660793A15C6; Wed, 17 Mar 2021 14:47:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MnqlKdbZFZjDNkHFtopSSkoftViZAkSNLoyL9WQfPRlHMuUSn7F53Mi9XWpV2zYNCNNmM7hBgoI/iM2zOjk6LacKU5lzYoGKy9/AGnHXNZUYP793vKa8D69zo04+IS1XwDE0ZfMzksnYTfnUrd6rMuL/ca+4i1hPb5clWCkaQdTViB8NDFvv2CR18AYOQVH4+aEDhWW43howeY9W7dBM2lMqQOjgiNqX4VbaDXDK7PYnpRs5mRGCnCMkqjR0ncdfj4YKxBFUu7Kl7D8MO9NGeE/5qlj037Z7ylW5KW+F9Ik3VJAk5EFy/Us85jtHo0gQ1SWHnAvA3sJrAN+g1HggLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HP4kvvzpWVWPWs+Hvk9OPXtavah9rRXcLDaXgBSH4Uo=; b=ZrQ1x8cXdbtbRe3Iip+nxjFVPkwYQ6TZpIp1KmLWOJ5Tw84lLlqXeU6ERldLTi/9DkZHJ3mzK/Fg6GT/CLM678tryMly3LXaOF5usHxoP5LkJOfYFZSI7elwTjif0dDT76GAdjpcc7EGvCQPc6AZgNLQ6FM489w1FKnJseV44/XhUZb8HY86EbFHTK8IkyFBVXB5ZIixnT6JNepK4vrsloZDKBMiXXnJEIwKzRDuWDw6Acno5tOCFgepE18DEz+B5ZSObLztZW4lp7aOM2LXb8KTvx+zWHMwxZnvZMxNMRtdWK3d08eIeiPzlb7t83SanFUx+uIK8si3kuiXuWMmog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HP4kvvzpWVWPWs+Hvk9OPXtavah9rRXcLDaXgBSH4Uo=; b=VKcrUHmTm1ktjJczKWDIFV8G41pe/k5/orB7DjtvlAS0FcUn+L3R+XaPyb2JsgYKXyOU/O62tMYWvb92XaI1ZBfFUA44B51beiBUGrAFqPi7wOwHQDBVT6W0GP8Vn6fv7YXnZzgN0RdkUuQT0MtjSKlOTLNsb3AIlRWC/D2fU80= Received: from MW2PR00MB0427.namprd00.prod.outlook.com (2603:10b6:302:b::15) by MW2PR00MB0314.namprd00.prod.outlook.com (2603:10b6:302:8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3996.0; Wed, 17 Mar 2021 21:47:47 +0000 Received: from MW2PR00MB0427.namprd00.prod.outlook.com ([fe80::89cd:3767:fe:36ae]) by MW2PR00MB0427.namprd00.prod.outlook.com ([fe80::89cd:3767:fe:36ae%6]) with mapi id 15.20.3996.000; Wed, 17 Mar 2021 21:47:47 +0000 From: Mike Jones To: "watsonbladd@gmail.com" , nat , "rdd@cert.org" CC: "secdir@ietf.org" , "oauth@ietf.org" , "last-call@ietf.org" , "draft-ietf-oauth-jwsreq.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-oauth-jwsreq-30 Thread-Index: AdcMgZCvYIwrbG0eQzWUUepTetS2xAO9T18A Date: Wed, 17 Mar 2021 21:47:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-02-26T18:45:46Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d0870aa9-8291-4ab0-8ef5-bbc0f75710c3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2607:fb90:9ebc:fede:745e:fd1b:ce83:9052] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7024f96f-fa9f-4e7b-1b8a-08d8e98e4e32 x-ms-traffictypediagnostic: MW2PR00MB0314: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CRTpt4FLx568S57Lk900+ctjW9KQi9yy9SPcEJAFENBPLTm8B4rNIea/wO9+GByZiLlqUjBvOAmA3vbYuxSn4/SGsbr+5+iI7eKXFur1FqXPtvx6d/N1dAM+T8u2YhRpSkU61KPWN0WvElSLu0fRF3j23sozzUqAt0Yj6MqcLj6Z9rG+OW8Ckfg0ujB05qZpcZ6aWswjIP6veBkMAb09yK+ILfYJwpY2E88kpDHQz1U241Pqf2uU0YNEOdwX2ASvQhYutUV3JbGysBzu94ul0Vrtj4Nzpls6AnxoyitM086BaQeYJV5WEDvz7+QWx+vDGXa8M0PJvWSK4uXv7tkjar3vyjve5GW3n48m5OF8COXMGDLQSra672zm7DzsP9eqOkjAm/reTjG6Df73ZgWJM8kgv1xytlbRWPH8mCYlcj/qUH+4VBTdmO2NVvfa3nSrZ0z4BpX+8uQs/JOQubUOQRrkjFF6zYQj1x7PupXNJgYlDFFFonsnxHxBnDdxjI7fBnaQGTD7Vv2057TEKfUzO5Uf+DrYivYie5gr1B7nz1eh2P1VnXZJHYygvVnhqBJhY1Tz5+Uf6k9fr/abG1vw3vEOaAchYSJZgaQ5FjSFeyn7fOADkeJIIjEFKe2s1o7Irk9/2tOrXtDDNfRkLAcLYMkfNdalFN4IA95aHYPngCxP30PIY8WrLRP3mAswE95o x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR00MB0427.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(39860400002)(376002)(136003)(55016002)(86362001)(33656002)(82950400001)(66574015)(83380400001)(82960400001)(8936002)(5660300002)(52536014)(166002)(54906003)(110136005)(8676002)(316002)(66946007)(66476007)(66556008)(64756008)(9686003)(4326008)(76116006)(6506007)(53546011)(7696005)(66446008)(478600001)(10290500003)(186003)(30864003)(966005)(71200400001)(8990500004)(2906002)(546114003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?a20zZHZ0dUJFdGdrTndISkpqb08vZUhTUVdzK1FKRS9NQndoZXRLekM0czVY?= =?utf-8?B?OEluMFZIOUVLeEd4U3FWYWNiR01rc1RPK0VYTkFMWDdWR0RCNmpTT1FDSm9E?= =?utf-8?B?VHRad2xPMGtMaVp1RWZwdTNOM0Vzc0J1U0ZOeUQwbFRSdDRBNkNnb2FEejIz?= =?utf-8?B?RCsybFhaVUNiMzAwa3ppSDc0Qk1OTHRVQnNTS2V3bDZrbk9uZFNmY1puei85?= =?utf-8?B?T1lKQlM2TWdxOHNaN3pVZitXQjhKbDA1VmNMRGxqdGRZRERGdHp0MlE4bE5F?= =?utf-8?B?bEx4ZzJRakdBemJqN0ZBOGhZOU5rUTFnYzV4cHNGOGx5MU91aDRaOXBrWGlr?= =?utf-8?B?cVdBUHR6N2ZYQ2w3YUhGb3NpUGRKZGFnYTRoVDRaYnNUaDYxUVloM1F3a2t1?= =?utf-8?B?OHJ0ZjBLMHkzL0x5MEFNaDljalBtejBQTW5hVVMyTjlsVVpJUG5CQWJwZ29r?= =?utf-8?B?ZGxJWjZ2S1dLTy9ma3IvbDB3Zm14djErVTVFbk5yK3Y1UjU5Z3IreXFGa2Nn?= =?utf-8?B?Q3lvcXdqR003Y0tKSzJvbzh1alBCaWNXMlVrVWo2OXhsZmtSdTViVU9jVDM3?= =?utf-8?B?eFdMUC94bEhMZnNxRk11T1M2MzZNZFk0aXFJdWY4MEU0ZC81RWt4a0NTaDB1?= =?utf-8?B?L2p1R0svM2FMcjZYcDNnWHpNNzRHOXlONGlTb1B6bDBRK2hORU4zbXVISVpV?= =?utf-8?B?VllyNXNpWDFPdUliVm9SUWNxZ1Nkck5YMElBUzN4aUxzRFpRalNXenFqc2Rt?= =?utf-8?B?S0NwRTJaQXBOSkNEU083WHZtNmhKYzM2WTBpdUs4UmkzM29lcWpHcDFIdVdD?= =?utf-8?B?eHh2eXdNdjhBRDNVcjB6eXM5OUNSbm1FRS9qK05Nd1UwVkl5WlJlWXdvbDBO?= =?utf-8?B?aElzTUU4Rm9ZTDhFZnBkYkk4QnlmYVlSelhrUEdIZWhyMitUdzFaaGRCMHVh?= =?utf-8?B?TFR5WTdDVE1LekowejJVN1gwQ0s2ZDlYZDc2dFpldmQ2dmZmVFJVS0pGSXJi?= =?utf-8?B?aTRpbUt1clA2MEVrK3JsQ0Y4K2ZVbWhlbk4wQlJ5SHlzQk1scjZvSWw3TkFD?= =?utf-8?B?aEdyakZCcGZaQXpGRVkwaWhoUndxSWFIRS8rRDhHOEh2SmVJdDJWZkUwYzdz?= =?utf-8?B?YlpRQjl6SXhyVjIrMzBOUjIvVzFRZitYSVFDU1ZpMXpOeURVWTc4Qm5rR3lQ?= =?utf-8?B?OFZhU1hlS0FwOHgranFkUDBBT2g1STczWVZqZ0tkVkppb2tQMXlHa2FBRUtz?= =?utf-8?B?TGJvb3RGWlFOZU1QTFpFTTR2SE5Va2ZDZGNIcjRaM3hPOWp5SHRxSTA0dGNz?= =?utf-8?B?a3BmazViNmFCaWVIQUpQMFJ2eFUreVkrSjZLY2xwMmdOL3owdXBlWDlUN1ph?= =?utf-8?B?M215L3JuQXZXdkRPV2ZBTXAwMlBzWEtwMUR6aDM5T25BeDNhZ2VsWjgvZVIw?= =?utf-8?B?VVU0ZnFOcXJ4bDdVUHV1WjVvK2hLb0lkU2xtUDkzVEVLSENoV3pMcXF1S1Zp?= =?utf-8?B?V2RQS0RaRkZmenltbENvWlBHS2FXR1diZkozVmFLR0R1ay92ZmxCa1YvUWhK?= =?utf-8?B?UXE2QXIzQ0t5d2src25QWGlzRFdhNmlSL01XQ09HWjM5cmdBVE5XUnozQm5o?= =?utf-8?B?RlVSbTVkb0tKL09xdFFYM3IvNS92SDVYZnZwMjk2QlJnbVkvUVQvc1E5c0t1?= =?utf-8?B?UkJJS2VSdFRCTU1qWUhyakdXckN5U1pKdjFyQ2pMOUIyWE15eE5kTUZMRExO?= =?utf-8?B?VWlVMU1CVGJhSEdYamNaa2s2UVJqNXB1YUxROS9jWEtZZjVCR2pIbUJweUVu?= =?utf-8?B?UEpjRW9wQjI3c25PVHN0cEJSd3k0NStIL3FXc0ZBNXNzNlpYUjhpTlp2UXFJ?= =?utf-8?Q?e1x2sQQiCmY4t?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR00MB0427A1F889A546B2B8D33125F56A9MW2PR00MB0427namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR00MB0427.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7024f96f-fa9f-4e7b-1b8a-08d8e98e4e32 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 21:47:47.8070 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DhgfQgromop+RXVe9sqYZqDsMKZhzDsz8qHF0gnZP/Gcpo35a5GAzvViWa4JoA8iDwqnWR+V0ovAn8qb01Xyqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0314 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-oauth-jwsreq-30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 21:47:56 -0000 --_000_MW2PR00MB0427A1F889A546B2B8D33125F56A9MW2PR00MB0427namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIGNyZWF0ZWQgdGhlIHB1bGwgcmVxdWVzdCBodHRwczovL2JpdGJ1Y2tldC5vcmcvTmF0 L29hdXRoLWp3c3JlcS9wdWxsLXJlcXVlc3RzLzE0LyBhcHBseWluZyB0aGUgcHJvcG9zZWQgY2hh bmdlcyBiZWxvdyB0byB0aGUgZHJhZnQuICBVbmxlc3Mgc3VnZ2VzdGlvbnMgZm9yIGNoYW5nZXMg YXJlIHJlY2VpdmVkLCB3ZeKAmWxsIG1lcmdlIHRoaXMgYW5kIHB1Ymxpc2ggLTMxIHRvIGFkZHJl c3MgV2F0c29u4oCZcyBjb21tZW50cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTWlrZSBKb25lcw0KU2Vu dDogRnJpZGF5LCBGZWJydWFyeSAyNiwgMjAyMSAxMjo1NSBQTQ0KVG86ICdXYXRzb24gTGFkZCcg PHdhdHNvbmJsYWRkQGdtYWlsLmNvbT47IE5hdCBTYWtpbXVyYSA8bmF0QG5hdC5jb25zdWx0aW5n PjsgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPg0KQ2M6IHNlY2RpciA8c2VjZGlyQGlldGYu b3JnPjsgSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+OyBsYXN0LWNhbGxAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFNlY2Rp ciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMwDQoNCg0KVGhh bmtzIGFnYWluIGZvciB5b3VyIHJldmlldywgV2F0c29uLiAgTXkgcmVwbGllcyB0byB5b3VyIGNv bW1lbnRzIGJlbG93IGFyZSBwcmVmaXhlZCBieSAiTWlrZT4iLg0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IFdhdHNvbiBMYWRkIDx3YXRzb25ibGFkZEBnbWFpbC5jb208 bWFpbHRvOndhdHNvbmJsYWRkQGdtYWlsLmNvbT4+DQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAx NSwgMjAyMCA5OjAxIFBNDQpUbzogTmF0IFNha2ltdXJhIDxuYXRAbmF0LmNvbnN1bHRpbmc8bWFp bHRvOm5hdEBuYXQuY29uc3VsdGluZz4+DQpDYzogc2VjZGlyIDxzZWNkaXJAaWV0Zi5vcmc8bWFp bHRvOnNlY2RpckBpZXRmLm9yZz4+OyBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZzxtYWls dG86b2F1dGhAaWV0Zi5vcmc+PjsgbGFzdC1jYWxsQGlldGYub3JnPG1haWx0bzpsYXN0LWNhbGxA aWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtb2F1dGgtandzcmVxLmFsbEBpZXRmLm9yZz4NClN1YmplY3Q6IFtFWFRFUk5BTF0g UmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMw DQoNCg0KDQpPbiBTYXQsIE9jdCAzMSwgMjAyMCBhdCA2OjEzIEFNIE5hdCBTYWtpbXVyYSA8bmF0 QG5hdC5jb25zdWx0aW5nPG1haWx0bzpuYXRAbmF0LmNvbnN1bHRpbmc+PiB3cm90ZToNCg0KPg0K DQo+IEhpIFdhdHNvbiwNCg0KPg0KDQo+IFRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZSByZXZpZXcu IEkgdGhvdWdodCBJIGhhdmUgc2VudCBteSByZXNwb25zZQ0KDQo+IGVhcmxpZXIsIHdoaWNoIEkg YWN0dWFsbHkgZGlkIG5vdC4gSXQgd2FzIHNpdHRpbmcgaW4gbXkgZHJhZnQgYm94LiBJDQoNCj4g YXBvbG9naXplIGZvciBpdC4NCg0KDQoNCk15IGFwb2xvZ2llcyBmb3IgbWlzc2luZyBpdCBpbiBt eSBpbmJveCBmb3IgYSBudW1iZXIgb2YgbW9udGhzLg0KDQo+DQoNCj4gTXkgcmVzcG9uc2VzIGlu bGluZToNCg0KPg0KDQo+IE9uIFNhdCwgU2VwIDI2LCAyMDIwIGF0IDk6NDYgQU0gV2F0c29uIExh ZGQgdmlhIERhdGF0cmFja2VyDQoNCj4gPG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlA aWV0Zi5vcmc+PiB3cm90ZToNCg0KPiA+DQoNCj4gPiBSZXZpZXdlcjogV2F0c29uIExhZGQNCg0K PiA+IFJldmlldyByZXN1bHQ6IFNlcmlvdXMgSXNzdWVzDQoNCj4gPg0KDQo+ID4gSSBnZW5lcmF0 ZWQgdGhpcyByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eQ0K DQo+ID4gZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nDQoNCj4gPiBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50 cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50DQoNCj4gPiBvZiBpbXByb3Zpbmcgc2VjdXJp dHkgcmVxdWlyZW1lbnRzIGFuZCBjb25zaWRlcmF0aW9ucyBpbiBJRVRGDQoNCj4gPiBkcmFmdHMu ICBDb21tZW50cyBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkgYmUgaW5jbHVkZWQgaW4g QUQNCg0KPiA+IHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCj4gPg0KDQo+ID4gVHdvIG1pbm9yIGlzc3Vl czogT24gcGFnZSA0LCAiVGhpcyBvZmZlcnMgYW4gYWRkaXRpb25hbCBkZWdyZWUgb2YNCg0KPiA+ IHByaXZhY3kgcHJvdGVjdGlvbi4iIHNob3VsZCBiZSByZXdvcmRlZC4gSSBkb24ndCB0aGluayBp dCBtYWtlcw0KDQo+ID4gc2Vuc2UgaW4gY29udGV4dCwgd2hlcmUgYXV0aGVudGljaXR5IHdhcyBk aXNjdXNzZWQuDQoNCj4NCg0KPg0KDQo+IEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGVkaXQsIGV4cGxh bmF0aW9uIGFib3V0IHR3byBkaXN0aW5jdCBwcml2YWN5DQoNCj4gYmVuZWZpdHMgd2FzIGNvbGxh dGVkIGluIG9uZSBzZW50ZW5jZSBhbmQgaGFzIGJlY29tZSB2ZXJ5IGRpZmZpY3VsdCB0bw0KDQo+ IHBhcnNlLg0KDQo+DQoNCj4gV2hhdCBpdCBpcyB0cnlpbmcgdG8gZXhwcmVzcyBhcyBwcml2YWN5 IGJlbmVmaXRzIGFyZSB0aGUgZm9sbG93aW5nLg0KDQo+DQoNCj4gMSkgVGhlIGF1dGhvcml6YXRp b24gcmVxdWVzdCBjb250ZW50IGlzIHNlbnQgdG8gdGhlIEFTIGluIHRoZQ0KDQo+IGJhY2tjaGFu bmVsIHNvIGl0IHdpbGwgbm90IGJlIGV4cG9zZWQgdGhyb3VnaCB0aGUgYnJvd3NlciB0byB0aGUg ZXllcw0KDQo+IG9mIGFuIGFjdGl2ZSBvciBwYXNzaXZlIG91dHNpZGVyIG9ic2VydmluZyB3aGF0 IGlzIGdvaW5nIG9uIGluIHRoZQ0KDQo+IGJyb3dzZXIuICBJbiB0aGUgUkZDNjc0OSBmcmFtZXdv cmsgY2FzZSwgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdA0KDQo+IGdvZXMgdGhyb3VnaCB0aGUg YnJvd3NlciByZWRpcmVjdCBhbmQgaXQgY291bGQgbGVhayB0byB0aGUgYWR2ZXJzYXJ5DQoNCj4g dmlhIFdQQUQvUEFDIEF0dGFjaywgcmVmZXJyZXIsIGJyb3dzZXIgaGlzdG9yeSwgZXRjLiBBbHNv LCBpZiB0aGUNCg0KPiBicm93c2VyIHdhcyBpbmZlY3RlZCBieSBhbiBhZHZlcnNhcnkgY29udHJv bGxlZCBtYWx3YXJlLCB0aGUgY29udGVudA0KDQo+IGNhbiBiZSBzbmlmZmVkIGJ5IHRoZSBhZHZl cnNhcnkuIEluIHRoZSBjYXNlIG9mIEpBUiwgaXQgZG9lcyBub3QNCg0KPiBoYXBwZW4uIFRoaXMg aXMgb25lIHByaXZhY3kgYmVuZWZpdCBpdCBpcyB0cnlpbmcgdG8gZXhwbGFpbi4NCg0KPg0KDQo+ IDIpIFRoZSBsb2NhdGlvbiB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgaXMgZ2V0dGlu ZyBwdXNoZWQgdG8NCg0KPiBkb2VzIG5vdCBoYXZlIHRvIGJlIHRoZSBBUy4gQSB0cnVzdGVkIHRo aXJkIHBhcnR5IHRoYXQgZXhhbWluZXMgdGhlDQoNCj4gY29udGVudCBmb3IgdGhlIGNvbmZvcm1h bmNlIHRvIHRoZSBjb2xsZWN0aW9uIG1pbmltaXphdGlvbiBwcmluY2lwbGUNCg0KPiBtYXkgYWN0 IGFzIHRoZSBwYXJ0eSB0aGF0IGFjY2VwdHMgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhbmQg aXNzdWVzDQoNCj4gdGhlIHJlcXVlc3RfdXJpLiBBUyBjYW4gdGhlbiBqdXN0IGV2YWx1YXRlIHRo ZSBkb21haW4gcGFydCBvZg0KDQo+IHJlcXVlc3RfdXJpIHRvIGV2YWx1YXRlIHRoYXQgdGhlIGF1 dGhvcml6YXRpb24gcmVxdWVzdCBpcyBjb25mb3JtYW50DQoNCj4gdG8gdGhpcyBwcmluY2lwbGUu IFRoaXMgaXMgYW5vdGhlciBwcml2YWN5IGJlbmVmaXQgZnJvbSB0aGUgcG9pbnQgb2YNCg0KPiB2 aWV3IG9mIHRoZSBpbmRpdmlkdWFsIHVzZXIuDQoNCg0KDQpJJ20gZmluZSB3aXRoIGFueSBmaXgg dG8gdGhlIHNlbnRlbmNlIHRoYXQgbWFrZXMgc2Vuc2UuIERvbid0IHRoaW5rIHdlIG5lZWQgdG8g aW5zZXJ0IHRoZSBhYm92ZSBidXQgSSB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZSB0aGUgZXhwbGFuYXRp b24uDQoNCg0KDQpNaWtlPiBHaXZlbiB0aGF0IGl0cyBtZWFuaW5nIGlzIGZhaXJseSBpbnNjcnV0 YWJsZSwgYW5kIHRoYXQgdGhlIHR3byBiZW5lZml0cyBkZXNjcmliZWQgYnkgTmF0IGFib3ZlIGFy ZSBwYXJ0aWFsbHkgcmVsYXRlZCB0byBwYXJhZ3JhcGhzIG90aGVyIHRoYW4gdGhlIG9uZSB3aXRo IHRoZSBwcml2YWN5IHN0YXRlbWVudCwgSSBwcm9wb3NlIHRoYXQgd2Ugc2ltcGx5IGRlbGV0ZSB0 aGUgc2VudGVuY2UgIlRoaXMgb2ZmZXJzIGFuIGFkZGl0aW9uYWwgZGVncmVlIG9mIHByaXZhY3kg cHJvdGVjdGlvbi4iIGZyb20gdGhpcyBwYXJhZ3JhcGguDQoNCg0KDQo+ID4gSXQgdG9vayBtZSBh IHdoaWxlIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUgYnkgcmVmZXJlbmNlIG1ldGhvZCBpczoNCg0K PiA+IG1heWJlIHRoZSBpbnRybyBzaG91bGQgc2F5IHZpYSBVUkwgaW5zdGVhZCBvZiBieSByZWZl cmVuY2UuDQoNCj4NCg0KPg0KDQo+IHJlcXVlc3RfdXJpIGNhbiBiZSBVUkwgb3IgYSBoYW5kbGUg c3VjaCBhcyBVUk4uIFRoYXQgaXMgd2h5IHRoZSAiYnkNCg0KPiByZWZlcmVuY2UiIHdvcmQgaXMg YmVpbmcgdXNlZCwgcGVyIHRoZSBzdWdnZXN0aW9uIG9mIHRoZSBXRy4NCg0KDQoNCkknbSBmaW5l IHdpdGggdGhhdCwganVzdCBub3RpbmcgbXkgY29uZnVzaW9uLg0KDQoNCg0KTWlrZT4gVW5kZXJz dG9vZC4gIEkgbG9va2VkIGF0IHdheXMgdG8gcG9zc2libHkgbW92ZSB0aGUgImJ5IHJlZmVyZW5j ZSIgdGV4dCB0aGF0IGZvbGxvd3MgaW4gYSBmZXcgcGFyYWdyYXBocyBlYXJsaWVyIHRvIHBvc3Np Ymx5IG1ha2UgdGhpcyBjbGVhcmVyLCBidXQgaXQgd291bGQgbWVzcyB1cCB0aGUgbG9naWNhbCBm bG93IG9mIHRoZSBJbnRyb2R1Y3Rpb24uICBVbmxlc3MgeW91IGhhdmUgYSBiZXR0ZXIgc3VnZ2Vz dGlvbiwgSSBwcm9wb3NlIHRoYXQgd2UgbGVhdmUgdGhpcyBhcy1pcy4NCg0KDQoNCj4gPiBBbmQg bm93IGZvciB0aGUgdGhvcm55IGlzc3VlcyB3aXRoIHRoaXMgZHJhZnQuIFNpZ25hdHVyZXMgYW5k DQoNCj4gPiBlbmNyeXB0aW9uIGFyZSBkaWZmZXJlbnQuIEFuZCBlbmNyeXB0aW5nIGEgc2lnbmVk IGJsb2IgZG9lc24ndCBtZWFuIHRoZSBzaWduZXIgZW5jcnlwdGVkIGl0Lg0KDQo+ID4gVGhlbiB0 aGVyZSBhcmUgYSBwbGV0aG9yYSBvZiBtZXRob2RzIHNwZWNpZmllZCBpbiB0aGUgZHJhZnQgIHRv DQoNCj4gPiBhdXRoZW50aWNhdGUgdGhlIGJsb2IsIHdoaWNoIHdpbGwgZ2l2ZSBkaWZmZXJlbnQg cmVzdWx0cyBpbg0KDQo+ID4gbWFsaWNpb3VzbHkgY29uc3RydWN0ZWQgZXhhbXBsZXMuIFRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KDQo+ID4gc2VjdGlvbiBzaG91bGQgZGlzY3VzcyB3aGF0 IHRoZSBlbmNyeXB0ZWQgdnMgc2lnbmVkIGNob2ljZXMgZ2l2ZSBpbg0KDQo+ID4gdGhlIHdheSBv ZiBzZWN1cml0eSwgYW5kIGl0IGRvZXNuJ3QuIFRoaXMgbWFrZXMgbWUgd29ycnkuDQoNCj4NCg0K PiBXZSBkb27igJl0IGV4cGVjdCB0aGUgZW5jcnlwdGlvbiB0byBlbnN1cmUgYXV0aGVudGljaXR5 LCB0aGF04oCZcyB3aGF0IHRoZQ0KDQo+IHNpZ25hdHVyZXMgYXJlIHVzZWQgZm9yLg0KDQoNCg0K VGhpcyBuZWVkcyB0byBiZSB2ZXJ5IGNsZWFybHkgc3BlbGxlZCBvdXQgaW4gdGhlIHRleHQuIExv dHMgb2YgcGVvcGxlIHdpbGwgbm90IHVuZGVyc3RhbmQgdGhpcy4gVGhlIHdvcmRpbmcgb2Ygc2Vj dGlvbiAxMC4yIGlzIGF0IGJlc3QgYW1iaXZhbGVudCwgd2l0aCBtdWx0aXBsZSBhbHRlcm5hdGl2 ZXMgcHJlc2VudGVkIGFzIGFjY2VwdGFibGUuDQoNCg0KDQpNaWtlPiBBZnRlciB0aGUgc2VudGVu Y2UgYXQgMTAuMiAoYikgYWJvdXQgc3ltbWV0cmljIGVuY3J5cHRpb24sIEkgcHJvcG9zZSB0aGF0 IHdlIGFkZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHRvIGVtcGhhc2l6ZSB0aGUgcG9pbnQgeW91 J3JlIHJhaXNpbmc6ICAiTm90ZSBob3dldmVyLCB0aGF0IGlmIHB1YmxpYyBrZXkgZW5jcnlwdGlv biBpcyB1c2VkLCBubyBzb3VyY2UgYXV0aGVudGljYXRpb24gaXMgZW5hYmxlZCBieSB0aGUgZW5j cnlwdGlvbiwgYXMgYW55IHBhcnR5IGNhbiBlbmNyeXB0IGNvbnRlbnQgdG8gdGhlIHB1YmxpYyBr ZXkuIg0KDQoNCg0KPGNob3A+DQoNCj4NCg0KPiBJIGRpZG4ndCBxdWl0ZSBnZXQgd2hhdCBpcyBt ZWFudCBieSAicGxldGhvcmEgb2YgbWV0aG9kcyBzcGVjaWZpZWQgaW4NCg0KPiB0aGUgZHJhZnQg dG8gYXV0aGVudGljYXRlIHRoZSBibG9iIC4uLiAiDQoNCj4gVGhlcmUgaXMgYSBiaXQgb2YgdGV4 dCBhYm91dCBhdXRoZW50aWNhdGluZyB0aGUgc291cmNlICg9Y2xpZW50KSBidXQNCg0KPiBub3Qg bXVjaCBvbiB0aGUgYmxvYiBpdHNlbGYuDQoNCj4gVGhlIGRpc2N1c3Npb24gYXJvdW5kIHRoZSBz aWduYXR1cmUgYW5kL29yIGVuY3J5cHRpb24gaXMgY292ZXJlZCBpbg0KDQo+IFJGQzc1MTkgKEpX VCksIHRoZSBmb3JtYXQgdGhhdCB0aGUgcmVxdWVzdCBvYmplY3QgYXNzdW1lcy4NCg0KPiBUaGlz IGlzIHJlcXVpcmVkIHJlYWRpbmcgd2hlbiBpbXBsZW1lbnRpbmcgdGhpcyBzcGVjLCBzbyBXRyB0 aG91Z2h0IGl0DQoNCj4gaXMgbm90IHdvcnRoIHJlcGVhdGluZyBoZXJlLg0KDQo+IEF0dGFja3Mg ZXRjLiBvbiB0aGUgc2lnbmF0dXJlIGFuZCBlbmNyeXB0aW9uIGFyZSBjb3ZlcmVkIGluIFJGQzc1 MTUNCg0KPiBhbmQgUkZDNzUxNiByZXNwZWN0aXZlbHkuDQoNCg0KDQpXZWxsLCB0aGUgZHJhZnQg aGFwcGVucyB0byBpbmNsdWRlIHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KICAgIlRoZSBBdXRob3Jp emF0aW9uIFNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBzaWduYXR1cmUgb2YgdGhlIEpTT04gV2Vi DQoNCiAgIFNpZ25hdHVyZSBbUkZDNzUxNV0gc2lnbmVkIFJlcXVlc3QgT2JqZWN0LiAgVGhlIHNp Z25hdHVyZSBNVVNUIGJlDQoNCiAgIHZhbGlkYXRlZCB1c2luZyB0aGUga2V5IGZvciB0aGF0ICJj bGllbnRfaWQiIGFuZCB0aGUgYWxnb3JpdGhtDQoNCiAgIHNwZWNpZmllZCBpbiB0aGUgImFsZyIg SGVhZGVyIFBhcmFtZXRlci4iDQoNCg0KDQpTaG91bGRuJ3QgdGhlIGtleSBiZSBhc3NvY2lhdGVk IHdpdGggYSBzaW5nbGUgYWxnb3JpdGhtPyBIb3cgZG8gd2UgZW5zdXJlIHRoYXQgdGhlIGNvbW1v biBhdHRhY2sgb2YgdGVsbGluZyB0aGUgc2VydmVyIHRvIHVzZSBobWFjIHRvIHZlcmlmeSB0aGUg c2lnbmF0dXJlIGRvZXNuJ3Qgd29yayBoZXJlPw0KDQoNCg0KTWlrZT4gR29vZCBwb2ludC4gIFRo aXMgYXR0YWNrIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMSBvZiBSRkMgODcyNSBhbmQgbWl0 aWdhdGVkIGJ5IHRoZSBwcmFjdGljZXMgaW4gU2VjdGlvbnMgMy4xIGFuZCAzLjIgb2YgdGhlIHNh bWUuICBJIHByb3Bvc2UgdGhhdCB3ZSByZXBsYWNlIHRoZSBzZW50ZW5jZToNCg0KICAgICJUaGUg c2lnbmF0dXJlIE1VU1QgYmUgdmFsaWRhdGVkIHVzaW5nIHRoZSBrZXkgZm9yIHRoYXQgImNsaWVu dF9pZCIgYW5kIHRoZSBhbGdvcml0aG0gc3BlY2lmaWVkIGluIHRoZSAiYWxnIiBIZWFkZXIgUGFy YW1ldGVyLiINCg0Kd2l0aDoNCg0KICAgICJUaGUgc2lnbmF0dXJlIE1VU1QgYmUgdmFsaWRhdGVk IHVzaW5nIGEga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50IGFuZCB0aGUgYWxnb3JpdGht IHNwZWNpZmllZCBpbiB0aGUgImFsZyIgSGVhZGVyIFBhcmFtZXRlci4gIElmIGEgImtpZCIgSGVh ZGVyIFBhcmFtZXRlciBpcyBwcmVzZW50LCB0aGUga2V5IGlkZW50aWZpZWQgTVVTVCBiZSB0aGUg a2V5IHVzZWQsIGFuZCBNVVNUIGJlIGEga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50LiAg QWxnb3JpdGhtIHZlcmlmaWNhdGlvbiBNVVNUIGJlIHBlcmZvcm1lZCwgYXMgc3BlY2lmaWVkIGlu IFNlY3Rpb25zIDMuMSBhbmQgMy4yIG9mIFJGQyA4NzI1LiINCg0KDQoNCj4gPiBMb29raW5nIGF0 IHRoZSBjaXRlZCByZWZlcmVuY2UgZm9yIGF0dGFja3MsIEkgc2VlIHRoZSBmaXggaXMgdG8NCg0K PiA+IGluY2x1ZGUgaW5mb3JtYXRpb24gYWJvdXQgd2hpY2ggSVBEIHdhcyB1c2VkIGJ5IHRoZSBS UC4gQnV0IHRoZQ0KDQo+ID4gZHJhZnQgYmVmb3JlIHVzIGRvZXNuJ3QgbWFuZGF0ZSB0aGF0LiBJ dCdzIG5vdCBjbGVhciB0aGFuIGhvdyB0aGUNCg0KPiA+IGNpdGVkIGF0dGFjayBpcyBwcmV2ZW50 ZWQgYnkgdGhlIGRyYWZ0LiBTYXlpbmcgdGhhdCB0aGUNCg0KPiA+IGNvbW11bmljYXRpb24gdGhy b3VnaCB0aGUgdXNlci1hZ2VudCBpcyBzdWJqZWN0IHRvDQoNCj4NCg0KPiBUaGUgbWVudGlvbiBv ZiBtaXgtdXAgYXR0YWNrIHdhcyBpbnRyb2R1Y2VkIGFmdGVyIHRoZSBMYXN0IGNhbGwgYnkgb25l DQoNCj4gb2YgdGhlIGNvbW1lbnQuIEl0IGp1c3QgYWRkZWQgaXQgaW4gdGhlIHNlbnRlbmNlIHdp dGggYSByZWZlcmVuY2UuIEkNCg0KPiBhbSBvayB0byByZW1vdmUgaXQuDQoNCg0KDQpUaGF0IHdv cmtzIGZvciBtZS4NCg0KDQoNCk1pa2U+IEkgd2lsbCByZW1vdmUgdGhlIG1peC11cCBhdHRhY2sg cmVmZXJlbmNlIGluIHRoZSBuZXh0IGRyYWZ0Lg0KDQoNCg0KPiBIYXZpbmcgc2FpZCB0aGF0LCB0 aGUgaGVhcnQgb2YgbWl4LXVwIGF0dGFjayBpcyB0aGF0IHRoZSBjb21iaW5hdGlvbg0KDQo+IG9m IHRoZSBjbGllbnQgYmVsaWV2ZXMgdGhhdCBpdCBpcyBjb21tdW5pY2F0aW5nIHdpdGggdGhlDQoN Cj4gYXR0YWNrZXItY29udHJvbGxlZCBBUyAoQUFTKSB3aGlsZSBpdCBpbi1mYWN0IGlzIHRhbGtp bmcgdG8gSG9uZXN0IEFTDQoNCj4gKEhBUyksIEFORCBIQVMgdW5hYmxlIHRvIGZpbmQgb3V0IHRo YXQgdGhlIGNsaWVudCBpcyB0aGlua2luZyB0aGF0IGl0DQoNCj4gaXMgdGFsa2luZyB0byBBQVMg bm90IGhpbS4NCg0KPg0KDQo+IE9BdXRoIEpBUiBzZWVtcyB0byBtaXRpZ2F0ZSBpdCBpbiB0d28g d2F5czoNCg0KPg0KDQo+IGEpIFVzZSByZXF1ZXN0X3VyaSB3aGljaCBpcyBob3N0ZWQgYnkgdGhl IEFTLiBUaGVuLCBpZiB0aGUgY2xpZW50IGlzDQoNCj4gdGhpbmtpbmcgdGhhdCBpdCBpcyB0YWxr aW5nIHRvIHRoZSBBQVMsIHRoZW4gaXQgd2lsbCBwdXNoIGl0IHRvIEFBUw0KDQo+IGFuZCB3aGVu IHRoZSB1c2VyIGlzIHJlZGlyZWN0ZWQgdG8gSEFTLCBIQVMgd2lsbCBmaW5kIG91dCB0aGF0IHRo ZQ0KDQo+IHJlcXVlc3RfdXJpIGlzIG5vdCBjcmVhdGVkIGJ5IGhlcnNlbGYgYW5kIHJldHVybiBh biBlcnJvciwgbWFraW5nIHRoZQ0KDQo+IG1peC11cCBhdHRhY2sgZmFpbC4NCg0KPg0KDQo+IGIp IEluY2x1ZGUgYGF1ZGAgaW4gdGhlIHJlcXVlc3QuIFRoZW4sIHdoZW4gdGhlIEhBUyB3aWxsIGZp bmQgdGhhdCB0aGUNCg0KPiByZXF1ZXN0IHdhcyBtaW50ZWQgdG8gQUFTIGFuZCBub3QgaGVyLiBT bywgaXQgd2lsbCByZXN1bHQgaW4gYW4gZXJyb3IsDQoNCj4gbWFraW5nIHRoZSBtaXgtdXAgYXR0 YWNrIGZhaWwuDQoNCg0KDQpJZiB0aGUgZHJhZnQgbWFuZGF0ZXMgZG9pbmcgdGhpcyBpdCBhZGRy ZXNzZXMgdGhlIGF0dGFjayBhbmQgdGhlIHNlbnRlbmNlIGNhbiBzdGF5Lg0KDQoNCg0KTWlrZT4g VGhlIGRyYWZ0IG1hbmRhdGVzIHVzZSBvZiAiYXVkIiBidXQgaXQgZG9lcyBub3QgbWFuZGF0ZSB0 aGF0IHRoZSByZXF1ZXN0X3VyaSBiZSBob3N0ZWQgYnkgdGhlIEFTLiAgVGhlcmVmb3JlLCBJIHRo aW5rIHdlIHNob3VsZCByZW1vdmUgdGhlIG1peC11cCBhdHRhY2sgcmVmZXJlbmNlLg0KDQoNCg0K PiBTbywgSSBhZGRlZCBtaXgtdXAgYXR0YWNrIHRvIHRoZSBzZW50ZW5jZSB0aGlua2luZyB0aGUg Y29tbWVudGVyJ3MNCg0KPiByZXF1ZXN0IHRvIGFkZCBpdCBpcyBmaW5lLCBidXQgSSBhbSBmaW5l IHdpdGggcmVtb3ZpbmcgaXQuDQoNCj4NCg0KPiA+IG1hbmlwdWxhdGlvbiwgYW5kIHRoaXMgcHJl dmVudHMgaXQsIGlnbm9yZXMgdGhhdCB0aGUgYXR0YWNrZXIgaW4NCg0KPiA+IHRoYXQgcG9zaXRp b24gc2VlcyBhIGxvdCBtb3JlLiBUaGUgdXNlci1hZ2VudCBhcyByZXNvdXJjZSBvd25lcg0KDQo+ ID4gbW9kaWZ5aW5nIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2VzIGlzIGEgdmVyeSBmdW5ueSBzb3J0 IG9mIGF0dGFjazoNCg0KPiA+IGNhbid0IHRoZXkgZG8gd2hhdCB0aGV5IHdhbnQgd2l0aCB0aGUg cmVzb3VyY2VzIHNpbmNlIHRoZXkgY29udHJvbCB0aGUgYWNjZXNzPw0KDQo+DQoNCj4gSWYgdGhl IGNsaWVudCBpcyBpbiB0aGUgYnJvd3NlciwgeWVzLg0KDQo+IEJ1dCBpbiB0aGUgbWFpbnN0cmVh bSBjYXNlLCB0aGUgY2xpZW50IGlzIG5vdCBpbiB0aGUgYnJvd3NlciBidXQgdGhlDQoNCj4gd2Vi LXNlcnZlciB0aGF0IHRoZSBicm93c2VyIGlzIGNvbW11bmljYXRpbmcgd2l0aCBhbmQgdGhlIHJl c291cmNlDQoNCj4gYWNjZXNzIGhhcHBlbnMgd2l0aG91dCBiZWluZyBtZWRpYXRlZCBieSB0aGUg YnJvd3Nlci4NCg0KDQoNCk15IGNvbmNlcm4gb24gdGhpcyBwb2ludCBpcyByZXNvbHZlZC4NCg0K DQoNCk1pa2U+IFRoYW5rcw0KDQoNCg0KPiA+IEtleSBtYW5hZ2VtZW50IGlzIGlnbm9yZWQuIFRo aXMgaXMgYSB2ZXJ5IGltcG9ydGFudCBpc3N1ZSwNCg0KPiA+IGVzcGVjaWFsbHkNCg0KPg0KDQo+ IEEgbG90IG9mIGdyb3VuZCBpcyBjb3ZlcmVkIGJ5IFJGQyA3NTE1LCA3NTE2LCA3NTE3LCA3NTE4 LCA3NTE5LCA3NTkxLA0KDQo+IGFuZCA4NDE0IHNvIHRoaXMgZG9jdW1lbnQgaXMgbm90IHNwZWNp ZmljYWxseSByZXN0YXRpbmcgdGhlbS4NCg0KPg0KDQo+ID4NCg0KPiA+IGNvbnNpZGVyaW5nIHRo ZSBwb3RlbnRpYWwgcHJvYmxlbXMgd2l0aCB0aGUgcmV1c2Ugb2YgSldULiBJJ2QgbGlrZQ0KDQo+ ID4gdG8gc2VlIGENCg0KPg0KDQo+IEFyZSB5b3UgdGFsa2luZyBhYm91dCB0aGUgcmV1c2Ugb2Yg dGhlIHJlcXVlc3Qgb2JqZWN0IGJ5IGFuIGFkdmVyc2FyeQ0KDQo+IHRyeWluZyB0byBhY3QgYXMg YW4gaG9uZXN0IGNsaWVudD8NCg0KPiBFdmVuIGlmIGl0IGhhcHBlbnMsIHRoZSBtYWxpY2lvdXMg Y2xpZW50IGRvZXMgbm90IGhhdmUgdGhlIHByb3Blcg0KDQo+IGNsaWVudCBjcmVkZW50aWFsIHNv IGl0IGNhbm5vdCByZWRlZW0gdGhlIGNvZGUgaXQgb2J0YWluZWQgd2l0aCB0aGUNCg0KPiB0b2tl bi4gSXQgaXMgbm8gZGlmZmVyZW50IHRoYW4gUkZDNjc0OSBjb2RlIGdyYW50LiBQcm90b2NvbHMg dGhhdA0KDQo+IGV4dGVuZCBpdCwgc3VjaCBhcyBPcGVuSUQgQ29ubmVjdCwgaGF2ZSBpbnRyb2R1 Y2VkIG5vbmNlIHRvIHByZXZlbnQNCg0KPiB0aGUgcmV1c2UgYW5kIHVzZWQgSkFSIChpdCBpcyBj YWxsZWQgcmVxdWVzdCBvYmplY3QgdGhlcmUpIHRvIGZ1cnRoZXINCg0KPiBwcm90ZWN0IHRhbXBl cmluZyBhbmQgYWNoaWV2ZSBjbGllbnQgYXV0aGVudGljYXRpb24gZXZlbiBpbiB0aGUgZnJvbnQN Cg0KPiBjaGFubmVsLg0KDQo+DQoNCj4gPiByZWNvbW1lbmRhdGlvbiB0aGF0IGtleXMgYmUgc2Vw YXJhdGVkIGJ5IGludGVuZGVkIHVzZXMsIHJhdGhlciB0aGFuDQoNCj4gPiBsaW1pdGluZyBwYXJ0 aWN1bGFyIGZpZWxkcyBpbiBhbiBhZC1ob2MgbWFubmVyLg0KDQo+DQoNCj4gQ291bGQgeW91IGtp bmRseSBlbGFib3JhdGUgb24gdGhlICJhZC1ob2MgbWFubmVyIiBwYXJ0IHNvIHRoYXQgSSBjYW4N Cg0KPiB1bmRlcnN0YW5kIGl0IG1vcmUgZnVsbHk/DQoNCg0KDQoxMC44LCBDcm9zcy1KV1QgQ29u ZnVzaW9uIGRpc2N1c3NlcyBhdm9pZGluZyBzaWduaW5nIGNlcnRhaW4gZmllbGRzLCByYXRoZXIg dGhhbiBzdWdnZXN0aW5nIGdvb2Qga2V5IHVzYWdlIGFzIGEgc29sdXRpb24uDQoNCg0KDQpNaWtl PiBJIHByb3Bvc2UgdG8gYWRkIHRoaXMgbmV3IHBhcmFncmFwaCBhdCB0aGUgZW5kIG9mIFNlY3Rp b24gMTAuOCB0byBpbXBsZW1lbnQgeW91ciBzdWdnZXN0aW9uOg0KDQogICAgIkZpbmFsbHksIGFu b3RoZXIgd2F5IHRvIHByZXZlbnQgY3Jvc3MtSldUIGNvbmZ1c2lvbiBpcyB0byB1c2UgYSBrZXkg bWFuYWdlbWVudCByZWdpbWUgaW4gd2hpY2gga2V5cyB1c2VkIHRvIHNpZ24gUmVxdWVzdCBPYmpl Y3RzIGFyZSBpZGVudGlmaWFibHkgZGlzdGluY3QgZnJvbSB0aG9zZSB1c2VkIGZvciBvdGhlciBw dXJwb3Nlcy4gIFRoZW4sIGlmIGFuIGFkdmVyc2FyeSBhdHRlbXB0cyB0byByZXB1cnBvc2UgdGhl IFJlcXVlc3QgT2JqZWN0IGluIGFub3RoZXIgY29udGV4dCwgYSBrZXkgbWlzbWF0Y2ggd2lsbCBv Y2N1ciwgdGh3YXJ0aW5nIHRoZSBhdHRhY2suIg0KDQoNCg0KPiA+IFRoZW4gd2UgaGF2ZSBzZWN0 aW9uIDExLiBXaGF0IHNlY3Rpb24gMTEgaW50cm9kdWNlcyBpcyBhbiBlbnRpcmUgbmV3DQoNCj4g PiBkcmFtYXRpcyBwZXJzb25hZSwgdGhlIFRydXN0IEZyYW1ld29yayBQcm92aWRlciwgd2l0aCBu byBwcmlvcg0KDQo+ID4gZGlzY3Vzc2lvbiBvZiB3aGF0IGl0IGlzIG9yIGEgcmVmZXJlbmNlIHRv IHdoZXJlIGl0IGlzIGRlZmluZWQgYW5kIGENCg0KPiA+IGdvb2QgbnVtYmVyIG9mIHN0YXRlbWVu dHMgYWJvdXQgaG93IGl0IHdvcmtzIHRoYXQgYXJlbid0IHJlYWxseSAgY2xlYXIgd2hhdCB0aGV5 IG1lYW4gZnJvbSB0aGUgZG9jdW1lbnQgdG8gbWUuDQoNCj4NCg0KPiBUcnVzdCBGcmFtZXdvcmsg UHJvdmlkZXIgZmlyc3QgYXBwZWFycyBpbiA1LjIuMS4NCg0KPiBBdCB0aGUgdGltZSBvZiB3cml0 aW5nIHRoZSByZWxhdGVkIHRleHQsIGl0IHdhcyBhIHByZXR0eSB3ZWxsLWtub3duDQoNCj4gY29u Y2VwdC4gSW4gdGhlIFVuaXRlZCBTdGF0ZSwgaXQgd2FzIHBhcnQgb2YgaXRzIE5hdGlvbmFsIFN0 cmF0ZWd5DQoNCj4gKE5TVElDKSBhbmQgaW50ZXJuYXRpb25hbGx5LCBpdCB3YXMgZXZlbiB0YWtl biB1cCBhdCBXRUYgRGF2b3MNCg0KPiBtZWV0aW5nLiBJdCBpcyBxdWl0ZSBzdXJwcmlzaW5nIHRo YXQgc3VjaCBhIG1haW5zdHJlYW0gY29uY2VwdCBmYWRlZA0KDQo+IGludG8gb2JzY3VyaXR5IHNv IHF1aWNrbHkuIFRoZSByZWFzb24gZm9yIGludHJvZHVjaW5nIGl0IHdhcyB0byBhKQ0KDQo+IGp1 c3RpZnkgcmVxdWVzdF91cmkgYXMgc29tZSBXRyBtZW1iZXJzIHdhbnRlZCBpdCB0byBiZSByZW1v dmVkLCBiKQ0KDQo+IGp1c3RpZnkgdGhhdCByZXF1c3RfdXJpIHRvIGJlIHNlcnZlZCBmcm9tIGEg ZGlmZmVyZW50IGRvbWFpbi4gTm93IHRoYXQNCg0KPiBwZW9wbGUgYXBwcmVjaWF0ZSBpdCwgZS5n LiwgaXQgY2FuIGJlIHNlZW4gZnJvbSBQQVIsIHRoZSBqdXN0aWZpY2F0aW9uDQoNCj4gZm9yIGEp IHByb2JhYmx5IGlzIG5vIGxvbmdlciByZXF1aXJlZC4gQSBmdWxsIGV4cGxhbmF0aW9uIGZvciBi KSB3b3VsZA0KDQo+IHByb2JhYmx5IGJlIGEgbXVjaCBsb25nZXIgdGV4dCBidXQgSSBkb3VidCBp ZiBpdCBiZWxvbmdzIHRvIHRoaXMNCg0KPiBkb2N1bWVudC4gSSBhbSBmaW5lIHdpdGggcmVtb3Zp bmcgdGhlIHJlZmVyZW5jZSB0byBUcnVzdCBmcmFtZXdvcmsNCg0KPiBldGMuIGFzIGxvbmcgYXMg dGhlIGNhcGFiaWxpdHkgdG8gcHVzaCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvIGENCg0K PiBwbGFjZSBvdGhlciB0aGFuIHRoZSBjbGllbnQgb3IgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGlzIG5vdA0KDQo+IHJlbW92ZWQuDQoNCg0KDQpMZXQncyByZW1vdmUgdGhlIHRleHQgdGhlbiwg YnV0IGtlZXAgdGhlIGNhcGFiaWxpdHkuDQoNCg0KDQpNaWtlPiBJIHByb3Bvc2UgdG8gcmVtb3Zl IHVzZXMgb2YgdGhlIHRlcm0gIlRydXN0IEZyYW1ld29yayBQcm92aWRlciIgYW5kIGluc3RlYWQg cmVwbGFjZSB0aGVtIGJ5IHRoZSBtb3JlIGdlbmVyaWMgdGVybSAidHJ1c3RlZCB0aGlyZC1wYXJ0 eSBzZXJ2aWNlIi4NCg0KDQoNCj4gPiBNeSBiaWdnZXN0IGNvbmNlcm4gaXMgdGhhdCB0aGVzZSBp c3N1ZXMgYXJlIHNpZ25zIHRoYXQgdGhlIHByb2JsZW0NCg0KPiA+IHRoaXMgZHJhZnQgaXMgdHJ5 aW5nIHRvIHNvbHZlIGFuZCB0aGUgbWVjaGFuaXNtcyB0byBzb2x2ZSBpdCBoYXZlbid0DQoNCj4g PiBiZWVuIGFuYWx5emVkIGFzIHRob3JvdWdobHkgYXMgdGhleSBzaG91bGQgaGF2ZSBiZWVuLiBX aXRob3V0IHRoYXQNCg0KPiA+IHNvcnQgb2YgdGhvcm91Z2ggYW5hbHlzaXMgaXQncyBub3QgY2Vy dGFpbiB0aGF0IHRoZSBtZWNoYW5pc21zDQoNCj4gPiBhY3R1YWxseSBzb2x2ZSB0aGUgcHJvYmxl bSBhbmQgaXQncyBub3QgY2xlYXIgd2hhdCB0aGUNCg0KPiA+IHJlY29tbWVuZGF0aW9ucyB0byBp bXBsZW1lbnRlcnMgaGF2ZSB0byBiZSB0byBwcmVzZXJ2ZSB0aG9zZSBwcm9wZXJ0aWVzLg0KDQo+ DQoNCj4gT0F1dGggSkFSLCBhcyB0aGUgbmFtZSAiVGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9u IEZyYW1ld29yazogSldUDQoNCj4gU2VjdXJlZCBBdXRob3JpemF0aW9uIFJlcXVlc3QgKEpBUiki IHN1Z2dlc3RzLCBpcyBhIGZyYW1ld29yayBhbmQgbm90DQoNCj4gYSBob3VzZSBpdHNlbGYuIE9u ZSBzdWNoIGV4YW1wbGUgaXMgRkFQSSBbMV0gd2hpY2ggd2FzIGZvcm1hbGx5DQoNCj4gdmVyaWZp ZWQgWzJdLg0KDQoNCg0KIkl0J3MgcG9zc2libGUgdG8gdXNlIHRoaXMgZHJhZnQgc2VjdXJpdHki IEkgZG9uJ3QgdGhpbmsgc2hvdWxkIGJlIGVub3VnaCBhbnltb3JlLiBSYXRoZXIgaXQgc2hvdWxk IGJlIGltcG9zc2libGUgdG8gdXNlIGluc2VjdXJlbHkuDQoNCg0KDQpNaWtlPiBUaGUgZHJhZnQg ZGVzY3JpYmVzIGhvdyB0byB1c2UgdGhlIG1lY2hhbmlzbSBzZWN1cmVseS4gIFllcywgaWYgcG9y dGlvbnMgb2YgdGhlIGRyYWZ0IChhbmQgdGhvc2UgaXQgZGVwZW5kcyB1cG9uKSBhcmUgbm90IGZv bGxvd2VkLCBpbnNlY3VyZSB1c2FnZSBjYW4gcmVzdWx0LiAgVGhhdCdzIHRydWUgb2YgYW55IHNl Y3VyaXR5IGRyYWZ0LiAgSWYgdGhlcmUgYXJlIGFkZGl0aW9uYWwgc3BlY2lmaWMgcmVxdWlyZW1l bnRzIGFuZC9vciByZWNvbW1lbmRhdGlvbnMgbmVlZGVkLCB3ZSdkIGJlIGdsYWQgdG8gYWRkIHRo ZW0uICBJZiBzbywgcGxlYXNlIGlkZW50aWZ5IHRoZW0uICAoSW5kZWVkLCB3ZSdyZSBhbHJlYWR5 IGRvaW5nIHNvIGluIHJlc3BvbnNlIHRvIHlvdXIgZXhpc3Rpbmcgc3BlY2lmaWMgZmVlZGJhY2su KQ0KDQoNCg0KTWlrZT4gQXMgZm9yIHBhc3QgSldUIHByb2JsZW1zLCB0aGUgSldUIEJDUCBbUkZD IDg3MjVdIHdhcyB3cml0dGVuIGF0IHRoZSByZXF1ZXN0IG9mIHRoZSBJRVNHIHRvIGlkZW50aWZ5 IGFuZCBtaXRpZ2F0ZSB0aGVtIC0gZXNwZWNpYWxseSBpbiBsaWdodCBvZiBKV1RzIGJlaW5nIHVz ZWQgZm9yIGFkZGl0aW9uYWwgdXNlIGNhc2VzLCBzdWNoIGFzIFNUSVIgc2VjdXJlZCB0ZWxlcGhv bnkgYW5kIHNlY3VyaW5nIGZpcnN0LXJlc3BvbmRlciBzZXJ2aWNlcy4gIElmIHlvdSBiZWxpZXZl IHRoYXQgYWRkaXRpb25hbCBnZW5lcmljIEpXVCBpc3N1ZXMgc2hvdWxkIGJlIGRpc2N1c3NlZCBh bmQgYWRkcmVzc2VkLCB3ZSBjb3VsZCBhbHdheXMgcmV2aXNlIHRoaXMgQkNQLiAgQnV0IGRvaW5n IHNvIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBSRkMuDQoNCg0KDQo+IFsxXQ0KDQo+IGh0 dHBzOi8vYml0YnVja2V0Lm9yZy9vcGVuaWQvZmFwaS9zcmMvbWFzdGVyL0ZpbmFuY2lhbF9BUElf V0RfMDAyLm1kDQoNCj4gWzJdIGh0dHBzOi8vYXJ4aXYub3JnL2Ficy8xOTAxLjExNTIwDQoNCj4N Cg0KPiA+DQoNCj4gPiBPYnZpb3VzbHkgdGhpcyBkcmFmdCBoYXMgaGFkIGEgbG9uZyBhbmQgdG9y dHVyZWQgaGlzdG9yeSB3aXRoDQoNCj4gPiBtdWx0aXBsZSByZXZpZXdzLCAgYW5kIHdoYXQgSSdt IHN1Z2dlc3RpbmcgbmVlZHMgdG8gaGFwcGVuIGlzIGEgbG90DQoNCj4gPiBvZiB3b3JrLiBCdXQg aXQncyBlc3NlbnRpYWwgaW4gYW55IHNlY3VyaXR5IHByb3RvY29sIHRvIGRvIHRoaXMNCg0KPiA+ IGFuYWx5c2lzIGFuZCBiZSBjbGVhciBhYm91dCB3aGF0IGlzLCBhbmQgd2hhdCBpcyBub3QsIHBy b3RlY3RlZCBieSB0aGUgcHJvdG9jb2wuDQoNCj4NCg0KPiBPQXV0aCBKQVIgaXMgbm90aGluZyBi dXQganVzdCBhbm90aGVyIGJpbmRpbmcgdG8gT0F1dGggMi4wLiBXaGVyZQ0KDQo+IFJGQzY3NDkg YmluZHMgaXQgdG8gZm9ybSBlbmNvZGluZywgaXQgcHJvdmlkZXMgdHdvIGFkZGl0aW9uYWwgYmlu ZGluZ3M6DQoNCj4gICAgIDEpIGJpbmRpbmcgdG8gSldULCBhbmQNCg0KPiAgICAgMikgYmluZGlu ZyB0byB0aGUgcHVzaGVkIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0aGF0IGlzIHJlZmVyZW5jZWQg YnkgYSBVUkkuDQoNCj4gSXQgaXMgdGhpcyBzaW1wbGUuIEFzIHN1Y2gsIGl0IHdvdWxkIGFsc28g aW5oZXJpdCBzb21lIG9mIHRoZQ0KDQo+IHNob3J0Y29taW5ncyBpbiBSRkM2NzQ5LiBIb3dldmVy LCBpdCBpcyBub3QgdGhpcyBkb2N1bWVudCB0byBhZGRyZXNzDQoNCj4gdGhlbS4gSXQgc2hvdWxk IGJlIGRvbmUgYnkgb3RoZXIgZG9jdW1lbnRzIHNvIHRoYXQgdGhlIHJlc3VsdCBjYW4gYmUNCg0K PiBlbmNvZGVkIHVzaW5nIHRoZSBtZWNoYW5pc21zIHByb3ZpZGVkIGluIHRoaXMgZG9jdW1lbnQu DQoNCg0KDQpUaGlzIGlzIG5vdCBhIHNpbXBsZSBtYXR0ZXIuIEpXVCBoYXMgYSBsb25nIGFuZCB0 d2lzdGVkIGhpc3Rvcnkgd2l0aCBzb21lIHBlcnZhc2l2ZSBlcnJvcnMgaW4gY29tbW9uIGxpYnJh cmllcywgYW5kIGlzIGEgZmFpcmx5IGxhcmdlIHN0YW5kYXJkLiBPQXV0aCAyLjAgaXMgYWxzbyBs YXJnZS4gRW5zdXJpbmcgdGhhdCB0aGUgbWFwcGluZyBoYXMgdGhlIHJpZ2h0IHByb3BlcnRpZXMg aXMgZ29pbmcgdG8gYmUgYSBtZXNzLiBJZiB0aGUgZW5jb2RpbmcgZG9lcyBub3QgcmVzcGVjdCB0 aGUgc2VtYW50aWNzIHdlIGhhdmUgYSBzZXJpb3VzIHNlY3VyaXR5IGlzc3VlLiBJZiBpbXBsZW1l bnRvcnMgYXNzdW1lIHRoZSBlbmNvZGluZyBwcm92aWRlcyBwcm9wZXJ0aWVzIGl0IGRvZXMgbm90 LCB3ZSBhZ2FpbiBoYXZlIGEgc2VjdXJpdHkgaXNzdWUuDQoNCg0KDQpNaWtlPiBTZWUgbXkgcHJl dmlvdXMgY29tbWVudHMgb24gcGFzdCBKV1QgaW1wbGVtZW50YXRpb24gZXJyb3JzIGFuZCB0aGUg d3JpdGluZyBvZiB0aGUgSldUIEJDUCBbUkZDIDg3MjVdIHRvIGFkZHJlc3MgdGhlc2UuDQoNCg0K DQo+IEl0IGlzIHF1aXRlIHN1cnByaXNpbmcgdGhhdCB0aGlzIGZhY3QgaXMgbm90IGdldHRpbmcg YXBwcmVjaWF0ZWQgYW5kDQoNCj4gaXMgdGFraW5nIHN1Y2ggYSBsb25nIHRpbWUgdG8gY29tcGxl dGUuDQoNCj4gTWF5YmUgSSBzaG91bGQgZGVsZXRlIGFsbCB0aGUgZXhwbGFuYXRpb24gdGV4dCBh bmQgbGVhdmUgaXQgd2l0aCBqdXN0DQoNCj4gdGhlIGNvcmUgdGV4dC4gRXhwbGFuYXRpb24gYW5k IGp1c3RpZmljYXRpb24gdGV4dCBmb3IgZGVmaW5pbmcNCg0KPiBhZGRpdGlvbmFsIGJpbmRpbmdz IHByb2JhYmx5IGFyZSBqdXN0IGRpc3RyYWN0aW9ucyBub3cgYXMgaXQgaXMgbm93DQoNCj4gYXBw cmVjaWF0ZWQgYW5kIHVzZWQgYWxsIG92ZXIgdGhlIHdvcmxkIHVubGlrZSB3aGVuIHRoZSBwcm9q ZWN0IHdhcw0KDQo+IHN0YXJ0ZWQuDQoNCg0KDQpNaWtlPiBJIHdvdWxkIHByb3Bvc2UgdGhhdCB3 ZSBtYWtlIG9ubHkgbmVjZXNzYXJ5IGNoYW5nZXMgdG8gdGhlIGRyYWZ0IGF0IHRoaXMgcG9pbnQu ICBMZXQncyBmaW5pc2ggdGhpcyBsb25nLW92ZXJkdWUgc3BlY2lmaWNhdGlvbiENCg0KDQoNCj4N Cg0KPiA+DQoNCj4gPiBTaW5jZXJlbHksDQoNCj4gPiBXYXRzb24gTGFkZA0KDQo+ID4NCg0KPg0K DQo+IFRoYW5rcyBhZ2FpbiBmb3IgeW91ciBkZXRhaWxlZCBjb21tZW50cy4NCg0KPg0KDQo+IEJl c3Qgd2lzaGVzLA0KDQo+DQoNCj4gLS0NCg0KPiBOYXQgU2FraW11cmENCg0KPiBOQVQuQ29uc3Vs dGluZyBMTEMNCg0KDQoNCk1pa2U+IEkgbm93IHBsYW4gdG8gY3JlYXRlIGVkaXRzIGluY29ycG9y YXRpbmcgdGhlIHByb3Bvc2VkIHJlc29sdXRpb25zIGFib3ZlIGZvciByZXZpZXcuDQoNCg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVz dCB3aXNoZXMsDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCg0KDQotLQ0KDQpBc3RyYSBtb3J0ZW1xdWUgcHJhZXN0YXJl IGdyYWRhdGltDQo= --_000_MW2PR00MB0427A1F889A546B2B8D33125F56A9MW2PR00MB0427namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPknigJl2ZSBjcmVhdGVkIHRoZSBwdWxsIHJlcXVlc3QgPGEgaHJlZj0i aHR0cHM6Ly9iaXRidWNrZXQub3JnL05hdC9vYXV0aC1qd3NyZXEvcHVsbC1yZXF1ZXN0cy8xNC8i Pg0KaHR0cHM6Ly9iaXRidWNrZXQub3JnL05hdC9vYXV0aC1qd3NyZXEvcHVsbC1yZXF1ZXN0cy8x NC88L2E+IGFwcGx5aW5nIHRoZSBwcm9wb3NlZCBjaGFuZ2VzIGJlbG93IHRvIHRoZSBkcmFmdC4m bmJzcDsgVW5sZXNzIHN1Z2dlc3Rpb25zIGZvciBjaGFuZ2VzIGFyZSByZWNlaXZlZCwgd2XigJls bCBtZXJnZSB0aGlzIGFuZCBwdWJsaXNoIC0zMSB0byBhZGRyZXNzIFdhdHNvbuKAmXMgY29tbWVu dHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1pa2UgSm9uZXMgPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgRmVicnVhcnkgMjYsIDIwMjEgMTI6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+ICdX YXRzb24gTGFkZCcgJmx0O3dhdHNvbmJsYWRkQGdtYWlsLmNvbSZndDs7IE5hdCBTYWtpbXVyYSAm bHQ7bmF0QG5hdC5jb25zdWx0aW5nJmd0OzsgUm9tYW4gRGFueWxpdyAmbHQ7cmRkQGNlcnQub3Jn Jmd0Ozxicj4NCjxiPkNjOjwvYj4gc2VjZGlyICZsdDtzZWNkaXJAaWV0Zi5vcmcmZ3Q7OyBJRVRG IG9hdXRoIFdHICZsdDtvYXV0aEBpZXRmLm9yZyZndDs7IGxhc3QtY2FsbEBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1vYXV0aC1qd3NyZXEuYWxsQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0zMDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzIGFnYWluIGZv ciB5b3VyIHJldmlldywgV2F0c29uLiZuYnNwOyBNeSByZXBsaWVzIHRvIHlvdXIgY29tbWVudHMg YmVsb3cgYXJlIHByZWZpeGVkIGJ5ICZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5N aWtlJmd0Ozwvc3Bhbj4mcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogV2F0c29uIExhZGQgJmx0OzxhIGhyZWY9 Im1haWx0bzp3YXRzb25ibGFkZEBnbWFpbC5jb20iPndhdHNvbmJsYWRkQGdtYWlsLmNvbTwvYT4m Z3Q7DQo8YnI+DQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNSwgMjAyMCA5OjAxIFBNPGJyPg0K VG86IE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hdEBuYXQuY29uc3VsdGluZyI+ bmF0QG5hdC5jb25zdWx0aW5nPC9hPiZndDs8YnI+DQpDYzogc2VjZGlyICZsdDs8YSBocmVmPSJt YWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+Jmd0OzsgSUVURiBvYXV0 aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwv YT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9yZyI+bGFzdC1jYWxsQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb2F1dGgtandzcmVxLmFsbEBp ZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS5hbGxAaWV0Zi5vcmc8L2E+PGJyPg0K U3ViamVjdDogW0VYVEVSTkFMXSBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1vYXV0aC1qd3NyZXEtMzA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T24gU2F0 LCBPY3QgMzEsIDIwMjAgYXQgNjoxMyBBTSBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0 bzpuYXRAbmF0LmNvbnN1bHRpbmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lIj5uYXRAbmF0LmNvbnN1bHRpbmc8L3NwYW4+PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEhpIFdhdHNvbiw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhhbmtzIHZlcnkgbXVjaCBmb3IgdGhl IHJldmlldy4gSSB0aG91Z2h0IEkgaGF2ZSBzZW50IG15IHJlc3BvbnNlDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZWFybGllciwgd2hpY2ggSSBhY3R1YWxs eSBkaWQgbm90LiBJdCB3YXMgc2l0dGluZyBpbiBteSBkcmFmdCBib3guIEkNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhcG9sb2dpemUgZm9yIGl0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NeSBhcG9sb2dpZXMgZm9yIG1pc3NpbmcgaXQgaW4g bXkgaW5ib3ggZm9yIGEgbnVtYmVyIG9mIG1vbnRocy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgTXkgcmVzcG9uc2VzIGlubGluZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgT24gU2F0LCBTZXAgMjYsIDIwMjAgYXQgOTo0NiBBTSBXYXRzb24g TGFkZCB2aWEgRGF0YXRyYWNrZXINCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5ub3JlcGx5QGlldGYu b3JnPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgUmV2aWV3ZXI6IFdhdHNvbiBMYWRkPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgUmV2aWV3IHJlc3VsdDogU2VyaW91cyBJc3N1ZXM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEkgZ2VuZXJhdGVkIHRo aXMgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGRpcmVjdG9yYXRl J3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZw0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgcHJvY2Vzc2Vk IGJ5IHRoZSBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUg aW50ZW50DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyBvZiBpbXByb3Zpbmcgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFuZCBjb25zaWRlcmF0aW9ucyBp biBJRVRGDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyBkcmFmdHMuJm5ic3A7IENvbW1lbnRzIG5vdCBhZGRyZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBi ZSBpbmNsdWRlZCBpbiBBRA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgcmV2aWV3cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiZuYnNwOyBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVHdvIG1pbm9yIGlzc3VlczogT24gcGFnZSA0LCAmcXVvdDtU aGlzIG9mZmVycyBhbiBhZGRpdGlvbmFsIGRlZ3JlZSBvZg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgcHJpdmFjeSBwcm90ZWN0aW9uLiZxdW90OyBz aG91bGQgYmUgcmV3b3JkZWQuIEkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMNCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHNlbnNlIGluIGNvbnRleHQsIHdo ZXJlIGF1dGhlbnRpY2l0eSB3YXMgZGlzY3Vzc2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBJbiB0aGUgY291cnNlIG9mIHRoZSBlZGl0LCBleHBsYW5hdGlvbiBhYm91dCB0d28g ZGlzdGluY3QgcHJpdmFjeQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGJlbmVmaXRzIHdhcyBjb2xsYXRlZCBpbiBvbmUgc2VudGVuY2UgYW5kIGhhcyBiZWNv bWUgdmVyeSBkaWZmaWN1bHQgdG8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBwYXJzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg V2hhdCBpdCBpcyB0cnlpbmcgdG8gZXhwcmVzcyBhcyBwcml2YWN5IGJlbmVmaXRzIGFyZSB0aGUg Zm9sbG93aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAxKSBUaGUg YXV0aG9yaXphdGlvbiByZXF1ZXN0IGNvbnRlbnQgaXMgc2VudCB0byB0aGUgQVMgaW4gdGhlDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYmFja2NoYW5uZWwg c28gaXQgd2lsbCBub3QgYmUgZXhwb3NlZCB0aHJvdWdoIHRoZSBicm93c2VyIHRvIHRoZSBleWVz DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgb2YgYW4gYWN0 aXZlIG9yIHBhc3NpdmUgb3V0c2lkZXIgb2JzZXJ2aW5nIHdoYXQgaXMgZ29pbmcgb24gaW4gdGhl DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYnJvd3Nlci4m bmJzcDsgSW4gdGhlIFJGQzY3NDkgZnJhbWV3b3JrIGNhc2UsIHRoZSBhdXRob3JpemF0aW9uIHJl cXVlc3QNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBnb2Vz IHRocm91Z2ggdGhlIGJyb3dzZXIgcmVkaXJlY3QgYW5kIGl0IGNvdWxkIGxlYWsgdG8gdGhlIGFk dmVyc2FyeQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHZp YSBXUEFEL1BBQyBBdHRhY2ssIHJlZmVycmVyLCBicm93c2VyIGhpc3RvcnksIGV0Yy4gQWxzbywg aWYgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYnJv d3NlciB3YXMgaW5mZWN0ZWQgYnkgYW4gYWR2ZXJzYXJ5IGNvbnRyb2xsZWQgbWFsd2FyZSwgdGhl IGNvbnRlbnQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBj YW4gYmUgc25pZmZlZCBieSB0aGUgYWR2ZXJzYXJ5LiBJbiB0aGUgY2FzZSBvZiBKQVIsIGl0IGRv ZXMgbm90DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaGFw cGVuLiBUaGlzIGlzIG9uZSBwcml2YWN5IGJlbmVmaXQgaXQgaXMgdHJ5aW5nIHRvIGV4cGxhaW4u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDIpIFRoZSBsb2NhdGlvbiB0 aGF0IHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgaXMgZ2V0dGluZyBwdXNoZWQgdG8NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkb2VzIG5vdCBoYXZlIHRv IGJlIHRoZSBBUy4gQSB0cnVzdGVkIHRoaXJkIHBhcnR5IHRoYXQgZXhhbWluZXMgdGhlDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY29udGVudCBmb3IgdGhl IGNvbmZvcm1hbmNlIHRvIHRoZSBjb2xsZWN0aW9uIG1pbmltaXphdGlvbiBwcmluY2lwbGUNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBtYXkgYWN0IGFzIHRo ZSBwYXJ0eSB0aGF0IGFjY2VwdHMgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhbmQgaXNzdWVz DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIHJlcXVl c3RfdXJpLiBBUyBjYW4gdGhlbiBqdXN0IGV2YWx1YXRlIHRoZSBkb21haW4gcGFydCBvZg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJlcXVlc3RfdXJpIHRv IGV2YWx1YXRlIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBjb25mb3JtYW50DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdG8gdGhpcyBwcmlu Y2lwbGUuIFRoaXMgaXMgYW5vdGhlciBwcml2YWN5IGJlbmVmaXQgZnJvbSB0aGUgcG9pbnQgb2YN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB2aWV3IG9mIHRo ZSBpbmRpdmlkdWFsIHVzZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkknbSBmaW5l IHdpdGggYW55IGZpeCB0byB0aGUgc2VudGVuY2UgdGhhdCBtYWtlcyBzZW5zZS4gRG9uJ3QgdGhp bmsgd2UgbmVlZCB0byBpbnNlcnQgdGhlIGFib3ZlIGJ1dCBJIHZlcnkgbXVjaCBhcHByZWNpYXRl IHRoZSBleHBsYW5hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IEdpdmVuIHRoYXQgaXRzIG1lYW5pbmcgaXMgZmFp cmx5IGluc2NydXRhYmxlLCBhbmQgdGhhdCB0aGUgdHdvIGJlbmVmaXRzIGRlc2NyaWJlZCBieSBO YXQgYWJvdmUgYXJlIHBhcnRpYWxseSByZWxhdGVkIHRvIHBhcmFncmFwaHMgb3RoZXIgdGhhbiB0 aGUgb25lIHdpdGggdGhlIHByaXZhY3kgc3RhdGVtZW50LCBJIHByb3Bvc2UgdGhhdCB3ZSBzaW1w bHkNCiBkZWxldGUgdGhlIHNlbnRlbmNlICZxdW90O1RoaXMgb2ZmZXJzIGFuIGFkZGl0aW9uYWwg ZGVncmVlIG9mIHByaXZhY3kgcHJvdGVjdGlvbi4mcXVvdDsgZnJvbSB0aGlzIHBhcmFncmFwaC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBJdCB0b29rIG1l IGEgd2hpbGUgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBieSByZWZlcmVuY2UgbWV0aG9kIGlzOg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgbWF5YmUg dGhlIGludHJvIHNob3VsZCBzYXkgdmlhIFVSTCBpbnN0ZWFkIG9mIGJ5IHJlZmVyZW5jZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVxdWVzdF91cmkgY2FuIGJlIFVSTCBvciBh IGhhbmRsZSBzdWNoIGFzIFVSTi4gVGhhdCBpcyB3aHkgdGhlICZxdW90O2J5DQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVmZXJlbmNlJnF1b3Q7IHdvcmQg aXMgYmVpbmcgdXNlZCwgcGVyIHRoZSBzdWdnZXN0aW9uIG9mIHRoZSBXRy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SSdtIGZpbmUgd2l0aCB0aGF0LCBqdXN0IG5vdGluZyBteSBjb25m dXNpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDBCMDUwIj5NaWtlJmd0OyBVbmRlcnN0b29kLiZuYnNwOyBJIGxvb2tlZCBhdCB3YXlzIHRvIHBv c3NpYmx5IG1vdmUgdGhlICZxdW90O2J5IHJlZmVyZW5jZSZxdW90OyB0ZXh0IHRoYXQgZm9sbG93 cyBpbiBhIGZldyBwYXJhZ3JhcGhzIGVhcmxpZXIgdG8gcG9zc2libHkgbWFrZSB0aGlzIGNsZWFy ZXIsIGJ1dCBpdCB3b3VsZCBtZXNzIHVwIHRoZSBsb2dpY2FsIGZsb3cgb2YgdGhlIEludHJvZHVj dGlvbi4mbmJzcDsNCiBVbmxlc3MgeW91IGhhdmUgYSBiZXR0ZXIgc3VnZ2VzdGlvbiwgSSBwcm9w b3NlIHRoYXQgd2UgbGVhdmUgdGhpcyBhcy1pcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyBBbmQgbm93IGZvciB0aGUgdGhvcm55IGlzc3VlcyB3aXRoIHRo aXMgZHJhZnQuIFNpZ25hdHVyZXMgYW5kDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyBlbmNyeXB0aW9uIGFyZSBkaWZmZXJlbnQuIEFuZCBlbmNyeXB0 aW5nIGEgc2lnbmVkIGJsb2IgZG9lc24ndCBtZWFuIHRoZSBzaWduZXIgZW5jcnlwdGVkIGl0Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFRoZW4gdGhl cmUgYXJlIGEgcGxldGhvcmEgb2YgbWV0aG9kcyBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0Jm5ic3A7 IHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBh dXRoZW50aWNhdGUgdGhlIGJsb2IsIHdoaWNoIHdpbGwgZ2l2ZSBkaWZmZXJlbnQgcmVzdWx0cyBp bg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgbWFs aWNpb3VzbHkgY29uc3RydWN0ZWQgZXhhbXBsZXMuIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgc2Vj dGlvbiBzaG91bGQgZGlzY3VzcyB3aGF0IHRoZSBlbmNyeXB0ZWQgdnMgc2lnbmVkIGNob2ljZXMg Z2l2ZSBpbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgdGhlIHdheSBvZiBzZWN1cml0eSwgYW5kIGl0IGRvZXNuJ3QuIFRoaXMgbWFrZXMgbWUgd29y cnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFdlIGRvbuKAmXQgZXhw ZWN0IHRoZSBlbmNyeXB0aW9uIHRvIGVuc3VyZSBhdXRoZW50aWNpdHksIHRoYXTigJlzIHdoYXQg dGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc2lnbmF0 dXJlcyBhcmUgdXNlZCBmb3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgbmVl ZHMgdG8gYmUgdmVyeSBjbGVhcmx5IHNwZWxsZWQgb3V0IGluIHRoZSB0ZXh0LiBMb3RzIG9mIHBl b3BsZSB3aWxsIG5vdCB1bmRlcnN0YW5kIHRoaXMuIFRoZSB3b3JkaW5nIG9mIHNlY3Rpb24gMTAu MiBpcyBhdCBiZXN0IGFtYml2YWxlbnQsIHdpdGggbXVsdGlwbGUgYWx0ZXJuYXRpdmVzIHByZXNl bnRlZCBhcyBhY2NlcHRhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgQWZ0ZXIgdGhlIHNlbnRlbmNlIGF0IDEwLjIg KGIpIGFib3V0IHN5bW1ldHJpYyBlbmNyeXB0aW9uLCBJIHByb3Bvc2UgdGhhdCB3ZSBhZGQgdGhl IGZvbGxvd2luZyBzZW50ZW5jZSB0byBlbXBoYXNpemUgdGhlIHBvaW50IHlvdSdyZSByYWlzaW5n OiAmbmJzcDsmcXVvdDtOb3RlIGhvd2V2ZXIsIHRoYXQgaWYgcHVibGljIGtleSBlbmNyeXB0aW9u IGlzIHVzZWQsIG5vDQogc291cmNlIGF1dGhlbnRpY2F0aW9uIGlzIGVuYWJsZWQgYnkgdGhlIGVu Y3J5cHRpb24sIGFzIGFueSBwYXJ0eSBjYW4gZW5jcnlwdCBjb250ZW50IHRvIHRoZSBwdWJsaWMg a2V5LiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O2Nob3AmZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IEkgZGlkbid0IHF1aXRlIGdldCB3aGF0IGlzIG1lYW50IGJ5ICZx dW90O3BsZXRob3JhIG9mIG1ldGhvZHMgc3BlY2lmaWVkIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIGRyYWZ0IHRvIGF1dGhlbnRpY2F0ZSB0aGUg YmxvYiAuLi4gJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IFRoZXJlIGlzIGEgYml0IG9mIHRleHQgYWJvdXQgYXV0aGVudGljYXRpbmcgdGhlIHNvdXJj ZSAoPWNsaWVudCkgYnV0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgbm90IG11Y2ggb24gdGhlIGJsb2IgaXRzZWxmLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgZGlzY3Vzc2lvbiBhcm91bmQgdGhlIHNpZ25hdHVy ZSBhbmQvb3IgZW5jcnlwdGlvbiBpcyBjb3ZlcmVkIGluPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFJGQzc1MTkgKEpXVCksIHRoZSBmb3JtYXQgdGhhdCB0aGUg cmVxdWVzdCBvYmplY3QgYXNzdW1lcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgVGhpcyBpcyByZXF1aXJlZCByZWFkaW5nIHdoZW4gaW1wbGVtZW50aW5nIHRo aXMgc3BlYywgc28gV0cgdGhvdWdodCBpdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IGlzIG5vdCB3b3J0aCByZXBlYXRpbmcgaGVyZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQXR0YWNrcyBldGMuIG9uIHRoZSBzaWdu YXR1cmUgYW5kIGVuY3J5cHRpb24gYXJlIGNvdmVyZWQgaW4gUkZDNzUxNQ0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFuZCBSRkM3NTE2IHJlc3BlY3RpdmVs eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2VsbCwgdGhlIGRyYWZ0IGhhcHBlbnMg dG8gaW5jbHVkZSB0aGUgZm9sbG93aW5nIHRleHQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgJnF1b3Q7VGhlIEF1dGhvcml6YXRpb24gU2VydmVy IE1VU1QgdmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBvZiB0aGUgSlNPTiBXZWI8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBTaWduYXR1cmUgW1JGQzc1 MTVdIHNpZ25lZCBSZXF1ZXN0IE9iamVjdC4mbmJzcDsgVGhlIHNpZ25hdHVyZSBNVVNUIGJlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdmFsaWRh dGVkIHVzaW5nIHRoZSBrZXkgZm9yIHRoYXQgJnF1b3Q7Y2xpZW50X2lkJnF1b3Q7IGFuZCB0aGUg YWxnb3JpdGhtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgc3BlY2lmaWVkIGluIHRoZSAmcXVvdDthbGcmcXVvdDsgSGVhZGVyIFBhcmFtZXRlci4m cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2hvdWxkbid0IHRoZSBrZXkgYmUg YXNzb2NpYXRlZCB3aXRoIGEgc2luZ2xlIGFsZ29yaXRobT8gSG93IGRvIHdlIGVuc3VyZSB0aGF0 IHRoZSBjb21tb24gYXR0YWNrIG9mIHRlbGxpbmcgdGhlIHNlcnZlciB0byB1c2UgaG1hYyB0byB2 ZXJpZnkgdGhlIHNpZ25hdHVyZSBkb2Vzbid0IHdvcmsgaGVyZT88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IEdvb2QgcG9p bnQuJm5ic3A7IFRoaXMgYXR0YWNrIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMSBvZiBSRkMg ODcyNSBhbmQgbWl0aWdhdGVkIGJ5IHRoZSBwcmFjdGljZXMgaW4gU2VjdGlvbnMgMy4xIGFuZCAz LjIgb2YgdGhlIHNhbWUuJm5ic3A7IEkgcHJvcG9zZSB0aGF0IHdlIHJlcGxhY2UgdGhlIHNlbnRl bmNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhlIHNpZ25h dHVyZSBNVVNUIGJlIHZhbGlkYXRlZCB1c2luZyB0aGUga2V5IGZvciB0aGF0ICZxdW90O2NsaWVu dF9pZCZxdW90OyBhbmQgdGhlIGFsZ29yaXRobSBzcGVjaWZpZWQgaW4gdGhlICZxdW90O2FsZyZx dW90OyBIZWFkZXIgUGFyYW1ldGVyLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj53aXRoOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhlIHNpZ25hdHVyZSBNVVNU IGJlIHZhbGlkYXRlZCB1c2luZyBhIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudCBhbmQg dGhlIGFsZ29yaXRobSBzcGVjaWZpZWQgaW4gdGhlICZxdW90O2FsZyZxdW90OyBIZWFkZXIgUGFy YW1ldGVyLiZuYnNwOyBJZiBhICZxdW90O2tpZCZxdW90OyBIZWFkZXIgUGFyYW1ldGVyIGlzIHBy ZXNlbnQsIHRoZSBrZXkgaWRlbnRpZmllZCBNVVNUIGJlIHRoZQ0KIGtleSB1c2VkLCBhbmQgTVVT VCBiZSBhIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudC4mbmJzcDsgQWxnb3JpdGhtIHZl cmlmaWNhdGlvbiBNVVNUIGJlIHBlcmZvcm1lZCwgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb25zIDMu MSBhbmQgMy4yIG9mIFJGQyA4NzI1LiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IExvb2tpbmcgYXQgdGhlIGNpdGVkIHJlZmVyZW5jZSBmb3IgYXR0 YWNrcywgSSBzZWUgdGhlIGZpeCBpcyB0bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgaW5jbHVkZSBpbmZvcm1hdGlvbiBhYm91dCB3aGljaCBJUEQg d2FzIHVzZWQgYnkgdGhlIFJQLiBCdXQgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyBkcmFmdCBiZWZvcmUgdXMgZG9lc24ndCBtYW5kYXRlIHRo YXQuIEl0J3Mgbm90IGNsZWFyIHRoYW4gaG93IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgY2l0ZWQgYXR0YWNrIGlzIHByZXZlbnRlZCBieSB0 aGUgZHJhZnQuIFNheWluZyB0aGF0IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgY29tbXVuaWNhdGlvbiB0aHJvdWdoIHRoZSB1c2VyLWFnZW50 IGlzIHN1YmplY3QgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhl IG1lbnRpb24gb2YgbWl4LXVwIGF0dGFjayB3YXMgaW50cm9kdWNlZCBhZnRlciB0aGUgTGFzdCBj YWxsIGJ5IG9uZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IG9mIHRoZSBjb21tZW50LiBJdCBqdXN0IGFkZGVkIGl0IGluIHRoZSBzZW50ZW5jZSB3aXRoIGEg cmVmZXJlbmNlLiBJDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgYW0gb2sgdG8gcmVtb3ZlIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGF0 IHdvcmtzIGZvciBtZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IEkgd2lsbCByZW1vdmUgdGhlIG1peC11cCBhdHRhY2sg cmVmZXJlbmNlIGluIHRoZSBuZXh0IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBIYXZpbmcgc2FpZCB0aGF0LCB0aGUgaGVhcnQgb2YgbWl4LXVwIGF0dGFj ayBpcyB0aGF0IHRoZSBjb21iaW5hdGlvbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IG9mIHRoZSBjbGllbnQgYmVsaWV2ZXMgdGhhdCBpdCBpcyBjb21tdW5p Y2F0aW5nIHdpdGggdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgYXR0YWNrZXItY29udHJvbGxlZCBBUyAoQUFTKSB3aGlsZSBpdCBpbi1mYWN0IGlzIHRh bGtpbmcgdG8gSG9uZXN0IEFTDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgKEhBUyksIEFORCBIQVMgdW5hYmxlIHRvIGZpbmQgb3V0IHRoYXQgdGhlIGNsaWVu dCBpcyB0aGlua2luZyB0aGF0IGl0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgaXMgdGFsa2luZyB0byBBQVMgbm90IGhpbS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgT0F1dGggSkFSIHNlZW1zIHRvIG1pdGlnYXRlIGl0IGluIHR3 byB3YXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhKSBVc2UgcmVx dWVzdF91cmkgd2hpY2ggaXMgaG9zdGVkIGJ5IHRoZSBBUy4gVGhlbiwgaWYgdGhlIGNsaWVudCBp cw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoaW5raW5n IHRoYXQgaXQgaXMgdGFsa2luZyB0byB0aGUgQUFTLCB0aGVuIGl0IHdpbGwgcHVzaCBpdCB0byBB QVMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhbmQgd2hl biB0aGUgdXNlciBpcyByZWRpcmVjdGVkIHRvIEhBUywgSEFTIHdpbGwgZmluZCBvdXQgdGhhdCB0 aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyByZXF1ZXN0 X3VyaSBpcyBub3QgY3JlYXRlZCBieSBoZXJzZWxmIGFuZCByZXR1cm4gYW4gZXJyb3IsIG1ha2lu ZyB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBtaXgt dXAgYXR0YWNrIGZhaWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGIp IEluY2x1ZGUgYGF1ZGAgaW4gdGhlIHJlcXVlc3QuIFRoZW4sIHdoZW4gdGhlIEhBUyB3aWxsIGZp bmQgdGhhdCB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyByZXF1ZXN0IHdhcyBtaW50ZWQgdG8gQUFTIGFuZCBub3QgaGVyLiBTbywgaXQgd2lsbCByZXN1 bHQgaW4gYW4gZXJyb3IsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgbWFraW5nIHRoZSBtaXgtdXAgYXR0YWNrIGZhaWwuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPklmIHRoZSBkcmFmdCBtYW5kYXRlcyBkb2luZyB0aGlzIGl0IGFkZHJlc3NlcyB0 aGUgYXR0YWNrIGFuZCB0aGUgc2VudGVuY2UgY2FuIHN0YXkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBUaGUgZHJhZnQg bWFuZGF0ZXMgdXNlIG9mICZxdW90O2F1ZCZxdW90OyBidXQgaXQgZG9lcyBub3QgbWFuZGF0ZSB0 aGF0IHRoZSByZXF1ZXN0X3VyaSBiZSBob3N0ZWQgYnkgdGhlIEFTLiZuYnNwOyBUaGVyZWZvcmUs IEkgdGhpbmsgd2Ugc2hvdWxkIHJlbW92ZSB0aGUgbWl4LXVwIGF0dGFjayByZWZlcmVuY2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNvLCBJIGFkZGVkIG1peC11 cCBhdHRhY2sgdG8gdGhlIHNlbnRlbmNlIHRoaW5raW5nIHRoZSBjb21tZW50ZXIncw0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJlcXVlc3QgdG8gYWRkIGl0 IGlzIGZpbmUsIGJ1dCBJIGFtIGZpbmUgd2l0aCByZW1vdmluZyBpdC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBtYW5pcHVsYXRpb24sIGFuZCB0aGlzIHByZXZl bnRzIGl0LCBpZ25vcmVzIHRoYXQgdGhlIGF0dGFja2VyIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyB0aGF0IHBvc2l0aW9uIHNlZXMgYSBsb3Qg bW9yZS4gVGhlIHVzZXItYWdlbnQgYXMgcmVzb3VyY2Ugb3duZXINCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IG1vZGlmeWluZyB0aGUgcmVxdWVzdGVk IHJlc291cmNlcyBpcyBhIHZlcnkgZnVubnkgc29ydCBvZiBhdHRhY2s6DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBjYW4ndCB0aGV5IGRvIHdoYXQg dGhleSB3YW50IHdpdGggdGhlIHJlc291cmNlcyBzaW5jZSB0aGV5IGNvbnRyb2wgdGhlIGFjY2Vz cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSWYgdGhlIGNsaWVudCBp cyBpbiB0aGUgYnJvd3NlciwgeWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBCdXQgaW4gdGhlIG1haW5zdHJlYW0gY2FzZSwgdGhlIGNsaWVudCBpcyBub3Qg aW4gdGhlIGJyb3dzZXIgYnV0IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IHdlYi1zZXJ2ZXIgdGhhdCB0aGUgYnJvd3NlciBpcyBjb21tdW5pY2F0aW5n IHdpdGggYW5kIHRoZSByZXNvdXJjZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IGFjY2VzcyBoYXBwZW5zIHdpdGhvdXQgYmVpbmcgbWVkaWF0ZWQgYnkgdGhl IGJyb3dzZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk15IGNvbmNlcm4gb24gdGhp cyBwb2ludCBpcyByZXNvbHZlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IFRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7IEtleSBtYW5hZ2VtZW50IGlzIGlnbm9yZWQuIFRoaXMgaXMgYSB2ZXJ5IGltcG9ydGFudCBp c3N1ZSwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 IGVzcGVjaWFsbHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQSBsb3Qg b2YgZ3JvdW5kIGlzIGNvdmVyZWQgYnkgUkZDIDc1MTUsIDc1MTYsIDc1MTcsIDc1MTgsIDc1MTks IDc1OTEsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYW5k IDg0MTQgc28gdGhpcyBkb2N1bWVudCBpcyBub3Qgc3BlY2lmaWNhbGx5IHJlc3RhdGluZyB0aGVt LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgY29uc2lkZXJpbmcgdGhlIHBv dGVudGlhbCBwcm9ibGVtcyB3aXRoIHRoZSByZXVzZSBvZiBKV1QuIEknZCBsaWtlDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyB0byBzZWUgYTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBcmUgeW91IHRhbGtpbmcgYWJvdXQg dGhlIHJldXNlIG9mIHRoZSByZXF1ZXN0IG9iamVjdCBieSBhbiBhZHZlcnNhcnkNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0cnlpbmcgdG8gYWN0IGFzIGFu IGhvbmVzdCBjbGllbnQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IEV2ZW4gaWYgaXQgaGFwcGVucywgdGhlIG1hbGljaW91cyBjbGllbnQgZG9lcyBub3QgaGF2 ZSB0aGUgcHJvcGVyDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgY2xpZW50IGNyZWRlbnRpYWwgc28gaXQgY2Fubm90IHJlZGVlbSB0aGUgY29kZSBpdCBvYnRh aW5lZCB3aXRoIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IHRva2VuLiBJdCBpcyBubyBkaWZmZXJlbnQgdGhhbiBSRkM2NzQ5IGNvZGUgZ3JhbnQuIFBy b3RvY29scyB0aGF0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgZXh0ZW5kIGl0LCBzdWNoIGFzIE9wZW5JRCBDb25uZWN0LCBoYXZlIGludHJvZHVjZWQgbm9u Y2UgdG8gcHJldmVudA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IHRoZSByZXVzZSBhbmQgdXNlZCBKQVIgKGl0IGlzIGNhbGxlZCByZXF1ZXN0IG9iamVjdCB0 aGVyZSkgdG8gZnVydGhlcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHByb3RlY3QgdGFtcGVyaW5nIGFuZCBhY2hpZXZlIGNsaWVudCBhdXRoZW50aWNhdGlv biBldmVuIGluIHRoZSBmcm9udA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IGNoYW5uZWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsgcmVjb21tZW5kYXRpb24gdGhhdCBrZXlzIGJlIHNlcGFyYXRlZCBieSBpbnRlbmRlZCB1 c2VzLCByYXRoZXIgdGhhbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgbGltaXRpbmcgcGFydGljdWxhciBmaWVsZHMgaW4gYW4gYWQtaG9jIG1hbm5l ci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ291bGQgeW91IGtpbmRs eSBlbGFib3JhdGUgb24gdGhlICZxdW90O2FkLWhvYyBtYW5uZXImcXVvdDsgcGFydCBzbyB0aGF0 IEkgY2FuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdW5k ZXJzdGFuZCBpdCBtb3JlIGZ1bGx5PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xMC44 LCBDcm9zcy1KV1QgQ29uZnVzaW9uIGRpc2N1c3NlcyBhdm9pZGluZyBzaWduaW5nIGNlcnRhaW4g ZmllbGRzLCByYXRoZXIgdGhhbiBzdWdnZXN0aW5nIGdvb2Qga2V5IHVzYWdlIGFzIGEgc29sdXRp b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBC MDUwIj5NaWtlJmd0OyBJIHByb3Bvc2UgdG8gYWRkIHRoaXMgbmV3IHBhcmFncmFwaCBhdCB0aGUg ZW5kIG9mIFNlY3Rpb24gMTAuOCB0byBpbXBsZW1lbnQgeW91ciBzdWdnZXN0aW9uOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7RmluYWxseSwgYW5vdGhlciB3YXkg dG8gcHJldmVudCBjcm9zcy1KV1QgY29uZnVzaW9uIGlzIHRvIHVzZSBhIGtleSBtYW5hZ2VtZW50 IHJlZ2ltZSBpbiB3aGljaCBrZXlzIHVzZWQgdG8gc2lnbiBSZXF1ZXN0IE9iamVjdHMgYXJlIGlk ZW50aWZpYWJseSBkaXN0aW5jdCBmcm9tIHRob3NlIHVzZWQgZm9yIG90aGVyIHB1cnBvc2VzLiZu YnNwOyBUaGVuLCBpZg0KIGFuIGFkdmVyc2FyeSBhdHRlbXB0cyB0byByZXB1cnBvc2UgdGhlIFJl cXVlc3QgT2JqZWN0IGluIGFub3RoZXIgY29udGV4dCwgYSBrZXkgbWlzbWF0Y2ggd2lsbCBvY2N1 ciwgdGh3YXJ0aW5nIHRoZSBhdHRhY2suJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVGhlbiB3ZSBoYXZlIHNlY3Rpb24gMTEuIFdoYXQgc2VjdGlv biAxMSBpbnRyb2R1Y2VzIGlzIGFuIGVudGlyZSBuZXcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGRyYW1hdGlzIHBlcnNvbmFlLCB0aGUgVHJ1c3Qg RnJhbWV3b3JrIFByb3ZpZGVyLCB3aXRoIG5vIHByaW9yDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBkaXNjdXNzaW9uIG9mIHdoYXQgaXQgaXMgb3Ig YSByZWZlcmVuY2UgdG8gd2hlcmUgaXQgaXMgZGVmaW5lZCBhbmQgYQ0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgZ29vZCBudW1iZXIgb2Ygc3RhdGVt ZW50cyBhYm91dCBob3cgaXQgd29ya3MgdGhhdCBhcmVuJ3QgcmVhbGx5Jm5ic3A7IGNsZWFyIHdo YXQgdGhleSBtZWFuIGZyb20gdGhlIGRvY3VtZW50IHRvIG1lLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBUcnVzdCBGcmFtZXdvcmsgUHJvdmlkZXIgZmlyc3QgYXBwZWFy cyBpbiA1LjIuMS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg QXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0aGUgcmVsYXRlZCB0ZXh0LCBpdCB3YXMgYSBwcmV0dHkg d2VsbC1rbm93bg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGNvbmNlcHQuIEluIHRoZSBVbml0ZWQgU3RhdGUsIGl0IHdhcyBwYXJ0IG9mIGl0cyBOYXRpb25h bCBTdHJhdGVneTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAo TlNUSUMpIGFuZCBpbnRlcm5hdGlvbmFsbHksIGl0IHdhcyBldmVuIHRha2VuIHVwIGF0IFdFRiBE YXZvcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1lZXRp bmcuIEl0IGlzIHF1aXRlIHN1cnByaXNpbmcgdGhhdCBzdWNoIGEgbWFpbnN0cmVhbSBjb25jZXB0 IGZhZGVkDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaW50 byBvYnNjdXJpdHkgc28gcXVpY2tseS4gVGhlIHJlYXNvbiBmb3IgaW50cm9kdWNpbmcgaXQgd2Fz IHRvIGEpDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsganVz dGlmeSByZXF1ZXN0X3VyaSBhcyBzb21lIFdHIG1lbWJlcnMgd2FudGVkIGl0IHRvIGJlIHJlbW92 ZWQsIGIpDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsganVz dGlmeSB0aGF0IHJlcXVzdF91cmkgdG8gYmUgc2VydmVkIGZyb20gYSBkaWZmZXJlbnQgZG9tYWlu LiBOb3cgdGhhdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IHBlb3BsZSBhcHByZWNpYXRlIGl0LCBlLmcuLCBpdCBjYW4gYmUgc2VlbiBmcm9tIFBBUiwgdGhl IGp1c3RpZmljYXRpb24NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBmb3IgYSkgcHJvYmFibHkgaXMgbm8gbG9uZ2VyIHJlcXVpcmVkLiBBIGZ1bGwgZXhwbGFu YXRpb24gZm9yIGIpIHdvdWxkDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgcHJvYmFibHkgYmUgYSBtdWNoIGxvbmdlciB0ZXh0IGJ1dCBJIGRvdWJ0IGlmIGl0 IGJlbG9uZ3MgdG8gdGhpcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGRvY3VtZW50LiBJIGFtIGZpbmUgd2l0aCByZW1vdmluZyB0aGUgcmVmZXJlbmNlIHRv IFRydXN0IGZyYW1ld29yaw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGV0Yy4gYXMgbG9uZyBhcyB0aGUgY2FwYWJpbGl0eSB0byBwdXNoIHRoZSBhdXRob3Jp emF0aW9uIHJlcXVlc3QgdG8gYQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IHBsYWNlIG90aGVyIHRoYW4gdGhlIGNsaWVudCBvciB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgaXMgbm90DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgcmVtb3ZlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TGV0J3MgcmVtb3Zl IHRoZSB0ZXh0IHRoZW4sIGJ1dCBrZWVwIHRoZSBjYXBhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1pa2UmZ3Q7IEkgcHJvcG9z ZSB0byByZW1vdmUgdXNlcyBvZiB0aGUgdGVybSAmcXVvdDtUcnVzdCBGcmFtZXdvcmsgUHJvdmlk ZXImcXVvdDsgYW5kIGluc3RlYWQgcmVwbGFjZSB0aGVtIGJ5IHRoZSBtb3JlIGdlbmVyaWMgdGVy bSAmcXVvdDt0cnVzdGVkIHRoaXJkLXBhcnR5IHNlcnZpY2UmcXVvdDsuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgTXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRo YXQgdGhlc2UgaXNzdWVzIGFyZSBzaWducyB0aGF0IHRoZSBwcm9ibGVtDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyB0aGlzIGRyYWZ0IGlzIHRyeWlu ZyB0byBzb2x2ZSBhbmQgdGhlIG1lY2hhbmlzbXMgdG8gc29sdmUgaXQgaGF2ZW4ndA0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgYmVlbiBhbmFseXpl ZCBhcyB0aG9yb3VnaGx5IGFzIHRoZXkgc2hvdWxkIGhhdmUgYmVlbi4gV2l0aG91dCB0aGF0DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBzb3J0IG9m IHRob3JvdWdoIGFuYWx5c2lzIGl0J3Mgbm90IGNlcnRhaW4gdGhhdCB0aGUgbWVjaGFuaXNtcw0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgYWN0dWFs bHkgc29sdmUgdGhlIHByb2JsZW0gYW5kIGl0J3Mgbm90IGNsZWFyIHdoYXQgdGhlDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyByZWNvbW1lbmRhdGlv bnMgdG8gaW1wbGVtZW50ZXJzIGhhdmUgdG8gYmUgdG8gcHJlc2VydmUgdGhvc2UgcHJvcGVydGll cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgT0F1dGggSkFSLCBhcyB0 aGUgbmFtZSAmcXVvdDtUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrOiBKV1QN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTZWN1cmVkIEF1 dGhvcml6YXRpb24gUmVxdWVzdCAoSkFSKSZxdW90OyBzdWdnZXN0cywgaXMgYSBmcmFtZXdvcmsg YW5kIG5vdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGEg aG91c2UgaXRzZWxmLiBPbmUgc3VjaCBleGFtcGxlIGlzIEZBUEkgWzFdIHdoaWNoIHdhcyBmb3Jt YWxseQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHZlcmlm aWVkIFsyXS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7SXQncyBwb3NzaWJs ZSB0byB1c2UgdGhpcyBkcmFmdCBzZWN1cml0eSZxdW90OyBJIGRvbid0IHRoaW5rIHNob3VsZCBi ZSBlbm91Z2ggYW55bW9yZS4gUmF0aGVyIGl0IHNob3VsZCBiZSBpbXBvc3NpYmxlIHRvIHVzZSBp bnNlY3VyZWx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwQjA1MCI+TWlrZSZndDsgVGhlIGRyYWZ0IGRlc2NyaWJlcyBob3cgdG8gdXNlIHRoZSBt ZWNoYW5pc20gc2VjdXJlbHkuJm5ic3A7IFllcywgaWYgcG9ydGlvbnMgb2YgdGhlIGRyYWZ0IChh bmQgdGhvc2UgaXQgZGVwZW5kcyB1cG9uKSBhcmUgbm90IGZvbGxvd2VkLCBpbnNlY3VyZSB1c2Fn ZSBjYW4gcmVzdWx0LiZuYnNwOyBUaGF0J3MgdHJ1ZSBvZiBhbnkgc2VjdXJpdHkgZHJhZnQuJm5i c3A7IElmDQogdGhlcmUgYXJlIGFkZGl0aW9uYWwgc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGFuZC9v ciByZWNvbW1lbmRhdGlvbnMgbmVlZGVkLCB3ZSdkIGJlIGdsYWQgdG8gYWRkIHRoZW0uJm5ic3A7 IElmIHNvLCBwbGVhc2UgaWRlbnRpZnkgdGhlbS4mbmJzcDsgKEluZGVlZCwgd2UncmUgYWxyZWFk eSBkb2luZyBzbyBpbiByZXNwb25zZSB0byB5b3VyIGV4aXN0aW5nIHNwZWNpZmljIGZlZWRiYWNr Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IEFz IGZvciBwYXN0IEpXVCBwcm9ibGVtcywgdGhlIEpXVCBCQ1AgW1JGQyA4NzI1XSB3YXMgd3JpdHRl biBhdCB0aGUgcmVxdWVzdCBvZiB0aGUgSUVTRyB0byBpZGVudGlmeSBhbmQgbWl0aWdhdGUgdGhl bSAtIGVzcGVjaWFsbHkgaW4gbGlnaHQgb2YgSldUcyBiZWluZyB1c2VkIGZvciBhZGRpdGlvbmFs IHVzZSBjYXNlcywgc3VjaCBhcyBTVElSIHNlY3VyZWQNCiB0ZWxlcGhvbnkgYW5kIHNlY3VyaW5n IGZpcnN0LXJlc3BvbmRlciBzZXJ2aWNlcy4mbmJzcDsgSWYgeW91IGJlbGlldmUgdGhhdCBhZGRp dGlvbmFsIGdlbmVyaWMgSldUIGlzc3VlcyBzaG91bGQgYmUgZGlzY3Vzc2VkIGFuZCBhZGRyZXNz ZWQsIHdlIGNvdWxkIGFsd2F5cyByZXZpc2UgdGhpcyBCQ1AuJm5ic3A7IEJ1dCBkb2luZyBzbyBp cyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgUkZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBbMV0gPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vYml0YnVja2V0Lm9yZy9vcGVuaWQvZmFwaS9zcmMvbWFzdGVyL0ZpbmFuY2lhbF9BUElfV0Rf MDAyLm1kIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5odHRwczovL2JpdGJ1Y2tldC5vcmcvb3BlbmlkL2ZhcGkvc3JjL21hc3Rlci9GaW5hbmNp YWxfQVBJX1dEXzAwMi5tZDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IFsyXSA8YSBocmVmPSJodHRwczovL2FyeGl2Lm9yZy9hYnMvMTkwMS4x MTUyMCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pmh0dHBzOi8vYXJ4aXYub3JnL2Ficy8xOTAxLjExNTIwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IE9idmlvdXNseSB0aGlzIGRyYWZ0IGhhcyBoYWQgYSBs b25nIGFuZCB0b3J0dXJlZCBoaXN0b3J5IHdpdGgNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IG11bHRpcGxlIHJldmlld3MsJm5ic3A7IGFuZCB3aGF0 IEknbSBzdWdnZXN0aW5nIG5lZWRzIHRvIGhhcHBlbiBpcyBhIGxvdA0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgb2Ygd29yay4gQnV0IGl0J3MgZXNz ZW50aWFsIGluIGFueSBzZWN1cml0eSBwcm90b2NvbCB0byBkbyB0aGlzDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBhbmFseXNpcyBhbmQgYmUgY2xl YXIgYWJvdXQgd2hhdCBpcywgYW5kIHdoYXQgaXMgbm90LCBwcm90ZWN0ZWQgYnkgdGhlIHByb3Rv Y29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPQXV0aCBKQVIgaXMg bm90aGluZyBidXQganVzdCBhbm90aGVyIGJpbmRpbmcgdG8gT0F1dGggMi4wLiBXaGVyZQ0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFJGQzY3NDkgYmluZHMg aXQgdG8gZm9ybSBlbmNvZGluZywgaXQgcHJvdmlkZXMgdHdvIGFkZGl0aW9uYWwgYmluZGluZ3M6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDEpIGJpbmRpbmcgdG8gSldULCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMikgYmluZGlu ZyB0byB0aGUgcHVzaGVkIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0aGF0IGlzIHJlZmVyZW5jZWQg YnkgYSBVUkkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEl0 IGlzIHRoaXMgc2ltcGxlLiBBcyBzdWNoLCBpdCB3b3VsZCBhbHNvIGluaGVyaXQgc29tZSBvZiB0 aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzaG9ydGNv bWluZ3MgaW4gUkZDNjc0OS4gSG93ZXZlciwgaXQgaXMgbm90IHRoaXMgZG9jdW1lbnQgdG8gYWRk cmVzcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoZW0u IEl0IHNob3VsZCBiZSBkb25lIGJ5IG90aGVyIGRvY3VtZW50cyBzbyB0aGF0IHRoZSByZXN1bHQg Y2FuIGJlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZW5j b2RlZCB1c2luZyB0aGUgbWVjaGFuaXNtcyBwcm92aWRlZCBpbiB0aGlzIGRvY3VtZW50LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIGlzIG5vdCBhIHNpbXBsZSBtYXR0ZXIuIEpX VCBoYXMgYSBsb25nIGFuZCB0d2lzdGVkIGhpc3Rvcnkgd2l0aCBzb21lIHBlcnZhc2l2ZSBlcnJv cnMgaW4gY29tbW9uIGxpYnJhcmllcywgYW5kIGlzIGEgZmFpcmx5IGxhcmdlIHN0YW5kYXJkLiBP QXV0aCAyLjAgaXMgYWxzbyBsYXJnZS4gRW5zdXJpbmcgdGhhdCB0aGUgbWFwcGluZyBoYXMgdGhl IHJpZ2h0IHByb3BlcnRpZXMgaXMgZ29pbmcgdG8gYmUNCiBhIG1lc3MuIElmIHRoZSBlbmNvZGlu ZyBkb2VzIG5vdCByZXNwZWN0IHRoZSBzZW1hbnRpY3Mgd2UgaGF2ZSBhIHNlcmlvdXMgc2VjdXJp dHkgaXNzdWUuIElmIGltcGxlbWVudG9ycyBhc3N1bWUgdGhlIGVuY29kaW5nIHByb3ZpZGVzIHBy b3BlcnRpZXMgaXQgZG9lcyBub3QsIHdlIGFnYWluIGhhdmUgYSBzZWN1cml0eSBpc3N1ZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1p a2UmZ3Q7IFNlZSBteSBwcmV2aW91cyBjb21tZW50cyBvbiBwYXN0IEpXVCBpbXBsZW1lbnRhdGlv biBlcnJvcnMgYW5kIHRoZSB3cml0aW5nIG9mIHRoZSBKV1QgQkNQIFtSRkMgODcyNV0gdG8gYWRk cmVzcyB0aGVzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSXQg aXMgcXVpdGUgc3VycHJpc2luZyB0aGF0IHRoaXMgZmFjdCBpcyBub3QgZ2V0dGluZyBhcHByZWNp YXRlZCBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBp cyB0YWtpbmcgc3VjaCBhIGxvbmcgdGltZSB0byBjb21wbGV0ZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgTWF5YmUgSSBzaG91bGQgZGVsZXRlIGFsbCB0aGUg ZXhwbGFuYXRpb24gdGV4dCBhbmQgbGVhdmUgaXQgd2l0aCBqdXN0DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIGNvcmUgdGV4dC4gRXhwbGFuYXRpb24g YW5kIGp1c3RpZmljYXRpb24gdGV4dCBmb3IgZGVmaW5pbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhZGRpdGlvbmFsIGJpbmRpbmdzIHByb2JhYmx5IGFy ZSBqdXN0IGRpc3RyYWN0aW9ucyBub3cgYXMgaXQgaXMgbm93DQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYXBwcmVjaWF0ZWQgYW5kIHVzZWQgYWxsIG92ZXIg dGhlIHdvcmxkIHVubGlrZSB3aGVuIHRoZSBwcm9qZWN0IHdhcw0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHN0YXJ0ZWQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBJIHdvdWxkIHBy b3Bvc2UgdGhhdCB3ZSBtYWtlIG9ubHkgbmVjZXNzYXJ5IGNoYW5nZXMgdG8gdGhlIGRyYWZ0IGF0 IHRoaXMgcG9pbnQuJm5ic3A7IExldCdzIGZpbmlzaCB0aGlzIGxvbmctb3ZlcmR1ZSBzcGVjaWZp Y2F0aW9uITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgU2luY2VyZWx5LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFdhdHNvbiBMYWRkPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgVGhhbmtzIGFnYWluIGZvciB5b3VyIGRldGFpbGVkIGNvbW1lbnRzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgTmF0IFNha2ltdXJhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IE5BVC5Db25zdWx0aW5nIExMQzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgSSBub3cgcGxh biB0byBjcmVhdGUgZWRpdHMgaW5jb3Jwb3JhdGluZyB0aGUgcHJvcG9zZWQgcmVzb2x1dGlvbnMg YWJvdmUgZm9yIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIw NTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCZXN0IHdpc2hlcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Bc3RyYSBtb3J0ZW1xdWUgcHJhZXN0YXJl IGdyYWRhdGltPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MW2PR00MB0427A1F889A546B2B8D33125F56A9MW2PR00MB0427namp_-- From nobody Wed Mar 17 18:21:00 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD973A155B; Wed, 17 Mar 2021 18:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5rXqHDZDtOl; Wed, 17 Mar 2021 18:20:51 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 ED6A23A19CE; Wed, 17 Mar 2021 18:20:50 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id h10so4545164edt.13; Wed, 17 Mar 2021 18:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lj8VIjg7kSYGFTAd5E+DKYZX8QucN4fKGwqGzX/pGek=; b=nIzIs/C9KWn3NWYpQtFxDoCeYaBrEQh/0xfMWnHiogTSCzdj/wY7m4woUqzr1Tji15 KxAKzjrVIBRVrnet11xNTTTDf0A1wWB0zPajEWv/VrTQb950Mfn7rzw8I3PV/sygJr0V Ok/Je9ruN2UqHgWuJuuNH26B1QrACnTw7FmI6nIz4nfWkwvm3AQnct1E9ZctHWHDrPp3 nH7Q1AUT7nVQJYmwcwsfTCBIc8IWV7ZjYSXI0GByzDUHMa96Y4vjhU9dEimREmq/C8ku P/pe7VgihAwH/BqtWIcXH+JpkZE6BB1JytcqNKsVcKk6BdZuBS4BWXi44DmYYFIyDZs1 9xnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lj8VIjg7kSYGFTAd5E+DKYZX8QucN4fKGwqGzX/pGek=; b=swzgoOjGQwJFbWFm+lKFqM04mYSef+kvsgB1z1sYXQfUmrndKqBuvdytv13woiR4mg pVKWRH6T+3pLwU9vyKVDO9tr88eqbtp2qvRjx/d/oU0atu00pi3iac6WjNj0StTtmhCi zoXz/kVSecIhxBG0nVJq5NXdaMJOW9KnkLG5P8PwJS8pWYtb10b84P8KvZ77t7l5LEzD kb4f9XdJOfMsanhaUYvXI85bMUvdYAPLkt06RgYMy4c0wzcVo2L61QDK/5zkPV8iUzuW 0yaTfp2x8VpuAY2yjbKRCgEE5yhedI9E8ic5x1D8XzNQR0JeKIVHrSNqCGY8MGmJAW2D 3Zeg== X-Gm-Message-State: AOAM533CdEIlI90peaKGoUvKtSkMoRBU5/SRIYUVBQfoUzgjZSpvT1fH UK3L0qbNuKfn+EeiBTl7aosLFkeKhmmikCMADVw= X-Google-Smtp-Source: ABdhPJykzeOrFQn25d5oWANCLaPULnCznz38yO2bjWaargCIBlMTFkd6HwI8WWPwdtYYOP1CNjeJjUaDKZqZPadg6ys= X-Received: by 2002:a05:6402:382:: with SMTP id o2mr619511edv.238.1616030449480; Wed, 17 Mar 2021 18:20:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Watson Ladd Date: Wed, 17 Mar 2021 18:20:37 -0700 Message-ID: To: Mike Jones Cc: nat , "rdd@cert.org" , "secdir@ietf.org" , "oauth@ietf.org" , "last-call@ietf.org" , "draft-ietf-oauth-jwsreq.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-oauth-jwsreq-30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 01:20:55 -0000 On Wed, Mar 17, 2021 at 2:47 PM Mike Jones wr= ote: > > I=E2=80=99ve created the pull request https://bitbucket.org/Nat/oauth-jws= req/pull-requests/14/ applying the proposed changes below to the draft. Un= less suggestions for changes are received, we=E2=80=99ll merge this and pub= lish -31 to address Watson=E2=80=99s comments. I think these changes as addres my concerns. I wish that we could further restrict to a known-good, easily implementable profile, but we can't get everything we want. Sincerely, Watson Ladd > > > > -- Mike > > > > From: Mike Jones > Sent: Friday, February 26, 2021 12:55 PM > To: 'Watson Ladd' ; Nat Sakimura ; Roman Danyliw > Cc: secdir ; IETF oauth WG ; last-call@i= etf.org; draft-ietf-oauth-jwsreq.all@ietf.org > Subject: Re: Secdir last call review of draft-ietf-oauth-jwsreq-30 > > > > Thanks again for your review, Watson. My replies to your comments below = are prefixed by "Mike>". > > > > -----Original Message----- > From: Watson Ladd > Sent: Tuesday, December 15, 2020 9:01 PM > To: Nat Sakimura > Cc: secdir ; IETF oauth WG ; last-call@i= etf.org; draft-ietf-oauth-jwsreq.all@ietf.org > Subject: [EXTERNAL] Re: Secdir last call review of draft-ietf-oauth-jwsre= q-30 > > > > On Sat, Oct 31, 2020 at 6:13 AM Nat Sakimura wrote: > > > > > > Hi Watson, > > > > > > Thanks very much for the review. I thought I have sent my response > > > earlier, which I actually did not. It was sitting in my draft box. I > > > apologize for it. > > > > My apologies for missing it in my inbox for a number of months. > > > > > > My responses inline: > > > > > > On Sat, Sep 26, 2020 at 9:46 AM Watson Ladd via Datatracker > > > wrote: > > > > > > > > Reviewer: Watson Ladd > > > > Review result: Serious Issues > > > > > > > > I generated this review of this document as part of the security > > > > directorate's ongoing effort to review all IETF documents being > > > > processed by the IESG. These comments were written with the intent > > > > of improving security requirements and considerations in IETF > > > > drafts. Comments not addressed in last call may be included in AD > > > > reviews during the IESG review. Document editors and WG chairs shoul= d treat these comments just like any other last call comments. > > > > > > > > Two minor issues: On page 4, "This offers an additional degree of > > > > privacy protection." should be reworded. I don't think it makes > > > > sense in context, where authenticity was discussed. > > > > > > > > > In the course of the edit, explanation about two distinct privacy > > > benefits was collated in one sentence and has become very difficult to > > > parse. > > > > > > What it is trying to express as privacy benefits are the following. > > > > > > 1) The authorization request content is sent to the AS in the > > > backchannel so it will not be exposed through the browser to the eyes > > > of an active or passive outsider observing what is going on in the > > > browser. In the RFC6749 framework case, the authorization request > > > goes through the browser redirect and it could leak to the adversary > > > via WPAD/PAC Attack, referrer, browser history, etc. Also, if the > > > browser was infected by an adversary controlled malware, the content > > > can be sniffed by the adversary. In the case of JAR, it does not > > > happen. This is one privacy benefit it is trying to explain. > > > > > > 2) The location that the authorization request is getting pushed to > > > does not have to be the AS. A trusted third party that examines the > > > content for the conformance to the collection minimization principle > > > may act as the party that accepts the authorization request and issues > > > the request_uri. AS can then just evaluate the domain part of > > > request_uri to evaluate that the authorization request is conformant > > > to this principle. This is another privacy benefit from the point of > > > view of the individual user. > > > > I'm fine with any fix to the sentence that makes sense. Don't think we ne= ed to insert the above but I very much appreciate the explanation. > > > > Mike> Given that its meaning is fairly inscrutable, and that the two bene= fits described by Nat above are partially related to paragraphs other than = the one with the privacy statement, I propose that we simply delete the sen= tence "This offers an additional degree of privacy protection." from this p= aragraph. > > > > > > It took me a while to understand what the by reference method is: > > > > maybe the intro should say via URL instead of by reference. > > > > > > > > > request_uri can be URL or a handle such as URN. That is why the "by > > > reference" word is being used, per the suggestion of the WG. > > > > I'm fine with that, just noting my confusion. > > > > Mike> Understood. I looked at ways to possibly move the "by reference" t= ext that follows in a few paragraphs earlier to possibly make this clearer,= but it would mess up the logical flow of the Introduction. Unless you hav= e a better suggestion, I propose that we leave this as-is. > > > > > > And now for the thorny issues with this draft. Signatures and > > > > encryption are different. And encrypting a signed blob doesn't mean t= he signer encrypted it. > > > > Then there are a plethora of methods specified in the draft to > > > > authenticate the blob, which will give different results in > > > > maliciously constructed examples. The security considerations > > > > section should discuss what the encrypted vs signed choices give in > > > > the way of security, and it doesn't. This makes me worry. > > > > > > We don=E2=80=99t expect the encryption to ensure authenticity, that=E2= =80=99s what the > > > signatures are used for. > > > > This needs to be very clearly spelled out in the text. Lots of people wil= l not understand this. The wording of section 10.2 is at best ambivalent, w= ith multiple alternatives presented as acceptable. > > > > Mike> After the sentence at 10.2 (b) about symmetric encryption, I propos= e that we add the following sentence to emphasize the point you're raising:= "Note however, that if public key encryption is used, no source authentic= ation is enabled by the encryption, as any party can encrypt content to the= public key." > > > > > > > > > > I didn't quite get what is meant by "plethora of methods specified in > > > the draft to authenticate the blob ... " > > > There is a bit of text about authenticating the source (=3Dclient) but > > > not much on the blob itself. > > > The discussion around the signature and/or encryption is covered in > > > RFC7519 (JWT), the format that the request object assumes. > > > This is required reading when implementing this spec, so WG thought it > > > is not worth repeating here. > > > Attacks etc. on the signature and encryption are covered in RFC7515 > > > and RFC7516 respectively. > > > > Well, the draft happens to include the following text: > > "The Authorization Server MUST validate the signature of the JSON Web > > Signature [RFC7515] signed Request Object. The signature MUST be > > validated using the key for that "client_id" and the algorithm > > specified in the "alg" Header Parameter." > > > > Shouldn't the key be associated with a single algorithm? How do we ensure= that the common attack of telling the server to use hmac to verify the sig= nature doesn't work here? > > > > Mike> Good point. This attack is described in Section 2.1 of RFC 8725 an= d mitigated by the practices in Sections 3.1 and 3.2 of the same. I propos= e that we replace the sentence: > > "The signature MUST be validated using the key for that "client_id" a= nd the algorithm specified in the "alg" Header Parameter." > > with: > > "The signature MUST be validated using a key associated with the clie= nt and the algorithm specified in the "alg" Header Parameter. If a "kid" H= eader Parameter is present, the key identified MUST be the key used, and MU= ST be a key associated with the client. Algorithm verification MUST be per= formed, as specified in Sections 3.1 and 3.2 of RFC 8725." > > > > > > Looking at the cited reference for attacks, I see the fix is to > > > > include information about which IPD was used by the RP. But the > > > > draft before us doesn't mandate that. It's not clear than how the > > > > cited attack is prevented by the draft. Saying that the > > > > communication through the user-agent is subject to > > > > > > The mention of mix-up attack was introduced after the Last call by one > > > of the comment. It just added it in the sentence with a reference. I > > > am ok to remove it. > > > > That works for me. > > > > Mike> I will remove the mix-up attack reference in the next draft. > > > > > Having said that, the heart of mix-up attack is that the combination > > > of the client believes that it is communicating with the > > > attacker-controlled AS (AAS) while it in-fact is talking to Honest AS > > > (HAS), AND HAS unable to find out that the client is thinking that it > > > is talking to AAS not him. > > > > > > OAuth JAR seems to mitigate it in two ways: > > > > > > a) Use request_uri which is hosted by the AS. Then, if the client is > > > thinking that it is talking to the AAS, then it will push it to AAS > > > and when the user is redirected to HAS, HAS will find out that the > > > request_uri is not created by herself and return an error, making the > > > mix-up attack fail. > > > > > > b) Include `aud` in the request. Then, when the HAS will find that the > > > request was minted to AAS and not her. So, it will result in an error, > > > making the mix-up attack fail. > > > > If the draft mandates doing this it addresses the attack and the sentence= can stay. > > > > Mike> The draft mandates use of "aud" but it does not mandate that the re= quest_uri be hosted by the AS. Therefore, I think we should remove the mix= -up attack reference. > > > > > So, I added mix-up attack to the sentence thinking the commenter's > > > request to add it is fine, but I am fine with removing it. > > > > > > > manipulation, and this prevents it, ignores that the attacker in > > > > that position sees a lot more. The user-agent as resource owner > > > > modifying the requested resources is a very funny sort of attack: > > > > can't they do what they want with the resources since they control th= e access? > > > > > > If the client is in the browser, yes. > > > But in the mainstream case, the client is not in the browser but the > > > web-server that the browser is communicating with and the resource > > > access happens without being mediated by the browser. > > > > My concern on this point is resolved. > > > > Mike> Thanks > > > > > > Key management is ignored. This is a very important issue, > > > > especially > > > > > > A lot of ground is covered by RFC 7515, 7516, 7517, 7518, 7519, 7591, > > > and 8414 so this document is not specifically restating them. > > > > > > > > > > > considering the potential problems with the reuse of JWT. I'd like > > > > to see a > > > > > > Are you talking about the reuse of the request object by an adversary > > > trying to act as an honest client? > > > Even if it happens, the malicious client does not have the proper > > > client credential so it cannot redeem the code it obtained with the > > > token. It is no different than RFC6749 code grant. Protocols that > > > extend it, such as OpenID Connect, have introduced nonce to prevent > > > the reuse and used JAR (it is called request object there) to further > > > protect tampering and achieve client authentication even in the front > > > channel. > > > > > > > recommendation that keys be separated by intended uses, rather than > > > > limiting particular fields in an ad-hoc manner. > > > > > > Could you kindly elaborate on the "ad-hoc manner" part so that I can > > > understand it more fully? > > > > 10.8, Cross-JWT Confusion discusses avoiding signing certain fields, rath= er than suggesting good key usage as a solution. > > > > Mike> I propose to add this new paragraph at the end of Section 10.8 to i= mplement your suggestion: > > "Finally, another way to prevent cross-JWT confusion is to use a key = management regime in which keys used to sign Request Objects are identifiab= ly distinct from those used for other purposes. Then, if an adversary atte= mpts to repurpose the Request Object in another context, a key mismatch wil= l occur, thwarting the attack." > > > > > > Then we have section 11. What section 11 introduces is an entire new > > > > dramatis personae, the Trust Framework Provider, with no prior > > > > discussion of what it is or a reference to where it is defined and a > > > > good number of statements about how it works that aren't really clea= r what they mean from the document to me. > > > > > > Trust Framework Provider first appears in 5.2.1. > > > At the time of writing the related text, it was a pretty well-known > > > concept. In the United State, it was part of its National Strategy > > > (NSTIC) and internationally, it was even taken up at WEF Davos > > > meeting. It is quite surprising that such a mainstream concept faded > > > into obscurity so quickly. The reason for introducing it was to a) > > > justify request_uri as some WG members wanted it to be removed, b) > > > justify that requst_uri to be served from a different domain. Now that > > > people appreciate it, e.g., it can be seen from PAR, the justification > > > for a) probably is no longer required. A full explanation for b) would > > > probably be a much longer text but I doubt if it belongs to this > > > document. I am fine with removing the reference to Trust framework > > > etc. as long as the capability to push the authorization request to a > > > place other than the client or the authorization server is not > > > removed. > > > > Let's remove the text then, but keep the capability. > > > > Mike> I propose to remove uses of the term "Trust Framework Provider" and= instead replace them by the more generic term "trusted third-party service= ". > > > > > > My biggest concern is that these issues are signs that the problem > > > > this draft is trying to solve and the mechanisms to solve it haven't > > > > been analyzed as thoroughly as they should have been. Without that > > > > sort of thorough analysis it's not certain that the mechanisms > > > > actually solve the problem and it's not clear what the > > > > recommendations to implementers have to be to preserve those properti= es. > > > > > > OAuth JAR, as the name "The OAuth 2.0 Authorization Framework: JWT > > > Secured Authorization Request (JAR)" suggests, is a framework and not > > > a house itself. One such example is FAPI [1] which was formally > > > verified [2]. > > > > "It's possible to use this draft security" I don't think should be enough= anymore. Rather it should be impossible to use insecurely. > > > > Mike> The draft describes how to use the mechanism securely. Yes, if por= tions of the draft (and those it depends upon) are not followed, insecure u= sage can result. That's true of any security draft. If there are addition= al specific requirements and/or recommendations needed, we'd be glad to add= them. If so, please identify them. (Indeed, we're already doing so in re= sponse to your existing specific feedback.) > > > > Mike> As for past JWT problems, the JWT BCP [RFC 8725] was written at the= request of the IESG to identify and mitigate them - especially in light of= JWTs being used for additional use cases, such as STIR secured telephony a= nd securing first-responder services. If you believe that additional gener= ic JWT issues should be discussed and addressed, we could always revise thi= s BCP. But doing so is beyond the scope of this RFC. > > > > > [1] > > > https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md > > > [2] https://arxiv.org/abs/1901.11520 > > > > > > > > > > > Obviously this draft has had a long and tortured history with > > > > multiple reviews, and what I'm suggesting needs to happen is a lot > > > > of work. But it's essential in any security protocol to do this > > > > analysis and be clear about what is, and what is not, protected by th= e protocol. > > > > > > OAuth JAR is nothing but just another binding to OAuth 2.0. Where > > > RFC6749 binds it to form encoding, it provides two additional bindings: > > > 1) binding to JWT, and > > > 2) binding to the pushed authorization request that is referenced b= y a URI. > > > It is this simple. As such, it would also inherit some of the > > > shortcomings in RFC6749. However, it is not this document to address > > > them. It should be done by other documents so that the result can be > > > encoded using the mechanisms provided in this document. > > > > This is not a simple matter. JWT has a long and twisted history with some= pervasive errors in common libraries, and is a fairly large standard. OAut= h 2.0 is also large. Ensuring that the mapping has the right properties is = going to be a mess. If the encoding does not respect the semantics we have = a serious security issue. If implementors assume the encoding provides prop= erties it does not, we again have a security issue. > > > > Mike> See my previous comments on past JWT implementation errors and the = writing of the JWT BCP [RFC 8725] to address these. > > > > > It is quite surprising that this fact is not getting appreciated and > > > is taking such a long time to complete. > > > Maybe I should delete all the explanation text and leave it with just > > > the core text. Explanation and justification text for defining > > > additional bindings probably are just distractions now as it is now > > > appreciated and used all over the world unlike when the project was > > > started. > > > > Mike> I would propose that we make only necessary changes to the draft at= this point. Let's finish this long-overdue specification! > > > > > > > > > > > > > Sincerely, > > > > Watson Ladd > > > > > > > > > > Thanks again for your detailed comments. > > > > > > Best wishes, > > > > > > -- > > > Nat Sakimura > > > NAT.Consulting LLC > > > > Mike> I now plan to create edits incorporating the proposed resolutions a= bove for review. > > > > Best wishes, > > -- Mike > > > > -- > > Astra mortemque praestare gradatim --=20 Astra mortemque praestare gradatim From nobody Wed Mar 17 21:40:43 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277A73A1DC4 for ; Wed, 17 Mar 2021 21:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDOYVlvmJDCv for ; Wed, 17 Mar 2021 21:40:39 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719D43A1DBF for ; Wed, 17 Mar 2021 21:40:39 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12I4eVoY007909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 00:40:36 -0400 Date: Wed, 17 Mar 2021 21:40:31 -0700 From: Benjamin Kaduk To: Charlie Kaufman Cc: "secdir@ietf.org" Message-ID: <20210318044031.GZ79563@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-ace-oauth-params-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 04:40:41 -0000 Hi Charlie, Thanks for the re-review; I'm glad that things lined up so that you could revisit the document (and that it looks to be in good shape to you). -Ben On Sat, Mar 13, 2021 at 04:29:27AM +0000, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This is a re-review; I reviewed version -06 in December 2019. > > In the intervening versions, the specification was simplified somewhat at the cost of removing support for key rollover of asymmetric keys in certain scenarios. A section was added "Requirements when using asymmetric keys" which contained what I considered a confusing reference to DTLS, but it does not make the spec ambiguous. > > This is a small extension to [I-D.ietf-ace-oauth-authz] and is separate from that document for technical reasons that I don't understand but which seem plausible. > > The security considerations section says simply (and I agree): > > This document is an extension to [I-D.ietf-ace-oauth-authz]. All security considerations from that document apply here as well. > > All of the nits mentioned in the previous review have been corrected. > From nobody Thu Mar 18 10:58:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD9E3A30B2; Thu, 18 Mar 2021 10:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX3zKKXDMLWa; Thu, 18 Mar 2021 10:57:48 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F1A3A30BC; Thu, 18 Mar 2021 10:57:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZHnagO+7S1awbnGWvPYGIQ5bdrDBZ9pQGVPXJkauo652hHB5TmofkgQ3e9C0rAhd6Fp1gJuxLkdHVMVZJ+hHzo01idjPRScT4gzEfq1x20wdj6OPniUGfRRy+etiRrOGwUROTmZO1Req4+COIetH6Rjt+9gea101CiEpy503Rq6FJGDjECu3WUlbWhAFD3PQMm96s7Prz66fFwSrxU9Vf2kSUogk0SjoX1htrsQLXk+RpV9rFVSIh6MY+2GMJAKC8aCfJRcxn8Zy1wk0u/0/9UV37KCFnZipJYn/kC27X3HxxmI4WULlvp5FBv4ztgs3SPzX4sO5UBt4tJXBI8sncA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WaIyc6hEd50bcxJLZOr7M6J5mez6vRDG8Ac1oVnQzJw=; b=IAobzLXYPrOoH3qeSp60n5QLYLxPrwqAzx+LWoozqX4awb2v5YtzrZN4nUDqzwWaEw1RWEv9N5DMpybDTt6rMBRTn4uNa5XB7PY12cO39HLyoMfRUvqUmBrIESKQtuxPxqcPIX0jj8HwgOfxgZo1S8rK1it/D3nVyfsHfeLuQtub4YU0q2LxdXFziqbu3QSf1XJqhSWijQkfkMl1KBqw1sSJn1FD+9Q3Ac18RbpBYPeMNNEuVhip/Y0R9+QTKDBg+qnbMP5qLr9pTslfcEsJFfS/N1ZOTE/DmqKBkLzokz5I8kEQHNE+M/ps+fa97v/kFf+iMIRgNLJ5sQFHbnEfKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WaIyc6hEd50bcxJLZOr7M6J5mez6vRDG8Ac1oVnQzJw=; b=RDhBUdTwPLR5HNX3ZciWy0YWCAWPFofFO3SsV+n1uMWF43nkdqopyvqNM17qC1UtaaN0oQpZmk8R95bzOjTg8t+HgQjxMQsf/7a21hBYjBm83lhFVJppw7IwTPWcUpLp9LmgfCmHu56k/8jydwQ40OoQtrkdmeNM68jblDkJYHg= Received: from SN6PR00MB0429.namprd00.prod.outlook.com (2603:10b6:805:d::12) by SA2PR00MB1004.namprd00.prod.outlook.com (2603:10b6:806:11f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4000.0; Thu, 18 Mar 2021 17:57:45 +0000 Received: from SN6PR00MB0429.namprd00.prod.outlook.com ([fe80::e85c:3b3a:966b:a996]) by SN6PR00MB0429.namprd00.prod.outlook.com ([fe80::e85c:3b3a:966b:a996%7]) with mapi id 15.20.3997.000; Thu, 18 Mar 2021 17:57:44 +0000 From: Mike Jones To: "watsonbladd@gmail.com" CC: nat , "rdd@cert.org" , "secdir@ietf.org" , "oauth@ietf.org" , "last-call@ietf.org" , "draft-ietf-oauth-jwsreq.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-oauth-jwsreq-30 Thread-Index: AdccIC8wGrljqzKhTUG8OW/2jvKZTQ== Date: Thu, 18 Mar 2021 17:57:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-03-18T17:56:48Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a0cf4b95-6ff3-4052-ba14-ea47d6d64b50; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2607:fb90:9ebc:fede:c40e:ba95:74a7:bfec] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a3b75da3-4a4f-4e90-f495-08d8ea375563 x-ms-traffictypediagnostic: SA2PR00MB1004: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Rx8qcDzw5c3wVUjHwwpAveQ8l6lVitpCXPYaC9+zWAsdQ9UOLdMOmuAVReT3+dYD9Xca+AXA8PEkvhrHJSTiLocJqOwSKTCIbj+lSbc1CP/12SKIH7dyRQDRaEXeI4lRy+rXQlzoBM9a224zVMiwz/6JnIOzCgCzJCsY83G/+SNxc/HQ4gwdYDKkcxcvFUqiXxuenCoca4/lByC4MMrTT664UvKHDvCxCOoP7K+F+1cme1IgfMS7aCo0HN1xcFbqI8Z/ULQZ5bYSbHkFTzO56sgP0TPQg4HSTenZ2dsZsn/JvZnLfwHZm0+crfrpOrb7YjR/i/5RqQ38RBMfXCl/nNkvW454cC2GhDjf6s6KP7BPWPpYpbml6F/nLvAmBIhvShnXlwvUmHoBCGIX1eFeipzZ6qBFn6S/qBrl6ILPrPhEGjRBAH0e7CmUT3nvJh5jsse9yeDHrIzF95KZUdFtWNVXNrDLe4Jic/+QZFD1Dkf28a1piRLdOLPLL1EEWgE8cGrlsrXzox8h15JC+1f9QVl5NDDpbywRQbSI0zIgZ8Du+ou+BKRwhM3NTr2azu8tGamhjl9vpfQsXAsy2levwn7VEQvJ3QKiT7JXrS+eLGb8VTK0n28tiDj+9pl8a+n/n+65AQ0E2j/D/UoQLAnPqXPiW7farZaI9vTh+KOSKBHzeGqzouY0d+y3+S4qwP2i50XkqZFYZk1ZKcGcqMVbZv9L98DhWC0cwLAUNV0mNyM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR00MB0429.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(366004)(136003)(39860400002)(9686003)(55016002)(2906002)(38100700001)(71200400001)(8676002)(6916009)(4326008)(83380400001)(82950400001)(186003)(76116006)(82960400001)(66946007)(66476007)(66556008)(966005)(64756008)(66446008)(5660300002)(52536014)(33656002)(54906003)(53546011)(8936002)(6506007)(316002)(10290500003)(86362001)(30864003)(8990500004)(7696005)(478600001)(66574015)(546114003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?MXo4MEFBRFEzMHFoQThWSTBGK3RnR1NxOUlveFcvOFlhdWtoRGJhVzVVUnZu?= =?utf-8?B?Vi9waXNnMkU4bWpva295UTkrTHM5OCt6eWZ2T3FoR1RjYmdzVERzTDQzMUVD?= =?utf-8?B?MGlYYXVhODdETkt6ZEU5UTVOanU0V295VEsvQ1BuK0paUFFsNFNhNFk5VGFC?= =?utf-8?B?ejBtb1pJU3lHSW5Wa2F1eldPM3RrUzFxVndrSU96cDEya0pwUGU5WXRhL0hx?= =?utf-8?B?RU1Zb3ZPbnd6c2VPL2dobGhNQnNHTWdHMzczaU12cjcrRVl2V0p6SXk1cjEw?= =?utf-8?B?bExJNXo4dmdLdUtWbXJNTk51bGdhZFVHYmxuWHBPZmdXNnBXRlNwc0ZLQVda?= =?utf-8?B?T2xwUWx2Ykd0TFY4dlBDS3NuYloyR1hvb21YMGx0NzJFOEpxK3ZjWVVnRnc0?= =?utf-8?B?SUtZVlpYREZKNTRJWlBJUk5maDREK0d1cTE2REkxQ0lCdHFnQUxrRmhYRjM1?= =?utf-8?B?SUZPL3Q1cGtNUGVESW1VSG9XYWJ0WFBGYTFCalRIOTZqdVhlQ010MjlMUmVD?= =?utf-8?B?aitlYnV5Rm5PelpsUllSZDJYZjFmYmtTM08rSjJtOFlxVUZkd28yUnEwZUdp?= =?utf-8?B?RjJwajhoYURDMHRaMEpCSHUvYk1adEZGRVpqMmNtZ1NodlV1TXA2QVVPelRS?= =?utf-8?B?TTM5NmczdGhxYjJOc1ZDMkxBR1NsN1NHcE9ZcDdLaTJxWTcweDBnWjlzanV3?= =?utf-8?B?bWh2TXdTZkx6TWtHOEY5KzhlN3pCSmRWRWdZYisyaEZFczNhY1h6SUd1bkU1?= =?utf-8?B?QmZ6QUxDQkdRTW5ma3NibW5ocG5JMWU0Rkg4a2dEbE9RMVlTdGNMN1NRU3dD?= =?utf-8?B?SG1tUExRK3AvK2w3dGNRMTZiblRFQkpCcXRUajlUeEhhQThMQTkrRlA1MHQw?= =?utf-8?B?eU1oOXhKeGZOL0xISDRDVDAvTHdkK1p0MXlCTFN3WTJXTUFHOW1hRm5BQVE1?= =?utf-8?B?VmtHM3l0dmhIK2V0ai9PNGtudDV0YnRPd0pyaTlmdlJGME96ck5JZkpPL2dH?= =?utf-8?B?M0lha0g3KzM1NGd3Vzl4ZUQ4VHZuNmNkdE4rSjk4V2lMWWlxd25aa1ViZlZw?= =?utf-8?B?RnNYYmlTYml5NU1ycmhOS0EyYWE2d1IyWm9aSEtkSEN6MktYMTBTSXBIdEFa?= =?utf-8?B?cG83UWN2UHdteVdoUnpWU3lXZit6NDdSM2ExWjJCbXAzbzM0Q2ZmSkJhMVNZ?= =?utf-8?B?OW5weWFHVjRCblIySGxmZEdsNDdjcnh4MnlMb3d0bU00YUZNTzNPaTRxMlFu?= =?utf-8?B?YTFiQUdqVnRONXJpbytIUnJXNFBwTVJwRlhwUTV5Kys3UWp2dDloN3ZQdEdx?= =?utf-8?B?WkdNK00xaGkxTUFvM0VUVWFNUlBtbGxTbDFrN3lWRUptb25IbWxYUnhJbmp1?= =?utf-8?B?eS9WdW8yN3NVMVg2ODVBZDVKZ0pITGUyK2tNY0QvZk5haWRkVDJNc09uZzBM?= =?utf-8?B?a3J2bjNIVko4OXlYdldzb1dTWnVscVNTS0tnV1Nncm9FZCswVS9PdVFaVVli?= =?utf-8?B?Yit5aTIxNHFXQzZ2aEZSYzhaUTBDdC9pMUNrc2dnSUx4d1k1OWFIa0lCd3Z2?= =?utf-8?B?azlRNEIveTZDU0Z4ckJ1WklNOWtnSzhPNUQ3SjBrMlhkWFZhalBTdFRuZm8w?= =?utf-8?B?aEc3RkkxZ0RBZWQyQ3NVRjZBUDQzVGlUN1BOR3Y3Z2pVdXdMeWNZSk8vSFVm?= =?utf-8?B?QWt0OUYvZWVXdlM1alFuMUE3WFduVDBLam56WlM0Y2JsWThNSHZmUmUzVE1M?= =?utf-8?B?UnJuZW1xQ2ZXTkE0U3ZFbExvTVlFbG82NFBrZ1ZsQzBtZVRTMktRcTdNZFFE?= =?utf-8?B?ZjNRVEg2c2JUWnJ0c2daS2lUaHNPMTdPNWNDcWl3MWJqY0o2WTYybU5aVk41?= =?utf-8?Q?iA8ZFmPhWfXhF?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR00MB0429.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3b75da3-4a4f-4e90-f495-08d8ea375563 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2021 17:57:44.2903 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zjIH1b77nceBN4PYRitKBsSbFIkgicQMhO7WU1YoTu4Q8+FnXcfmES7jp5vABn2W1UsgQgw5gufPXh45Z2XyZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR00MB1004 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-oauth-jwsreq-30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:57:51 -0000 VGhhbmtzLCBXYXRzb24uICBXZSd2ZSBwdWJsaXNoZWQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMxIHdpdGggdGhlc2UgY2hhbmdlcy4NCg0KCQkJ CS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdhdHNvbiBMYWRk IDx3YXRzb25ibGFkZEBnbWFpbC5jb20+IA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxNywgMjAy MSA2OjIxIFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0K Q2M6IG5hdCA8bmF0QG5hdC5jb25zdWx0aW5nPjsgcmRkQGNlcnQub3JnOyBzZWNkaXJAaWV0Zi5v cmc7IG9hdXRoQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgt andzcmVxLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMwDQoNCk9uIFdlZCwgTWFyIDE3LCAyMDIxIGF0 IDI6NDcgUE0gTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPiB3cm90ZToN Cj4NCj4gSeKAmXZlIGNyZWF0ZWQgdGhlIHB1bGwgcmVxdWVzdCBodHRwczovL2JpdGJ1Y2tldC5v cmcvTmF0L29hdXRoLWp3c3JlcS9wdWxsLXJlcXVlc3RzLzE0LyBhcHBseWluZyB0aGUgcHJvcG9z ZWQgY2hhbmdlcyBiZWxvdyB0byB0aGUgZHJhZnQuICBVbmxlc3Mgc3VnZ2VzdGlvbnMgZm9yIGNo YW5nZXMgYXJlIHJlY2VpdmVkLCB3ZeKAmWxsIG1lcmdlIHRoaXMgYW5kIHB1Ymxpc2ggLTMxIHRv IGFkZHJlc3MgV2F0c29u4oCZcyBjb21tZW50cy4NCg0KSSB0aGluayB0aGVzZSBjaGFuZ2VzIGFz IGFkZHJlcyBteSBjb25jZXJucy4gSSB3aXNoIHRoYXQgd2UgY291bGQgZnVydGhlciByZXN0cmlj dCB0byBhIGtub3duLWdvb2QsIGVhc2lseSBpbXBsZW1lbnRhYmxlIHByb2ZpbGUsIGJ1dCB3ZSBj YW4ndCBnZXQgZXZlcnl0aGluZyB3ZSB3YW50Lg0KDQpTaW5jZXJlbHksDQpXYXRzb24gTGFkZA0K DQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQo+DQo+DQo+DQo+IEZyb206IE1pa2UgSm9uZXMNCj4gU2VudDog RnJpZGF5LCBGZWJydWFyeSAyNiwgMjAyMSAxMjo1NSBQTQ0KPiBUbzogJ1dhdHNvbiBMYWRkJyA8 d2F0c29uYmxhZGRAZ21haWwuY29tPjsgTmF0IFNha2ltdXJhIA0KPiA8bmF0QG5hdC5jb25zdWx0 aW5nPjsgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPg0KPiBDYzogc2VjZGlyIDxzZWNkaXJA aWV0Zi5vcmc+OyBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz47IA0KPiBsYXN0LWNhbGxA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLmFsbEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEt MzANCj4NCj4NCj4NCj4gVGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldywgV2F0c29uLiAgTXkg cmVwbGllcyB0byB5b3VyIGNvbW1lbnRzIGJlbG93IGFyZSBwcmVmaXhlZCBieSAiTWlrZT4iLg0K Pg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXYXRzb24gTGFk ZCA8d2F0c29uYmxhZGRAZ21haWwuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNSwg MjAyMCA5OjAxIFBNDQo+IFRvOiBOYXQgU2FraW11cmEgPG5hdEBuYXQuY29uc3VsdGluZz4NCj4g Q2M6IHNlY2RpciA8c2VjZGlyQGlldGYub3JnPjsgSUVURiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5v cmc+OyANCj4gbGFzdC1jYWxsQGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS5hbGxA aWV0Zi5vcmcNCj4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogU2VjZGlyIGxhc3QgY2FsbCByZXZp ZXcgb2YgDQo+IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMwDQo+DQo+DQo+DQo+IE9uIFNhdCwg T2N0IDMxLCAyMDIwIGF0IDY6MTMgQU0gTmF0IFNha2ltdXJhIDxuYXRAbmF0LmNvbnN1bHRpbmc+ IHdyb3RlOg0KPg0KPiA+DQo+DQo+ID4gSGkgV2F0c29uLA0KPg0KPiA+DQo+DQo+ID4gVGhhbmtz IHZlcnkgbXVjaCBmb3IgdGhlIHJldmlldy4gSSB0aG91Z2h0IEkgaGF2ZSBzZW50IG15IHJlc3Bv bnNlDQo+DQo+ID4gZWFybGllciwgd2hpY2ggSSBhY3R1YWxseSBkaWQgbm90LiBJdCB3YXMgc2l0 dGluZyBpbiBteSBkcmFmdCBib3guIEkNCj4NCj4gPiBhcG9sb2dpemUgZm9yIGl0Lg0KPg0KPg0K Pg0KPiBNeSBhcG9sb2dpZXMgZm9yIG1pc3NpbmcgaXQgaW4gbXkgaW5ib3ggZm9yIGEgbnVtYmVy IG9mIG1vbnRocy4NCj4NCj4gPg0KPg0KPiA+IE15IHJlc3BvbnNlcyBpbmxpbmU6DQo+DQo+ID4N Cj4NCj4gPiBPbiBTYXQsIFNlcCAyNiwgMjAyMCBhdCA5OjQ2IEFNIFdhdHNvbiBMYWRkIHZpYSBE YXRhdHJhY2tlcg0KPg0KPiA+IDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCj4NCj4gPiA+DQo+ DQo+ID4gPiBSZXZpZXdlcjogV2F0c29uIExhZGQNCj4NCj4gPiA+IFJldmlldyByZXN1bHQ6IFNl cmlvdXMgSXNzdWVzDQo+DQo+ID4gPg0KPg0KPiA+ID4gSSBnZW5lcmF0ZWQgdGhpcyByZXZpZXcg b2YgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eQ0KPg0KPiA+ID4gZGlyZWN0 b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5n DQo+DQo+ID4gPiBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdy aXR0ZW4gd2l0aCB0aGUgDQo+ID4gPiBpbnRlbnQNCj4NCj4gPiA+IG9mIGltcHJvdmluZyBzZWN1 cml0eSByZXF1aXJlbWVudHMgYW5kIGNvbnNpZGVyYXRpb25zIGluIElFVEYNCj4NCj4gPiA+IGRy YWZ0cy4gIENvbW1lbnRzIG5vdCBhZGRyZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBiZSBpbmNsdWRl ZCBpbiBBRA0KPg0KPiA+ID4gcmV2aWV3cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiAgRG9jdW1l bnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4NCj4gPiA+DQo+DQo+ID4gPiBU d28gbWlub3IgaXNzdWVzOiBPbiBwYWdlIDQsICJUaGlzIG9mZmVycyBhbiBhZGRpdGlvbmFsIGRl Z3JlZSBvZg0KPg0KPiA+ID4gcHJpdmFjeSBwcm90ZWN0aW9uLiIgc2hvdWxkIGJlIHJld29yZGVk LiBJIGRvbid0IHRoaW5rIGl0IG1ha2VzDQo+DQo+ID4gPiBzZW5zZSBpbiBjb250ZXh0LCB3aGVy ZSBhdXRoZW50aWNpdHkgd2FzIGRpc2N1c3NlZC4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4gSW4g dGhlIGNvdXJzZSBvZiB0aGUgZWRpdCwgZXhwbGFuYXRpb24gYWJvdXQgdHdvIGRpc3RpbmN0IHBy aXZhY3kNCj4NCj4gPiBiZW5lZml0cyB3YXMgY29sbGF0ZWQgaW4gb25lIHNlbnRlbmNlIGFuZCBo YXMgYmVjb21lIHZlcnkgZGlmZmljdWx0IA0KPiA+IHRvDQo+DQo+ID4gcGFyc2UuDQo+DQo+ID4N Cj4NCj4gPiBXaGF0IGl0IGlzIHRyeWluZyB0byBleHByZXNzIGFzIHByaXZhY3kgYmVuZWZpdHMg YXJlIHRoZSBmb2xsb3dpbmcuDQo+DQo+ID4NCj4NCj4gPiAxKSBUaGUgYXV0aG9yaXphdGlvbiBy ZXF1ZXN0IGNvbnRlbnQgaXMgc2VudCB0byB0aGUgQVMgaW4gdGhlDQo+DQo+ID4gYmFja2NoYW5u ZWwgc28gaXQgd2lsbCBub3QgYmUgZXhwb3NlZCB0aHJvdWdoIHRoZSBicm93c2VyIHRvIHRoZSAN Cj4gPiBleWVzDQo+DQo+ID4gb2YgYW4gYWN0aXZlIG9yIHBhc3NpdmUgb3V0c2lkZXIgb2JzZXJ2 aW5nIHdoYXQgaXMgZ29pbmcgb24gaW4gdGhlDQo+DQo+ID4gYnJvd3Nlci4gIEluIHRoZSBSRkM2 NzQ5IGZyYW1ld29yayBjYXNlLCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0DQo+DQo+ID4gZ29l cyB0aHJvdWdoIHRoZSBicm93c2VyIHJlZGlyZWN0IGFuZCBpdCBjb3VsZCBsZWFrIHRvIHRoZSBh ZHZlcnNhcnkNCj4NCj4gPiB2aWEgV1BBRC9QQUMgQXR0YWNrLCByZWZlcnJlciwgYnJvd3NlciBo aXN0b3J5LCBldGMuIEFsc28sIGlmIHRoZQ0KPg0KPiA+IGJyb3dzZXIgd2FzIGluZmVjdGVkIGJ5 IGFuIGFkdmVyc2FyeSBjb250cm9sbGVkIG1hbHdhcmUsIHRoZSBjb250ZW50DQo+DQo+ID4gY2Fu IGJlIHNuaWZmZWQgYnkgdGhlIGFkdmVyc2FyeS4gSW4gdGhlIGNhc2Ugb2YgSkFSLCBpdCBkb2Vz IG5vdA0KPg0KPiA+IGhhcHBlbi4gVGhpcyBpcyBvbmUgcHJpdmFjeSBiZW5lZml0IGl0IGlzIHRy eWluZyB0byBleHBsYWluLg0KPg0KPiA+DQo+DQo+ID4gMikgVGhlIGxvY2F0aW9uIHRoYXQgdGhl IGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBnZXR0aW5nIHB1c2hlZCB0bw0KPg0KPiA+IGRvZXMg bm90IGhhdmUgdG8gYmUgdGhlIEFTLiBBIHRydXN0ZWQgdGhpcmQgcGFydHkgdGhhdCBleGFtaW5l cyB0aGUNCj4NCj4gPiBjb250ZW50IGZvciB0aGUgY29uZm9ybWFuY2UgdG8gdGhlIGNvbGxlY3Rp b24gbWluaW1pemF0aW9uIHByaW5jaXBsZQ0KPg0KPiA+IG1heSBhY3QgYXMgdGhlIHBhcnR5IHRo YXQgYWNjZXB0cyB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGFuZCANCj4gPiBpc3N1ZXMNCj4N Cj4gPiB0aGUgcmVxdWVzdF91cmkuIEFTIGNhbiB0aGVuIGp1c3QgZXZhbHVhdGUgdGhlIGRvbWFp biBwYXJ0IG9mDQo+DQo+ID4gcmVxdWVzdF91cmkgdG8gZXZhbHVhdGUgdGhhdCB0aGUgYXV0aG9y aXphdGlvbiByZXF1ZXN0IGlzIGNvbmZvcm1hbnQNCj4NCj4gPiB0byB0aGlzIHByaW5jaXBsZS4g VGhpcyBpcyBhbm90aGVyIHByaXZhY3kgYmVuZWZpdCBmcm9tIHRoZSBwb2ludCBvZg0KPg0KPiA+ IHZpZXcgb2YgdGhlIGluZGl2aWR1YWwgdXNlci4NCj4NCj4NCj4NCj4gSSdtIGZpbmUgd2l0aCBh bnkgZml4IHRvIHRoZSBzZW50ZW5jZSB0aGF0IG1ha2VzIHNlbnNlLiBEb24ndCB0aGluayB3ZSBu ZWVkIHRvIGluc2VydCB0aGUgYWJvdmUgYnV0IEkgdmVyeSBtdWNoIGFwcHJlY2lhdGUgdGhlIGV4 cGxhbmF0aW9uLg0KPg0KPg0KPg0KPiBNaWtlPiBHaXZlbiB0aGF0IGl0cyBtZWFuaW5nIGlzIGZh aXJseSBpbnNjcnV0YWJsZSwgYW5kIHRoYXQgdGhlIHR3byBiZW5lZml0cyBkZXNjcmliZWQgYnkg TmF0IGFib3ZlIGFyZSBwYXJ0aWFsbHkgcmVsYXRlZCB0byBwYXJhZ3JhcGhzIG90aGVyIHRoYW4g dGhlIG9uZSB3aXRoIHRoZSBwcml2YWN5IHN0YXRlbWVudCwgSSBwcm9wb3NlIHRoYXQgd2Ugc2lt cGx5IGRlbGV0ZSB0aGUgc2VudGVuY2UgIlRoaXMgb2ZmZXJzIGFuIGFkZGl0aW9uYWwgZGVncmVl IG9mIHByaXZhY3kgcHJvdGVjdGlvbi4iIGZyb20gdGhpcyBwYXJhZ3JhcGguDQo+DQo+DQo+DQo+ ID4gPiBJdCB0b29rIG1lIGEgd2hpbGUgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBieSByZWZlcmVu Y2UgbWV0aG9kIGlzOg0KPg0KPiA+ID4gbWF5YmUgdGhlIGludHJvIHNob3VsZCBzYXkgdmlhIFVS TCBpbnN0ZWFkIG9mIGJ5IHJlZmVyZW5jZS4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4gcmVxdWVz dF91cmkgY2FuIGJlIFVSTCBvciBhIGhhbmRsZSBzdWNoIGFzIFVSTi4gVGhhdCBpcyB3aHkgdGhl ICJieQ0KPg0KPiA+IHJlZmVyZW5jZSIgd29yZCBpcyBiZWluZyB1c2VkLCBwZXIgdGhlIHN1Z2dl c3Rpb24gb2YgdGhlIFdHLg0KPg0KPg0KPg0KPiBJJ20gZmluZSB3aXRoIHRoYXQsIGp1c3Qgbm90 aW5nIG15IGNvbmZ1c2lvbi4NCj4NCj4NCj4NCj4gTWlrZT4gVW5kZXJzdG9vZC4gIEkgbG9va2Vk IGF0IHdheXMgdG8gcG9zc2libHkgbW92ZSB0aGUgImJ5IHJlZmVyZW5jZSIgdGV4dCB0aGF0IGZv bGxvd3MgaW4gYSBmZXcgcGFyYWdyYXBocyBlYXJsaWVyIHRvIHBvc3NpYmx5IG1ha2UgdGhpcyBj bGVhcmVyLCBidXQgaXQgd291bGQgbWVzcyB1cCB0aGUgbG9naWNhbCBmbG93IG9mIHRoZSBJbnRy b2R1Y3Rpb24uICBVbmxlc3MgeW91IGhhdmUgYSBiZXR0ZXIgc3VnZ2VzdGlvbiwgSSBwcm9wb3Nl IHRoYXQgd2UgbGVhdmUgdGhpcyBhcy1pcy4NCj4NCj4NCj4NCj4gPiA+IEFuZCBub3cgZm9yIHRo ZSB0aG9ybnkgaXNzdWVzIHdpdGggdGhpcyBkcmFmdC4gU2lnbmF0dXJlcyBhbmQNCj4NCj4gPiA+ IGVuY3J5cHRpb24gYXJlIGRpZmZlcmVudC4gQW5kIGVuY3J5cHRpbmcgYSBzaWduZWQgYmxvYiBk b2Vzbid0IG1lYW4gdGhlIHNpZ25lciBlbmNyeXB0ZWQgaXQuDQo+DQo+ID4gPiBUaGVuIHRoZXJl IGFyZSBhIHBsZXRob3JhIG9mIG1ldGhvZHMgc3BlY2lmaWVkIGluIHRoZSBkcmFmdCAgdG8NCj4N Cj4gPiA+IGF1dGhlbnRpY2F0ZSB0aGUgYmxvYiwgd2hpY2ggd2lsbCBnaXZlIGRpZmZlcmVudCBy ZXN1bHRzIGluDQo+DQo+ID4gPiBtYWxpY2lvdXNseSBjb25zdHJ1Y3RlZCBleGFtcGxlcy4gVGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQo+DQo+ID4gPiBzZWN0aW9uIHNob3VsZCBkaXNjdXNz IHdoYXQgdGhlIGVuY3J5cHRlZCB2cyBzaWduZWQgY2hvaWNlcyBnaXZlIA0KPiA+ID4gaW4NCj4N Cj4gPiA+IHRoZSB3YXkgb2Ygc2VjdXJpdHksIGFuZCBpdCBkb2Vzbid0LiBUaGlzIG1ha2VzIG1l IHdvcnJ5Lg0KPg0KPiA+DQo+DQo+ID4gV2UgZG9u4oCZdCBleHBlY3QgdGhlIGVuY3J5cHRpb24g dG8gZW5zdXJlIGF1dGhlbnRpY2l0eSwgdGhhdOKAmXMgd2hhdCANCj4gPiB0aGUNCj4NCj4gPiBz aWduYXR1cmVzIGFyZSB1c2VkIGZvci4NCj4NCj4NCj4NCj4gVGhpcyBuZWVkcyB0byBiZSB2ZXJ5 IGNsZWFybHkgc3BlbGxlZCBvdXQgaW4gdGhlIHRleHQuIExvdHMgb2YgcGVvcGxlIHdpbGwgbm90 IHVuZGVyc3RhbmQgdGhpcy4gVGhlIHdvcmRpbmcgb2Ygc2VjdGlvbiAxMC4yIGlzIGF0IGJlc3Qg YW1iaXZhbGVudCwgd2l0aCBtdWx0aXBsZSBhbHRlcm5hdGl2ZXMgcHJlc2VudGVkIGFzIGFjY2Vw dGFibGUuDQo+DQo+DQo+DQo+IE1pa2U+IEFmdGVyIHRoZSBzZW50ZW5jZSBhdCAxMC4yIChiKSBh Ym91dCBzeW1tZXRyaWMgZW5jcnlwdGlvbiwgSSBwcm9wb3NlIHRoYXQgd2UgYWRkIHRoZSBmb2xs b3dpbmcgc2VudGVuY2UgdG8gZW1waGFzaXplIHRoZSBwb2ludCB5b3UncmUgcmFpc2luZzogICJO b3RlIGhvd2V2ZXIsIHRoYXQgaWYgcHVibGljIGtleSBlbmNyeXB0aW9uIGlzIHVzZWQsIG5vIHNv dXJjZSBhdXRoZW50aWNhdGlvbiBpcyBlbmFibGVkIGJ5IHRoZSBlbmNyeXB0aW9uLCBhcyBhbnkg cGFydHkgY2FuIGVuY3J5cHQgY29udGVudCB0byB0aGUgcHVibGljIGtleS4iDQo+DQo+DQo+DQo+ IDxjaG9wPg0KPg0KPiA+DQo+DQo+ID4gSSBkaWRuJ3QgcXVpdGUgZ2V0IHdoYXQgaXMgbWVhbnQg YnkgInBsZXRob3JhIG9mIG1ldGhvZHMgc3BlY2lmaWVkIA0KPiA+IGluDQo+DQo+ID4gdGhlIGRy YWZ0IHRvIGF1dGhlbnRpY2F0ZSB0aGUgYmxvYiAuLi4gIg0KPg0KPiA+IFRoZXJlIGlzIGEgYml0 IG9mIHRleHQgYWJvdXQgYXV0aGVudGljYXRpbmcgdGhlIHNvdXJjZSAoPWNsaWVudCkgYnV0DQo+ DQo+ID4gbm90IG11Y2ggb24gdGhlIGJsb2IgaXRzZWxmLg0KPg0KPiA+IFRoZSBkaXNjdXNzaW9u IGFyb3VuZCB0aGUgc2lnbmF0dXJlIGFuZC9vciBlbmNyeXB0aW9uIGlzIGNvdmVyZWQgaW4NCj4N Cj4gPiBSRkM3NTE5IChKV1QpLCB0aGUgZm9ybWF0IHRoYXQgdGhlIHJlcXVlc3Qgb2JqZWN0IGFz c3VtZXMuDQo+DQo+ID4gVGhpcyBpcyByZXF1aXJlZCByZWFkaW5nIHdoZW4gaW1wbGVtZW50aW5n IHRoaXMgc3BlYywgc28gV0cgdGhvdWdodCANCj4gPiBpdA0KPg0KPiA+IGlzIG5vdCB3b3J0aCBy ZXBlYXRpbmcgaGVyZS4NCj4NCj4gPiBBdHRhY2tzIGV0Yy4gb24gdGhlIHNpZ25hdHVyZSBhbmQg ZW5jcnlwdGlvbiBhcmUgY292ZXJlZCBpbiBSRkM3NTE1DQo+DQo+ID4gYW5kIFJGQzc1MTYgcmVz cGVjdGl2ZWx5Lg0KPg0KPg0KPg0KPiBXZWxsLCB0aGUgZHJhZnQgaGFwcGVucyB0byBpbmNsdWRl IHRoZSBmb2xsb3dpbmcgdGV4dDoNCj4NCj4gICAgIlRoZSBBdXRob3JpemF0aW9uIFNlcnZlciBN VVNUIHZhbGlkYXRlIHRoZSBzaWduYXR1cmUgb2YgdGhlIEpTT04gDQo+IFdlYg0KPg0KPiAgICBT aWduYXR1cmUgW1JGQzc1MTVdIHNpZ25lZCBSZXF1ZXN0IE9iamVjdC4gIFRoZSBzaWduYXR1cmUg TVVTVCBiZQ0KPg0KPiAgICB2YWxpZGF0ZWQgdXNpbmcgdGhlIGtleSBmb3IgdGhhdCAiY2xpZW50 X2lkIiBhbmQgdGhlIGFsZ29yaXRobQ0KPg0KPiAgICBzcGVjaWZpZWQgaW4gdGhlICJhbGciIEhl YWRlciBQYXJhbWV0ZXIuIg0KPg0KPg0KPg0KPiBTaG91bGRuJ3QgdGhlIGtleSBiZSBhc3NvY2lh dGVkIHdpdGggYSBzaW5nbGUgYWxnb3JpdGhtPyBIb3cgZG8gd2UgZW5zdXJlIHRoYXQgdGhlIGNv bW1vbiBhdHRhY2sgb2YgdGVsbGluZyB0aGUgc2VydmVyIHRvIHVzZSBobWFjIHRvIHZlcmlmeSB0 aGUgc2lnbmF0dXJlIGRvZXNuJ3Qgd29yayBoZXJlPw0KPg0KPg0KPg0KPiBNaWtlPiBHb29kIHBv aW50LiAgVGhpcyBhdHRhY2sgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xIG9mIFJGQyA4NzI1 IGFuZCBtaXRpZ2F0ZWQgYnkgdGhlIHByYWN0aWNlcyBpbiBTZWN0aW9ucyAzLjEgYW5kIDMuMiBv ZiB0aGUgc2FtZS4gIEkgcHJvcG9zZSB0aGF0IHdlIHJlcGxhY2UgdGhlIHNlbnRlbmNlOg0KPg0K PiAgICAgIlRoZSBzaWduYXR1cmUgTVVTVCBiZSB2YWxpZGF0ZWQgdXNpbmcgdGhlIGtleSBmb3Ig dGhhdCAiY2xpZW50X2lkIiBhbmQgdGhlIGFsZ29yaXRobSBzcGVjaWZpZWQgaW4gdGhlICJhbGci IEhlYWRlciBQYXJhbWV0ZXIuIg0KPg0KPiB3aXRoOg0KPg0KPiAgICAgIlRoZSBzaWduYXR1cmUg TVVTVCBiZSB2YWxpZGF0ZWQgdXNpbmcgYSBrZXkgYXNzb2NpYXRlZCB3aXRoIHRoZSBjbGllbnQg YW5kIHRoZSBhbGdvcml0aG0gc3BlY2lmaWVkIGluIHRoZSAiYWxnIiBIZWFkZXIgUGFyYW1ldGVy LiAgSWYgYSAia2lkIiBIZWFkZXIgUGFyYW1ldGVyIGlzIHByZXNlbnQsIHRoZSBrZXkgaWRlbnRp ZmllZCBNVVNUIGJlIHRoZSBrZXkgdXNlZCwgYW5kIE1VU1QgYmUgYSBrZXkgYXNzb2NpYXRlZCB3 aXRoIHRoZSBjbGllbnQuICBBbGdvcml0aG0gdmVyaWZpY2F0aW9uIE1VU1QgYmUgcGVyZm9ybWVk LCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbnMgMy4xIGFuZCAzLjIgb2YgUkZDIDg3MjUuIg0KPg0K Pg0KPg0KPiA+ID4gTG9va2luZyBhdCB0aGUgY2l0ZWQgcmVmZXJlbmNlIGZvciBhdHRhY2tzLCBJ IHNlZSB0aGUgZml4IGlzIHRvDQo+DQo+ID4gPiBpbmNsdWRlIGluZm9ybWF0aW9uIGFib3V0IHdo aWNoIElQRCB3YXMgdXNlZCBieSB0aGUgUlAuIEJ1dCB0aGUNCj4NCj4gPiA+IGRyYWZ0IGJlZm9y ZSB1cyBkb2Vzbid0IG1hbmRhdGUgdGhhdC4gSXQncyBub3QgY2xlYXIgdGhhbiBob3cgdGhlDQo+ DQo+ID4gPiBjaXRlZCBhdHRhY2sgaXMgcHJldmVudGVkIGJ5IHRoZSBkcmFmdC4gU2F5aW5nIHRo YXQgdGhlDQo+DQo+ID4gPiBjb21tdW5pY2F0aW9uIHRocm91Z2ggdGhlIHVzZXItYWdlbnQgaXMg c3ViamVjdCB0bw0KPg0KPiA+DQo+DQo+ID4gVGhlIG1lbnRpb24gb2YgbWl4LXVwIGF0dGFjayB3 YXMgaW50cm9kdWNlZCBhZnRlciB0aGUgTGFzdCBjYWxsIGJ5IA0KPiA+IG9uZQ0KPg0KPiA+IG9m IHRoZSBjb21tZW50LiBJdCBqdXN0IGFkZGVkIGl0IGluIHRoZSBzZW50ZW5jZSB3aXRoIGEgcmVm ZXJlbmNlLiBJDQo+DQo+ID4gYW0gb2sgdG8gcmVtb3ZlIGl0Lg0KPg0KPg0KPg0KPiBUaGF0IHdv cmtzIGZvciBtZS4NCj4NCj4NCj4NCj4gTWlrZT4gSSB3aWxsIHJlbW92ZSB0aGUgbWl4LXVwIGF0 dGFjayByZWZlcmVuY2UgaW4gdGhlIG5leHQgZHJhZnQuDQo+DQo+DQo+DQo+ID4gSGF2aW5nIHNh aWQgdGhhdCwgdGhlIGhlYXJ0IG9mIG1peC11cCBhdHRhY2sgaXMgdGhhdCB0aGUgY29tYmluYXRp b24NCj4NCj4gPiBvZiB0aGUgY2xpZW50IGJlbGlldmVzIHRoYXQgaXQgaXMgY29tbXVuaWNhdGlu ZyB3aXRoIHRoZQ0KPg0KPiA+IGF0dGFja2VyLWNvbnRyb2xsZWQgQVMgKEFBUykgd2hpbGUgaXQg aW4tZmFjdCBpcyB0YWxraW5nIHRvIEhvbmVzdCANCj4gPiBBUw0KPg0KPiA+IChIQVMpLCBBTkQg SEFTIHVuYWJsZSB0byBmaW5kIG91dCB0aGF0IHRoZSBjbGllbnQgaXMgdGhpbmtpbmcgdGhhdCAN Cj4gPiBpdA0KPg0KPiA+IGlzIHRhbGtpbmcgdG8gQUFTIG5vdCBoaW0uDQo+DQo+ID4NCj4NCj4g PiBPQXV0aCBKQVIgc2VlbXMgdG8gbWl0aWdhdGUgaXQgaW4gdHdvIHdheXM6DQo+DQo+ID4NCj4N Cj4gPiBhKSBVc2UgcmVxdWVzdF91cmkgd2hpY2ggaXMgaG9zdGVkIGJ5IHRoZSBBUy4gVGhlbiwg aWYgdGhlIGNsaWVudCBpcw0KPg0KPiA+IHRoaW5raW5nIHRoYXQgaXQgaXMgdGFsa2luZyB0byB0 aGUgQUFTLCB0aGVuIGl0IHdpbGwgcHVzaCBpdCB0byBBQVMNCj4NCj4gPiBhbmQgd2hlbiB0aGUg dXNlciBpcyByZWRpcmVjdGVkIHRvIEhBUywgSEFTIHdpbGwgZmluZCBvdXQgdGhhdCB0aGUNCj4N Cj4gPiByZXF1ZXN0X3VyaSBpcyBub3QgY3JlYXRlZCBieSBoZXJzZWxmIGFuZCByZXR1cm4gYW4g ZXJyb3IsIG1ha2luZyANCj4gPiB0aGUNCj4NCj4gPiBtaXgtdXAgYXR0YWNrIGZhaWwuDQo+DQo+ ID4NCj4NCj4gPiBiKSBJbmNsdWRlIGBhdWRgIGluIHRoZSByZXF1ZXN0LiBUaGVuLCB3aGVuIHRo ZSBIQVMgd2lsbCBmaW5kIHRoYXQgDQo+ID4gdGhlDQo+DQo+ID4gcmVxdWVzdCB3YXMgbWludGVk IHRvIEFBUyBhbmQgbm90IGhlci4gU28sIGl0IHdpbGwgcmVzdWx0IGluIGFuIA0KPiA+IGVycm9y LA0KPg0KPiA+IG1ha2luZyB0aGUgbWl4LXVwIGF0dGFjayBmYWlsLg0KPg0KPg0KPg0KPiBJZiB0 aGUgZHJhZnQgbWFuZGF0ZXMgZG9pbmcgdGhpcyBpdCBhZGRyZXNzZXMgdGhlIGF0dGFjayBhbmQg dGhlIHNlbnRlbmNlIGNhbiBzdGF5Lg0KPg0KPg0KPg0KPiBNaWtlPiBUaGUgZHJhZnQgbWFuZGF0 ZXMgdXNlIG9mICJhdWQiIGJ1dCBpdCBkb2VzIG5vdCBtYW5kYXRlIHRoYXQgdGhlIHJlcXVlc3Rf dXJpIGJlIGhvc3RlZCBieSB0aGUgQVMuICBUaGVyZWZvcmUsIEkgdGhpbmsgd2Ugc2hvdWxkIHJl bW92ZSB0aGUgbWl4LXVwIGF0dGFjayByZWZlcmVuY2UuDQo+DQo+DQo+DQo+ID4gU28sIEkgYWRk ZWQgbWl4LXVwIGF0dGFjayB0byB0aGUgc2VudGVuY2UgdGhpbmtpbmcgdGhlIGNvbW1lbnRlcidz DQo+DQo+ID4gcmVxdWVzdCB0byBhZGQgaXQgaXMgZmluZSwgYnV0IEkgYW0gZmluZSB3aXRoIHJl bW92aW5nIGl0Lg0KPg0KPiA+DQo+DQo+ID4gPiBtYW5pcHVsYXRpb24sIGFuZCB0aGlzIHByZXZl bnRzIGl0LCBpZ25vcmVzIHRoYXQgdGhlIGF0dGFja2VyIGluDQo+DQo+ID4gPiB0aGF0IHBvc2l0 aW9uIHNlZXMgYSBsb3QgbW9yZS4gVGhlIHVzZXItYWdlbnQgYXMgcmVzb3VyY2Ugb3duZXINCj4N Cj4gPiA+IG1vZGlmeWluZyB0aGUgcmVxdWVzdGVkIHJlc291cmNlcyBpcyBhIHZlcnkgZnVubnkg c29ydCBvZiBhdHRhY2s6DQo+DQo+ID4gPiBjYW4ndCB0aGV5IGRvIHdoYXQgdGhleSB3YW50IHdp dGggdGhlIHJlc291cmNlcyBzaW5jZSB0aGV5IGNvbnRyb2wgdGhlIGFjY2Vzcz8NCj4NCj4gPg0K Pg0KPiA+IElmIHRoZSBjbGllbnQgaXMgaW4gdGhlIGJyb3dzZXIsIHllcy4NCj4NCj4gPiBCdXQg aW4gdGhlIG1haW5zdHJlYW0gY2FzZSwgdGhlIGNsaWVudCBpcyBub3QgaW4gdGhlIGJyb3dzZXIg YnV0IHRoZQ0KPg0KPiA+IHdlYi1zZXJ2ZXIgdGhhdCB0aGUgYnJvd3NlciBpcyBjb21tdW5pY2F0 aW5nIHdpdGggYW5kIHRoZSByZXNvdXJjZQ0KPg0KPiA+IGFjY2VzcyBoYXBwZW5zIHdpdGhvdXQg YmVpbmcgbWVkaWF0ZWQgYnkgdGhlIGJyb3dzZXIuDQo+DQo+DQo+DQo+IE15IGNvbmNlcm4gb24g dGhpcyBwb2ludCBpcyByZXNvbHZlZC4NCj4NCj4NCj4NCj4gTWlrZT4gVGhhbmtzDQo+DQo+DQo+ DQo+ID4gPiBLZXkgbWFuYWdlbWVudCBpcyBpZ25vcmVkLiBUaGlzIGlzIGEgdmVyeSBpbXBvcnRh bnQgaXNzdWUsDQo+DQo+ID4gPiBlc3BlY2lhbGx5DQo+DQo+ID4NCj4NCj4gPiBBIGxvdCBvZiBn cm91bmQgaXMgY292ZXJlZCBieSBSRkMgNzUxNSwgNzUxNiwgNzUxNywgNzUxOCwgNzUxOSwgDQo+ ID4gNzU5MSwNCj4NCj4gPiBhbmQgODQxNCBzbyB0aGlzIGRvY3VtZW50IGlzIG5vdCBzcGVjaWZp Y2FsbHkgcmVzdGF0aW5nIHRoZW0uDQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4gPiBjb25zaWRl cmluZyB0aGUgcG90ZW50aWFsIHByb2JsZW1zIHdpdGggdGhlIHJldXNlIG9mIEpXVC4gSSdkIGxp a2UNCj4NCj4gPiA+IHRvIHNlZSBhDQo+DQo+ID4NCj4NCj4gPiBBcmUgeW91IHRhbGtpbmcgYWJv dXQgdGhlIHJldXNlIG9mIHRoZSByZXF1ZXN0IG9iamVjdCBieSBhbiANCj4gPiBhZHZlcnNhcnkN Cj4NCj4gPiB0cnlpbmcgdG8gYWN0IGFzIGFuIGhvbmVzdCBjbGllbnQ/DQo+DQo+ID4gRXZlbiBp ZiBpdCBoYXBwZW5zLCB0aGUgbWFsaWNpb3VzIGNsaWVudCBkb2VzIG5vdCBoYXZlIHRoZSBwcm9w ZXINCj4NCj4gPiBjbGllbnQgY3JlZGVudGlhbCBzbyBpdCBjYW5ub3QgcmVkZWVtIHRoZSBjb2Rl IGl0IG9idGFpbmVkIHdpdGggdGhlDQo+DQo+ID4gdG9rZW4uIEl0IGlzIG5vIGRpZmZlcmVudCB0 aGFuIFJGQzY3NDkgY29kZSBncmFudC4gUHJvdG9jb2xzIHRoYXQNCj4NCj4gPiBleHRlbmQgaXQs IHN1Y2ggYXMgT3BlbklEIENvbm5lY3QsIGhhdmUgaW50cm9kdWNlZCBub25jZSB0byBwcmV2ZW50 DQo+DQo+ID4gdGhlIHJldXNlIGFuZCB1c2VkIEpBUiAoaXQgaXMgY2FsbGVkIHJlcXVlc3Qgb2Jq ZWN0IHRoZXJlKSB0byANCj4gPiBmdXJ0aGVyDQo+DQo+ID4gcHJvdGVjdCB0YW1wZXJpbmcgYW5k IGFjaGlldmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGV2ZW4gaW4gdGhlIA0KPiA+IGZyb250DQo+ DQo+ID4gY2hhbm5lbC4NCj4NCj4gPg0KPg0KPiA+ID4gcmVjb21tZW5kYXRpb24gdGhhdCBrZXlz IGJlIHNlcGFyYXRlZCBieSBpbnRlbmRlZCB1c2VzLCByYXRoZXIgDQo+ID4gPiB0aGFuDQo+DQo+ ID4gPiBsaW1pdGluZyBwYXJ0aWN1bGFyIGZpZWxkcyBpbiBhbiBhZC1ob2MgbWFubmVyLg0KPg0K PiA+DQo+DQo+ID4gQ291bGQgeW91IGtpbmRseSBlbGFib3JhdGUgb24gdGhlICJhZC1ob2MgbWFu bmVyIiBwYXJ0IHNvIHRoYXQgSSBjYW4NCj4NCj4gPiB1bmRlcnN0YW5kIGl0IG1vcmUgZnVsbHk/ DQo+DQo+DQo+DQo+IDEwLjgsIENyb3NzLUpXVCBDb25mdXNpb24gZGlzY3Vzc2VzIGF2b2lkaW5n IHNpZ25pbmcgY2VydGFpbiBmaWVsZHMsIHJhdGhlciB0aGFuIHN1Z2dlc3RpbmcgZ29vZCBrZXkg dXNhZ2UgYXMgYSBzb2x1dGlvbi4NCj4NCj4NCj4NCj4gTWlrZT4gSSBwcm9wb3NlIHRvIGFkZCB0 aGlzIG5ldyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBTZWN0aW9uIDEwLjggdG8gaW1wbGVtZW50 IHlvdXIgc3VnZ2VzdGlvbjoNCj4NCj4gICAgICJGaW5hbGx5LCBhbm90aGVyIHdheSB0byBwcmV2 ZW50IGNyb3NzLUpXVCBjb25mdXNpb24gaXMgdG8gdXNlIGEga2V5IG1hbmFnZW1lbnQgcmVnaW1l IGluIHdoaWNoIGtleXMgdXNlZCB0byBzaWduIFJlcXVlc3QgT2JqZWN0cyBhcmUgaWRlbnRpZmlh Ymx5IGRpc3RpbmN0IGZyb20gdGhvc2UgdXNlZCBmb3Igb3RoZXIgcHVycG9zZXMuICBUaGVuLCBp ZiBhbiBhZHZlcnNhcnkgYXR0ZW1wdHMgdG8gcmVwdXJwb3NlIHRoZSBSZXF1ZXN0IE9iamVjdCBp biBhbm90aGVyIGNvbnRleHQsIGEga2V5IG1pc21hdGNoIHdpbGwgb2NjdXIsIHRod2FydGluZyB0 aGUgYXR0YWNrLiINCj4NCj4NCj4NCj4gPiA+IFRoZW4gd2UgaGF2ZSBzZWN0aW9uIDExLiBXaGF0 IHNlY3Rpb24gMTEgaW50cm9kdWNlcyBpcyBhbiBlbnRpcmUgDQo+ID4gPiBuZXcNCj4NCj4gPiA+ IGRyYW1hdGlzIHBlcnNvbmFlLCB0aGUgVHJ1c3QgRnJhbWV3b3JrIFByb3ZpZGVyLCB3aXRoIG5v IHByaW9yDQo+DQo+ID4gPiBkaXNjdXNzaW9uIG9mIHdoYXQgaXQgaXMgb3IgYSByZWZlcmVuY2Ug dG8gd2hlcmUgaXQgaXMgZGVmaW5lZCBhbmQgDQo+ID4gPiBhDQo+DQo+ID4gPiBnb29kIG51bWJl ciBvZiBzdGF0ZW1lbnRzIGFib3V0IGhvdyBpdCB3b3JrcyB0aGF0IGFyZW4ndCByZWFsbHkgIGNs ZWFyIHdoYXQgdGhleSBtZWFuIGZyb20gdGhlIGRvY3VtZW50IHRvIG1lLg0KPg0KPiA+DQo+DQo+ ID4gVHJ1c3QgRnJhbWV3b3JrIFByb3ZpZGVyIGZpcnN0IGFwcGVhcnMgaW4gNS4yLjEuDQo+DQo+ ID4gQXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0aGUgcmVsYXRlZCB0ZXh0LCBpdCB3YXMgYSBwcmV0 dHkgd2VsbC1rbm93bg0KPg0KPiA+IGNvbmNlcHQuIEluIHRoZSBVbml0ZWQgU3RhdGUsIGl0IHdh cyBwYXJ0IG9mIGl0cyBOYXRpb25hbCBTdHJhdGVneQ0KPg0KPiA+IChOU1RJQykgYW5kIGludGVy bmF0aW9uYWxseSwgaXQgd2FzIGV2ZW4gdGFrZW4gdXAgYXQgV0VGIERhdm9zDQo+DQo+ID4gbWVl dGluZy4gSXQgaXMgcXVpdGUgc3VycHJpc2luZyB0aGF0IHN1Y2ggYSBtYWluc3RyZWFtIGNvbmNl cHQgZmFkZWQNCj4NCj4gPiBpbnRvIG9ic2N1cml0eSBzbyBxdWlja2x5LiBUaGUgcmVhc29uIGZv ciBpbnRyb2R1Y2luZyBpdCB3YXMgdG8gYSkNCj4NCj4gPiBqdXN0aWZ5IHJlcXVlc3RfdXJpIGFz IHNvbWUgV0cgbWVtYmVycyB3YW50ZWQgaXQgdG8gYmUgcmVtb3ZlZCwgYikNCj4NCj4gPiBqdXN0 aWZ5IHRoYXQgcmVxdXN0X3VyaSB0byBiZSBzZXJ2ZWQgZnJvbSBhIGRpZmZlcmVudCBkb21haW4u IE5vdyANCj4gPiB0aGF0DQo+DQo+ID4gcGVvcGxlIGFwcHJlY2lhdGUgaXQsIGUuZy4sIGl0IGNh biBiZSBzZWVuIGZyb20gUEFSLCB0aGUgDQo+ID4ganVzdGlmaWNhdGlvbg0KPg0KPiA+IGZvciBh KSBwcm9iYWJseSBpcyBubyBsb25nZXIgcmVxdWlyZWQuIEEgZnVsbCBleHBsYW5hdGlvbiBmb3Ig YikgDQo+ID4gd291bGQNCj4NCj4gPiBwcm9iYWJseSBiZSBhIG11Y2ggbG9uZ2VyIHRleHQgYnV0 IEkgZG91YnQgaWYgaXQgYmVsb25ncyB0byB0aGlzDQo+DQo+ID4gZG9jdW1lbnQuIEkgYW0gZmlu ZSB3aXRoIHJlbW92aW5nIHRoZSByZWZlcmVuY2UgdG8gVHJ1c3QgZnJhbWV3b3JrDQo+DQo+ID4g ZXRjLiBhcyBsb25nIGFzIHRoZSBjYXBhYmlsaXR5IHRvIHB1c2ggdGhlIGF1dGhvcml6YXRpb24g cmVxdWVzdCB0byANCj4gPiBhDQo+DQo+ID4gcGxhY2Ugb3RoZXIgdGhhbiB0aGUgY2xpZW50IG9y IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBub3QNCj4NCj4gPiByZW1vdmVkLg0KPg0KPg0K Pg0KPiBMZXQncyByZW1vdmUgdGhlIHRleHQgdGhlbiwgYnV0IGtlZXAgdGhlIGNhcGFiaWxpdHku DQo+DQo+DQo+DQo+IE1pa2U+IEkgcHJvcG9zZSB0byByZW1vdmUgdXNlcyBvZiB0aGUgdGVybSAi VHJ1c3QgRnJhbWV3b3JrIFByb3ZpZGVyIiBhbmQgaW5zdGVhZCByZXBsYWNlIHRoZW0gYnkgdGhl IG1vcmUgZ2VuZXJpYyB0ZXJtICJ0cnVzdGVkIHRoaXJkLXBhcnR5IHNlcnZpY2UiLg0KPg0KPg0K Pg0KPiA+ID4gTXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRoYXQgdGhlc2UgaXNzdWVzIGFyZSBzaWdu cyB0aGF0IHRoZSBwcm9ibGVtDQo+DQo+ID4gPiB0aGlzIGRyYWZ0IGlzIHRyeWluZyB0byBzb2x2 ZSBhbmQgdGhlIG1lY2hhbmlzbXMgdG8gc29sdmUgaXQgDQo+ID4gPiBoYXZlbid0DQo+DQo+ID4g PiBiZWVuIGFuYWx5emVkIGFzIHRob3JvdWdobHkgYXMgdGhleSBzaG91bGQgaGF2ZSBiZWVuLiBX aXRob3V0IHRoYXQNCj4NCj4gPiA+IHNvcnQgb2YgdGhvcm91Z2ggYW5hbHlzaXMgaXQncyBub3Qg Y2VydGFpbiB0aGF0IHRoZSBtZWNoYW5pc21zDQo+DQo+ID4gPiBhY3R1YWxseSBzb2x2ZSB0aGUg cHJvYmxlbSBhbmQgaXQncyBub3QgY2xlYXIgd2hhdCB0aGUNCj4NCj4gPiA+IHJlY29tbWVuZGF0 aW9ucyB0byBpbXBsZW1lbnRlcnMgaGF2ZSB0byBiZSB0byBwcmVzZXJ2ZSB0aG9zZSBwcm9wZXJ0 aWVzLg0KPg0KPiA+DQo+DQo+ID4gT0F1dGggSkFSLCBhcyB0aGUgbmFtZSAiVGhlIE9BdXRoIDIu MCBBdXRob3JpemF0aW9uIEZyYW1ld29yazogSldUDQo+DQo+ID4gU2VjdXJlZCBBdXRob3JpemF0 aW9uIFJlcXVlc3QgKEpBUikiIHN1Z2dlc3RzLCBpcyBhIGZyYW1ld29yayBhbmQgDQo+ID4gbm90 DQo+DQo+ID4gYSBob3VzZSBpdHNlbGYuIE9uZSBzdWNoIGV4YW1wbGUgaXMgRkFQSSBbMV0gd2hp Y2ggd2FzIGZvcm1hbGx5DQo+DQo+ID4gdmVyaWZpZWQgWzJdLg0KPg0KPg0KPg0KPiAiSXQncyBw b3NzaWJsZSB0byB1c2UgdGhpcyBkcmFmdCBzZWN1cml0eSIgSSBkb24ndCB0aGluayBzaG91bGQg YmUgZW5vdWdoIGFueW1vcmUuIFJhdGhlciBpdCBzaG91bGQgYmUgaW1wb3NzaWJsZSB0byB1c2Ug aW5zZWN1cmVseS4NCj4NCj4NCj4NCj4gTWlrZT4gVGhlIGRyYWZ0IGRlc2NyaWJlcyBob3cgdG8g dXNlIHRoZSBtZWNoYW5pc20gc2VjdXJlbHkuICBZZXMsIGlmIA0KPiBNaWtlPiBwb3J0aW9ucyBv ZiB0aGUgZHJhZnQgKGFuZCB0aG9zZSBpdCBkZXBlbmRzIHVwb24pIGFyZSBub3QgDQo+IE1pa2U+ IGZvbGxvd2VkLCBpbnNlY3VyZSB1c2FnZSBjYW4gcmVzdWx0LiAgVGhhdCdzIHRydWUgb2YgYW55 IA0KPiBNaWtlPiBzZWN1cml0eSBkcmFmdC4gIElmIHRoZXJlIGFyZSBhZGRpdGlvbmFsIHNwZWNp ZmljIHJlcXVpcmVtZW50cyANCj4gTWlrZT4gYW5kL29yIHJlY29tbWVuZGF0aW9ucyBuZWVkZWQs IHdlJ2QgYmUgZ2xhZCB0byBhZGQgdGhlbS4gIElmIHNvLCANCj4gTWlrZT4gcGxlYXNlIGlkZW50 aWZ5IHRoZW0uICAoSW5kZWVkLCB3ZSdyZSBhbHJlYWR5IGRvaW5nIHNvIGluIA0KPiBNaWtlPiBy ZXNwb25zZSB0byB5b3VyIGV4aXN0aW5nIHNwZWNpZmljIGZlZWRiYWNrLikNCj4NCj4NCj4NCj4g TWlrZT4gQXMgZm9yIHBhc3QgSldUIHByb2JsZW1zLCB0aGUgSldUIEJDUCBbUkZDIDg3MjVdIHdh cyB3cml0dGVuIGF0IHRoZSByZXF1ZXN0IG9mIHRoZSBJRVNHIHRvIGlkZW50aWZ5IGFuZCBtaXRp Z2F0ZSB0aGVtIC0gZXNwZWNpYWxseSBpbiBsaWdodCBvZiBKV1RzIGJlaW5nIHVzZWQgZm9yIGFk ZGl0aW9uYWwgdXNlIGNhc2VzLCBzdWNoIGFzIFNUSVIgc2VjdXJlZCB0ZWxlcGhvbnkgYW5kIHNl Y3VyaW5nIGZpcnN0LXJlc3BvbmRlciBzZXJ2aWNlcy4gIElmIHlvdSBiZWxpZXZlIHRoYXQgYWRk aXRpb25hbCBnZW5lcmljIEpXVCBpc3N1ZXMgc2hvdWxkIGJlIGRpc2N1c3NlZCBhbmQgYWRkcmVz c2VkLCB3ZSBjb3VsZCBhbHdheXMgcmV2aXNlIHRoaXMgQkNQLiAgQnV0IGRvaW5nIHNvIGlzIGJl eW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBSRkMuDQo+DQo+DQo+DQo+ID4gWzFdDQo+DQo+ID4gaHR0 cHM6Ly9iaXRidWNrZXQub3JnL29wZW5pZC9mYXBpL3NyYy9tYXN0ZXIvRmluYW5jaWFsX0FQSV9X RF8wMDIubWQNCj4NCj4gPiBbMl0gaHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE5MDEuMTE1MjANCj4N Cj4gPg0KPg0KPiA+ID4NCj4NCj4gPiA+IE9idmlvdXNseSB0aGlzIGRyYWZ0IGhhcyBoYWQgYSBs b25nIGFuZCB0b3J0dXJlZCBoaXN0b3J5IHdpdGgNCj4NCj4gPiA+IG11bHRpcGxlIHJldmlld3Ms ICBhbmQgd2hhdCBJJ20gc3VnZ2VzdGluZyBuZWVkcyB0byBoYXBwZW4gaXMgYSANCj4gPiA+IGxv dA0KPg0KPiA+ID4gb2Ygd29yay4gQnV0IGl0J3MgZXNzZW50aWFsIGluIGFueSBzZWN1cml0eSBw cm90b2NvbCB0byBkbyB0aGlzDQo+DQo+ID4gPiBhbmFseXNpcyBhbmQgYmUgY2xlYXIgYWJvdXQg d2hhdCBpcywgYW5kIHdoYXQgaXMgbm90LCBwcm90ZWN0ZWQgYnkgdGhlIHByb3RvY29sLg0KPg0K PiA+DQo+DQo+ID4gT0F1dGggSkFSIGlzIG5vdGhpbmcgYnV0IGp1c3QgYW5vdGhlciBiaW5kaW5n IHRvIE9BdXRoIDIuMC4gV2hlcmUNCj4NCj4gPiBSRkM2NzQ5IGJpbmRzIGl0IHRvIGZvcm0gZW5j b2RpbmcsIGl0IHByb3ZpZGVzIHR3byBhZGRpdGlvbmFsIGJpbmRpbmdzOg0KPg0KPiA+ICAgICAx KSBiaW5kaW5nIHRvIEpXVCwgYW5kDQo+DQo+ID4gICAgIDIpIGJpbmRpbmcgdG8gdGhlIHB1c2hl ZCBhdXRob3JpemF0aW9uIHJlcXVlc3QgdGhhdCBpcyByZWZlcmVuY2VkIGJ5IGEgVVJJLg0KPg0K PiA+IEl0IGlzIHRoaXMgc2ltcGxlLiBBcyBzdWNoLCBpdCB3b3VsZCBhbHNvIGluaGVyaXQgc29t ZSBvZiB0aGUNCj4NCj4gPiBzaG9ydGNvbWluZ3MgaW4gUkZDNjc0OS4gSG93ZXZlciwgaXQgaXMg bm90IHRoaXMgZG9jdW1lbnQgdG8gYWRkcmVzcw0KPg0KPiA+IHRoZW0uIEl0IHNob3VsZCBiZSBk b25lIGJ5IG90aGVyIGRvY3VtZW50cyBzbyB0aGF0IHRoZSByZXN1bHQgY2FuIGJlDQo+DQo+ID4g ZW5jb2RlZCB1c2luZyB0aGUgbWVjaGFuaXNtcyBwcm92aWRlZCBpbiB0aGlzIGRvY3VtZW50Lg0K Pg0KPg0KPg0KPiBUaGlzIGlzIG5vdCBhIHNpbXBsZSBtYXR0ZXIuIEpXVCBoYXMgYSBsb25nIGFu ZCB0d2lzdGVkIGhpc3Rvcnkgd2l0aCBzb21lIHBlcnZhc2l2ZSBlcnJvcnMgaW4gY29tbW9uIGxp YnJhcmllcywgYW5kIGlzIGEgZmFpcmx5IGxhcmdlIHN0YW5kYXJkLiBPQXV0aCAyLjAgaXMgYWxz byBsYXJnZS4gRW5zdXJpbmcgdGhhdCB0aGUgbWFwcGluZyBoYXMgdGhlIHJpZ2h0IHByb3BlcnRp ZXMgaXMgZ29pbmcgdG8gYmUgYSBtZXNzLiBJZiB0aGUgZW5jb2RpbmcgZG9lcyBub3QgcmVzcGVj dCB0aGUgc2VtYW50aWNzIHdlIGhhdmUgYSBzZXJpb3VzIHNlY3VyaXR5IGlzc3VlLiBJZiBpbXBs ZW1lbnRvcnMgYXNzdW1lIHRoZSBlbmNvZGluZyBwcm92aWRlcyBwcm9wZXJ0aWVzIGl0IGRvZXMg bm90LCB3ZSBhZ2FpbiBoYXZlIGEgc2VjdXJpdHkgaXNzdWUuDQo+DQo+DQo+DQo+IE1pa2U+IFNl ZSBteSBwcmV2aW91cyBjb21tZW50cyBvbiBwYXN0IEpXVCBpbXBsZW1lbnRhdGlvbiBlcnJvcnMg YW5kIHRoZSB3cml0aW5nIG9mIHRoZSBKV1QgQkNQIFtSRkMgODcyNV0gdG8gYWRkcmVzcyB0aGVz ZS4NCj4NCj4NCj4NCj4gPiBJdCBpcyBxdWl0ZSBzdXJwcmlzaW5nIHRoYXQgdGhpcyBmYWN0IGlz IG5vdCBnZXR0aW5nIGFwcHJlY2lhdGVkIGFuZA0KPg0KPiA+IGlzIHRha2luZyBzdWNoIGEgbG9u ZyB0aW1lIHRvIGNvbXBsZXRlLg0KPg0KPiA+IE1heWJlIEkgc2hvdWxkIGRlbGV0ZSBhbGwgdGhl IGV4cGxhbmF0aW9uIHRleHQgYW5kIGxlYXZlIGl0IHdpdGggDQo+ID4ganVzdA0KPg0KPiA+IHRo ZSBjb3JlIHRleHQuIEV4cGxhbmF0aW9uIGFuZCBqdXN0aWZpY2F0aW9uIHRleHQgZm9yIGRlZmlu aW5nDQo+DQo+ID4gYWRkaXRpb25hbCBiaW5kaW5ncyBwcm9iYWJseSBhcmUganVzdCBkaXN0cmFj dGlvbnMgbm93IGFzIGl0IGlzIG5vdw0KPg0KPiA+IGFwcHJlY2lhdGVkIGFuZCB1c2VkIGFsbCBv dmVyIHRoZSB3b3JsZCB1bmxpa2Ugd2hlbiB0aGUgcHJvamVjdCB3YXMNCj4NCj4gPiBzdGFydGVk Lg0KPg0KPg0KPg0KPiBNaWtlPiBJIHdvdWxkIHByb3Bvc2UgdGhhdCB3ZSBtYWtlIG9ubHkgbmVj ZXNzYXJ5IGNoYW5nZXMgdG8gdGhlIGRyYWZ0IGF0IHRoaXMgcG9pbnQuICBMZXQncyBmaW5pc2gg dGhpcyBsb25nLW92ZXJkdWUgc3BlY2lmaWNhdGlvbiENCj4NCj4NCj4NCj4gPg0KPg0KPiA+ID4N Cj4NCj4gPiA+IFNpbmNlcmVseSwNCj4NCj4gPiA+IFdhdHNvbiBMYWRkDQo+DQo+ID4gPg0KPg0K PiA+DQo+DQo+ID4gVGhhbmtzIGFnYWluIGZvciB5b3VyIGRldGFpbGVkIGNvbW1lbnRzLg0KPg0K PiA+DQo+DQo+ID4gQmVzdCB3aXNoZXMsDQo+DQo+ID4NCj4NCj4gPiAtLQ0KPg0KPiA+IE5hdCBT YWtpbXVyYQ0KPg0KPiA+IE5BVC5Db25zdWx0aW5nIExMQw0KPg0KPg0KPg0KPiBNaWtlPiBJIG5v dyBwbGFuIHRvIGNyZWF0ZSBlZGl0cyBpbmNvcnBvcmF0aW5nIHRoZSBwcm9wb3NlZCByZXNvbHV0 aW9ucyBhYm92ZSBmb3IgcmV2aWV3Lg0KPg0KPg0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMsDQo+DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQo+DQo+DQo+DQo+IC0tDQo+DQo+IEFzdHJhIG1vcnRlbXF1ZSBwcmFlc3RhcmUgZ3JhZGF0aW0N Cg0KDQoNCi0tDQpBc3RyYSBtb3J0ZW1xdWUgcHJhZXN0YXJlIGdyYWRhdGltDQo= From nobody Thu Mar 18 16:40:02 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9DF3A0E61 for ; Thu, 18 Mar 2021 16:40:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <161611080188.23765.4070773226410610808@ietfa.amsl.com> Date: Thu, 18 Mar 2021 16:40:01 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 23:40:02 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-03-25 Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Charlie Kaufman R2019-12-13 draft-ietf-ace-oauth-params Russ Mundy R2020-07-20 draft-ietf-ace-dtls-authorize Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Nancy Cam-Winget 2021-03-16 draft-ietf-acme-authority-token-tnauthlist Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Donald Eastlake 2021-03-22 draft-ietf-dots-rfc8782-bis Daniel Franke 2021-03-28 draft-ietf-tls-dtls-connection-id Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Dan Harkins 2021-03-22 draft-ietf-6man-spring-srv6-oam Leif Johansson None draft-ietf-netconf-crypto-types Charlie Kaufman R2019-12-13 draft-ietf-ace-oauth-params Tero Kivinen 2021-03-31 draft-ietf-roll-aodv-rpl Watson Ladd 2021-03-29 draft-ietf-lsr-ospf-prefix-originator Chris Lonvick 2021-03-29 draft-ietf-grow-bmp-local-rib Russ Mundy R2020-07-20 draft-ietf-ace-dtls-authorize Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Tim Polk None draft-ietf-opsawg-finding-geofeeds Yaron Sheffer R2021-03-29 draft-ietf-opsawg-tacacs-yang Sean Turner 2021-02-25 draft-ietf-ntp-port-randomization Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Christian Huitema 2021-03-26 draft-ietf-dtn-bpsec-default-sc Scott Kelly 2021-04-01 draft-ietf-tcpm-accurate-ecn Tina Tsou 2021-02-15 draft-ietf-idr-eag-distribution Paul Wouters 2021-02-19 draft-ietf-idr-bgp-ls-app-specific-attr Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Aanchal Malhotra David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir From nobody Thu Mar 18 18:25:40 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BB13A1192; Thu, 18 Mar 2021 18:25:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: draft-ietf-dtn-bpsec-default-sc.all@ietf.org, dtn@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161611713427.19367.10392386702864224514@ietfa.amsl.com> Reply-To: Christian Huitema Date: Thu, 18 Mar 2021 18:25:34 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-dtn-bpsec-default-sc-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 01:25:34 -0000 Reviewer: Christian Huitema Review result: Has Nits I have reviewed draft-ietf-dtn-bpsec-default-sc-02 as part of an early security review requested by the transport AD. The draft specifies how to use either HMAC/SHA based authencation or AES-GCM authenticated encryption in the framework defined by the Bundle Protocol Security Specification (draft-ietf-dtn-bpsec-27) for the Bundle Protocol Version 7 draft-ietf-dtn-bpbis-31.txt. The specifications are straightforward applications of well-known algorithms: HMAC256/SHA256, HMAC384/SHA384, HMAC512/SHA512, AES128 GCM, and AES256 GCM. The text is written in a detailed manner, guiding potential developers through the implementation of these algorithms. For me, these descriptions seem almost ready, expect for two nits. However, the overall system appears very complex, and some ways to manage that complexity would be welcome. My minimum suggestion would be to add test vectors. The first nit regards the table of BIB-HMAC-SHA2 Security Parameters in section 3.3.4. The default value for the SHA Variant is specified as "256", but section 3.3.1 only defines values 5, 6 and 7 for that parameter. I assume that the intent is to default to HMAC256/SHA256, but in that case the default should be 5, not 256. The second nit regards the discussion of authentication and confidentiality in section 4.1. AEAD algorithms distinguish between authenticated data and encrypted data. The text expresses a different concept,separate definitions of "scope of confidentiality" and "scope of authentication". I suggest that these paragraphs be rewrittent to specify that "the scope of authentication is always the union of the additional data and the scope of confidentiality." These are small issues. My real concern with this document is the overall complexity of the Bundle Protocol and the Security specification. The protocols appear specified for maximum flexibility. Messages can be relayed. Relays can add their own security blocks to the bundle. Authentication and encryption can apply to different blocks in the bundle. Messages can be fragmented. Nodes can choose to apply different level of security to different bundles, or to different blocks in the same bundle. I suppose that these choices are justified by application requirements, but all this complexity may end up causing interoperability issues, and potential security failures. The way CBOR encoding are used brings another source of complexity. CBOR allows for different ways of encoding the same data. The bundle security document and this algorithm specification document request that some data parts be re-encoded in the "canonical" CBOR format before authentication tags are computed or verified. Experience in other domains shows that relying on canonization before authentication is very fragile, and a source of interoperability failures. It would be much more robust to assume that authenticated objects are immutable, and that the wire format of these objects is fed directly into the hash algorithm. To mitigate the risk of interoperability failures, I suggest adding test vectors to the specification. Each test case should start with a clear text test bundle, apply either authentication or authenticated encryption according to some variations of the authentication or AAD scope flags, and produce a result. Different test vectors might start with different mode of CBOR encoding, to test the canonization process. This kind of investment might save a lot of time to future developers! Not a comment on this draft, but I see lot of potential issues with fragmentation. I understand that in a Delay Tolerant Network,relays need to be able to fragment messages. The draft correctly points out that if an authenticated message is fragmented, authentication can only be received while all fragments are received. However, this would not protect from attacks against fragmentation similar to those seen in IP, IPv6 and TCP. I think that some kind of secure fragmentation protocol need to be studied and specified by the working group. From nobody Fri Mar 19 09:13:15 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6C43A1973; Fri, 19 Mar 2021 09:13:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-opsawg-tacacs-yang.all@ietf.org, last-call@ietf.org, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161617038470.3998.2980645570550909386@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Fri, 19 Mar 2021 09:13:04 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-yang-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 16:13:05 -0000 Reviewer: Yaron Sheffer Review result: Ready All comments of my previous review have been addressed. Thank you! From nobody Fri Mar 19 10:56:09 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1BD3A1B5D; Fri, 19 Mar 2021 10:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.94 X-Spam-Level: X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=2.839, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRbpmRBLgiAY; Fri, 19 Mar 2021 10:55:53 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A28B53A1B84; Fri, 19 Mar 2021 10:55:52 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 19 Mar 2021 10:55:48 -0700 From: "Randall Gellens" To: "Linda Dunbar" Cc: secdir@ietf.org, draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org, ecrit@ietf.org, last-call@ietf.org, "Murray S. Kucherawy" , "Benjamin Kaduk" Date: Fri, 19 Mar 2021 10:55:51 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <20210316173921.GG79563@kduck.mit.edu> <20210316173921.GG79563@kduck.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B33E0B51-9FE4-43B4-8109-B19623A0CDF1_=" Embedded-HTML: [{"HTML":[4893, 1626], "plain":[3421, 1208], "uuid":"34A029A3-465F-4DE7-A39F-6E3D4D53F3D9"}, {"HTML":[6953, 1626], "plain":[4687, 1208], "uuid":"F520A1A3-1DD1-4C89-A527-DBD56B974BA4"}, {"HTML":[9375, 1626], "plain":[6087, 1208], "uuid":"DDD052BF-8A97-4A33-8A4C-CF2162D18B09"}, {"HTML":[11694, 3917], "plain":[7449, 1789], "uuid":"51A81255-64B8-4B40-8043-13A36AF2EB70"}, {"HTML":[16039, 3917], "plain":[9290, 1789], "uuid":"3C818FDA-ED69-46BD-BFE6-1355343515D0"}, {"HTML":[20746, 3917], "plain":[11265, 1789], "uuid":"1C477AC0-D120-4170-9E0E-E898A86C2559"}, {"HTML":[32802, 1244], "plain":[18183, 693], "uuid":"F4D745B0-346C-4720-BA91-5A36D62DE078"}, {"HTML":[34481, 1244], "plain":[18935, 693], "uuid":"36378602-B157-45A5-BD0E-1240F38088BA"}, {"HTML":[36522, 1244], "plain":[19821, 693], "uuid":"9FC73ACC-C119-4A51-AF54-2D2A47019374"}] Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 17:55:58 -0000 --=_MailMate_B33E0B51-9FE4-43B4-8109-B19623A0CDF1_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Hi Linda, Thank you for reviewing the document. After the discussion, do you = still have any questions or do you feel there is any ambiguity that = needs to be resolved? --Randall On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the security directorate's = > ongoing > effort to review all IETF documents being processed by the IESG. = > These > comments were written primarily for the benefit of the security area = > directors. > Document editors and WG chairs should treat these comments just like = > any other > last call comments. > > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Best Regards, > Linda Dunbar On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the security directorate's = > ongoing > effort to review all IETF documents being processed by the IESG. = > These > comments were written primarily for the benefit of the security area = > directors. > Document editors and WG chairs should treat these comments just like = > any other > last call comments. > > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Best Regards, > Linda Dunbar > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Not Ready > > I have reviewed this document as part of the security directorate's = > ongoing > effort to review all IETF documents being processed by the IESG. = > These > comments were written primarily for the benefit of the security area = > directors. > Document editors and WG chairs should treat these comments just like = > any other > last call comments. > > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Best Regards, > Linda Dunbar > > > > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker < > noreply@ietf.org> wrote: > >> This document doesn't seem to be complete. The document claims that = >> it >> changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change >> or >> add values. But which SDOs are allowed? Are there any procedures to >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> > > Specification Required is defined in RFC 8162. The IESG will be = > tasked > with appointing a designated expert (DE) to review registration = > requests > against the published specification. The DE will have discretion to > determine whether an application should be accepted. The document = > contains > no guidance about particular SDOs, so the DE is left to decide whether = > to > factor the source into the approval or rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the > call about "legitimate". > > -MSK On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker < > noreply@ietf.org> wrote: > >> This document doesn't seem to be complete. The document claims that = >> it >> changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change >> or >> add values. But which SDOs are allowed? Are there any procedures to >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> > > Specification Required is defined in RFC 8162. The IESG will be = > tasked > with appointing a designated expert (DE) to review registration = > requests > against the published specification. The DE will have discretion to > determine whether an application should be accepted. The document = > contains > no guidance about particular SDOs, so the DE is left to decide whether = > to > factor the source into the approval or rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the > call about "legitimate". > > -MSK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker < > noreply@ietf.org> wrote: > >> This document doesn't seem to be complete. The document claims that = >> it >> changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change >> or >> add values. But which SDOs are allowed? Are there any procedures to >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> > > Specification Required is defined in RFC 8162. The IESG will be = > tasked > with appointing a designated expert (DE) to review registration = > requests > against the published specification. The DE will have discretion to > determine whether an application should be accepted. The document = > contains > no guidance about particular SDOs, so the DE is left to decide whether = > to > factor the source into the approval or rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the > call about "legitimate". > > -MSK > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:12, Linda Dunbar wrote: > Murray, > > Then why need this document? > Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be ta= sked with = > appointing a designated expert (DE) to review registration requests = > against the published specification=E2=80=9D? > > Linda > > From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM > To: Linda Dunbar > Cc: secdir@ietf.org; = > draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = > ecrit@ietf.org; last-call@ietf.org > Subject: Re: Secdir last call review of = > draft-ietf-ecrit-location-profile-registry-policy-01 > > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = > > wrote: > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Specification Required is defined in RFC 8162. The IESG will be = > tasked with appointing a designated expert (DE) to review registration = > requests against the published specification. The DE will have = > discretion to determine whether an application should be accepted. = > The document contains no guidance about particular SDOs, so the DE is = > left to decide whether to factor the source into the approval or = > rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the call about "legitimate". > > -MSK On 16 Mar 2021, at 10:12, Linda Dunbar wrote: > Murray, > > Then why need this document? > Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be ta= sked with = > appointing a designated expert (DE) to review registration requests = > against the published specification=E2=80=9D? > > Linda > > From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM > To: Linda Dunbar > Cc: secdir@ietf.org; = > draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = > ecrit@ietf.org; last-call@ietf.org > Subject: Re: Secdir last call review of = > draft-ietf-ecrit-location-profile-registry-policy-01 > > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = > > wrote: > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Specification Required is defined in RFC 8162. The IESG will be = > tasked with appointing a designated expert (DE) to review registration = > requests against the published specification. The DE will have = > discretion to determine whether an application should be accepted. = > The document contains no guidance about particular SDOs, so the DE is = > left to decide whether to factor the source into the approval or = > rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the call about "legitimate". > > -MSK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 10:12, Linda Dunbar wrote: > Murray, > > Then why need this document? > Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be ta= sked with = > appointing a designated expert (DE) to review registration requests = > against the published specification=E2=80=9D? > > Linda > > From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM > To: Linda Dunbar > Cc: secdir@ietf.org; = > draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = > ecrit@ietf.org; last-call@ietf.org > Subject: Re: Secdir last call review of = > draft-ietf-ecrit-location-profile-registry-policy-01 > > Hi Linda, thanks for your review. Comments below. > > On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = > > wrote: > This document doesn't seem to be complete. The document claims that it = > changes > the policy of the Location-to-Service Translation (LoST) Location = > Profile > registry from Standards Action to Specification Required, but it = > doesn't > specify what is the new procedure. It says allowing other SDOs to = > change or > add values. But which SDOs are allowed? Are there any procedures to = > identify > which SDOs are legitimate? can any organizations, say XYZ, change, add = > or > delete the values? > > Specification Required is defined in RFC 8162. The IESG will be = > tasked with appointing a designated expert (DE) to review registration = > requests against the published specification. The DE will have = > discretion to determine whether an application should be accepted. = > The document contains no guidance about particular SDOs, so the DE is = > left to decide whether to factor the source into the approval or = > rejection of the request. > > So any SDO can make a request to update the registry. The DE makes = > the call about "legitimate". > > -MSK > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote: > Hi Linda, > > The current registration procedure (visible at > https://www.iana.org/assignments/lost-location-profiles/lost-location-p= rofiles.xhtml) > of Standards Action only requires a standards-track RFC to get an > allocation; there is no designated expert involved in that procedure. > RFC 8126 again remains a good reference for these registration = > policies. > > Thanks, > > Ben > > > On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: >> Murray, >> >> Then why need this document? >> Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be t= asked with = >> appointing a designated expert (DE) to review registration requests = >> against the published specification=E2=80=9D? >> >> Linda >> >> From: Murray S. Kucherawy >> Sent: Tuesday, March 16, 2021 11:46 AM >> To: Linda Dunbar >> Cc: secdir@ietf.org; = >> draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = >> ecrit@ietf.org; last-call@ietf.org >> Subject: Re: Secdir last call review of = >> draft-ietf-ecrit-location-profile-registry-policy-01 >> >> Hi Linda, thanks for your review. Comments below. >> >> On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = >> > wrote: >> This document doesn't seem to be complete. The document claims that = >> it changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change or >> add values. But which SDOs are allowed? Are there any procedures to = >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> >> Specification Required is defined in RFC 8162. The IESG will be = >> tasked with appointing a designated expert (DE) to review = >> registration requests against the published specification. The DE = >> will have discretion to determine whether an application should be = >> accepted. The document contains no guidance about particular SDOs, = >> so the DE is left to decide whether to factor the source into the = >> approval or rejection of the request. >> >> So any SDO can make a request to update the registry. The DE makes = >> the call about "legitimate". >> >> -MSK > >> -- = >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote: > Hi Linda, > > The current registration procedure (visible at > https://www.iana.org/assignments/lost-location-profiles/lost-location-p= rofiles.xhtml) > of Standards Action only requires a standards-track RFC to get an > allocation; there is no designated expert involved in that procedure. > RFC 8126 again remains a good reference for these registration = > policies. > > Thanks, > > Ben > > > On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: >> Murray, >> >> Then why need this document? >> Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be t= asked with = >> appointing a designated expert (DE) to review registration requests = >> against the published specification=E2=80=9D? >> >> Linda >> >> From: Murray S. Kucherawy >> Sent: Tuesday, March 16, 2021 11:46 AM >> To: Linda Dunbar >> Cc: secdir@ietf.org; = >> draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; = >> ecrit@ietf.org; last-call@ietf.org >> Subject: Re: Secdir last call review of = >> draft-ietf-ecrit-location-profile-registry-policy-01 >> >> Hi Linda, thanks for your review. Comments below. >> >> On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker = >> > wrote: >> This document doesn't seem to be complete. The document claims that = >> it changes >> the policy of the Location-to-Service Translation (LoST) Location = >> Profile >> registry from Standards Action to Specification Required, but it = >> doesn't >> specify what is the new procedure. It says allowing other SDOs to = >> change or >> add values. But which SDOs are allowed? Are there any procedures to = >> identify >> which SDOs are legitimate? can any organizations, say XYZ, change, = >> add or >> delete the values? >> >> Specification Required is defined in RFC 8162. The IESG will be = >> tasked with appointing a designated expert (DE) to review = >> registration requests against the published specification. The DE = >> will have discretion to determine whether an application should be = >> accepted. The document contains no guidance about particular SDOs, = >> so the DE is left to decide whether to factor the source into the = >> approval or rejection of the request. >> >> So any SDO can make a request to update the registry. The DE makes = >> the call about "legitimate". >> >> -MSK > >> -- = >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call > > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: > On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar = > > wrote: > >> Then why need this document? >> >> Isn=E2=80=99t it already the practice that =E2=80=9C*The IESG will be = tasked with >> appointing a designated expert (DE) to review registration requests = >> against >> the published specification=E2=80=9D? * >> > > No, the current rules for that registry are specified by Standards = > Action > (Section 4.9 of RFC 8126), which requires a standards track RFC. = > There's > no designated expert in that model. The working group wants to change = > the > policy to the less restrictive model that allows for specifications > published outside of the IETF to qualify, subject to expert review. > > -MSK On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: > On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar = > > wrote: > >> Then why need this document? >> >> Isn=E2=80=99t it already the practice that =E2=80=9C*The IESG will be = tasked with >> appointing a designated expert (DE) to review registration requests = >> against >> the published specification=E2=80=9D? * >> > > No, the current rules for that registry are specified by Standards = > Action > (Section 4.9 of RFC 8126), which requires a standards track RFC. = > There's > no designated expert in that model. The working group wants to change = > the > policy to the less restrictive model that allows for specifications > published outside of the IETF to qualify, subject to expert review. > > -MSK > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: > On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar = > > wrote: > >> Then why need this document? >> >> Isn=E2=80=99t it already the practice that =E2=80=9C*The IESG will be = tasked with >> appointing a designated expert (DE) to review registration requests = >> against >> the published specification=E2=80=9D? * >> > > No, the current rules for that registry are specified by Standards = > Action > (Section 4.9 of RFC 8126), which requires a standards track RFC. = > There's > no designated expert in that model. The working group wants to change = > the > policy to the less restrictive model that allows for specifications > published outside of the IETF to qualify, subject to expert review. > > -MSK > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 14:01, Randall Gellens wrote: > I just want to add that the document currently does contain some = > guidance. Section 4 (IANA Considerations) contains: > > The reviewer should verify that: > o the proposed new value is specified by the IETF, NENA, or a > similar SDO in which location profiles are in scope; > > --Randall > > -- = > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --=_MailMate_B33E0B51-9FE4-43B4-8109-B19623A0CDF1_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Linda,

Thank you for reviewing the document. After the discussi= on, do you still have any questions or do you feel there is any ambiguity= that needs to be resolved?

--Randall

On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wro= te:

Reviewer: Linda Dunbar
Review result: Not Ready

I have reviewed this document as part of the security dir= ectorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area dire= ctors.
Document editors and WG chairs should treat these comments just like any= other
last call comments.

This document doesn't seem to be complete. The document c= laims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Best Regards,
Linda Dunbar

On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wro= te:

Reviewer: Linda Dunbar
Review result: Not Ready

I have reviewed this document as part of the security dir= ectorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area dire= ctors.
Document editors and WG chairs should treat these comments just like any= other
last call comments.

This document doesn't seem to be complete. The document c= laims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Best Regards,
Linda Dunbar

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wro= te:

Reviewer: Linda Dunbar
Review result: Not Ready

I have reviewed this document as part of the security dir= ectorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area dire= ctors.
Document editors and WG chairs should treat these comments just like any= other
last call comments.

This document doesn't seem to be complete. The document c= laims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Best Regards,
Linda Dunbar

--
last-call mailing list
last-call@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/last-call

On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.=C2=A0 C= omments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Data= tracker <noreply@ietf.org> = wrote:
This = document doesn't seem to be complete. The document claims that it cha= nges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn= 9;t
specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Requ= ired is defined in RFC 8162.=C2=A0 The IESG will be tasked with appointin= g a designated expert (DE) to review registration requests against the pu= blished specification.=C2=A0 The DE will have discretion to determine whe= ther an application should be accepted.=C2=A0 The document contains no gu= idance about particular SDOs, so the DE is left to decide whether to fact= or the source into the approval or rejection of the request.
So any SDO can make a request to update the registry.=C2=A0 = The DE makes the call about "legitimate".

<= div>-MSK

On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.=C2=A0 C= omments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Data= tracker <noreply@ietf.org> = wrote:
This = document doesn't seem to be complete. The document claims that it cha= nges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn= 9;t
specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Requ= ired is defined in RFC 8162.=C2=A0 The IESG will be tasked with appointin= g a designated expert (DE) to review registration requests against the pu= blished specification.=C2=A0 The DE will have discretion to determine whe= ther an application should be accepted.=C2=A0 The document contains no gu= idance about particular SDOs, so the DE is left to decide whether to fact= or the source into the approval or rejection of the request.
So any SDO can make a request to update the registry.=C2=A0 = The DE makes the call about "legitimate".

<= div>-MSK

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.=C2=A0 C= omments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Data= tracker <noreply@ietf.org> = wrote:
This = document doesn't seem to be complete. The document claims that it cha= nges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn= 9;t
specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Requ= ired is defined in RFC 8162.=C2=A0 The IESG will be tasked with appointin= g a designated expert (DE) to review registration requests against the pu= blished specification.=C2=A0 The DE will have discretion to determine whe= ther an application should be accepted.=C2=A0 The document contains no gu= idance about particular SDOs, so the DE is left to decide whether to fact= or the source into the approval or rejection of the request.
So any SDO can make a request to update the registry.=C2=A0 = The DE makes the call about "legitimate".

<= div>-MSK

--
last-call mailing list
last-call@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/last-call

On 16 Mar 2021, at 10:12, Linda Dunbar wrote:

= Murray,

= =C2=A0

= Then why need this document?

= Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be tasked with appointing a designated expert (= DE) to review registration requests against the published specification=E2= =80=9D?

= =C2=A0

= Linda

= =C2=A0

= From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-po= licy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-= profile-registry-policy-01

= =C2=A0

= Hi Linda, thanks for your review.=C2=A0 Comments below.

= =C2=A0

= On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

= This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

= =C2=A0

= Specification Required is defined in RFC 8162.=C2=A0 The IESG will be tas= ked with appointing a designated expert (DE) to review registration reque= sts against the published specification.=C2=A0 The DE will have discretio= n to determine whether an application should be accepted.=C2=A0 The document contains no guidance about partic= ular SDOs, so the DE is left to decide whether to factor the source into = the approval or rejection of the request.

= =C2=A0

= So any SDO can make a request to update the registry.=C2=A0 The DE makes = the call about "legitimate".

= =C2=A0

= -MSK

On 16 Mar 2021, at 10:12, Linda Dunbar wrote:

= Murray,

= =C2=A0

= Then why need this document?

= Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be tasked with appointing a designated expert (= DE) to review registration requests against the published specification=E2= =80=9D?

= =C2=A0

= Linda

= =C2=A0

= From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-po= licy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-= profile-registry-policy-01

= =C2=A0

= Hi Linda, thanks for your review.=C2=A0 Comments below.

= =C2=A0

= On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

= This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

= =C2=A0

= Specification Required is defined in RFC 8162.=C2=A0 The IESG will be tas= ked with appointing a designated expert (DE) to review registration reque= sts against the published specification.=C2=A0 The DE will have discretio= n to determine whether an application should be accepted.=C2=A0 The document contains no guidance about partic= ular SDOs, so the DE is left to decide whether to factor the source into = the approval or rejection of the request.

= =C2=A0

= So any SDO can make a request to update the registry.=C2=A0 The DE makes = the call about "legitimate".

= =C2=A0

= -MSK

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 10:12, Linda Dunbar wrote:

= Murray,

= =C2=A0

= Then why need this document?

= Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be tasked with appointing a designated expert (= DE) to review registration requests against the published specification=E2= =80=9D?

= =C2=A0

= Linda

= =C2=A0

= From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-po= licy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-= profile-registry-policy-01

= =C2=A0

= Hi Linda, thanks for your review.=C2=A0 Comments below.

= =C2=A0

= On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

= This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure.=C2=A0 It says allowing other SDOs to c= hange or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

= =C2=A0

= Specification Required is defined in RFC 8162.=C2=A0 The IESG will be tas= ked with appointing a designated expert (DE) to review registration reque= sts against the published specification.=C2=A0 The DE will have discretio= n to determine whether an application should be accepted.=C2=A0 The document contains no guidance about partic= ular SDOs, so the DE is left to decide whether to factor the source into = the approval or rejection of the request.

= =C2=A0

= So any SDO can make a request to update the registry.=C2=A0 The DE makes = the call about "legitimate".

= =C2=A0

= -MSK

--
last-call mailing list
last-call@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/last-call

On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote:

Hi Linda,

The current registration procedure (visible at
https://www.iana.org/assignm= ents/lost-location-profiles/lost-location-profiles.xhtml)
of Standards Action only requires a standards-track RFC to get an
allocation; there is no designated expert involved in that procedure.
= RFC 8126 again remains a good reference for these registration policies.<= /p>

Thanks,

Ben

On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wr= ote:

Murray,

Then why need this document?
Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be task= ed with appointing a designated expert (DE) to review registration reques= ts against the published specification=E2=80=9D?

Linda

From: Murray S. Kucherawy superuser@gmail.com
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com
Cc: secdir@ietf.o= rg; draft-ietf-ecrit-location-profile-r= egistry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile= -registry-policy-01

Hi Linda, thanks for your review. Comments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatrac= ker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Required is defined in RFC 8162. The IESG = will be tasked with appointing a designated expert (DE) to review registr= ation requests against the published specification. The DE will have dis= cretion to determine whether an application should be accepted. The docu= ment contains no guidance about particular SDOs, so the DE is left to dec= ide whether to factor the source into the approval or rejection of the re= quest.

So any SDO can make a request to update the registry. Th= e DE makes the call about "legitimate".

-MSK

--
last-call mailing list
last-call@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/last-call

On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote:

Hi Linda,

The current registration procedure (visible at
https://www.iana.org/assignm= ents/lost-location-profiles/lost-location-profiles.xhtml)
of Standards Action only requires a standards-track RFC to get an
allocation; there is no designated expert involved in that procedure.
= RFC 8126 again remains a good reference for these registration policies.<= /p>

Thanks,

Ben

On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wr= ote:

Murray,

Then why need this document?
Isn=E2=80=99t it already the practice that =E2=80=9CThe IESG will be task= ed with appointing a designated expert (DE) to review registration reques= ts against the published specification=E2=80=9D?

Linda

From: Murray S. Kucherawy superuser@gmail.com
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com
Cc: secdir@ietf.o= rg; draft-ietf-ecrit-location-profile-r= egistry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile= -registry-policy-01

Hi Linda, thanks for your review. Comments below.

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatrac= ker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
This document doesn't seem to be complete. The document claims that it ch= anges
the policy of the Location-to-Service Translation (LoST) Location Profile=
registry from Standards Action to Specification Required, but it doesn't<= br> specify what is the new procedure. It says allowing other SDOs to change= or
add values. But which SDOs are allowed? Are there any procedures to ident= ify
which SDOs are legitimate? can any organizations, say XYZ, change, add or=
delete the values?

Specification Required is defined in RFC 8162. The IESG = will be tasked with appointing a designated expert (DE) to review registr= ation requests against the published specification. The DE will have dis= cretion to determine whether an application should be accepted. The docu= ment contains no guidance about particular SDOs, so the DE is left to dec= ide whether to factor the source into the approval or rejection of the re= quest.

So any SDO can make a request to update the registry. Th= e DE makes the call about "legitimate".

-MSK

--
last-call mailing list
last-call@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/last-call

--
last-call mailing list
last-call@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/last-call

On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Du= nbar <linda.dunbar@futur= ewei.com> wrote:
Then why need this= document? =

Isn=E2=80=99t it already the practice that =E2=80=9C= The IESG will be tasked with appo= inting a designated expert (DE) to review registration requests against t= he published specification=E2=80=9D?


No, the current rules for th= at registry are specified by Standards Action (Section 4.9 of RFC 8126), = which requires a standards track RFC.=C2=A0 There's no designated exp= ert in that model.=C2=A0 The working group wants to change the policy to = the less restrictive model that allows for specifications published outsi= de of the IETF to qualify, subject to expert review.

=
-MSK

On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Du= nbar <linda.dunbar@futur= ewei.com> wrote:
Then why need this= document? =

Isn=E2=80=99t it already the practice that =E2=80=9C= The IESG will be tasked with appo= inting a designated expert (DE) to review registration requests against t= he published specification=E2=80=9D?


No, the current rules for th= at registry are specified by Standards Action (Section 4.9 of RFC 8126), = which requires a standards track RFC.=C2=A0 There's no designated exp= ert in that model.=C2=A0 The working group wants to change the policy to = the less restrictive model that allows for specifications published outsi= de of the IETF to qualify, subject to expert review.

=
-MSK

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Du= nbar <linda.dunbar@futur= ewei.com> wrote:
Then why need this= document? =

Isn=E2=80=99t it already the practice that =E2=80=9C= The IESG will be tasked with appo= inting a designated expert (DE) to review registration requests against t= he published specification=E2=80=9D?


No, the current rules for th= at registry are specified by Standards Action (Section 4.9 of RFC 8126), = which requires a standards track RFC.=C2=A0 There's no designated exp= ert in that model.=C2=A0 The working group wants to change the policy to = the less restrictive model that allows for specifications published outsi= de of the IETF to qualify, subject to expert review.

=
-MSK

--
last-call mailing list
last-call@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/last-call

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

Ecrit mailing list
Ecrit@ietf.org=
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021, at 14:01, Randall Gellens wrote:

I just want to add that the document currently does conta= in some guidance. Section 4 (IANA Considerations) contains:

The reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

--Randall

--
last-call mailing list
last-call@ietf= =2Eorg
https://www.ietf.org/mailman/listinfo/last-call

--=_MailMate_B33E0B51-9FE4-43B4-8109-B19623A0CDF1_=-- From nobody Fri Mar 19 11:09:30 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0203A00C4; Fri, 19 Mar 2021 11:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFjSqlFodKZr; Fri, 19 Mar 2021 11:09:16 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2129.outbound.protection.outlook.com [40.107.243.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB503A006A; Fri, 19 Mar 2021 11:09:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C8x1CvFY/BZEkvKIuqvDynsTvv0JAHiYapGMFlUDe0Y5y3MVsKKzR6OwzqFXWZqtBhFDD+RDOGEHezx3JhfT0m6XijJNfcW3BrdQZ8A3Wmu4HwOk6qU8bxo//ZyJlhej/MooFkYPCRF1D16okrSY+G+HH5Mp+bq7D0cZqhrYUFpHVUeg+A9K6gqJ4PbrY3MsO+LDSQqtp0hj+PcmB1j6r3KFdDUl9VhiVwJbAZ+iBZDjEioMldbp26stSnhcgKGrmGWVAr30pIshwBqNiPu+5OJzIqo9UuZJ9jZ4GwzFTVZFMoN4F7RhA01mdRT0ylK5ltiYHt7GWDPPtduzald+KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wo8IcDdCYe+AoH90+LPM1oI5DY8NDzTsGVSuzD5ywvE=; b=SIK0t8n8ptCc/SaeCHX+s91HYuFe8qdSzfA2l8WOsqN+X1yrJsB1Seu0FfJcGUqHw3qME8HuyRYuvK67B56t16xz8a7uSsYnlrE2OY30rlLMT1jixyKog6/ahhLuSPp8No1daD+ObB2Ct/11BkizsNJp7h4wR1DcYKZPxJCCdwuhKfZ8f5fQfoyh8Z8ZJZYsXQe8g98DkRPSX+307dhwl8JBqMH8O8V8Fty5zNkzVfShPitTwvckpLt+RLWIhtc8jqodufVG+Jqsk3jPLtFMGaooa7mZt6qNmo5p+S2wHZncsd94n4hZaCRtb5NS99qzUjWCdS2QH20uGBYY33R1fg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wo8IcDdCYe+AoH90+LPM1oI5DY8NDzTsGVSuzD5ywvE=; b=lSuKW51xkgOx0EKwXGjFiAsQWiTh6xQIaOfZrP0GAwtP9mHSVzE8SEV3TXPHG+YFtk/mTMsfQUxOV7/6TkT5SM0XFsAwJ3VT83xb+BwLa10MZ2tpgEZVLmJKxEqDBx2GRhO3dWBG+GPknZF4Fgjs1JhQHYK4rMWtt4MLcIYfWBQ= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SA1PR13MB4958.namprd13.prod.outlook.com (2603:10b6:806:189::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.10; Fri, 19 Mar 2021 18:09:11 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::3050:546b:c47:a42a%6]) with mapi id 15.20.3977.010; Fri, 19 Mar 2021 18:09:11 +0000 From: Linda Dunbar To: Randall Gellens CC: "secdir@ietf.org" , "draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org" , "ecrit@ietf.org" , "last-call@ietf.org" , "Murray S. Kucherawy" , Benjamin Kaduk Thread-Topic: Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 Thread-Index: AQHXHOkcUCvg6FHqy0WVdZZ/yPofN6qLm/Mg Date: Fri, 19 Mar 2021 18:09:11 +0000 Message-ID: References: <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <161591246412.5771.17798271339560020312@ietfa.amsl.com> <20210316173921.GG79563@kduck.mit.edu> <20210316173921.GG79563@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: randy.pensive.org; dkim=none (message not signed) header.d=none;randy.pensive.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 76fc377f-b874-4239-b965-08d8eb0218df x-ms-traffictypediagnostic: SA1PR13MB4958: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LmV3c7kn4ZhnEsoIGcVFw9WLGSL7qy2Bjeeh5gJqif4SF8tg4t5ye9NVMkZQE8EgRZU6P2qne5x8hEXDSE5MmKIqfBeRh2yi0a+Kcro00aK2pzysY+eIAnZiugsDqwuy8zQ+IGkYC1teGzPe2202Oqc8XR2fbNbUmoLwoGRxC72AalV+t84FFMxQICHWwy+FyK/FU5ZjL/80HoLfBgtIn/AAh01FB8bb3y7+0/AVNMB1PrxrpOuQ+ZjTSRMnQxW/9RXnlU9ana3SvOqjM7ND6hhi7EJPc5j1AhASkl6JaWEamlNyWXqEHPiWrTP0kYrPShHMvjs4b+91URVWO6blsj8I8J45waSXQlmchXHgHRigToOY9jX/OSWItVLFZNTaHBpKtJZ5Kl/s5pOsY+xpzQv/7NyBSWV5ADmGrASet40iMrAqgpbpDg5d+fmiD7G03OXipuC6h3I9+kXBtUv955lzNDcyLDORLwO3iqdyGfXCCGMmaax8d/yF+wxKyiw03P5gocs6IeBMHFhkNbz8ChVRWhH5n6Ul95UK2kcXCwm8k/JF/+wksYK3KTH3iMJEPsU1T/b6PCJcQfle1WTfrJVBjwerJconjIxWhpEG0oHK8Gx9Gp+e1kZGhR3rIzbT34oCeSKWkCmW64H3SDum+33TCIedrioZSnC7WoE05I+DsrJ/6fWf23eg93WK+o+w+NbfRMeI9ww/c8vNQHDYkJP5IPKLrfjOiF5N3Mvi38U= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(39840400004)(376002)(346002)(186003)(83380400001)(66446008)(66946007)(54906003)(71200400001)(316002)(30864003)(5660300002)(86362001)(52536014)(66476007)(76116006)(166002)(66556008)(64756008)(26005)(53546011)(38100700001)(8676002)(6506007)(478600001)(8936002)(9686003)(55016002)(966005)(44832011)(2906002)(7696005)(4326008)(33656002)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ei42XJvMAT6GmTE+Wsa3uiRYANAemshBqh7zu8/vAVMAT49K0I+2GjsmmMLJ?= =?us-ascii?Q?BQxVHDLv5gYm96A+tK1UTXS/vd39WJ/elzH8IVGCA5cPSItpUrrkO8oxK6RN?= =?us-ascii?Q?4abxQdduXaaQTq5CbbDgTVPielCQKh/ceoX1aMTgEVr/0aZd7CTrIqsSZmoB?= =?us-ascii?Q?T3EhOnYyE6ebX3frbHnuYa13U3SyX4lTXXLKL/IiKOGgRdD5MHj+VAZ7b9A/?= =?us-ascii?Q?h3Bm4tS+OkbZYjKqUeudKl+fEsqpvpmgRVafe61frs1krovShUb6iMmu1M/U?= =?us-ascii?Q?vpJE/dpMHs/EuwhHIGkzC3dLElAZnw9NqPkH6RqCWzBC6XeJpdlGTBOZjEzg?= =?us-ascii?Q?DlAFlGCpzCKZ7KCkzeNeOmL8uUIh5DzGiMazsRqQ7rk7y+Mw59/L9paOfr9o?= =?us-ascii?Q?j5KrRM4628ojQUWfbPY94l3CWre3OmCScXBiX67TxXuKgVzf5Ag9c0SZMiVY?= =?us-ascii?Q?O5VsA5kvuwgLF56bgWMCZKAisnge2ELimAruzZS9kAhvu33zR9R811j/Cfvd?= =?us-ascii?Q?d4CNHMcslk6xdI/8G2FK7eQbLqsD1F/Xdr+wIYBlkL+LIiCHrijMMTjcvRYU?= =?us-ascii?Q?6BxW8u6KnSeOBaEWdyfP0l+9A6715/owzxhnzQkl6e8U95LZ2Cav0Fg4qSQT?= =?us-ascii?Q?XRae7Jm8qAkdqZ08sqvVxNWTuFM5BcddYso1c+fMXZoa1D1BI2VG36Se4VlI?= =?us-ascii?Q?QIbdwY7aOJq1vev9wFnRDA8mg/cNbsy8Br69carc8n/ye1EM594fByK5694W?= =?us-ascii?Q?GzPIs5pxWp37hfNS2BDxCJvTByXBRNTnz6Dj9Q3TJ+S6VswmJ1wQaXZ318Nd?= =?us-ascii?Q?Ctf+QlQhrUfuZqX6SqEfOaMKiN/AysRL8ulb1otkIZZAwTxjasJe9bT1ekdB?= =?us-ascii?Q?yMQ9rUBCW4IXMNQwxvuks9+YQF6tlVyOBHesbD4HEbrZpSY3oZKa9a+CQosI?= =?us-ascii?Q?0MPa4ybmuaJOyPQo2f5MvcLuixi9wDCc69wpQGqPDxiQfwWzqDCZW3/eJfxF?= =?us-ascii?Q?6a/Cmf5ful9J1WFapvaN1dDDpIOOvJOfBXeehaAyXT6qtEaLadANTr7yyI5B?= =?us-ascii?Q?Gvqa0c4/b6TGI2oiur2srI0rheceYjVPGgG7jh73fCEq0Ej4LO47bYj8uuB3?= =?us-ascii?Q?zSjWFrca9vGELla2jYc1zcBz3KoBztBhl9/QLKSOT/2H6NPoGnTF3wWwuKAt?= =?us-ascii?Q?QnziRbMtjtsno5d/K0tbW9dpg4ghL86AjpN1VkfNEB+mdyD8k8zcbnjA3T0z?= =?us-ascii?Q?EQkkkVb5PBmkwkQVaiIHy2155VnIg/RLT9iSIxSYmc43qLuxWA+YrNF4iY7R?= =?us-ascii?Q?Kx0=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR13MB23347EAFEEBBF83BA1827A4C85689SN6PR13MB2334namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 76fc377f-b874-4239-b965-08d8eb0218df X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2021 18:09:11.1672 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Oo9qeh+H1BA7mI10aIjPq2Y8qvEq/QpDU86aECnS9adg0AagRQn/RoVBgUsjr1+Sx4EHikB/ck09YWuEZTMAWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR13MB4958 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ecrit-location-profile-registry-policy-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 18:09:21 -0000 --_000_SN6PR13MB23347EAFEEBBF83BA1827A4C85689SN6PR13MB2334namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Randall, No, I don't have any more comments. Replies are good. Linda From: Randall Gellens Sent: Friday, March 19, 2021 12:56 PM To: Linda Dunbar Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@= ietf.org; ecrit@ietf.org; last-call@ietf.org; Murray S. Kucherawy ; Benjamin Kaduk Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, Thank you for reviewing the document. After the discussion, do you still ha= ve any questions or do you feel there is any ambiguity that needs to be res= olved? --Randall On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Best Regards, Linda Dunbar On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Best Regards, Linda Dunbar ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 9:34, Linda Dunbar via Datatracker wrote: Reviewer: Linda Dunbar Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Best Regards, Linda Dunbar -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 9:45, Murray S. Kucherawy wrote: Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:12, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar > Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK On 16 Mar 2021, at 10:12, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar > Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 10:12, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy > Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar > Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker > wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change o= r add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification. The DE will have discretion to determine w= hether an application should be accepted. The document contains no guidanc= e about particular SDOs, so the DE is left to decide whether to factor the = source into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the cal= l about "legitimate". -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote: Hi Linda, The current registration procedure (visible at https://www.iana.org/assignments/lost-location-profiles/lost-location-profi= les.xhtml) of Standards Action only requires a standards-track RFC to get an allocation; there is no designated expert involved in that procedure. RFC 8126 again remains a good reference for these registration policies. Thanks, Ben On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy superuser@gmail.com Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar linda.dunbar@futurewei.com Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker >> wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked with= appointing a designated expert (DE) to review registration requests agains= t the published specification. The DE will have discretion to determine whe= ther an application should be accepted. The document contains no guidance a= bout particular SDOs, so the DE is left to decide whether to factor the sou= rce into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the call= about "legitimate". -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:39, Benjamin Kaduk wrote: Hi Linda, The current registration procedure (visible at https://www.iana.org/assignments/lost-location-profiles/lost-location-profi= les.xhtml) of Standards Action only requires a standards-track RFC to get an allocation; there is no designated expert involved in that procedure. RFC 8126 again remains a good reference for these registration policies. Thanks, Ben On Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote: Murray, Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? Linda From: Murray S. Kucherawy superuser@gmail.com Sent: Tuesday, March 16, 2021 11:46 AM To: Linda Dunbar linda.dunbar@futurewei.com Cc: secdir@ietf.org; draft-ietf-ecrit-location-prof= ile-registry-policy.all@ietf.org; ecrit@ietf.org; last-c= all@ietf.org Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01 Hi Linda, thanks for your review. Comments below. On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker >> wrote: This document doesn't seem to be complete. The document claims that it chan= ges the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or add values. But which SDOs are allowed? Are there any procedures to identif= y which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values? Specification Required is defined in RFC 8162. The IESG will be tasked with= appointing a designated expert (DE) to review registration requests agains= t the published specification. The DE will have discretion to determine whe= ther an application should be accepted. The document contains no guidance a= bout particular SDOs, so the DE is left to decide whether to factor the sou= rce into the approval or rejection of the request. So any SDO can make a request to update the registry. The DE makes the call= about "legitimate". -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar > wrote: Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? No, the current rules for that registry are specified by Standards Action (= Section 4.9 of RFC 8126), which requires a standards track RFC. There's no= designated expert in that model. The working group wants to change the po= licy to the less restrictive model that allows for specifications published= outside of the IETF to qualify, subject to expert review. -MSK On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar > wrote: Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? No, the current rules for that registry are specified by Standards Action (= Section 4.9 of RFC 8126), which requires a standards track RFC. There's no= designated expert in that model. The working group wants to change the po= licy to the less restrictive model that allows for specifications published= outside of the IETF to qualify, subject to expert review. -MSK ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 10:40, Murray S. Kucherawy wrote: On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar > wrote: Then why need this document? Isn't it already the practice that "The IESG will be tasked with appointing= a designated expert (DE) to review registration requests against the publi= shed specification"? No, the current rules for that registry are specified by Standards Action (= Section 4.9 of RFC 8126), which requires a standards track RFC. There's no= designated expert in that model. The working group wants to change the po= licy to the less restrictive model that allows for specifications published= outside of the IETF to qualify, subject to expert review. -MSK -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit On 16 Mar 2021, at 14:01, Randall Gellens wrote: I just want to add that the document currently does contain some guidance. = Section 4 (IANA Considerations) contains: The reviewer should verify that: o the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope; --Randall -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call --_000_SN6PR13MB23347EAFEEBBF83BA1827A4C85689SN6PR13MB2334namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Randall,

 

No, I don’t have any more comments. Replies ar= e good.

 

Linda

 

From: Randall Gellens <rg+ietf@randy.pensi= ve.org>
Sent: Friday, March 19, 2021 12:56 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-poli= cy.all@ietf.org; ecrit@ietf.org; last-call@ietf.org; Murray S. Kucherawy &l= t;superuser@gmail.com>; Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-pr= ofile-registry-policy-01

 

Hi Linda,<= /o:p>

Thank you for r= eviewing the document. After the discussion, do you still have any question= s or do you feel there is any ambiguity that needs to be resolved?

--Randall<= /o:p>

On 16 Mar 2021,= at 9:34, Linda Dunbar via Datatracker wrote:

R= eviewer: Linda Dunbar
Review result: Not Ready

I= have reviewed this document as part of the security directorate's ongoing<= br> effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area direct= ors.
Document editors and WG chairs should treat these comments just like any ot= her
last call comments.

T= his document doesn't seem to be complete. The document claims that it chang= es
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

B= est Regards,
Linda Dunbar

On 16 Mar 2021,= at 9:34, Linda Dunbar via Datatracker wrote:

R= eviewer: Linda Dunbar
Review result: Not Ready

I= have reviewed this document as part of the security directorate's ongoing<= br> effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area direct= ors.
Document editors and WG chairs should treat these comments just like any ot= her
last call comments.

T= his document doesn't seem to be complete. The document claims that it chang= es
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

B= est Regards,
Linda Dunbar

E= crit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/listinfo/ecrit=

On 16 Mar 2021,= at 9:34, Linda Dunbar via Datatracker wrote:

R= eviewer: Linda Dunbar
Review result: Not Ready

I= have reviewed this document as part of the security directorate's ongoing<= br> effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area direct= ors.
Document editors and WG chairs should treat these comments just like any ot= her
last call comments.

T= his document doesn't seem to be complete. The document claims that it chang= es
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

B= est Regards,
Linda Dunbar

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/last-c= all

On 16 Mar 2021,= at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.  Comments below.<= o:p>

 

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatra= cker <noreply@ietf.org> wrote= :

This document doesn't seem to be complete. The document = claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Required is defined in RFC 8162.  The= IESG will be tasked with appointing a designated expert (DE) to review reg= istration requests against the published specification.  The DE will have discretion to determine whether an application should be = accepted.  The document contains no guidance about particular SDOs, so= the DE is left to decide whether to factor the source into the approval or= rejection of the request.

 

So any SDO can make a request to update the registry.&nb= sp; The DE makes the call about "legitimate".

 

-MSK

On 16 Mar 2021,= at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.  Comments below.<= o:p>

 

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatra= cker <noreply@ietf.org> wrote= :

This document doesn't seem to be complete. The document = claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Required is defined in RFC 8162.  The= IESG will be tasked with appointing a designated expert (DE) to review reg= istration requests against the published specification.  The DE will have discretion to determine whether an application should be = accepted.  The document contains no guidance about particular SDOs, so= the DE is left to decide whether to factor the source into the approval or= rejection of the request.

 

So any SDO can make a request to update the registry.&nb= sp; The DE makes the call about "legitimate".

 

-MSK

E= crit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/listinfo/ecrit=

On 16 Mar 2021,= at 9:45, Murray S. Kucherawy wrote:

Hi Linda, thanks for your review.  Comments below.<= o:p>

 

On Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatra= cker <noreply@ietf.org> wrote= :

This document doesn't seem to be complete. The document = claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Required is defined in RFC 8162.  The= IESG will be tasked with appointing a designated expert (DE) to review reg= istration requests against the published specification.  The DE will have discretion to determine whether an application should be = accepted.  The document contains no guidance about particular SDOs, so= the DE is left to decide whether to factor the source into the approval or= rejection of the request.

 

So any SDO can make a request to update the registry.&nb= sp; The DE makes the call about "legitimate".

 

-MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/l= ast-call

On 16 Mar 2021,= at 10:12, Linda Dunbar wrote:

Murray,

 

Then why need this do= cument?

Isn’t it alread= y the practice that “The IESG= will be tasked with appointing a designated expert (DE) to review registra= tion requests against the published specification”?

 <= span style=3D"color:#777777">

Linda

 

From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.or= g
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-pr= ofile-registry-policy-01

 

Hi Linda, thanks for = your review.  Comments below.

 

On Tue, Mar 16, 2021 = at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

This document doesn't= seem to be complete. The document claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Require= d is defined in RFC 8162.  The IESG will be tasked with appointing a d= esignated expert (DE) to review registration requests against the published= specification.  The DE will have discretion to determine whether an application should be accepted.  The document= contains no guidance about particular SDOs, so the DE is left to decide wh= ether to factor the source into the approval or rejection of the request.

 

So any SDO can make a= request to update the registry.  The DE makes the call about "le= gitimate".

 

-MSK

On 16 Mar 2021,= at 10:12, Linda Dunbar wrote:

Murray,

 

Then why need this do= cument?

Isn’t it alread= y the practice that “The IESG= will be tasked with appointing a designated expert (DE) to review registra= tion requests against the published specification”?

 <= span style=3D"color:#777777">

Linda

 

From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.or= g
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-pr= ofile-registry-policy-01

 

Hi Linda, thanks for = your review.  Comments below.

 

On Tue, Mar 16, 2021 = at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

This document doesn't= seem to be complete. The document claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Require= d is defined in RFC 8162.  The IESG will be tasked with appointing a d= esignated expert (DE) to review registration requests against the published= specification.  The DE will have discretion to determine whether an application should be accepted.  The document= contains no guidance about particular SDOs, so the DE is left to decide wh= ether to factor the source into the approval or rejection of the request.

 

So any SDO can make a= request to update the registry.  The DE makes the call about "le= gitimate".

 

-MSK

E= crit mailing list
Ecrit@ietf.= org
<= span style=3D"color:#777777">https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021,= at 10:12, Linda Dunbar wrote:

Murray,

 

Then why need this do= cument?

Isn’t it alread= y the practice that “The IESG= will be tasked with appointing a designated expert (DE) to review registra= tion requests against the published specification”?

 <= span style=3D"color:#777777">

Linda

 

From: Murray S. Kucherawy <superuser@gmail.com>
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>
Cc: secdir@ietf.org; draft-ietf-ecrit-location-profile-registry-policy.all@ietf.org; ecrit@ietf.org; last-call@ietf.or= g
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-pr= ofile-registry-policy-01

 

Hi Linda, thanks for = your review.  Comments below.

 

On Tue, Mar 16, 2021 = at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org> wrote:

This document doesn't= seem to be complete. The document claims that it changes
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure.  It says allowing other SDOs to cha= nge or
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

 

Specification Require= d is defined in RFC 8162.  The IESG will be tasked with appointing a d= esignated expert (DE) to review registration requests against the published= specification.  The DE will have discretion to determine whether an application should be accepted.  The document= contains no guidance about particular SDOs, so the DE is left to decide wh= ether to factor the source into the approval or rejection of the request.

 

So any SDO can make a= request to update the registry.  The DE makes the call about "le= gitimate".

 

-MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/last= -call

On 16 Mar 2021,= at 10:39, Benjamin Kaduk wrote:

H= i Linda,

T= he current registration procedure (visible at
https= ://www.iana.org/assignments/lost-location-profiles/lost-location-profiles.x= html)
of Standards Action only requires a standards-track RFC to get an
allocation; there is no designated expert involved in that procedure.
RFC 8126 again remains a good reference for these registration policies.

T= hanks,

B= en

O= n Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote:

M= urray,

T= hen why need this document?
Isn’t it already the practice that “The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification”?

L= inda

F= rom: Murray S. Kucherawy superu= ser@gmail.com
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com
Cc: secdir= @ietf.org; draft-ietf-ecrit-location-profile-regi= stry-policy.all@ietf.org; ecrit@ietf.= org; last-ca= ll@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01

H= i Linda, thanks for your review. Comments below.

O= n Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org<mail= to:noreply@ietf.org>> wrote:
This document doesn't seem to be complete. The document claims that it chan= ges
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

S= pecification Required is defined in RFC 8162. The IESG will be tasked with = appointing a designated expert (DE) to review registration requests against= the published specification. The DE will have discretion to determine whether an application should be accepted. The doc= ument contains no guidance about particular SDOs, so the DE is left to deci= de whether to factor the source into the approval or rejection of the reque= st.

S= o any SDO can make a request to update the registry. The DE makes the call = about "legitimate".

-= MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
<= span style=3D"color:#999999">https://www.ietf.org/mailman/listinfo/last-cal= l

On 16 Mar 2021,= at 10:39, Benjamin Kaduk wrote:

H= i Linda,

T= he current registration procedure (visible at
https= ://www.iana.org/assignments/lost-location-profiles/lost-location-profiles.x= html)
of Standards Action only requires a standards-track RFC to get an
allocation; there is no designated expert involved in that procedure.
RFC 8126 again remains a good reference for these registration policies.

T= hanks,

B= en

O= n Tue, Mar 16, 2021 at 05:12:52PM +0000, Linda Dunbar wrote:

M= urray,

T= hen why need this document?
Isn’t it already the practice that “The IESG will be tasked wit= h appointing a designated expert (DE) to review registration requests again= st the published specification”?

L= inda

F= rom: Murray S. Kucherawy superu= ser@gmail.com
Sent: Tuesday, March 16, 2021 11:46 AM
To: Linda Dunbar linda.dunbar@futurewei.com
Cc: secdir= @ietf.org; draft-ietf-ecrit-location-profile-regi= stry-policy.all@ietf.org; ecrit@ietf.= org; last-ca= ll@ietf.org
Subject: Re: Secdir last call review of draft-ietf-ecrit-location-profile-r= egistry-policy-01

H= i Linda, thanks for your review. Comments below.

O= n Tue, Mar 16, 2021 at 9:34 AM Linda Dunbar via Datatracker <noreply@ietf.org<mail= to:noreply@ietf.org>> wrote:
This document doesn't seem to be complete. The document claims that it chan= ges
the policy of the Location-to-Service Translation (LoST) Location Profile registry from Standards Action to Specification Required, but it doesn't specify what is the new procedure. It says allowing other SDOs to change or=
add values. But which SDOs are allowed? Are there any procedures to identif= y
which SDOs are legitimate? can any organizations, say XYZ, change, add or delete the values?

S= pecification Required is defined in RFC 8162. The IESG will be tasked with = appointing a designated expert (DE) to review registration requests against= the published specification. The DE will have discretion to determine whether an application should be accepted. The doc= ument contains no guidance about particular SDOs, so the DE is left to deci= de whether to factor the source into the approval or rejection of the reque= st.

S= o any SDO can make a request to update the registry. The DE makes the call = about "legitimate".

-= MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/last-c= all

-= -
last-call mailing list
last-ca= ll@ietf.org
<= span style=3D"color:#777777">https://www.ietf.org/mailman/listinfo/last-cal= l

On 16 Mar 2021,= at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Then why need this document?

Isn’t it already the practice that “The IESG will be tasked with appointing a designated expert (DE) to review registration = requests against the published specification”?

 

No, the current rules for that registry are specified by= Standards Action (Section 4.9 of RFC 8126), which requires a standards tra= ck RFC.  There's no designated expert in that model.  The working group wants to change the policy to the less rest= rictive model that allows for specifications published outside of the IETF = to qualify, subject to expert review.

 

-MSK

On 16 Mar 2021,= at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Then why need this document?

Isn’t it already the practice that “The IESG will be tasked with appointing a designated expert (DE) to review registration = requests against the published specification”?

 

No, the current rules for that registry are specified by= Standards Action (Section 4.9 of RFC 8126), which requires a standards tra= ck RFC.  There's no designated expert in that model.  The working group wants to change the policy to the less rest= rictive model that allows for specifications published outside of the IETF = to qualify, subject to expert review.

 

-MSK

E= crit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/listinfo/ecrit

On 16 Mar 2021,= at 10:40, Murray S. Kucherawy wrote:

On Tue, Mar 16, 2021 at 10:12 AM Linda Dunbar <linda.dunbar@futurewei.com> = wrote:

Then why need this document?

Isn’t it already the practice that “The IESG will be tasked with appointing a designated expert (DE) to review registration = requests against the published specification”?

 

No, the current rules for that registry are specified by= Standards Action (Section 4.9 of RFC 8126), which requires a standards tra= ck RFC.  There's no designated expert in that model.  The working group wants to change the policy to the less rest= rictive model that allows for specifications published outside of the IETF = to qualify, subject to expert review.

 

-MSK

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/l= ast-call

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

E= crit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/listinfo/ecrit=

On 16 Mar 2021,= at 14:01, Randall Gellens wrote:

I= just want to add that the document currently does contain some guidance. S= ection 4 (IANA Considerations) contains:

T= he reviewer should verify that:
o the proposed new value is specified by the IETF, NENA, or a
similar SDO in which location profiles are in scope;

-= -Randall

-= -
last-call mailing list
last-ca= ll@ietf.org
https://www.ietf.org/mailman/listinfo/last-c= all

--_000_SN6PR13MB23347EAFEEBBF83BA1827A4C85689SN6PR13MB2334namp_-- From nobody Fri Mar 19 22:33:38 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7BB3A1AD0; Fri, 19 Mar 2021 22:32:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: draft-ietf-lsr-ospf-prefix-originator.all@ietf.org, last-call@ietf.org, lsr@ietf.org, watsonbladd@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161621836770.16465.11678374336820664293@ietfa.amsl.com> Reply-To: Watson Ladd Date: Fri, 19 Mar 2021 22:32:47 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lsr-ospf-prefix-originator-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 05:32:48 -0000 Reviewer: Watson Ladd Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. This document describes a small extension to OSPF to include information of the originating router for a prefix, which otherwise would be lost as the prefix proceeds to be readvertised. This information is quite useful when determining what is going on under trying circumstances. Sincerely, Watson Ladd From nobody Sat Mar 20 16:00:47 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEF63A26F8; Thu, 18 Mar 2021 03:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1616062482; bh=/tl0HaIllYnyUkoyygVh3LTGaK1RPu2pd4DyJF47w5o=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ampGVw/7tpcnPYxOves39V5xY4aRvoevqechQ3dTMjbUYZQa8RNPHz2DQT2d7oJS1 yQB0w8PAFCx2pQevBttIhfrkfoZS5ecEapVrmIDiN8Tc+V6QDcdQyVFaGTtO0Rz2q5 +D0daNBgodMgCPvYI3KSmOSSfsyorBSXKvhKivQU= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Mar 18 03:14:42 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6143A26F2; Thu, 18 Mar 2021 03:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1616062482; bh=/tl0HaIllYnyUkoyygVh3LTGaK1RPu2pd4DyJF47w5o=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ampGVw/7tpcnPYxOves39V5xY4aRvoevqechQ3dTMjbUYZQa8RNPHz2DQT2d7oJS1 yQB0w8PAFCx2pQevBttIhfrkfoZS5ecEapVrmIDiN8Tc+V6QDcdQyVFaGTtO0Rz2q5 +D0daNBgodMgCPvYI3KSmOSSfsyorBSXKvhKivQU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D683A26F1 for ; Thu, 18 Mar 2021 03:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CTGbFwm7CA4 for ; Thu, 18 Mar 2021 03:14:38 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681D93A26EC for ; Thu, 18 Mar 2021 03:14:38 -0700 (PDT) Received: from [89.187.161.155] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lMpfo-0001aP-K9 for new-work@ietf.org; Thu, 18 Mar 2021 10:14:37 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <7a025ba6-027b-b009-d71c-5fdf448f36a2@w3.org> Date: Thu, 18 Mar 2021 18:14:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 20 Mar 2021 16:00:46 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Browser Testing and Tools Working Group (until 2021-04-16/17) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 10:14:44 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBCcm93c2Vy IFRlc3RpbmcgYW5kIFRvb2xzIFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcv MjAyMS8wMy9wcm9wb3NlZC1iYnR0LXdnLWNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmlu ZyB0aGF0IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRo aXMgZHJhZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUg cmV2aWV3IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDAzOjU5 IFVUQyBvbiAyMDIxLTA0LTE3CigyMzo1OSwgRWFzdGVybsKgIHRpbWUgb24gMjAyMS0wNC0xNikg b24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIuClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHB1YmxpYy1u ZXctd29ya0B3My5vcmcsCndoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xp c3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBj b21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRl ZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29t bWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0 ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlh IHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklm IHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlv biwgcGxlYXNlCmNvbnRhY3QgTWljaGFlbCBTbWl0aCwgQnJvd3NlciBUZXN0aW5nIGFuZCBUb29s cyBXRyBUZWFtIENvbnRhY3QsCmF0IDxtaWtlQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFu IEppYSzCoCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRwOi8vd3d3Lncz Lm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5v cmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Sat Mar 20 21:04:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEE13A144A; Sat, 20 Mar 2021 21:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnB2GWHRQDz2; Sat, 20 Mar 2021 21:03:57 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C433A1449; Sat, 20 Mar 2021 21:03:53 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12L43h0W023385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Mar 2021 00:03:47 -0400 Date: Sat, 20 Mar 2021 21:03:42 -0700 From: Benjamin Kaduk To: Christian Huitema Cc: secdir@ietf.org, draft-ietf-dtn-bpsec-default-sc.all@ietf.org Message-ID: <20210321040342.GO79563@kduck.mit.edu> References: <161611713427.19367.10392386702864224514@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161611713427.19367.10392386702864224514@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-dtn-bpsec-default-sc-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 04:04:02 -0000 Hi Christian, Thanks for the spot-on review! BP security is indeed pretty complicated with all those moving pieces, and I agree that test vectors would help give confidence in correctness of implementations. I had good experiences working with Ed on other DTN documents (the worst part was self-induced delay on my part), so I expect that the WG will be pretty receptive to your suggestions. Thanks again, Ben On Thu, Mar 18, 2021 at 06:25:34PM -0700, Christian Huitema via Datatracker wrote: > Reviewer: Christian Huitema > Review result: Has Nits > > I have reviewed draft-ietf-dtn-bpsec-default-sc-02 as part > of an early security review requested by the transport AD. The draft specifies > how to use either HMAC/SHA based authencation or AES-GCM authenticated > encryption in the framework defined by the Bundle Protocol Security > Specification (draft-ietf-dtn-bpsec-27) for the Bundle Protocol Version 7 > draft-ietf-dtn-bpbis-31.txt. > > The specifications are straightforward applications of well-known algorithms: > HMAC256/SHA256, HMAC384/SHA384, HMAC512/SHA512, AES128 GCM, and AES256 GCM. The > text is written in a detailed manner, guiding potential developers through the > implementation of these algorithms. For me, these descriptions seem almost > ready, expect for two nits. However, the overall system appears very complex, > and some ways to manage that complexity would be welcome. My minimum suggestion > would be to add test vectors. > > The first nit regards the table of BIB-HMAC-SHA2 Security Parameters in section > 3.3.4. The default value for the SHA Variant is specified as "256", but section > 3.3.1 only defines values 5, 6 and 7 for that parameter. I assume that the > intent is to default to HMAC256/SHA256, but in that case the default should be > 5, not 256. > > The second nit regards the discussion of authentication and confidentiality in > section 4.1. AEAD algorithms distinguish between authenticated data and > encrypted data. The text expresses a different concept,separate definitions of > "scope of confidentiality" and "scope of authentication". I suggest that these > paragraphs be rewrittent to specify that "the scope of authentication is always > the union of the additional data and the scope of confidentiality." > > These are small issues. My real concern with this document is the overall > complexity of the Bundle Protocol and the Security specification. The protocols > appear specified for maximum flexibility. Messages can be relayed. Relays can > add their own security blocks to the bundle. Authentication and encryption can > apply to different blocks in the bundle. Messages can be fragmented. Nodes can > choose to apply different level of security to different bundles, or to > different blocks in the same bundle. I suppose that these choices are justified > by application requirements, but all this complexity may end up causing > interoperability issues, and potential security failures. > > The way CBOR encoding are used brings another source of complexity. CBOR allows > for different ways of encoding the same data. The bundle security document and > this algorithm specification document request that some data parts be > re-encoded in the "canonical" CBOR format before authentication tags are > computed or verified. Experience in other domains shows that relying on > canonization before authentication is very fragile, and a source of > interoperability failures. It would be much more robust to assume that > authenticated objects are immutable, and that the wire format of these objects > is fed directly into the hash algorithm. > > To mitigate the risk of interoperability failures, I suggest adding test > vectors to the specification. Each test case should start with a clear text > test bundle, apply either authentication or authenticated encryption according > to some variations of the authentication or AAD scope flags, and produce a > result. Different test vectors might start with different mode of CBOR > encoding, to test the canonization process. This kind of investment might save > a lot of time to future developers! > > Not a comment on this draft, but I see lot of potential issues with > fragmentation. I understand that in a Delay Tolerant Network,relays need to be > able to fragment messages. The draft correctly points out that if an > authenticated message is fragmented, authentication can only be received while > all fragments are received. However, this would not protect from attacks > against fragmentation similar to those seen in IP, IPv6 and TCP. I think that > some kind of secure fragmentation protocol need to be studied and specified by > the working group. > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Sun Mar 21 08:31:51 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BA23A0D81; Sun, 21 Mar 2021 08:31:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: draft-ietf-ntp-port-randomization.all@ietf.org, last-call@ietf.org, ntp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161634069996.31375.17595634557822390595@ietfa.amsl.com> Reply-To: Sean Turner Date: Sun, 21 Mar 2021 08:31:40 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ntp-port-randomization-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2021 15:31:40 -0000 Reviewer: Sean Turner Review result: Ready Hi! I am doing this review as part of the Security Directorate. This I-D updates NTP v4 [RFC 5095] to recommend the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required. The port randomization recommendation is based on BCP 156 [RFC6056], which recommends the randomization of transport-protocol ephemeral ports. This I-D is in fact co-authored by one of the co-authors of BCP 156. The I-D motivates the recommendation and enumerates some considerations as they relate to NTP as well as identifies the exact changes (i.e., two-sentence dstport replaced with more text). It also appears that this I-D is well implemented as noted in the implementation status section. From nobody Sun Mar 21 23:48:11 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40FF3A154F; Sun, 21 Mar 2021 23:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.698 X-Spam-Level: X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=F/f0JJrC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EeGiQ8u2 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 jj0268jMGKOE; Sun, 21 Mar 2021 23:47:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C116A3A154E; Sun, 21 Mar 2021 23:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1516; q=dns/txt; s=iport; t=1616395675; x=1617605275; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mRNbEIjUnTxFKU0oVTmSo6LOWogXwtwNhIiU8QbnP9U=; b=F/f0JJrCwTEzITH9AuC7yu6gCQzpkJvzgW4MPt75s7pI1rLfbeu0STCU dTzjbwv8s8YYg4ozqYgECPQr6nl88d9GtvxWGlgcSVSp3SnMlQXE3O/L8 tXThqLaoyoDXCwG0PJnX5bfPVj6EMxo6nj/v0nQbvuZuMu/wha/GoLrPG Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3ArE1zEBKqbTcI/EbfDtmcuZUyDhhPgJ39IxIV5?= =?us-ascii?q?5w7irlHbqWk+dH4MVfC4el25HfGWIza77RPjO+F+6zjWGlV55GHvThCdZFXT?= =?us-ascii?q?BYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8P3ZlmUqXq3vnYeH?= =?us-ascii?q?xzlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/VZ9?= =?us-ascii?q?w=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A/1tX0auPiOGntWK5YwnfrNRL7skCB4cji2?= =?us-ascii?q?hD6mlwRA09T+WxrOrrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOgLU5FYyJGC?= =?us-ascii?q?3ronGhIo0n14vtxDX8Bzbzn9Qy6Y5JSII7MtH5CDFB4vrSyAOzH888hPyO96?= =?us-ascii?q?61jenTpk0dMj1CQYsI1XYfNi+wFEpqSA5aQb8wE5SB7sRKzgDQB0g/RMK9G3?= =?us-ascii?q?UDQqz/vNXNjp3relorABQg5QmIg1qTmf/HOjKf2QoTVC4K/Kc6/QH+4kLEz4?= =?us-ascii?q?iAk9X+8B/T0GfP849b8eGA9vJvDNGB4/JlUQnEpR2vYO1aKti/lRAz5Nqi8V?= =?us-ascii?q?M71OTLyi1QQ/hbz1P0UiWLrQD22w/muQxeq0PK7VODm3PsrYjYaVsBerB8rL?= =?us-ascii?q?lUeBfY9EYs1esUuMkgsg7p1Os0MTr6kCvw/NTOXR1x/3DE3EYKq/IZjHBUTO?= =?us-ascii?q?IlGdlshLEf509cHdMhGy/3+ekcYZFTJfzc//pffBemaWnYtABUsaWRd0k0dy?= =?us-ascii?q?32JnQqi4iw6Xx7jXp5x0wXyIg0hXEb7q8wTJFC+qDtLrlovKsmdL5UUYtNQM?= =?us-ascii?q?M6BeenAG3ERhzBdEiIJ078Ka0BM3XR77bq/bQO4v2wcpBg9upxpL3xFHdj8U?= =?us-ascii?q?IicUPnDsODmLdR9ArWfWm7VTPxjuZT+oZ+ob+5YLbwKyWMRBQPnqKb0rAiK/?= =?us-ascii?q?yef8z2FINdAvflI2erM51OxRfCV55bLmRbX9YSvto9RlKSssPGIoDnrYXgAb?= =?us-ascii?q?HuDYuoNQxhdnL0A3MFUjS2Dt5H9FqXVnjxhwWUW36FQD24wbtAVIzhu8QDwo?= =?us-ascii?q?kEMYNB9iIPj06i282NITpe9qg/fE50JqL7grq2zFPGpFrg3iFMAF5wH0xV6L?= =?us-ascii?q?LvXzdhvgkRKX75dr4FppGYYmBd3HyOIxdlVMPIGAtDp1B6kJjHa6C49GQHMZ?= =?us-ascii?q?aKI2iah3wcqDahVJEHgJCO4s/jZ9clFJo8QbdwEg/KDhRxng5vpA54GVc5b3?= =?us-ascii?q?6aMgmrpbSujZQSCu2aSsJ1hx2zJ9VI7VjFs1+HmM0pTnwHfjKnXMKNmzwyTz?= =?us-ascii?q?5MilAZyd5FvJOw3RKUbUo2mqARLUBFYmX/OsM2MC21IKFv3o3NVC41Z2GQnj?= =?us-ascii?q?Cegww0YQPRhjUvr12kCzaVd/HNCkdaoVZC3M/RgQlJX1TYWV5sYXZntoA4Mm?= =?us-ascii?q?LKth9IoLO2T5v29XeNYV0fxexYChX5WH85JwNjwM3f7m/JpB+LCWgmypIyPu?= =?us-ascii?q?bUEbQkdPXJ1mmwLZCT/Jt2bMN87dJrMsvjvfQMVv/acwiJLCngA+dswACNoG?= =?us-ascii?q?05URME5UUMgLft2Bf/6nK/02N6Cf3OIE5+T7VzGaDW00H0A/KJ2o5+l9Q7oK?= =?us-ascii?q?+5NXjwcMePzeXSYyRYIh3e5W6wQOdAk+EfgYsi8L9yFYLcSz3GyTVO2wg/Nt?= =?us-ascii?q?79kAcGW7tgiYqxTLNHbogXYWZU71ApnNOAIA8itRH3GPY3eRUog2XAN92E7r?= =?us-ascii?q?LUodMUcwG8jRq1PUPa/zxW/v/DUSfGz7IcBq4qKWldaUQ36h1Zjau/XpyVDB?= =?us-ascii?q?/ve/BI/VK8PHP4baRUT7KdH64M6hl9+NOFkoasBmXF8RGVuSE+JK1A82yqG5?= =?us-ascii?q?zvRA2NHPNF6Ny8NxCHhLCw7Mu6kTfwTn+6Zi0j9Pl4XF1Vat4GjD8oyJAz2G?= =?us-ascii?q?y1TKf8p0o+iVtQ4T19jDfWq8GbyXaeGVsDKBHTh5VdQCJaPXeJh9nU6OTw7g?= =?us-ascii?q?WJ3BFVnZ3YUFpKdt5AG9IMXpH6IidnJ88XpqOp9cMU81N+SQZrCXU9hjD71/?= =?us-ascii?q?5n2rn82Oy6YZyRNUvV?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPBQApPVhg/5RdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgVCBU1EHgVA2MQqEOINIA4U5iD8DiiuPCoJTA1QLAQEBDQE?= =?us-ascii?q?BMgIEAQGEUAIXgWQCJTgTAgMBAQsBAQUBAQECAQYEcYVhDYZEAQEBBCMRDAE?= =?us-ascii?q?BMQYBCwQCAQgRBAEBAwImAgICHxEVCAgCBAENBQiFPgMvAUuhEAKKHneBMoM?= =?us-ascii?q?EAQEGhRQNC4ITCYEPKoJ2hAmGRCYcgUlCgRFDglk+gh6CJIMUNYIrgy4BA4F?= =?us-ascii?q?SGUsvARiUQpRJkE4wWwqDBpcoBIVQpD+VAY5uj02EPgICAgIEBQIOAQEGgSN?= =?us-ascii?q?II4FZcBWDJFAXAg2OH4NvillzOAIGCgEBAwl8jVABgQ4BAQ?= X-IronPort-AV: E=Sophos;i="5.81,268,1610409600"; d="scan'208";a="866068908" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Mar 2021 06:47:42 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 12M6lgUP016652 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 22 Mar 2021 06:47:42 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 22 Mar 2021 01:47:41 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 22 Mar 2021 01:47:41 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 22 Mar 2021 02:47:41 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rvtw25Ahs+5bij3K0Gzi5IyCTEwogl5Bz1r0b+M0dujhj+mYQZlCFMgICdj9FxH+Y+4IcfPrp2uz6hRwvuEDww97IVNo08o/HL4h5A+UxeVtRo1oOjHN0dt3ecwpc8uvRPxqfRgukeplU2I5+lBXyWaOQW8q7iRsTEPuDqnaM1Scax6Yw7ng9dHPxI3BNkAaU3ab8oVfb6eSo+eEUvOX0sd49UmOoWjT9eLtNJLGVxMd9Y2/606jvUEsnV7354EBYU7DxJu+HYWLgizC0+z3sftWmBawttSxoET7d86V/VAJOyXEz0OAqgUjDLNY/zRV0p+94x9Qhf75fvkjzLXD1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mRNbEIjUnTxFKU0oVTmSo6LOWogXwtwNhIiU8QbnP9U=; b=amTIkzzkGVSK7E9WFYsW3Hs/SS+pR3kUSUlRmAfyL+Fo/9kTnxIRqKXElAUGrmgCLyqv5Xcsaxho/M9pyqmFFMuW7yCgXUBcgCGFFYF1lpMgFlEWlkdK1muX6uXnSIT/uOqxiJjxNLhXIT5QtaP/siu0/1yMBjc2PLrCUI1YlcOVxgo8o4NF2VPixKfk5tV3K+tFHBvczASzKaU3YZL5szvU5dgWeO7W8pFCZbgayls505t8twRC3J/uZH96FEEI+6JKXoVHvq+0RKGa7na2O67tM8P19wkbkRJLF5IKV9KaEifTBJ4gBQ8AqSDkEfXS8qgnITrm7pOd7kobiFireA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mRNbEIjUnTxFKU0oVTmSo6LOWogXwtwNhIiU8QbnP9U=; b=EeGiQ8u2VgZRYQSLZ2pl78Eq2X4WP1pdmYSRPvvh/BvP1gRiCY6cXD9dHJvwIaSHkHjl+RRDoiIZhM40a6TOuE5sA2/TByIFZZ3bJ1svIHbKn8DIdBahim1g7quJrolQPLdiOPCYWEpSxjRJGhIg/ImXm6E8ftHe5ui7jVEFQ2c= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4604.namprd11.prod.outlook.com (2603:10b6:303:2f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.25; Mon, 22 Mar 2021 06:47:40 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::592f:2e19:cf5b:a0f5]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::592f:2e19:cf5b:a0f5%4]) with mapi id 15.20.3955.025; Mon, 22 Mar 2021 06:47:40 +0000 From: "Ketan Talaulikar (ketant)" To: Watson Ladd , "secdir@ietf.org" CC: "draft-ietf-lsr-ospf-prefix-originator.all@ietf.org" , "last-call@ietf.org" , "lsr@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-lsr-ospf-prefix-originator-09 Thread-Index: AQHXHUp/V9M6EWIkBE6QWgtSE3tqO6qPk7og Date: Mon, 22 Mar 2021 06:47:39 +0000 Message-ID: References: <161621836770.16465.11678374336820664293@ietfa.amsl.com> In-Reply-To: <161621836770.16465.11678374336820664293@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5712d0fa-8d53-41ea-36c2-08d8ecfe6313 x-ms-traffictypediagnostic: MW3PR11MB4604: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3IY4oqJfzbVk1E63CgtYHzbD5XwbeOewNwnQC8A7Er9XY52yTPctsEXf0Pyfp8c7FuLHiwyTR9aP57iqqx1TCTYYaSI5r7r2mtgPcPMU4QPguLXFlmoa/JttzEr41DKayvytjkQcoiiSKTO8wofp3S/3VOQzTQksevpsZ6JLF8ndaZ1WducN3uRlFgUAYauwBsx0LK+/WRoQO7/1O+IkoI1d7IG7VS45QiNvStqJMKWGXrXntF2XIBOMLweKPfqo43wX00G1go6ggwX+EzZ+VyWWy5rfU+MWaJnlJEWsAhnSJrB08KCFfWqPzdu7MqABqSBtXjnPjkxrC1rTgplRDnNv/DQoP6aHN/Ee+Qehwu4fomiKksIQ5qrwoNtUDbqFcLtaZr4nIuatdCeEAC/slL7TVqlSo6g5XFfQ9/1LHuA5JxXJW5cl7NAUFttGKHLm4nzj5f1qdn/Y4mQD03sadaE+WKrcSauvUSonQo5nP2VpHMPS3f4CZMIaIzyqeU4hcsTmI3mY+/J9hDF30tiL3WvGZw1pmCq//gkJQCTLvVOiIfKavHrXxZRy/wLzYuL1ChkzGLm94gl+xDm97Kd05eteN1FW7yO1281z4KFCbz5z5GpHJ3fi4Lcd+MmSFHJeRAdItmV7tXCPhmJSxJemCzModChlxzUxHLVXIkb3Vgc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(376002)(346002)(366004)(39860400002)(9686003)(55016002)(66574015)(478600001)(83380400001)(71200400001)(7696005)(53546011)(6506007)(38100700001)(8936002)(4326008)(26005)(8676002)(186003)(64756008)(66946007)(316002)(110136005)(5660300002)(52536014)(66446008)(2906002)(33656002)(54906003)(66556008)(76116006)(86362001)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?VkN2WkVjSEJNR05JUGVmbHNob3orWHlqdkM2T3dLWGkxbVNtRW1RM0pzR3Nq?= =?utf-8?B?MjB6VEE1VUJQazhCeVFuN2FpWGlHQjdQZFkxNSt4M0VqOThFZHlMWXY1NXl0?= =?utf-8?B?M09iUWJ4OW1zSFJDL1kydDFZRzhjaU1yQVp2ZHVBUmE4WTMrTDhsYU40QVA5?= =?utf-8?B?ZnVEUlliMVNQOUg2RTJjSkR3ZGNKbkNneEl0WjI4eHE3YzZJeEdkVm8rZW02?= =?utf-8?B?bENVOU9nQm95SEIzMmhBREtXUHRsMVFtVE4vMU52UzZMWHVibkY4ZExqSmR6?= =?utf-8?B?WHd1NmNYL0JubXpUNVpvNFdldGI2YzM4eFNxRFRPeVRqWFEvN2pDZGpENDR0?= =?utf-8?B?Zkd2K0dvbFcxUGxZRjljSjhlb2RvS3BDRXlKVGwyUEF3TG41cFkrdGFpSnFn?= =?utf-8?B?MEZ3eCswS0VLdDlRcnV0ZU1WWUtYOERzU3hrdTZ0WUFNVUZ4RnZ6SVdGdmV0?= =?utf-8?B?ekhmUm1OckZNQjJuTk9wOFNENkVGODgzVm8rRWFFK3pJcDdxMU9lK2VwVk9h?= =?utf-8?B?dEt3SDA5S3puTEtHRldTU1RNSnluRTlRUVc4S09XZmdlYlFUbDFGek1rdEth?= =?utf-8?B?QnYwWFdzSFNaUlpLNXpkeXMwM0x4WkNBRlBEWDRoUmJKemxYWTRLRGxzbjE1?= =?utf-8?B?K0c2bEVRVzJnVjFYV0xGaTV3V3ZhbGh5U01EZnRqeWt4YStlM08wd3dWdWpj?= =?utf-8?B?aFUzYjVlbWl0RHRtN0Z4TmhmajgwRkNwdEYzL1BvMFc0M2ZaOXFXbWdnR2Q3?= =?utf-8?B?U0lScndYelBCaldIY3JsUjRMeWhpdG9nbE5SZjRrUFRQNUxYLzlKMVRCZ2d3?= =?utf-8?B?QTZiaHRMMkVFRDB5V3FVWVB1WjFmR0t5UmtkckdpWUZrVTVoTFcvbGphWXov?= =?utf-8?B?SHJxd016cWVXcWJYUy9FbU5jaFJNaUI5VzYrU0NWV25Sd1lHSG9rczhwVjNr?= =?utf-8?B?eWtOR2YybWw0cDB3dHNWbEJFcEZLTFlvT1o0Q25zKzZUZzM5VFFkaXE1bnlv?= =?utf-8?B?RWttR0V2SEh2aTgzR055QXdZUHBQekd4TUhvWDBEVW91M1lBSkpjQkZMUllo?= =?utf-8?B?YWtkVFJJTUQ4UHgwMERuc0JaeTVnR2FvemlkYW5zNGhsNjhXbGFLSGZPdFZD?= =?utf-8?B?Y1hyM3RDWEhadmNldVFIdzdGYUdMTHVESk0wUEpjSjNGWWMrTSsra0huZkUw?= =?utf-8?B?NTkzZmd0cytjRXFOdlh4bjkzVWh6akl2Q09TVFM5QTc2dzZ1bHNyaDlNd3My?= =?utf-8?B?YktuV1lOOGdvZlh2d0RWRTZjVFUraVk4ejRpeDdud21YS2hSVTNaWEZwbTA0?= =?utf-8?B?dG5qaTY0ZHJyekxsOVI0bWMwU0pzNnFibWNFRWN4eWwvZHRtS1dVUDRRVXU3?= =?utf-8?B?MllFUjJpYWJHcE42ZStLeXNPZFVsUXl3Z1dUMHZjU1I0R29qOG1wekZSeVl2?= =?utf-8?B?YUo1T24wakxudTVvcFFRMmIySFc1SnZ1WUJ4VjZHNzBTbjBnMVdzd0sydkQv?= =?utf-8?B?L2cxNldhZzVQcDQzRi9abG55Z09nTmJHQmtZNXNhV1A3N25wci9WMXNlK2Vq?= =?utf-8?B?M3JpVEFYdmJxQWNiZjlrMmpERHQ4VVVKWEhnNk0zaTJybVhJdmdzcmZYVEdm?= =?utf-8?B?K1NYbDl2Nk15YmROejllcGlvOUMxaGx1RTFYQVQvTkxHdVU0SEh4a3lvYlVL?= =?utf-8?B?MDFiOG5LRmphclBLTCtueWo2SEJEOU1weVRpWTZ2eHk5UFovM3NleXhPTG85?= =?utf-8?Q?BcKKx2sFk7I9T0JuO8=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5712d0fa-8d53-41ea-36c2-08d8ecfe6313 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 06:47:39.9752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VEehnJlA+tfMi8xvpHQq6vroCYrTknzNEv06eFRuq+8fzRqludXmmuFnwrqFbyG2LlfIed9R9zo8i8Ysr0abRw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4604 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lsr-ospf-prefix-originator-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 06:48:01 -0000 SGkgV2F0c29uLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQotS2V0YW4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdhdHNvbiBMYWRkIHZpYSBEYXRhdHJhY2tlciA8 bm9yZXBseUBpZXRmLm9yZz4gDQpTZW50OiAyMCBNYXJjaCAyMDIxIDExOjAzDQpUbzogc2VjZGly QGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci5hbGxA aWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgbHNyQGlldGYub3JnOyB3YXRzb25ibGFkZEBn bWFpbC5jb20NClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYt bHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDkNCg0KUmV2aWV3ZXI6IFdhdHNvbiBMYWRkDQpS ZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmll dyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2Ug Y29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNl Y3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNo b3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBj b21tZW50cy4NCg0KVGhlIHN1bW1hcnkgb2YgdGhlIHJldmlldyBpcyBSZWFkeS4NCg0KVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBzbWFsbCBleHRlbnNpb24gdG8gT1NQRiB0byBpbmNsdWRlIGlu Zm9ybWF0aW9uIG9mIHRoZSBvcmlnaW5hdGluZyByb3V0ZXIgZm9yIGEgcHJlZml4LCB3aGljaCBv dGhlcndpc2Ugd291bGQgYmUgbG9zdCBhcyB0aGUgcHJlZml4IHByb2NlZWRzIHRvIGJlIHJlYWR2 ZXJ0aXNlZC4gVGhpcyBpbmZvcm1hdGlvbiBpcyBxdWl0ZSB1c2VmdWwgd2hlbiBkZXRlcm1pbmlu ZyB3aGF0IGlzIGdvaW5nIG9uIHVuZGVyIHRyeWluZyBjaXJjdW1zdGFuY2VzLg0KDQpTaW5jZXJl bHksDQpXYXRzb24gTGFkZA0KDQoNCg== From nobody Mon Mar 22 09:41:20 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C902C3A0CAF; Mon, 22 Mar 2021 09:41:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161643127376.6337.10029863442550466574@ietfa.amsl.com> Reply-To: Tero Kivinen Date: Mon, 22 Mar 2021 09:41:13 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 16:41:14 -0000 Reviewer: Tero Kivinen Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The title of the draft has some acronyms which are not expanded (AODV, P2P) and if you expand them the title comes way too long. I would propose a usable title, which might not need to use all possible acronyms, but would better explain what this document is trying to do. This draft defines a new mode of operation to the allow peer to peer on demand routing in low power and lossy networks. I have not enough knowledge of RPL to really know how the new mode differs from the old methods. The security considerations section points to the RFC6550, and then explains that if rogue router has key it can do all kind of things. Nits: In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and Lossy Networks)" defines acronyms differently than what is used everywhere else. In all other cases the document uses format where the acronym is in parenthesis after the full text, i.e. "Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550]" format. I would propose using the same format also for here. In section 1 there is acronym DAG which is not expanded, expand it on first use. Also there are unexpanded acronyms DAO, P2MP, which are not used anywhere else, perhaps just expand them here. In same paragraph there is also acronym MOP which is not expanded here on its first use, but it is expanded later. Expand it here on its first use. What is the difference between different reserve bits X and r in sections 4.1/4.2 and 4.3? Period missing from the end of sentence of the Option Length description in Section 4.3. In the IANA considerations section I propose add a note to RFC editor saying that the sentences saying " The parenthesized numbers are only suggestions." needs to be removed prior publication. From nobody Mon Mar 22 12:52:57 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C513A0CC5; Mon, 22 Mar 2021 12:52:55 -0700 (PDT) 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=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9feor6GsHvFT; Mon, 22 Mar 2021 12:52:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB9F3A0CC4; Mon, 22 Mar 2021 12:52:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 08339389A5; Mon, 22 Mar 2021 15:58:38 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YOzDFnKDUEpa; Mon, 22 Mar 2021 15:58:36 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BC21B389A2; Mon, 22 Mar 2021 15:58:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6BFB675; Mon, 22 Mar 2021 15:52:46 -0400 (EDT) From: Michael Richardson To: Tero Kivinen , secdir@ietf.org, roll@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org In-Reply-To: <161643127376.6337.10029863442550466574@ietfa.amsl.com> References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 19:52:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tero Kivinen via Datatracker wrote: > This draft defines a new mode of operation to the allow peer to peer = on demand > routing in low power and lossy networks. I have not enough knowledge = of RPL to > really know how the new mode differs from the old methods. The securi= ty > considerations section points to the RFC6550, and then explains that = if rogue > router has key it can do all kind of things. I would agree that this might be inadequate. ROLL did RFC7416, and that should probably be cited. Given that these networks are *adhoc*, I think that some applicability shou= ld be considered as to whether there are actually any useful security from L2 keys. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmBY9Y4ACgkQgItw+93Q 3WUEnAgAun/YhMvzeZpbc8wxIjqOPzw+YrU4Xcm3gupYgssc3F83y3BRQ95mR8fq fq1EmuxpzV1CQKCnIAgMtVqzOWiRD/V4/K1TIEQVYPacolzSsSZffZGTtx5lbM+n It82y7TJjrF0ZhNa6EGE4eWD3OrpqoON0yL6jUCNuM0JtGAQYyf25un3axer/RVE KdM94N0SG9/obqyxfZevWu8BC5/U9fHqMx0gL+0I1LJffEX87oXnmndMXmWJKM2Y reVbX7Qj8DwLSqso0CabRDMn0HOMXw2WfigAFiYYjShvs58Bt2xke4SRI17anWIG i+rNqFSZ0xOe4iz0nnJGyp4m7ogxXw== =0Mfw -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 22 21:53:45 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616C73A1D95; Mon, 22 Mar 2021 21:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRgrudtV7WvE; Mon, 22 Mar 2021 21:53:26 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 E1DED3A1D93; Mon, 22 Mar 2021 21:53:25 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id z3so16398416ioc.8; Mon, 22 Mar 2021 21:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Fwu7Uh/Isz2rIhY/tcZr9wozk9Vu3k8haQUKPv/07rY=; b=GIJOKAbYoY4iAOS+VjMCgMeSHCqa7PgKF2vPxCyWnxdmMwdhdsO1DOeqcl08hnsMpB cwf3UuSvlqeGdy6sMdZqD9YCzHCHxHOsDu/hfVHx1zRf5YPJ/SPCUwh7fNo9vovZLjeY NCqylgg3T9GrQ/ptTWrVUhZcD2AYd3IaHf7sRyWkg5kdPsnh1S9HnBTPimZqBy+e4jyc w+5TdojmCm92fqBn+P/6M2y3WtR/GFzVQp1lEjI1mqprlZ0DPUTbHK4JgLPK9n+3v6hN qERHEcNsCH060R8199boEFhywacTBfGdu9KV66SgCxYVj7Y8rGlSk6je8q9nvIU5/wZe QWSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Fwu7Uh/Isz2rIhY/tcZr9wozk9Vu3k8haQUKPv/07rY=; b=McVlt9Mu8F9uwqXkEaBl13bsbOA+UeJsEtsBW4xAzdPDJaXMdVSsnANH1vvfjguGTt Dp4zw3bTNO3fgmG52bW/Y0Lj7tTH7T+R8x2WFa8UBbqNMcTlIKXo1AXmRzohqcTWicKR /H2Y2V+fN6/xMQROeJkb+r2c0xXl1fThuC/83AnmiV+plFaySsYkYJk/aPHEosPuInmH KN1HDtHJxhRw8wKfP8Hu28uHMNdx5ofu/+4n9iFXbsGZRTXF9ijg2kRccs/KTuirbn0j 2hf//0uD7QUQH1IjjNB5BDBPWKswjQC4HVGA4BO2lHhjR9S2PaZcmSYudDHEjLIjxNXA 7s2Q== X-Gm-Message-State: AOAM531nljZXrq/B49TPHeasztTMZq/bfap1bB46Q1XYf3xpcHC6rtfR sv6RnqcFDhxkEG3CLy0fJmAAztz+PFg5zpXua1fMaOJf1rE= X-Google-Smtp-Source: ABdhPJxz5wpO2wP58NbSVt6u/XPJEyeQtF7xgpOLNJ4/sDjvhzBSB0F29r2k2uQvllp64E6CFYY9rJWLR5Vcp/EsYpc= X-Received: by 2002:a5d:8b09:: with SMTP id k9mr2758952ion.185.1616475203083; Mon, 22 Mar 2021 21:53:23 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Tue, 23 Mar 2021 00:53:11 -0400 Message-ID: To: "iesg@ietf.org" , last-call@ietf.org Cc: draft-ietf-dots-rfc8782-bis.all@ietf.org, secdir Content-Type: multipart/alternative; boundary="00000000000044a24b05be2cf6b0" Archived-At: Subject: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 04:53:31 -0000 --00000000000044a24b05be2cf6b0 Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These reviews are primarily for the benefit of the Security ADs. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with Issues. Security: I think the Security Considerations section is adequate in its coverage but see below for some wording problems. I did not review Sections 5 or 6. Minor Issues / Nits: General: I don't mean to be unduly harsh but I was put off by the discursive and verbose style of this draft. On reading through, I get the feeling that the same thing is often said more than once, sometimes with different levels of detail, sometimes with different terminology, sometimes in consecutive sentences and sometimes in different parts of the draft; however, the numerous examples are generally a good thing. General/Global: All six occurrences of "as a reminder" should be deleted from the draft. They just add useless words. General: There are lots and lots of default/recommended configuration values scattered around the draft. It might be useful to have a table or list of them all, perhaps as an Operational Considerations section or appendix. Section 1: Draft says "The DOTS server may (not) be co-located with the DOTS mitigator." This appears to be a particularly confusing way of saying "The DOTS server may or may not be co-located with the DOTS mitigator." to which wording I would suggest changing. Section 3: Suggest wording change for clarity from DOTS clients and servers behave as CoAP endpoints. By default, a DOTS client (or server) behaves as a CoAP client (or server). Nevertheless, a DOTS client (or server) behaves as a CoAP server (or client) for specific operations such as DOTS heartbeat operations (Section 4.7). to DOTS clients and servers behave as CoAP endpoints. By default, a DOTS client behaves as a CoAP client and a DOTS server behaves as CoAP server. However, for specific operations such as DOTS heartbeat operations (Section 4.7), a DOTS client or server may behave as the opposite type of CoAP endpoint. In the text below from the draft, the parenthesis and wording just seem to muddle things and create doubt as to the meaning: In deployments where multiple DOTS clients are enabled in a network (owned and operated by the same entity), I think it would be clearer and easier to understand (assuming I understood it correctly) as: In deployments where multiple DOTS clients are enabled in a network with the clients and network owned and operated by the same entity, Should "must" be capitalized in the following draft text? Future DOTS extensions that request a CBOR value in the range "128-255" must support means similar to the aforementioned DOTS telemetry ones. Section 4.4.1: The following draft text uses "the trailing "=" " which implies that a base 64 encoding ends with exactly one equal sign. But I believe there can be zero, one, or two equal signs. I suggest the following: OLD The truncated output is base64url encoded (Section 5 of [RFC4648]) with the trailing "=" removed from the encoding, and the resulting value used as the 'cuid'. NEW The truncated output is base64url encoded (Section 5 of [RFC4648]) with any trailing equal signs ("=") removed from the encoding, and the resulting value used as the 'cuid'. There is talk of greater/lesser mid values. Is that a ring arithmetic comparison and if so should it reference [RFC182]? Apparently pre-configured mitigation triggered by loss of the signal channel are supposed to use mid's starting at zero but wrap around for dynamic mitigation wraps to zero. Won't that cause conflicts? On target-protocol, I suppose a reference to the IANA protocol registry doesn't hurt but it seems to me that denial of service traffic could use any protocol number, not necessarily one with a specific definition. Maybe OLD Values are taken from the IANA protocol registry [IANA-Proto]. NEW Values are integers in the range of 0 to 255. See [IANA-Proto] for common values. Section 4.4.3: The section title and contents mis-use the word "efficacy" standing by itself. "efficacy" has a strong implication of being how well something works, NOT how long it works unless there is some additional word or words such as "period of effectiveness" or "effective for a week". As an example, "efficacy" for a vaccine is how well it work to block the disease after the full course of vaccination has been given. People use completely different words when talking about how long a vaccine's protection lasts. In this particular section, I recommend simply replacing all occurrences of "efficacy" with "lifetime". Section 4.4.3: Figure 16 seems to show a string value for attack-status but Table 4 has only integer values? Section 4.4.4: I suggest just removing the part of the sentence after the "," in the following draft text because it just makes the sentence longer and a little confusing: Once the active-but-terminating period elapses, the DOTS server MUST treat the mitigation as terminated, as the DOTS client is no longer responsible for the mitigation. Section 4.5: Point a: The two sentences on Heartbeat interval are parallel and slightly inconsistent. Suggest simply deleting the first sentence. Section 4.6: Suggested wording change to cut down on verbiage: OLD If a DOTS server wants to redirect a DOTS client to an alternative DOTS server for a signal session, then the Response Code 5.03 (Service Unavailable) will be returned in the response to the DOTS client. The DOTS server can return the error Response Code 5.03 in response to a request from the DOTS client or convey the error Response Code 5.03 in a unidirectional notification response from the DOTS server. NEW To redirect a DOTS client to an alternative DOTS server for a signal session, the server can return the Response Code 5.03 (Service Unavailable) to the DOTS client or the server can return that Response Code in a notification response to the client. Section 4.6: Suggest replacing "can" with "MAY" or "SHOULD" in the following draft text: Requests issued by misbehaving DOTS clients that do not honor the TTL conveyed in the Max-Age Option or react to explicit redirect messages can be rejected by DOTS servers. Section 7.3: Since the PMTU can change and could be lower that the values suggested to be assumed in the first paragraph of Section 7.3, it is essentially impossible to conform to the first sentence as written. I suggest the following change: OLD To avoid DOTS signal message fragmentation and the subsequent decreased probability of message delivery, DOTS agents MUST ensure that the DTLS record fits within a single datagram. NEW To avoid DOTS signal message fragmentation and the subsequent decreased probability of message delivery, DOTS agents MUST NOT send datagrams exceeding the limits discussed in this Section. Section 8: The following text says that a server only accepts messages from a gateway, although this is immediately contradicted in the next paragraph. I suggest the change indicated: OLD a DOTS server only allows DOTS signal channel messages from an authorized DOTS gateway, NEW only if a gateway is authorized does a DOTS server accept DOTS signal channel messages from it, Section 8, Figure 30: Seems slightly misleading because it looks like the link between the Guest and gateway is broken. But according to the text, they did mutually authenticate. I would suggest moving the "X" to indicate failure to just inside the DOTS gateway box where the link from the client arrives at the gateway box. Sections 10: If all references to [RFC8782] in a registry need to be replaced with references to [this document], there is no need to list all the occurrences in the registry. You can just tell IANA to do a global replace. Section 11: I suggest the following change: OLD For this attack vector to happen, the misbehaving client needs to pass the security validation checks by the DOTS server, and eventually the checks of a client-domain DOTS gateway. NEW For this attack to succeed, the misbehaving client's messages need to pass the security validation checks by the DOTS server and, if they transit a DOTS gateway, the security checks of that gateway. The way this sentence talks about moving around "mitigation efficacy" reads very strangely to me. I suggest the following re-wording: OLD A compromised DOTS client can collude with a DDoS attacker to send mitigation request for a target resource, get the mitigation efficacy from the DOTS server, and convey the mitigation efficacy to the DDoS attacker to possibly change the DDoS attack strategy. NEW A compromised DOTS client can be commanded by a DDoS attacker to abuse mitigation requests for a target resource. This could use the "mitigation" abilities of the DOTS server for the benefit of the attacker possibly leading to a changed and more effective DDoS attack strategy. Here is another "MUST" that I think should be reworded because you cannot guarantee conformance to the MUST. For example, the server could have run out of state memory. OLD That is, only actions on IP resources that belong to the DOTS client's domain MUST be authorized by a DOTS server. NEW A DOTS server MUST NOT authorize actions due to a DOTS client request unless those actions are limited to that client's IP resources. Miscellaneous observation: It's too bad that there seems to be absolutely no coordination between DOTS and BGP flowspec. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --00000000000044a24b05be2cf6b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's
ongoing effort to review all IETF documents being processe= d by the
IESG. These reviews are primarily for the benefit of the Securi= ty ADs.
Document editors and WG chairs should treat these comments just=
like any other last call comments.

The summary of the review is = Ready with Issues.


Security:

I think the Security Conside= rations section is adequate in its
coverage but see below for some wordi= ng problems.

I did not review Sections 5 or 6.


Minor Issu= es / Nits:

General: I don't mean to be unduly harsh but I was pu= t off by the
discursive and verbose style of this draft. On reading thro= ugh, I get
the feeling that the same thing is often said more than once,=
sometimes with different levels of detail, sometimes with different
= terminology, sometimes in consecutive sentences and sometimes in
differe= nt parts of the draft; however, the numerous examples are
generally a go= od thing.

General/Global: All six occurrences of "as a reminder= " should be
deleted from the draft. They just add useless words.
General: There are lots and lots of default/recommended configuration<= br>values scattered around the draft. It might be useful to have a tableor list of them all, perhaps as an Operational Considerations section
o= r appendix.


Section 1: Draft says "The DOTS server may (not= ) be co-located with
the DOTS mitigator." =C2=A0This appears to be = a particularly confusing way
of saying "The DOTS server may or may = not be co-located with the DOTS
mitigator." to which wording I woul= d suggest changing.


Section 3:

Suggest wording change for= clarity from
=C2=A0 =C2=A0DOTS clients and servers behave as CoAP endpo= ints.=C2=A0 By default, a
=C2=A0 =C2=A0DOTS client (or server) behaves a= s a CoAP client (or server).
=C2=A0 =C2=A0Nevertheless, a DOTS client (o= r server) behaves as a CoAP server (or
=C2=A0 =C2=A0client) for specific= operations such as DOTS heartbeat operations
=C2=A0 =C2=A0(Section 4.7)= .
to
=C2=A0 =C2=A0DOTS clients and servers behave as CoAP endpoints.= =C2=A0 By default, a
=C2=A0 =C2=A0DOTS client behaves as a CoAP client a= nd a DOTS server behaves as
=C2=A0 =C2=A0CoAP server. However, for speci= fic operations such as DOTS heartbeat
=C2=A0 =C2=A0operations (Section 4= .7), a DOTS client or server may behave as
=C2=A0 =C2=A0the opposite typ= e of CoAP endpoint.


In the text below from the draft, the parent= hesis and wording just
seem to muddle things and create doubt as to the = meaning:
=C2=A0 =C2=A0In deployments where multiple DOTS clients are ena= bled in a network
=C2=A0 =C2=A0(owned and operated by the same entity),<= br>I think it would be clearer and easier to understand (assuming I
unde= rstood it correctly) as:
=C2=A0 =C2=A0In deployments where multiple DOTS= clients are enabled in a network
=C2=A0 =C2=A0with the clients and netw= ork owned and operated by the same entity,

Should "must" b= e capitalized in the following draft text?
=C2=A0 =C2=A0Future DOTS exte= nsions that request a CBOR value in the range
=C2=A0 =C2=A0"128-255= " must support means similar to the aforementioned DOTS
=C2=A0 =C2= =A0telemetry ones.


Section 4.4.1:

The following draft tex= t uses "the trailing "=3D" " which implies that a
ba= se 64 encoding ends with exactly one equal sign. But I believe there
can= be zero, one, or two equal signs. I suggest the following:
OLD
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The truncated output is
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0base64url encoded (Section 5 of [RFC4648]) with the traili= ng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"=3D" removed from the en= coding, and the resulting value used as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0the 'cuid'.
NEW
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The trun= cated output is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base64url encoded (Sec= tion 5 of [RFC4648]) with any trailing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0equal signs ("=3D") removed from the encoding, and the
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resulting value used as the 'cuid'.<= br>

There is talk of greater/lesser mid values. Is that a ring arith= metic
comparison and if so should it reference [RFC182]?

Apparent= ly pre-configured mitigation triggered by loss of the signal
channel are= supposed to use mid's starting at zero but wrap around for
dynamic = mitigation wraps to zero. Won't that cause conflicts?

On targe= t-protocol, I suppose a reference to the IANA protocol
registry doesn= 9;t hurt but it seems to me that denial of service
traffic could use any= protocol number, not necessarily one with a
specific definition. Maybe<= br>OLD
=C2=A0 =C2=A0 =C2=A0 Values
=C2=A0 =C2=A0 =C2=A0 are taken fro= m the IANA protocol registry [IANA-Proto].
NEW
=C2=A0 =C2=A0 =C2=A0 V= alues are integers in the range of 0 to 255. See [IANA-Proto]
=C2=A0 =C2= =A0 =C2=A0 for common values.


Section 4.4.3: The section title= and contents mis-use the word
"efficacy" standing by itself. = =C2=A0"efficacy" has a strong implication of
being how well so= mething works, NOT how long it works unless there is
some additional wor= d or words such as "period of effectiveness" or
"effectiv= e for a week".=C2=A0 As an example, "efficacy" for a vaccine= is
how well it work to block the disease after the full course of
va= ccination has been given. People use completely different words when
tal= king about how long a vaccine's protection lasts. In this particularsection, I recommend simply replacing all occurrences of "efficacy&qu= ot;
with "lifetime".

Section 4.4.3: Figure 16 seems to = show a string value for
attack-status but Table 4 has only integer value= s?


Section 4.4.4: I suggest just removing the part of the senten= ce after
the "," in the following draft text because it just m= akes the sentence
longer and a little confusing:
=C2=A0 =C2=A0Once th= e active-but-terminating period elapses, the DOTS server MUST
=C2=A0 =C2= =A0treat the mitigation as terminated, as the DOTS client is no longer
= =C2=A0 =C2=A0responsible for the mitigation.


Section 4.5: Point = a: The two sentences on Heartbeat interval are
parallel and slightly inc= onsistent. Suggest simply deleting the first
sentence.


Sectio= n 4.6: Suggested wording change to cut down on verbiage:
OLD
=C2=A0 = =C2=A0If a DOTS server wants to redirect a DOTS client to an alternative=C2=A0 =C2=A0DOTS server for a signal session, then the Response Code 5.03=
=C2=A0 =C2=A0(Service Unavailable) will be returned in the response to = the DOTS
=C2=A0 =C2=A0client.

=C2=A0 =C2=A0The DOTS server can re= turn the error Response Code 5.03 in response
=C2=A0 =C2=A0to a request = from the DOTS client or convey the error Response Code
=C2=A0 =C2=A05.03= in a unidirectional notification response from the DOTS server.
NEW
= =C2=A0 =C2=A0To redirect a DOTS client to an alternative DOTS server for a<= br>=C2=A0 =C2=A0signal session, the server can return the Response Code 5.0= 3
=C2=A0 =C2=A0(Service Unavailable) to the DOTS client or the server ca= n return
=C2=A0 =C2=A0that Response Code in a notification response to t= he client.

Section 4.6: Suggest replacing "can" with "= ;MAY" or "SHOULD" in the
following draft text:
=C2=A0 = =C2=A0Requests issued by misbehaving DOTS clients that do not honor the TTL=
=C2=A0 =C2=A0conveyed in the Max-Age Option or react to explicit redire= ct messages
=C2=A0 =C2=A0can be rejected by DOTS servers.


Sec= tion 7.3: Since the PMTU can change and could be lower that the
values s= uggested to be assumed in the first paragraph of Section 7.3,
it is esse= ntially impossible to conform to the first sentence as
written. I sugges= t the following change:
OLD
=C2=A0 =C2=A0To avoid DOTS signal message= fragmentation and the subsequent
=C2=A0 =C2=A0decreased probability of = message delivery, DOTS agents MUST ensure
=C2=A0 =C2=A0that the DTLS rec= ord fits within a single datagram.
NEW
=C2=A0 =C2=A0To avoid DOTS sig= nal message fragmentation and the subsequent
=C2=A0 =C2=A0decreased prob= ability of message delivery, DOTS agents MUST NOT
=C2=A0 =C2=A0send data= grams exceeding the limits discussed in this Section.


Section 8:= The following text says that a server only accepts messages
from a gate= way, although this is immediately contradicted in the next
paragraph. I = suggest the change indicated:
OLD
=C2=A0 =C2=A0a DOTS server only all= ows DOTS signal
=C2=A0 =C2=A0channel messages from an authorized DOTS ga= teway,
NEW
=C2=A0 =C2=A0only if a gateway is authorized does a DOTS s= erver accept DOTS signal
=C2=A0 =C2=A0channel messages from it,

<= br>Section 8, Figure 30: Seems slightly misleading because it looks likethe link between the Guest and gateway is broken. But according to the
= text, they did mutually authenticate. I would suggest moving the "X&qu= ot;
to indicate failure to just inside the DOTS gateway box where the li= nk
from the client arrives at the gateway box.


Sections 10: I= f all references to [RFC8782] in a registry need to be
replaced with ref= erences to [this document], there is no need to list
all the occurrences= in the registry. You can just tell IANA to do a
global replace.

=
Section 11:

I suggest the following change:
OLD
=C2=A0 =C2= =A0For this attack vector
=C2=A0 =C2=A0to happen, the misbehaving client= needs to pass the security
=C2=A0 =C2=A0validation checks by the DOTS s= erver, and eventually the checks of a
=C2=A0 =C2=A0client-domain DOTS ga= teway.
NEW
=C2=A0 =C2=A0For this attack
=C2=A0 =C2=A0to succeed, = the misbehaving client's messages need to pass the security
=C2=A0 = =C2=A0validation checks by the DOTS server and, if they transit a DOTS
= =C2=A0 =C2=A0gateway, the security checks of that gateway.

The way t= his sentence talks about moving around "mitigation efficacy"
r= eads very strangely to me. I suggest the following re-wording:
OLD
= =C2=A0 =C2=A0A compromised DOTS client can collude with a DDoS attacker to = send
=C2=A0 =C2=A0mitigation request for a target resource, get the miti= gation efficacy
=C2=A0 =C2=A0from the DOTS server, and convey the mitiga= tion efficacy to the DDoS
=C2=A0 =C2=A0attacker to possibly change the D= DoS attack strategy.
NEW
=C2=A0 =C2=A0A compromised DOTS client can b= e commanded by a DDoS attacker to
=C2=A0 =C2=A0abuse mitigation requests= for a target resource. This could use the
=C2=A0 =C2=A0"mitigation= " abilities of the DOTS server for the benefit of the
=C2=A0 =C2=A0= attacker possibly leading to a changed and more effective DDoS
=C2=A0 = =C2=A0attack strategy.

Here is another "MUST" that I think= should be reworded because you
cannot guarantee conformance to the MUST= . For example, the server
could have run out of state memory.
OLD
= =C2=A0 =C2=A0That is, only actions on IP
=C2=A0 =C2=A0resources that bel= ong to the DOTS client's domain MUST be authorized
=C2=A0 =C2=A0by a= DOTS server.
NEW
=C2=A0 =C2=A0A DOTS server MUST NOT authorize actio= ns due to a DOTS client
=C2=A0 =C2=A0request unless those actions are li= mited to that client's IP
=C2=A0 =C2=A0resources.


Miscel= laneous observation: It's too bad that there seems to be
absolutely = no coordination between DOTS and BGP flowspec.

Thanks,
Donald
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (= cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com
--00000000000044a24b05be2cf6b0-- From nobody Tue Mar 23 01:13:22 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5A3A21D5; Tue, 23 Mar 2021 01:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.076 X-Spam-Level: * X-Spam-Status: No, score=1.076 tagged_above=-999 required=5 tests=[DATE_IN_PAST_03_06=1.076, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGbpARY__Pl6; Tue, 23 Mar 2021 01:13:11 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A4D3A21D7; Tue, 23 Mar 2021 01:13:09 -0700 (PDT) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 846DB28275E; Tue, 23 Mar 2021 08:13:04 +0000 (UTC) To: Sean Turner , secdir@ietf.org Cc: draft-ietf-ntp-port-randomization.all@ietf.org, last-call@ietf.org, ntp@ietf.org References: <161634069996.31375.17595634557822390595@ietfa.amsl.com> From: Fernando Gont Message-ID: <950f09c1-f7ea-127e-5fdb-d09cc4314018@si6networks.com> Date: Tue, 23 Mar 2021 01:46:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <161634069996.31375.17595634557822390595@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ntp-port-randomization-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 08:13:14 -0000 Hi, Sean, Thanks for your review! Cheers, Fernando On 21/3/21 12:31, Sean Turner via Datatracker wrote: > Reviewer: Sean Turner > Review result: Ready > > Hi! I am doing this review as part of the Security Directorate. > > This I-D updates NTP v4 [RFC 5095] to recommend the use of transport-protocol > ephemeral port randomization for those modes where use of the NTP well-known > port is not required. The port randomization recommendation is based on BCP 156 > [RFC6056], which recommends the randomization of transport-protocol ephemeral > ports. This I-D is in fact co-authored by one of the co-authors of BCP 156. The > I-D motivates the recommendation and enumerates some considerations as they > relate to NTP as well as identifies the exact changes (i.e., two-sentence > dstport replaced with more text). It also appears that this I-D is well > implemented as noted in the implementation status section. > > > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Mar 23 06:52:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886E33A0D6D; Tue, 23 Mar 2021 06:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emEbpOjT4aIK; Tue, 23 Mar 2021 06:51:48 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 761003A0D69; Tue, 23 Mar 2021 06:51:48 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4F4Xpn24hlz8t5g; Tue, 23 Mar 2021 14:51:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1616507505; bh=l4qetUZrp4NzHi41amVbtN/rBvFmnl+HZMUrofnn1TQ=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=gfjTktje8mcXOt3a90JzxV5W4XQP6frBJSX0terR1D1+2TjQzFSzfNxFUHJpvbnWI W3xhee2BkH0Vb+mMVZEPOKRAWUT5ODbI9Dt70ACZtg8QtCTsm+7XKhTDnWPCyVCken Ycxn0qvNPkl3Ujoj72caV5O3bHW82PHynxR9bXtnbtpAwjtLEKQ8kWwV5Aht0YF6LB 35uCw5lnpv08e+6T0WuBJDKG/nnHMgN6D4P2i2Hgyw/nDmBCVkwaz/4TPybk/Klpth qmISbupK41/XsSM4wIlMNyzgm4p4/HN3bcesnQTtZah381uyjj+ogfWtoJoGp3/pJH ptOaE5reHAMSA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4F4Xpn0fl0z3wdQ; Tue, 23 Mar 2021 14:51:45 +0100 (CET) From: To: Donald Eastlake , "iesg@ietf.org" , "last-call@ietf.org" CC: "draft-ietf-dots-rfc8782-bis.all@ietf.org" , secdir Thread-Topic: SECDIR Review draft-ietf-dots-rfc8782-bis-05 Thread-Index: AQHXH6B6k26mqQp2EE65nD9FVUjx5KqRf22g Date: Tue, 23 Mar 2021 13:51:44 +0000 Message-ID: <23514_1616507505_6059F271_23514_186_1_787AE7BB302AE849A7480A190F8B93303535A427@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303535A427OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 13:51:54 -0000 --_000_787AE7BB302AE849A7480A190F8B93303535A427OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRG9uYWxkLA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldy4NCg0KUGxlYXNlIHNlZSBp bmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IERvbmFsZCBFYXN0bGFrZSBbbWFpbHRvOmQz ZTNlM0BnbWFpbC5jb21dDQpFbnZvecOpIDogbWFyZGkgMjMgbWFycyAyMDIxIDA1OjUzDQrDgCA6 IGllc2dAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZw0KQ2MgOiBkcmFmdC1pZXRmLWRvdHMt cmZjODc4Mi1iaXMuYWxsQGlldGYub3JnOyBzZWNkaXIgPHNlY2RpckBpZXRmLm9yZz4NCk9iamV0 IDogU0VDRElSIFJldmlldyBkcmFmdC1pZXRmLWRvdHMtcmZjODc4Mi1iaXMtMDUNCg0KSSBoYXZl IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3Jh dGUncw0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBw cm9jZXNzZWQgYnkgdGhlDQpJRVNHLiBUaGVzZSByZXZpZXdzIGFyZSBwcmltYXJpbHkgZm9yIHRo ZSBiZW5lZml0IG9mIHRoZSBTZWN1cml0eSBBRHMuDQpEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBj aGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QNCmxpa2UgYW55IG90aGVyIGxh c3QgY2FsbCBjb21tZW50cy4NCg0KVGhlIHN1bW1hcnkgb2YgdGhlIHJldmlldyBpcyBSZWFkeSB3 aXRoIElzc3Vlcy4NCg0KDQpTZWN1cml0eToNCg0KSSB0aGluayB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBpcyBhZGVxdWF0ZSBpbiBpdHMNCmNvdmVyYWdlIGJ1dCBzZWUgYmVs b3cgZm9yIHNvbWUgd29yZGluZyBwcm9ibGVtcy4NCg0KSSBkaWQgbm90IHJldmlldyBTZWN0aW9u cyA1IG9yIDYuDQoNCg0KTWlub3IgSXNzdWVzIC8gTml0czoNCg0KR2VuZXJhbDogSSBkb24ndCBt ZWFuIHRvIGJlIHVuZHVseSBoYXJzaCBidXQgSSB3YXMgcHV0IG9mZiBieSB0aGUNCmRpc2N1cnNp dmUgYW5kIHZlcmJvc2Ugc3R5bGUgb2YgdGhpcyBkcmFmdC4gT24gcmVhZGluZyB0aHJvdWdoLCBJ IGdldA0KdGhlIGZlZWxpbmcgdGhhdCB0aGUgc2FtZSB0aGluZyBpcyBvZnRlbiBzYWlkIG1vcmUg dGhhbiBvbmNlLA0Kc29tZXRpbWVzIHdpdGggZGlmZmVyZW50IGxldmVscyBvZiBkZXRhaWwsIHNv bWV0aW1lcyB3aXRoIGRpZmZlcmVudA0KdGVybWlub2xvZ3ksIHNvbWV0aW1lcyBpbiBjb25zZWN1 dGl2ZSBzZW50ZW5jZXMgYW5kIHNvbWV0aW1lcyBpbg0KZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBk cmFmdDsgaG93ZXZlciwgdGhlIG51bWVyb3VzIGV4YW1wbGVzIGFyZQ0KZ2VuZXJhbGx5IGEgZ29v ZCB0aGluZy4NCg0KR2VuZXJhbC9HbG9iYWw6IEFsbCBzaXggb2NjdXJyZW5jZXMgb2YgImFzIGEg cmVtaW5kZXIiIHNob3VsZCBiZQ0KZGVsZXRlZCBmcm9tIHRoZSBkcmFmdC4gVGhleSBqdXN0IGFk ZCB1c2VsZXNzIHdvcmRzLg0KW01lZF0gRXhjZXB0IHRoZSBvbmUgYWJvdXQgSVB2NC9JUHY2LCB0 aG9zZSB3ZXJlIGFkZGVkIHRvIGFkZHJlc3MgY29tbWVudHMgdGhhdCB3ZSByZWNlaXZlZCBpbiB0 aGUgcGFzdC4gSSBwcmVmZXIgdG8gbWFpbnRhaW4gdGhlbS4NCg0KR2VuZXJhbDogVGhlcmUgYXJl IGxvdHMgYW5kIGxvdHMgb2YgZGVmYXVsdC9yZWNvbW1lbmRlZCBjb25maWd1cmF0aW9uDQp2YWx1 ZXMgc2NhdHRlcmVkIGFyb3VuZCB0aGUgZHJhZnQuIEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBoYXZl IGEgdGFibGUNCm9yIGxpc3Qgb2YgdGhlbSBhbGwsIHBlcmhhcHMgYXMgYW4gT3BlcmF0aW9uYWwg Q29uc2lkZXJhdGlvbnMgc2VjdGlvbg0Kb3IgYXBwZW5kaXguDQoNCg0KU2VjdGlvbiAxOiBEcmFm dCBzYXlzICJUaGUgRE9UUyBzZXJ2ZXIgbWF5IChub3QpIGJlIGNvLWxvY2F0ZWQgd2l0aA0KdGhl IERPVFMgbWl0aWdhdG9yLiIgIFRoaXMgYXBwZWFycyB0byBiZSBhIHBhcnRpY3VsYXJseSBjb25m dXNpbmcgd2F5DQpvZiBzYXlpbmcgIlRoZSBET1RTIHNlcnZlciBtYXkgb3IgbWF5IG5vdCBiZSBj by1sb2NhdGVkIHdpdGggdGhlIERPVFMNCm1pdGlnYXRvci4iIHRvIHdoaWNoIHdvcmRpbmcgSSB3 b3VsZCBzdWdnZXN0IGNoYW5naW5nLg0KDQpbTWVkXSBTdXJlLg0KDQoNClNlY3Rpb24gMzoNCg0K U3VnZ2VzdCB3b3JkaW5nIGNoYW5nZSBmb3IgY2xhcml0eSBmcm9tDQogICBET1RTIGNsaWVudHMg YW5kIHNlcnZlcnMgYmVoYXZlIGFzIENvQVAgZW5kcG9pbnRzLiAgQnkgZGVmYXVsdCwgYQ0KICAg RE9UUyBjbGllbnQgKG9yIHNlcnZlcikgYmVoYXZlcyBhcyBhIENvQVAgY2xpZW50IChvciBzZXJ2 ZXIpLg0KICAgTmV2ZXJ0aGVsZXNzLCBhIERPVFMgY2xpZW50IChvciBzZXJ2ZXIpIGJlaGF2ZXMg YXMgYSBDb0FQIHNlcnZlciAob3INCiAgIGNsaWVudCkgZm9yIHNwZWNpZmljIG9wZXJhdGlvbnMg c3VjaCBhcyBET1RTIGhlYXJ0YmVhdCBvcGVyYXRpb25zDQogICAoU2VjdGlvbiA0LjcpLg0KdG8N CiAgIERPVFMgY2xpZW50cyBhbmQgc2VydmVycyBiZWhhdmUgYXMgQ29BUCBlbmRwb2ludHMuICBC eSBkZWZhdWx0LCBhDQogICBET1RTIGNsaWVudCBiZWhhdmVzIGFzIGEgQ29BUCBjbGllbnQgYW5k IGEgRE9UUyBzZXJ2ZXIgYmVoYXZlcyBhcw0KICAgQ29BUCBzZXJ2ZXIuDQoNCltNZWRdIFdlbnQg d2l0aCB0aGlzIHBhcnQuDQoNCkhvd2V2ZXIsIGZvciBzcGVjaWZpYyBvcGVyYXRpb25zIHN1Y2gg YXMgRE9UUyBoZWFydGJlYXQNCiAgIG9wZXJhdGlvbnMgKFNlY3Rpb24gNC43KSwgYSBET1RTIGNs aWVudCBvciBzZXJ2ZXIgbWF5IGJlaGF2ZSBhcw0KICAgdGhlIG9wcG9zaXRlIHR5cGUgb2YgQ29B UCBlbmRwb2ludC4NCg0KW01lZF0gV2lsbCBsZWF2ZSB0aGUgb2xkIG9uZS4gVGhhbmtzLg0KDQoN CkluIHRoZSB0ZXh0IGJlbG93IGZyb20gdGhlIGRyYWZ0LCB0aGUgcGFyZW50aGVzaXMgYW5kIHdv cmRpbmcganVzdA0Kc2VlbSB0byBtdWRkbGUgdGhpbmdzIGFuZCBjcmVhdGUgZG91YnQgYXMgdG8g dGhlIG1lYW5pbmc6DQogICBJbiBkZXBsb3ltZW50cyB3aGVyZSBtdWx0aXBsZSBET1RTIGNsaWVu dHMgYXJlIGVuYWJsZWQgaW4gYSBuZXR3b3JrDQogICAob3duZWQgYW5kIG9wZXJhdGVkIGJ5IHRo ZSBzYW1lIGVudGl0eSksDQpJIHRoaW5rIGl0IHdvdWxkIGJlIGNsZWFyZXIgYW5kIGVhc2llciB0 byB1bmRlcnN0YW5kIChhc3N1bWluZyBJDQp1bmRlcnN0b29kIGl0IGNvcnJlY3RseSkgYXM6DQog ICBJbiBkZXBsb3ltZW50cyB3aGVyZSBtdWx0aXBsZSBET1RTIGNsaWVudHMgYXJlIGVuYWJsZWQg aW4gYSBuZXR3b3JrDQogICB3aXRoIHRoZSBjbGllbnRzIGFuZCBuZXR3b3JrIG93bmVkIGFuZCBv cGVyYXRlZCBieSB0aGUgc2FtZSBlbnRpdHksDQoNCltNZWRdIFVwZGF0ZWQgdGhpcyBvbmUgdG86 DQoNCiAgIEluIGRlcGxveW1lbnRzIHdoZXJlIG11bHRpcGxlIERPVFMgY2xpZW50cyBhcmUgZW5h YmxlZCBpbiBhIHNpbmdsZQ0KICAgIG5ldHdvcmsgYW5kIGFkbWluaXN0cmF0aXZlIGRvbWFpbg0K DQpTaG91bGQgIm11c3QiIGJlIGNhcGl0YWxpemVkIGluIHRoZSBmb2xsb3dpbmcgZHJhZnQgdGV4 dD8NCiAgIEZ1dHVyZSBET1RTIGV4dGVuc2lvbnMgdGhhdCByZXF1ZXN0IGEgQ0JPUiB2YWx1ZSBp biB0aGUgcmFuZ2UNCiAgICIxMjgtMjU1IiBtdXN0IHN1cHBvcnQgbWVhbnMgc2ltaWxhciB0byB0 aGUgYWZvcmVtZW50aW9uZWQgRE9UUw0KICAgdGVsZW1ldHJ5IG9uZXMuDQoNCltNZWRdIEdvb2Qg Y2F0Y2guIEZpeGVkLg0KDQoNClNlY3Rpb24gNC40LjE6DQoNClRoZSBmb2xsb3dpbmcgZHJhZnQg dGV4dCB1c2VzICJ0aGUgdHJhaWxpbmcgIj0iICIgd2hpY2ggaW1wbGllcyB0aGF0IGENCmJhc2Ug NjQgZW5jb2RpbmcgZW5kcyB3aXRoIGV4YWN0bHkgb25lIGVxdWFsIHNpZ24uIEJ1dCBJIGJlbGll dmUgdGhlcmUNCmNhbiBiZSB6ZXJvLCBvbmUsIG9yIHR3byBlcXVhbCBzaWducy4gSSBzdWdnZXN0 IHRoZSBmb2xsb3dpbmc6DQpPTEQNCiAgICAgICAgIFRoZSB0cnVuY2F0ZWQgb3V0cHV0IGlzDQog ICAgICAgICBiYXNlNjR1cmwgZW5jb2RlZCAoU2VjdGlvbiA1IG9mIFtSRkM0NjQ4XSkgd2l0aCB0 aGUgdHJhaWxpbmcNCiAgICAgICAgICI9IiByZW1vdmVkIGZyb20gdGhlIGVuY29kaW5nLCBhbmQg dGhlIHJlc3VsdGluZyB2YWx1ZSB1c2VkIGFzDQogICAgICAgICB0aGUgJ2N1aWQnLg0KTkVXDQog ICAgICAgICBUaGUgdHJ1bmNhdGVkIG91dHB1dCBpcw0KICAgICAgICAgYmFzZTY0dXJsIGVuY29k ZWQgKFNlY3Rpb24gNSBvZiBbUkZDNDY0OF0pIHdpdGggYW55IHRyYWlsaW5nDQogICAgICAgICBl cXVhbCBzaWducyAoIj0iKSByZW1vdmVkIGZyb20gdGhlIGVuY29kaW5nLCBhbmQgdGhlDQogICAg ICAgICByZXN1bHRpbmcgdmFsdWUgdXNlZCBhcyB0aGUgJ2N1aWQnLg0KDQpbTWVkXSBXZSBtZWFu dCDigJxhbnkgdHJhaWxpbmfigJ0uIEZpeGVkIGJ5IHVwZGF0aW5nIHRvIOKAnHR3byB0cmFpbGlu ZyAiPSLigJ0NCg0KVGhlcmUgaXMgdGFsayBvZiBncmVhdGVyL2xlc3NlciBtaWQgdmFsdWVzLiBJ cyB0aGF0IGEgcmluZyBhcml0aG1ldGljDQpjb21wYXJpc29uIGFuZCBpZiBzbyBzaG91bGQgaXQg cmVmZXJlbmNlIFtSRkMxODJdPw0KW01lZF0gSSBndWVzcyB5b3UgbWVhbnQgUkZDMTk4Mi4gV2Ug ZG9u4oCZdCBuZWVkIGl0IGhlcmUuDQoNCkFwcGFyZW50bHkgcHJlLWNvbmZpZ3VyZWQgbWl0aWdh dGlvbiB0cmlnZ2VyZWQgYnkgbG9zcyBvZiB0aGUgc2lnbmFsDQpjaGFubmVsIGFyZSBzdXBwb3Nl ZCB0byB1c2UgbWlkJ3Mgc3RhcnRpbmcgYXQgemVybyBidXQgd3JhcCBhcm91bmQgZm9yDQpkeW5h bWljIG1pdGlnYXRpb24gd3JhcHMgdG8gemVyby4gV29uJ3QgdGhhdCBjYXVzZSBjb25mbGljdHM/ DQoNCltNZWRdIEkgZG9u4oCZdCBzZWUgYW55IGlzc3VlIGFzIGNvbmZsaWN0cyB0YWtlcyBpbnRv IGFjY291bnQgdGhlIG1pdGlnYXRpb24tdHlwZS4NCg0KT24gdGFyZ2V0LXByb3RvY29sLCBJIHN1 cHBvc2UgYSByZWZlcmVuY2UgdG8gdGhlIElBTkEgcHJvdG9jb2wNCnJlZ2lzdHJ5IGRvZXNuJ3Qg aHVydCBidXQgaXQgc2VlbXMgdG8gbWUgdGhhdCBkZW5pYWwgb2Ygc2VydmljZQ0KdHJhZmZpYyBj b3VsZCB1c2UgYW55IHByb3RvY29sIG51bWJlciwgbm90IG5lY2Vzc2FyaWx5IG9uZSB3aXRoIGEN CnNwZWNpZmljIGRlZmluaXRpb24uIE1heWJlDQpPTEQNCiAgICAgIFZhbHVlcw0KICAgICAgYXJl IHRha2VuIGZyb20gdGhlIElBTkEgcHJvdG9jb2wgcmVnaXN0cnkgW0lBTkEtUHJvdG9dLg0KTkVX DQogICAgICBWYWx1ZXMgYXJlIGludGVnZXJzIGluIHRoZSByYW5nZSBvZiAwIHRvIDI1NS4gU2Vl IFtJQU5BLVByb3RvXQ0KICAgICAgZm9yIGNvbW1vbiB2YWx1ZXMuDQoNCltNZWRdIFdvcmtzIGZv ciBtZS4gVXBkYXRlZC4gVGhhbmtzLg0KDQpTZWN0aW9uIDQuNC4zOiBUaGUgc2VjdGlvbiB0aXRs ZSBhbmQgY29udGVudHMgbWlzLXVzZSB0aGUgd29yZA0KImVmZmljYWN5IiBzdGFuZGluZyBieSBp dHNlbGYuICAiZWZmaWNhY3kiIGhhcyBhIHN0cm9uZyBpbXBsaWNhdGlvbiBvZg0KYmVpbmcgaG93 IHdlbGwgc29tZXRoaW5nIHdvcmtzLCBOT1QgaG93IGxvbmcgaXQgd29ya3MgdW5sZXNzIHRoZXJl IGlzDQpzb21lIGFkZGl0aW9uYWwgd29yZCBvciB3b3JkcyBzdWNoIGFzICJwZXJpb2Qgb2YgZWZm ZWN0aXZlbmVzcyIgb3INCiJlZmZlY3RpdmUgZm9yIGEgd2VlayIuICBBcyBhbiBleGFtcGxlLCAi ZWZmaWNhY3kiIGZvciBhIHZhY2NpbmUgaXMNCmhvdyB3ZWxsIGl0IHdvcmsgdG8gYmxvY2sgdGhl IGRpc2Vhc2UgYWZ0ZXIgdGhlIGZ1bGwgY291cnNlIG9mDQp2YWNjaW5hdGlvbiBoYXMgYmVlbiBn aXZlbi4gUGVvcGxlIHVzZSBjb21wbGV0ZWx5IGRpZmZlcmVudCB3b3JkcyB3aGVuDQp0YWxraW5n IGFib3V0IGhvdyBsb25nIGEgdmFjY2luZSdzIHByb3RlY3Rpb24gbGFzdHMuIEluIHRoaXMgcGFy dGljdWxhcg0Kc2VjdGlvbiwgSSByZWNvbW1lbmQgc2ltcGx5IHJlcGxhY2luZyBhbGwgb2NjdXJy ZW5jZXMgb2YgImVmZmljYWN5Ig0Kd2l0aCAibGlmZXRpbWUiLg0KDQpbTWVkXSBOb3Qgc3VyZSB0 byB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9yIHRoZSBwcm9wb3NhbCB0byBjaGFuZ2Ug4oCc ZWZmaWNhY3nigJ0gdG8g4oCcbGlmZXRpbWXigJ0uIFRoaXMgc2VjdGlvbiBpcyBhYm91dCBzZW5k aW5nIGFuIHN0YXR1cyBpbiBhIHVwZGF0ZSBtZXNzYWdlIHRvIHJlcG9ydCB0aGUgZWZmaWNhY3kg b2Ygb25nb2luZyBtaXRpZ2F0aW9uLiBXZSBjYWxsIHRoYXQg4oCcZWZmaWNhY3kgdXBkYXRlc+KA nSwgZm9yIHNpbXBsaWNpdHkuDQoNClNlY3Rpb24gNC40LjM6IEZpZ3VyZSAxNiBzZWVtcyB0byBz aG93IGEgc3RyaW5nIHZhbHVlIGZvcg0KYXR0YWNrLXN0YXR1cyBidXQgVGFibGUgNCBoYXMgb25s eSBpbnRlZ2VyIHZhbHVlcz8NCg0KW01lZF0gVGhlIGZpZ3VyZSBpcyBjb3JyZWN0IGFzIHRoZSBl eGFtcGxlIHVzZXMgSlNPTi4gRldPVywgaGVyZSBpcyB0aGUgY29ycmVzcG9uZGluZyB0eXBlIGZv ciB0aGUgYXR0YWNrLXN0YXR1cyBhdHRyaWJ1dGU6DQoNCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLSsNCg0KICAg fCBQYXJhbWV0ZXIgTmFtZSAgICAgIHwgWUFORyBUeXBlICAgIHwgQ0JPUiB8IENCT1IgTWFqb3Ig IHwgSlNPTiAgIHwNCg0KICAgfCAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwg S2V5ICB8IFR5cGUgJiAgICAgIHwgVHlwZSAgIHwNCg0KICAgfCAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgIHwgICAgICB8IEluZm9ybWF0aW9uIHwgICAgICAgIHwNCg0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0rLS0tLS0tLS0tLS0tLSst LS0tLS0tLSsNCiAgIHwgYXR0YWNrLXN0YXR1cyAgICAgICB8IGVudW1lcmF0aW9uICB8IDI5ICAg fCAwIHVuc2lnbmVkICB8IFN0cmluZyB8DQoNCg0KVGhhdCBpcyBleHBsaWNpdGx5IG1lbnRpb25l ZCBpbiBTZWN0aW9uIDQuNDoNCg0KDQogICBKU09OIGVuY29kaW5nIG9mIFlBTkcgbW9kZWxlZCBk YXRhIFtSRkM3OTUxPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNzk1 MT5dIGlzIHVzZWQgdG8gaWxsdXN0cmF0ZQ0KDQogICB0aGUgdmFyaW91cyBtZXRob2RzIGRlZmlu ZWQgaW4gdGhlIGZvbGxvd2luZyBzdWJzZWN0aW9ucy4gIEFsc28sIHRoZQ0KDQogICBleGFtcGxl cyB1c2UgdGhlIExhYmVscyBkZWZpbmVkIGluIFNlY3Rpb25zIDEwLjYuMjxodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy1yZmM4NzgyLWJpcy0wNSNz ZWN0aW9uLTEwLjYuMj4sIDEwLjYuMzxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWlldGYtZG90cy1yZmM4NzgyLWJpcy0wNSNzZWN0aW9uLTEwLjYuMz4sIDEwLjYu NDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy1y ZmM4NzgyLWJpcy0wNSNzZWN0aW9uLTEwLjYuND4sDQoNCiAgIGFuZCAxMC42LjUuDQoNCg0KU2Vj dGlvbiA0LjQuNDogSSBzdWdnZXN0IGp1c3QgcmVtb3ZpbmcgdGhlIHBhcnQgb2YgdGhlIHNlbnRl bmNlIGFmdGVyDQp0aGUgIiwiIGluIHRoZSBmb2xsb3dpbmcgZHJhZnQgdGV4dCBiZWNhdXNlIGl0 IGp1c3QgbWFrZXMgdGhlIHNlbnRlbmNlDQpsb25nZXIgYW5kIGEgbGl0dGxlIGNvbmZ1c2luZzoN CiAgIE9uY2UgdGhlIGFjdGl2ZS1idXQtdGVybWluYXRpbmcgcGVyaW9kIGVsYXBzZXMsIHRoZSBE T1RTIHNlcnZlciBNVVNUDQogICB0cmVhdCB0aGUgbWl0aWdhdGlvbiBhcyB0ZXJtaW5hdGVkLCBh cyB0aGUgRE9UUyBjbGllbnQgaXMgbm8gbG9uZ2VyDQogICByZXNwb25zaWJsZSBmb3IgdGhlIG1p dGlnYXRpb24uDQoNCltNZWRdIE9LLg0KDQpTZWN0aW9uIDQuNTogUG9pbnQgYTogVGhlIHR3byBz ZW50ZW5jZXMgb24gSGVhcnRiZWF0IGludGVydmFsIGFyZQ0KcGFyYWxsZWwgYW5kIHNsaWdodGx5 IGluY29uc2lzdGVudC4gU3VnZ2VzdCBzaW1wbHkgZGVsZXRpbmcgdGhlIGZpcnN0DQpzZW50ZW5j ZS4NCg0KDQpTZWN0aW9uIDQuNjogU3VnZ2VzdGVkIHdvcmRpbmcgY2hhbmdlIHRvIGN1dCBkb3du IG9uIHZlcmJpYWdlOg0KT0xEDQogICBJZiBhIERPVFMgc2VydmVyIHdhbnRzIHRvIHJlZGlyZWN0 IGEgRE9UUyBjbGllbnQgdG8gYW4gYWx0ZXJuYXRpdmUNCiAgIERPVFMgc2VydmVyIGZvciBhIHNp Z25hbCBzZXNzaW9uLCB0aGVuIHRoZSBSZXNwb25zZSBDb2RlIDUuMDMNCiAgIChTZXJ2aWNlIFVu YXZhaWxhYmxlKSB3aWxsIGJlIHJldHVybmVkIGluIHRoZSByZXNwb25zZSB0byB0aGUgRE9UUw0K ICAgY2xpZW50Lg0KDQogICBUaGUgRE9UUyBzZXJ2ZXIgY2FuIHJldHVybiB0aGUgZXJyb3IgUmVz cG9uc2UgQ29kZSA1LjAzIGluIHJlc3BvbnNlDQogICB0byBhIHJlcXVlc3QgZnJvbSB0aGUgRE9U UyBjbGllbnQgb3IgY29udmV5IHRoZSBlcnJvciBSZXNwb25zZSBDb2RlDQogICA1LjAzIGluIGEg dW5pZGlyZWN0aW9uYWwgbm90aWZpY2F0aW9uIHJlc3BvbnNlIGZyb20gdGhlIERPVFMgc2VydmVy Lg0KTkVXDQogICBUbyByZWRpcmVjdCBhIERPVFMgY2xpZW50IHRvIGFuIGFsdGVybmF0aXZlIERP VFMgc2VydmVyIGZvciBhDQogICBzaWduYWwgc2Vzc2lvbiwgdGhlIHNlcnZlciBjYW4gcmV0dXJu IHRoZSBSZXNwb25zZSBDb2RlIDUuMDMNCiAgIChTZXJ2aWNlIFVuYXZhaWxhYmxlKSB0byB0aGUg RE9UUyBjbGllbnQgb3IgdGhlIHNlcnZlciBjYW4gcmV0dXJuDQogICB0aGF0IFJlc3BvbnNlIENv ZGUgaW4gYSBub3RpZmljYXRpb24gcmVzcG9uc2UgdG8gdGhlIGNsaWVudC4NCg0KW01lZF0gVGhh bmtzLiBDaGFuZ2VkIHRvOg0KDQpUbyByZWRpcmVjdCBhIERPVFMgY2xpZW50IHRvIGFuIGFsdGVy bmF0aXZlIERPVFMgc2VydmVyLCB0aGUgRE9UUyBzZXJ2ZXIgY2FuIHJldHVybiB0aGUgZXJyb3Ig UmVzcG9uc2UgQ29kZSA1LjAzIChTZXJ2aWNlIFVuYXZhaWxhYmxlKSBpbiByZXNwb25zZSB0byBh IHJlcXVlc3QgZnJvbSB0aGUgRE9UUyBjbGllbnQgb3IgY29udmV5IHRoZSBlcnJvciBSZXNwb25z ZSBDb2RlIDUuMDMgaW4gYSB1bmlkaXJlY3Rpb25hbCBub3RpZmljYXRpb24gcmVzcG9uc2UgdG8g dGhlIGNsaWVudC4NCg0KU2VjdGlvbiA0LjY6IFN1Z2dlc3QgcmVwbGFjaW5nICJjYW4iIHdpdGgg Ik1BWSIgb3IgIlNIT1VMRCIgaW4gdGhlDQpmb2xsb3dpbmcgZHJhZnQgdGV4dDoNCiAgIFJlcXVl c3RzIGlzc3VlZCBieSBtaXNiZWhhdmluZyBET1RTIGNsaWVudHMgdGhhdCBkbyBub3QgaG9ub3Ig dGhlIFRUTA0KICAgY29udmV5ZWQgaW4gdGhlIE1heC1BZ2UgT3B0aW9uIG9yIHJlYWN0IHRvIGV4 cGxpY2l0IHJlZGlyZWN0IG1lc3NhZ2VzDQogICBjYW4gYmUgcmVqZWN0ZWQgYnkgRE9UUyBzZXJ2 ZXJzLg0KDQpbTWVkXSBzL2Nhbi9NQVkuDQoNCg0KU2VjdGlvbiA3LjM6IFNpbmNlIHRoZSBQTVRV IGNhbiBjaGFuZ2UgYW5kIGNvdWxkIGJlIGxvd2VyIHRoYXQgdGhlDQp2YWx1ZXMgc3VnZ2VzdGVk IHRvIGJlIGFzc3VtZWQgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDcuMywNCml0 IGlzIGVzc2VudGlhbGx5IGltcG9zc2libGUgdG8gY29uZm9ybSB0byB0aGUgZmlyc3Qgc2VudGVu Y2UgYXMNCndyaXR0ZW4uIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIGNoYW5nZToNCk9MRA0KICAg VG8gYXZvaWQgRE9UUyBzaWduYWwgbWVzc2FnZSBmcmFnbWVudGF0aW9uIGFuZCB0aGUgc3Vic2Vx dWVudA0KICAgZGVjcmVhc2VkIHByb2JhYmlsaXR5IG9mIG1lc3NhZ2UgZGVsaXZlcnksIERPVFMg YWdlbnRzIE1VU1QgZW5zdXJlDQogICB0aGF0IHRoZSBEVExTIHJlY29yZCBmaXRzIHdpdGhpbiBh IHNpbmdsZSBkYXRhZ3JhbS4NCg0KW01lZF0gV2UgYXJlIGVjaG9pbmcgdGhlIGZvbGxvd2luZyBm cm9tIFNlY3Rpb24gNC4xLjEgb2YgNjM0NzoNCg0KDQrigJxFYWNoIERUTFMgcmVjb3JkIE1VU1Qg Zml0IHdpdGhpbiBhIHNpbmdsZSBkYXRhZ3JhbS7igJ0NCg0KDQpORVcNCiAgIFRvIGF2b2lkIERP VFMgc2lnbmFsIG1lc3NhZ2UgZnJhZ21lbnRhdGlvbiBhbmQgdGhlIHN1YnNlcXVlbnQNCiAgIGRl Y3JlYXNlZCBwcm9iYWJpbGl0eSBvZiBtZXNzYWdlIGRlbGl2ZXJ5LCBET1RTIGFnZW50cyBNVVNU IE5PVA0KICAgc2VuZCBkYXRhZ3JhbXMgZXhjZWVkaW5nIHRoZSBsaW1pdHMgZGlzY3Vzc2VkIGlu IHRoaXMgU2VjdGlvbi4NCg0KDQpTZWN0aW9uIDg6IFRoZSBmb2xsb3dpbmcgdGV4dCBzYXlzIHRo YXQgYSBzZXJ2ZXIgb25seSBhY2NlcHRzIG1lc3NhZ2VzDQpmcm9tIGEgZ2F0ZXdheSwgYWx0aG91 Z2ggdGhpcyBpcyBpbW1lZGlhdGVseSBjb250cmFkaWN0ZWQgaW4gdGhlIG5leHQNCg0KW01lZF0g SSBkb27igJl0IHNlZSBhIGNvbnRyYWRpY3Rpb24gYXMgdGhlIHNlbnRlbmNlIHlvdSBxdW90ZWQg aXMgYW4gZXhhbXBsZTog4oCcSWYsIGZvciBleGFtcGxlLCDigKbigJ0NCg0KDQpwYXJhZ3JhcGgu IEkgc3VnZ2VzdCB0aGUgY2hhbmdlIGluZGljYXRlZDoNCk9MRA0KICAgYSBET1RTIHNlcnZlciBv bmx5IGFsbG93cyBET1RTIHNpZ25hbA0KICAgY2hhbm5lbCBtZXNzYWdlcyBmcm9tIGFuIGF1dGhv cml6ZWQgRE9UUyBnYXRld2F5LA0KTkVXDQogICBvbmx5IGlmIGEgZ2F0ZXdheSBpcyBhdXRob3Jp emVkIGRvZXMgYSBET1RTIHNlcnZlciBhY2NlcHQgRE9UUyBzaWduYWwNCiAgIGNoYW5uZWwgbWVz c2FnZXMgZnJvbSBpdCwNCg0KDQpTZWN0aW9uIDgsIEZpZ3VyZSAzMDogU2VlbXMgc2xpZ2h0bHkg bWlzbGVhZGluZyBiZWNhdXNlIGl0IGxvb2tzIGxpa2UNCnRoZSBsaW5rIGJldHdlZW4gdGhlIEd1 ZXN0IGFuZCBnYXRld2F5IGlzIGJyb2tlbi4gQnV0IGFjY29yZGluZyB0byB0aGUNCnRleHQsIHRo ZXkgZGlkIG11dHVhbGx5IGF1dGhlbnRpY2F0ZS4gSSB3b3VsZCBzdWdnZXN0IG1vdmluZyB0aGUg IlgiDQp0byBpbmRpY2F0ZSBmYWlsdXJlIHRvIGp1c3QgaW5zaWRlIHRoZSBET1RTIGdhdGV3YXkg Ym94IHdoZXJlIHRoZSBsaW5rDQpmcm9tIHRoZSBjbGllbnQgYXJyaXZlcyBhdCB0aGUgZ2F0ZXdh eSBib3guDQoNCltNZWRdIOKAnHjigJ0gaXMgaW4gcmVmZXJlbmNlIHRvIHRoaXMgdGV4dDoNCg0K DQogICBJbg0KDQogICB0aGlzIGV4YW1wbGUsIHRoZSBET1RTIGdhdGV3YXkgb25seSBhbGxvd3Mg dGhlIGFwcGxpY2F0aW9uIHNlcnZlciBhbmQNCg0KICAgRERvUyBhdHRhY2sgZGV0ZWN0b3IgdG8g cmVxdWVzdCBERG9TIG1pdGlnYXRpb24sIGJ1dCBkb2VzIG5vdCBwZXJtaXQNCg0KICAgdGhlIHVz ZXIgb2YgdHlwZSAnZ3Vlc3QnIHRvIHJlcXVlc3QgRERvUyBtaXRpZ2F0aW9uDQoNCkkgdGhpbmsg eW91IHdlcmUgY29uZnVzZWQgYnkg4oCcbXV0dWFsbHkgYXV0aGVudGljYXRl4oCdLiBDaGFuZ2Vk IGl0IHRvIOKAnHByb2NlZWQgd2l0aCBtdXR1YWwgYXV0aGVudGljYXRpb27igJ0uDQoNClNlY3Rp b25zIDEwOiBJZiBhbGwgcmVmZXJlbmNlcyB0byBbUkZDODc4Ml0gaW4gYSByZWdpc3RyeSBuZWVk IHRvIGJlDQpyZXBsYWNlZCB3aXRoIHJlZmVyZW5jZXMgdG8gW3RoaXMgZG9jdW1lbnRdLCB0aGVy ZSBpcyBubyBuZWVkIHRvIGxpc3QNCmFsbCB0aGUgb2NjdXJyZW5jZXMgaW4gdGhlIHJlZ2lzdHJ5 LiBZb3UgY2FuIGp1c3QgdGVsbCBJQU5BIHRvIGRvIGENCmdsb2JhbCByZXBsYWNlLg0KDQpbTWVk XSBTb21lIHRhYmxlcyBhcmUgbWFpbnRhaW5lZCBhcyB3ZSByZWZlciB0byB0aGUg4oCcbGFiZWzi gJ0gaW4gb3RoZXIgc2VjdGlvbi4gV2UgdG8gcmVtb3ZlIHRoZSBvbmUgYWJvdXQga2V5cy4NCg0K DQpTZWN0aW9uIDExOg0KDQpJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBjaGFuZ2U6DQpPTEQNCiAg IEZvciB0aGlzIGF0dGFjayB2ZWN0b3INCiAgIHRvIGhhcHBlbiwgdGhlIG1pc2JlaGF2aW5nIGNs aWVudCBuZWVkcyB0byBwYXNzIHRoZSBzZWN1cml0eQ0KICAgdmFsaWRhdGlvbiBjaGVja3MgYnkg dGhlIERPVFMgc2VydmVyLCBhbmQgZXZlbnR1YWxseSB0aGUgY2hlY2tzIG9mIGENCiAgIGNsaWVu dC1kb21haW4gRE9UUyBnYXRld2F5Lg0KTkVXDQogICBGb3IgdGhpcyBhdHRhY2sNCiAgIHRvIHN1 Y2NlZWQsIHRoZSBtaXNiZWhhdmluZyBjbGllbnQncyBtZXNzYWdlcyBuZWVkIHRvIHBhc3MgdGhl IHNlY3VyaXR5DQogICB2YWxpZGF0aW9uIGNoZWNrcyBieSB0aGUgRE9UUyBzZXJ2ZXIgYW5kLCBp ZiB0aGV5IHRyYW5zaXQgYSBET1RTDQogICBnYXRld2F5LCB0aGUgc2VjdXJpdHkgY2hlY2tzIG9m IHRoYXQgZ2F0ZXdheS4NCg0KW01lZF0gVGhhbmtzLiBXZW50IHdpdGggdGhpcyBjaGFuZ2U6DQoN CuKAnEZvciB0aGlzIGF0dGFjayB0byBzdWNjZWVkLCB0aGUgbWlzYmVoYXZpbmcgY2xpZW50J3Mg bWVzc2FnZXMgbmVlZCB0byBwYXNzIHRoZSBzZWN1cml0eSB2YWxpZGF0aW9uIGNoZWNrcyBieSB0 aGUgRE9UUyBzZXJ2ZXIgYW5kLCBpZiB0aGUgY29tbXVuaWNhdGlvbiBpbnZvbHZlcyBhIGNsaWVu dC1kb21haW4gRE9UUyBnYXRld2F5LCB0aGUgc2VjdXJpdHkgY2hlY2tzIG9mIHRoYXQgZ2F0ZXdh eS7igJ0NCg0KDQoNClRoZSB3YXkgdGhpcyBzZW50ZW5jZSB0YWxrcyBhYm91dCBtb3ZpbmcgYXJv dW5kICJtaXRpZ2F0aW9uIGVmZmljYWN5Ig0KcmVhZHMgdmVyeSBzdHJhbmdlbHkgdG8gbWUuIEkg c3VnZ2VzdCB0aGUgZm9sbG93aW5nIHJlLXdvcmRpbmc6DQpPTEQNCiAgIEEgY29tcHJvbWlzZWQg RE9UUyBjbGllbnQgY2FuIGNvbGx1ZGUgd2l0aCBhIEREb1MgYXR0YWNrZXIgdG8gc2VuZA0KICAg bWl0aWdhdGlvbiByZXF1ZXN0IGZvciBhIHRhcmdldCByZXNvdXJjZSwgZ2V0IHRoZSBtaXRpZ2F0 aW9uIGVmZmljYWN5DQogICBmcm9tIHRoZSBET1RTIHNlcnZlciwgYW5kIGNvbnZleSB0aGUgbWl0 aWdhdGlvbiBlZmZpY2FjeSB0byB0aGUgRERvUw0KICAgYXR0YWNrZXIgdG8gcG9zc2libHkgY2hh bmdlIHRoZSBERG9TIGF0dGFjayBzdHJhdGVneS4NCk5FVw0KICAgQSBjb21wcm9taXNlZCBET1RT IGNsaWVudCBjYW4gYmUgY29tbWFuZGVkIGJ5IGEgRERvUyBhdHRhY2tlciB0bw0KICAgYWJ1c2Ug bWl0aWdhdGlvbiByZXF1ZXN0cyBmb3IgYSB0YXJnZXQgcmVzb3VyY2UuIFRoaXMgY291bGQgdXNl IHRoZQ0KICAgIm1pdGlnYXRpb24iIGFiaWxpdGllcyBvZiB0aGUgRE9UUyBzZXJ2ZXIgZm9yIHRo ZSBiZW5lZml0IG9mIHRoZQ0KICAgYXR0YWNrZXIgcG9zc2libHkgbGVhZGluZyB0byBhIGNoYW5n ZWQgYW5kIG1vcmUgZWZmZWN0aXZlIEREb1MNCiAgIGF0dGFjayBzdHJhdGVneS4NCg0KW01lZF0g VGhhbmtzLiBJIHByZWZlciB0aGUgT0xEIHdvcmRpbmcuDQoNCg0KSGVyZSBpcyBhbm90aGVyICJN VVNUIiB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJld29yZGVkIGJlY2F1c2UgeW91DQpjYW5ub3Qg Z3VhcmFudGVlIGNvbmZvcm1hbmNlIHRvIHRoZSBNVVNULiBGb3IgZXhhbXBsZSwgdGhlIHNlcnZl cg0KY291bGQgaGF2ZSBydW4gb3V0IG9mIHN0YXRlIG1lbW9yeS4NCk9MRA0KICAgVGhhdCBpcywg b25seSBhY3Rpb25zIG9uIElQDQogICByZXNvdXJjZXMgdGhhdCBiZWxvbmcgdG8gdGhlIERPVFMg Y2xpZW50J3MgZG9tYWluIE1VU1QgYmUgYXV0aG9yaXplZA0KICAgYnkgYSBET1RTIHNlcnZlci4N Ck5FVw0KICAgQSBET1RTIHNlcnZlciBNVVNUIE5PVCBhdXRob3JpemUgYWN0aW9ucyBkdWUgdG8g YSBET1RTIGNsaWVudA0KICAgcmVxdWVzdCB1bmxlc3MgdGhvc2UgYWN0aW9ucyBhcmUgbGltaXRl ZCB0byB0aGF0IGNsaWVudCdzIElQDQogICByZXNvdXJjZXMuDQoNCltNZWRdIE5vIHByb2JsZW0u IEkgd2VudCB3aXRoIHRoaXMgY2hhbmdlOg0KDQrigJxBIERPVFMgc2VydmVyIE1VU1QgTk9UIGF1 dGhvcml6ZSBhY3Rpb25zIGR1ZSB0byBhIERPVFMgY2xpZW50IHJlcXVlc3QgdW5sZXNzIHRob3Nl IGFjdGlvbnMgYXJlIGxpbWl0ZWQgdG8gdGhhdCBET1RTIGNsaWVudCdzIGRvbWFpbiBJUCByZXNv dXJjZXMu4oCdDQoNCg0KTWlzY2VsbGFuZW91cyBvYnNlcnZhdGlvbjogSXQncyB0b28gYmFkIHRo YXQgdGhlcmUgc2VlbXMgdG8gYmUNCmFic29sdXRlbHkgbm8gY29vcmRpbmF0aW9uIGJldHdlZW4g RE9UUyBhbmQgQkdQIGZsb3dzcGVjLg0KDQpbTWVkXSBXZSB0cmllZCBpbiBSRkM4NzgzIHRvIG1h a2UgdXNlIG9mIGF0dHJpYnV0ZXMgdGhhdCBjYW4gYmUgZWFzaWx5IG1hcHBlZCB0byBCR1AgRmxv d3NwZWMuIFRoZSBnbHVlIGJldHdlZW4gRE9UUyBhbmQgQkdQIGZsb3dwc2VjIGlzIGltcGxlbWVu dGF0aW9uLXNwZWNpZmljLCBJTU8uDQoNClRoYW5rcywNCkRvbmFsZA0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIy NzAgKGNlbGwpDQogMjM4NiBQYW5vcmFtaWMgQ2lyY2xlLCBBcG9wa2EsIEZMIDMyNzAzIFVTQQ0K IGQzZTNlM0BnbWFpbC5jb208bWFpbHRvOmQzZTNlM0BnbWFpbC5jb20+DQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFu ayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B93303535A427OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBy w6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgRG9uYWxkLA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+TWFueSB0aGFua3MgZm9yIHRoZSByZXZpZXcuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IERvbmFsZCBFYXN0bGFrZSBbbWFpbHRvOmQzZTNlM0BnbWFpbC5jb21dDQo8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gbWFyZGkgMjMgbWFycyAyMDIxIDA1OjUzPGJyPg0KPGI+w4AmbmJzcDs6 PC9iPiBpZXNnQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmc8YnI+DQo8Yj5DYyZuYnNwOzo8 L2I+IGRyYWZ0LWlldGYtZG90cy1yZmM4NzgyLWJpcy5hbGxAaWV0Zi5vcmc7IHNlY2RpciAmbHQ7 c2VjZGlyQGlldGYub3JnJmd0Ozxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gU0VDRElSIFJldmll dyBkcmFmdC1pZXRmLWRvdHMtcmZjODc4Mi1iaXMtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1l bnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUnczxicj4NCm9uZ29pbmcgZWZm b3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZTxi cj4NCklFU0cuIFRoZXNlIHJldmlld3MgYXJlIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlIFNlY3VyaXR5IEFEcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Eb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNv bW1lbnRzIGp1c3Q8YnI+DQpsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPg0K PGJyPg0KVGhlIHN1bW1hcnkgb2YgdGhlIHJldmlldyBpcyBSZWFkeSB3aXRoIElzc3Vlcy48YnI+ DQo8YnI+DQo8YnI+DQpTZWN1cml0eTo8YnI+DQo8YnI+DQpJIHRoaW5rIHRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIGFkZXF1YXRlIGluIGl0czxicj4NCmNvdmVyYWdlIGJ1 dCBzZWUgYmVsb3cgZm9yIHNvbWUgd29yZGluZyBwcm9ibGVtcy48YnI+DQo8YnI+DQpJIGRpZCBu b3QgcmV2aWV3IFNlY3Rpb25zIDUgb3IgNi48YnI+DQo8YnI+DQo8YnI+DQpNaW5vciBJc3N1ZXMg LyBOaXRzOjxicj4NCjxicj4NCkdlbmVyYWw6IEkgZG9uJ3QgbWVhbiB0byBiZSB1bmR1bHkgaGFy c2ggYnV0IEkgd2FzIHB1dCBvZmYgYnkgdGhlPGJyPg0KZGlzY3Vyc2l2ZSBhbmQgdmVyYm9zZSBz dHlsZSBvZiB0aGlzIGRyYWZ0LiBPbiByZWFkaW5nIHRocm91Z2gsIEkgZ2V0PGJyPg0KdGhlIGZl ZWxpbmcgdGhhdCB0aGUgc2FtZSB0aGluZyBpcyBvZnRlbiBzYWlkIG1vcmUgdGhhbiBvbmNlLDxi cj4NCnNvbWV0aW1lcyB3aXRoIGRpZmZlcmVudCBsZXZlbHMgb2YgZGV0YWlsLCBzb21ldGltZXMg d2l0aCBkaWZmZXJlbnQ8YnI+DQp0ZXJtaW5vbG9neSwgc29tZXRpbWVzIGluIGNvbnNlY3V0aXZl IHNlbnRlbmNlcyBhbmQgc29tZXRpbWVzIGluPGJyPg0KZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBk cmFmdDsgaG93ZXZlciwgdGhlIG51bWVyb3VzIGV4YW1wbGVzIGFyZTxicj4NCmdlbmVyYWxseSBh IGdvb2QgdGhpbmcuPGJyPg0KPGJyPg0KR2VuZXJhbC9HbG9iYWw6IEFsbCBzaXggb2NjdXJyZW5j ZXMgb2YgJnF1b3Q7YXMgYSByZW1pbmRlciZxdW90OyBzaG91bGQgYmU8YnI+DQpkZWxldGVkIGZy b20gdGhlIGRyYWZ0LiBUaGV5IGp1c3QgYWRkIHVzZWxlc3Mgd29yZHMuPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIEV4Y2VwdCB0aGUgb25lIGFib3V0 IElQdjQvSVB2NiwgdGhvc2Ugd2VyZSBhZGRlZCB0byBhZGRyZXNzIGNvbW1lbnRzIHRoYXQgd2Ug cmVjZWl2ZWQgaW4gdGhlIHBhc3QuIEkgcHJlZmVyIHRvIG1haW50YWluIHRoZW0uDQo8L3NwYW4+ PC9pPjwvYj48YnI+DQo8YnI+DQpHZW5lcmFsOiBUaGVyZSBhcmUgbG90cyBhbmQgbG90cyBvZiBk ZWZhdWx0L3JlY29tbWVuZGVkIGNvbmZpZ3VyYXRpb248YnI+DQp2YWx1ZXMgc2NhdHRlcmVkIGFy b3VuZCB0aGUgZHJhZnQuIEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBoYXZlIGEgdGFibGU8YnI+DQpv ciBsaXN0IG9mIHRoZW0gYWxsLCBwZXJoYXBzIGFzIGFuIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRp b25zIHNlY3Rpb248YnI+DQpvciBhcHBlbmRpeC48YnI+DQo8YnI+DQo8YnI+DQpTZWN0aW9uIDE6 IERyYWZ0IHNheXMgJnF1b3Q7VGhlIERPVFMgc2VydmVyIG1heSAobm90KSBiZSBjby1sb2NhdGVk IHdpdGg8YnI+DQp0aGUgRE9UUyBtaXRpZ2F0b3IuJnF1b3Q7ICZuYnNwO1RoaXMgYXBwZWFycyB0 byBiZSBhIHBhcnRpY3VsYXJseSBjb25mdXNpbmcgd2F5PGJyPg0Kb2Ygc2F5aW5nICZxdW90O1Ro ZSBET1RTIHNlcnZlciBtYXkgb3IgbWF5IG5vdCBiZSBjby1sb2NhdGVkIHdpdGggdGhlIERPVFM8 YnI+DQptaXRpZ2F0b3IuJnF1b3Q7IHRvIHdoaWNoIHdvcmRpbmcgSSB3b3VsZCBzdWdnZXN0IGNo YW5naW5nLjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj5bTWVkXSBTdXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KU2VjdGlvbiAzOjxicj4NCjxicj4NClN1Z2dlc3Qg d29yZGluZyBjaGFuZ2UgZm9yIGNsYXJpdHkgZnJvbTxicj4NCiZuYnNwOyAmbmJzcDtET1RTIGNs aWVudHMgYW5kIHNlcnZlcnMgYmVoYXZlIGFzIENvQVAgZW5kcG9pbnRzLiZuYnNwOyBCeSBkZWZh dWx0LCBhPGJyPg0KJm5ic3A7ICZuYnNwO0RPVFMgY2xpZW50IChvciBzZXJ2ZXIpIGJlaGF2ZXMg YXMgYSBDb0FQIGNsaWVudCAob3Igc2VydmVyKS48YnI+DQombmJzcDsgJm5ic3A7TmV2ZXJ0aGVs ZXNzLCBhIERPVFMgY2xpZW50IChvciBzZXJ2ZXIpIGJlaGF2ZXMgYXMgYSBDb0FQIHNlcnZlciAo b3I8YnI+DQombmJzcDsgJm5ic3A7Y2xpZW50KSBmb3Igc3BlY2lmaWMgb3BlcmF0aW9ucyBzdWNo IGFzIERPVFMgaGVhcnRiZWF0IG9wZXJhdGlvbnM8YnI+DQombmJzcDsgJm5ic3A7KFNlY3Rpb24g NC43KS48YnI+DQp0bzxicj4NCiZuYnNwOyAmbmJzcDtET1RTIGNsaWVudHMgYW5kIHNlcnZlcnMg YmVoYXZlIGFzIENvQVAgZW5kcG9pbnRzLiZuYnNwOyBCeSBkZWZhdWx0LCBhPGJyPg0KJm5ic3A7 ICZuYnNwO0RPVFMgY2xpZW50IGJlaGF2ZXMgYXMgYSBDb0FQIGNsaWVudCBhbmQgYSBET1RTIHNl cnZlciBiZWhhdmVzIGFzPGJyPg0KJm5ic3A7ICZuYnNwO0NvQVAgc2VydmVyLiA8c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj5bTWVkXSBXZW50IHdpdGggdGhpcyBwYXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Ib3dldmVyLCBmb3Igc3BlY2lmaWMgb3BlcmF0aW9ucyBzdWNoIGFzIERPVFMgaGVh cnRiZWF0PGJyPg0KJm5ic3A7ICZuYnNwO29wZXJhdGlvbnMgKFNlY3Rpb24gNC43KSwgYSBET1RT IGNsaWVudCBvciBzZXJ2ZXIgbWF5IGJlaGF2ZSBhczxicj4NCiZuYnNwOyAmbmJzcDt0aGUgb3Bw b3NpdGUgdHlwZSBvZiBDb0FQIGVuZHBvaW50Ljxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBXaWxsIGxlYXZlIHRoZSBvbGQgb25l LiBUaGFua3MuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQpJbiB0aGUgdGV4dCBiZWxvdyBmcm9tIHRoZSBkcmFmdCwgdGhlIHBh cmVudGhlc2lzIGFuZCB3b3JkaW5nIGp1c3Q8YnI+DQpzZWVtIHRvIG11ZGRsZSB0aGluZ3MgYW5k IGNyZWF0ZSBkb3VidCBhcyB0byB0aGUgbWVhbmluZzo8YnI+DQombmJzcDsgJm5ic3A7SW4gZGVw bG95bWVudHMgd2hlcmUgbXVsdGlwbGUgRE9UUyBjbGllbnRzIGFyZSBlbmFibGVkIGluIGEgbmV0 d29yazxicj4NCiZuYnNwOyAmbmJzcDsob3duZWQgYW5kIG9wZXJhdGVkIGJ5IHRoZSBzYW1lIGVu dGl0eSksPGJyPg0KSSB0aGluayBpdCB3b3VsZCBiZSBjbGVhcmVyIGFuZCBlYXNpZXIgdG8gdW5k ZXJzdGFuZCAoYXNzdW1pbmcgSTxicj4NCnVuZGVyc3Rvb2QgaXQgY29ycmVjdGx5KSBhczo8YnI+ DQombmJzcDsgJm5ic3A7SW4gZGVwbG95bWVudHMgd2hlcmUgbXVsdGlwbGUgRE9UUyBjbGllbnRz IGFyZSBlbmFibGVkIGluIGEgbmV0d29yazxicj4NCiZuYnNwOyAmbmJzcDt3aXRoIHRoZSBjbGll bnRzIGFuZCBuZXR3b3JrIG93bmVkIGFuZCBvcGVyYXRlZCBieSB0aGUgc2FtZSBlbnRpdHksPHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W01lZF0gVXBkYXRlZCB0aGlzIG9uZSB0bzoNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBJbiBkZXBsb3ltZW50cyB3aGVyZSBtdWx0aXBs ZSBET1RTIGNsaWVudHMgYXJlIGVuYWJsZWQgaW4gYSBzaW5nbGU8bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDtuZXR3b3JrIGFuZCBhZG1pbmlzdHJhdGl2ZSBkb21h aW48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NClNob3VsZCAmcXVvdDttdXN0JnF1b3Q7IGJlIGNhcGl0YWxpemVkIGluIHRoZSBmb2xsb3dp bmcgZHJhZnQgdGV4dD88YnI+DQombmJzcDsgJm5ic3A7RnV0dXJlIERPVFMgZXh0ZW5zaW9ucyB0 aGF0IHJlcXVlc3QgYSBDQk9SIHZhbHVlIGluIHRoZSByYW5nZTxicj4NCiZuYnNwOyAmbmJzcDsm cXVvdDsxMjgtMjU1JnF1b3Q7IG11c3Qgc3VwcG9ydCBtZWFucyBzaW1pbGFyIHRvIHRoZSBhZm9y ZW1lbnRpb25lZCBET1RTPGJyPg0KJm5ic3A7ICZuYnNwO3RlbGVtZXRyeSBvbmVzLjxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBH b29kIGNhdGNoLiBGaXhlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KU2VjdGlvbiA0LjQuMTo8YnI+DQo8YnI+DQpUaGUg Zm9sbG93aW5nIGRyYWZ0IHRleHQgdXNlcyAmcXVvdDt0aGUgdHJhaWxpbmcgJnF1b3Q7PSZxdW90 OyAmcXVvdDsgd2hpY2ggaW1wbGllcyB0aGF0IGE8YnI+DQpiYXNlIDY0IGVuY29kaW5nIGVuZHMg d2l0aCBleGFjdGx5IG9uZSBlcXVhbCBzaWduLiBCdXQgSSBiZWxpZXZlIHRoZXJlPGJyPg0KY2Fu IGJlIHplcm8sIG9uZSwgb3IgdHdvIGVxdWFsIHNpZ25zLiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2lu Zzo8YnI+DQpPTEQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHRy dW5jYXRlZCBvdXRwdXQgaXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 YmFzZTY0dXJsIGVuY29kZWQgKFNlY3Rpb24gNSBvZiBbUkZDNDY0OF0pIHdpdGggdGhlIHRyYWls aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90Oz0mcXVvdDsg cmVtb3ZlZCBmcm9tIHRoZSBlbmNvZGluZywgYW5kIHRoZSByZXN1bHRpbmcgdmFsdWUgdXNlZCBh czxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgJ2N1aWQnLjxicj4N Ck5FVzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgdHJ1bmNhdGVk IG91dHB1dCBpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiYXNlNjR1 cmwgZW5jb2RlZCAoU2VjdGlvbiA1IG9mIFtSRkM0NjQ4XSkgd2l0aCBhbnkgdHJhaWxpbmc8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXF1YWwgc2lnbnMgKCZxdW90Oz0m cXVvdDspIHJlbW92ZWQgZnJvbSB0aGUgZW5jb2RpbmcsIGFuZCB0aGU8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVzdWx0aW5nIHZhbHVlIHVzZWQgYXMgdGhlICdjdWlk Jy48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0Ij48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBXZSBtZWFudCDigJxhbnkgdHJhaWxp bmfigJ0uIEZpeGVkIGJ5IHVwZGF0aW5nIHRvIOKAnHR3byB0cmFpbGluZyAmcXVvdDs9JnF1b3Q7 4oCdPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpUaGVyZSBpcyB0YWxrIG9mIGdyZWF0ZXIvbGVzc2VyIG1pZCB2YWx1ZXMuIElzIHRoYXQg YSByaW5nIGFyaXRobWV0aWM8YnI+DQpjb21wYXJpc29uIGFuZCBpZiBzbyBzaG91bGQgaXQgcmVm ZXJlbmNlIFtSRkMxODJdPzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj5bTWVkXSBJIGd1ZXNzIHlvdSBtZWFudCBSRkMxOTgyLiBXZSBkb27igJl0IG5lZWQgaXQg aGVyZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KQXBwYXJlbnRseSBwcmUtY29uZmlndXJlZCBtaXRpZ2F0aW9uIHRyaWdnZXJlZCBi eSBsb3NzIG9mIHRoZSBzaWduYWw8YnI+DQpjaGFubmVsIGFyZSBzdXBwb3NlZCB0byB1c2UgbWlk J3Mgc3RhcnRpbmcgYXQgemVybyBidXQgd3JhcCBhcm91bmQgZm9yPGJyPg0KZHluYW1pYyBtaXRp Z2F0aW9uIHdyYXBzIHRvIHplcm8uIFdvbid0IHRoYXQgY2F1c2UgY29uZmxpY3RzPzxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPltNZWRdIEkgZG9u4oCZdCBzZWUgYW55IGlzc3VlIGFzIGNvbmZsaWN0cyB0 YWtlcyBpbnRvIGFjY291bnQgdGhlIG1pdGlnYXRpb24tdHlwZS4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gdGFyZ2V0LXByb3Rv Y29sLCBJIHN1cHBvc2UgYSByZWZlcmVuY2UgdG8gdGhlIElBTkEgcHJvdG9jb2w8YnI+DQpyZWdp c3RyeSBkb2Vzbid0IGh1cnQgYnV0IGl0IHNlZW1zIHRvIG1lIHRoYXQgZGVuaWFsIG9mIHNlcnZp Y2U8YnI+DQp0cmFmZmljIGNvdWxkIHVzZSBhbnkgcHJvdG9jb2wgbnVtYmVyLCBub3QgbmVjZXNz YXJpbHkgb25lIHdpdGggYTxicj4NCnNwZWNpZmljIGRlZmluaXRpb24uIE1heWJlPGJyPg0KT0xE PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgVmFsdWVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgYXJlIHRha2VuIGZyb20gdGhlIElBTkEgcHJvdG9jb2wgcmVnaXN0cnkgW0lBTkEtUHJvdG9d Ljxicj4NCk5FVzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFZhbHVlcyBhcmUgaW50ZWdlcnMg aW4gdGhlIHJhbmdlIG9mIDAgdG8gMjU1LiBTZWUgW0lBTkEtUHJvdG9dPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgZm9yIGNvbW1vbiB2YWx1ZXMuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIFdvcmtzIGZvciBtZS4gVXBkYXRl ZC4gVGhhbmtzLg0KPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpTZWN0aW9uIDQuNC4zOiBUaGUgc2VjdGlvbiB0aXRsZSBhbmQgY29udGVu dHMgbWlzLXVzZSB0aGUgd29yZDxicj4NCiZxdW90O2VmZmljYWN5JnF1b3Q7IHN0YW5kaW5nIGJ5 IGl0c2VsZi4gJm5ic3A7JnF1b3Q7ZWZmaWNhY3kmcXVvdDsgaGFzIGEgc3Ryb25nIGltcGxpY2F0 aW9uIG9mPGJyPg0KYmVpbmcgaG93IHdlbGwgc29tZXRoaW5nIHdvcmtzLCBOT1QgaG93IGxvbmcg aXQgd29ya3MgdW5sZXNzIHRoZXJlIGlzPGJyPg0Kc29tZSBhZGRpdGlvbmFsIHdvcmQgb3Igd29y ZHMgc3VjaCBhcyAmcXVvdDtwZXJpb2Qgb2YgZWZmZWN0aXZlbmVzcyZxdW90OyBvcjxicj4NCiZx dW90O2VmZmVjdGl2ZSBmb3IgYSB3ZWVrJnF1b3Q7LiZuYnNwOyBBcyBhbiBleGFtcGxlLCAmcXVv dDtlZmZpY2FjeSZxdW90OyBmb3IgYSB2YWNjaW5lIGlzPGJyPg0KaG93IHdlbGwgaXQgd29yayB0 byBibG9jayB0aGUgZGlzZWFzZSBhZnRlciB0aGUgZnVsbCBjb3Vyc2Ugb2Y8YnI+DQp2YWNjaW5h dGlvbiBoYXMgYmVlbiBnaXZlbi4gUGVvcGxlIHVzZSBjb21wbGV0ZWx5IGRpZmZlcmVudCB3b3Jk cyB3aGVuPGJyPg0KdGFsa2luZyBhYm91dCBob3cgbG9uZyBhIHZhY2NpbmUncyBwcm90ZWN0aW9u IGxhc3RzLiBJbiB0aGlzIHBhcnRpY3VsYXI8YnI+DQpzZWN0aW9uLCBJIHJlY29tbWVuZCBzaW1w bHkgcmVwbGFjaW5nIGFsbCBvY2N1cnJlbmNlcyBvZiAmcXVvdDtlZmZpY2FjeSZxdW90Ozxicj4N CndpdGggJnF1b3Q7bGlmZXRpbWUmcXVvdDsuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01lZF0gTm90 IHN1cmUgdG8gdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGZvciB0aGUgcHJvcG9zYWwgdG8gY2hh bmdlIOKAnGVmZmljYWN54oCdIHRvIOKAnGxpZmV0aW1l4oCdLiBUaGlzIHNlY3Rpb24gaXMgYWJv dXQgc2VuZGluZyBhbiBzdGF0dXMgaW4gYSB1cGRhdGUgbWVzc2FnZSB0bw0KIHJlcG9ydCB0aGUg ZWZmaWNhY3kgb2Ygb25nb2luZyBtaXRpZ2F0aW9uLiBXZSBjYWxsIHRoYXQg4oCcZWZmaWNhY3kg dXBkYXRlc+KAnSwgZm9yIHNpbXBsaWNpdHkuPC9zcGFuPjwvaT48L2I+PGJyPg0KPGJyPg0KU2Vj dGlvbiA0LjQuMzogRmlndXJlIDE2IHNlZW1zIHRvIHNob3cgYSBzdHJpbmcgdmFsdWUgZm9yPGJy Pg0KYXR0YWNrLXN0YXR1cyBidXQgVGFibGUgNCBoYXMgb25seSBpbnRlZ2VyIHZhbHVlcz88c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj5bTWVkXSBUaGUgZmlndXJlIGlzIGNvcnJlY3QgYXMgdGhlIGV4YW1w bGUgdXNlcyBKU09OLiBGV09XLCBoZXJlIGlzIHRoZSBjb3JyZXNwb25kaW5nIHR5cGUgZm9yIHRo ZSBhdHRhY2stc3RhdHVzIGF0dHJpYnV0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgJiM0Mzst LS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0mIzQzOy0t LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgfCBQYXJhbWV0ZXIgTmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IFlBTkcgVHlwZSZuYnNwOyZuYnNwOyZuYnNwOyB8IENCT1IgfCBDQk9SIE1ham9yJm5ic3A7IHwg SlNPTiZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IEtleSZuYnNwOyB8IFR5cGUgJmFtcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBUeXBlJm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJbmZvcm1hdGlvbiB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t LS0tJiM0MzstLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tJiM0Mzs8bzpwPjwv bzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8 IGF0dGFjay1zdGF0dXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBlbnVt ZXJhdGlvbiZuYnNwOyB8IDI5Jm5ic3A7Jm5ic3A7IHwgMCB1bnNpZ25lZCZuYnNwOyB8IFN0cmlu ZyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBpcyBleHBsaWNpdGx5IG1lbnRpb25lZCBpbiBTZWN0aW9u IDQuNDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEpTT04gZW5jb2Rpbmcgb2YgWUFORyBtb2RlbGVkIGRhdGEg WzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNzk1MSIg dGl0bGU9IiZxdW90O0pTT04gRW5jb2Rpbmcgb2YgRGF0YSBNb2RlbGVkIHdpdGggWUFORyZxdW90 OyI+UkZDNzk1MTwvYT5dIGlzIHVzZWQgdG8gaWxsdXN0cmF0ZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyB0aGUgdmFyaW91cyBtZXRob2RzIGRlZmluZWQgaW4gdGhlIGZvbGxv d2luZyBzdWJzZWN0aW9ucy4mbmJzcDsgQWxzbywgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGV4YW1wbGVzIHVzZSB0aGUgTGFiZWxzIGRlZmluZWQgaW4gU2VjdGlvbnMg PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LWRvdHMtcmZjODc4Mi1iaXMtMDUjc2VjdGlvbi0xMC42LjIiPjEwLjYuMjwvYT4sIDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXJm Yzg3ODItYmlzLTA1I3NlY3Rpb24tMTAuNi4zIj4xMC42LjM8L2E+LCA8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy1yZmM4NzgyLWJp cy0wNSNzZWN0aW9uLTEwLjYuNCI+MTAuNi40PC9hPiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgYW5kIDEwLjYuNS48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KU2VjdGlvbiA0LjQuNDogSSBzdWdnZXN0IGp1c3QgcmVtb3Zpbmcg dGhlIHBhcnQgb2YgdGhlIHNlbnRlbmNlIGFmdGVyPGJyPg0KdGhlICZxdW90OywmcXVvdDsgaW4g dGhlIGZvbGxvd2luZyBkcmFmdCB0ZXh0IGJlY2F1c2UgaXQganVzdCBtYWtlcyB0aGUgc2VudGVu Y2U8YnI+DQpsb25nZXIgYW5kIGEgbGl0dGxlIGNvbmZ1c2luZzo8YnI+DQombmJzcDsgJm5ic3A7 T25jZSB0aGUgYWN0aXZlLWJ1dC10ZXJtaW5hdGluZyBwZXJpb2QgZWxhcHNlcywgdGhlIERPVFMg c2VydmVyIE1VU1Q8YnI+DQombmJzcDsgJm5ic3A7dHJlYXQgdGhlIG1pdGlnYXRpb24gYXMgdGVy bWluYXRlZCwgYXMgdGhlIERPVFMgY2xpZW50IGlzIG5vIGxvbmdlcjxicj4NCiZuYnNwOyAmbmJz cDtyZXNwb25zaWJsZSBmb3IgdGhlIG1pdGlnYXRpb24uPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIE9LLg0KPC9zcGFuPjwvaT48 L2I+PGJyPg0KPGJyPg0KU2VjdGlvbiA0LjU6IFBvaW50IGE6IFRoZSB0d28gc2VudGVuY2VzIG9u IEhlYXJ0YmVhdCBpbnRlcnZhbCBhcmU8YnI+DQpwYXJhbGxlbCBhbmQgc2xpZ2h0bHkgaW5jb25z aXN0ZW50LiBTdWdnZXN0IHNpbXBseSBkZWxldGluZyB0aGUgZmlyc3Q8YnI+DQpzZW50ZW5jZS48 YnI+DQo8YnI+DQo8YnI+DQpTZWN0aW9uIDQuNjogU3VnZ2VzdGVkIHdvcmRpbmcgY2hhbmdlIHRv IGN1dCBkb3duIG9uIHZlcmJpYWdlOjxicj4NCk9MRDxicj4NCiZuYnNwOyAmbmJzcDtJZiBhIERP VFMgc2VydmVyIHdhbnRzIHRvIHJlZGlyZWN0IGEgRE9UUyBjbGllbnQgdG8gYW4gYWx0ZXJuYXRp dmU8YnI+DQombmJzcDsgJm5ic3A7RE9UUyBzZXJ2ZXIgZm9yIGEgc2lnbmFsIHNlc3Npb24sIHRo ZW4gdGhlIFJlc3BvbnNlIENvZGUgNS4wMzxicj4NCiZuYnNwOyAmbmJzcDsoU2VydmljZSBVbmF2 YWlsYWJsZSkgd2lsbCBiZSByZXR1cm5lZCBpbiB0aGUgcmVzcG9uc2UgdG8gdGhlIERPVFM8YnI+ DQombmJzcDsgJm5ic3A7Y2xpZW50Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgRE9UUyBz ZXJ2ZXIgY2FuIHJldHVybiB0aGUgZXJyb3IgUmVzcG9uc2UgQ29kZSA1LjAzIGluIHJlc3BvbnNl PGJyPg0KJm5ic3A7ICZuYnNwO3RvIGEgcmVxdWVzdCBmcm9tIHRoZSBET1RTIGNsaWVudCBvciBj b252ZXkgdGhlIGVycm9yIFJlc3BvbnNlIENvZGU8YnI+DQombmJzcDsgJm5ic3A7NS4wMyBpbiBh IHVuaWRpcmVjdGlvbmFsIG5vdGlmaWNhdGlvbiByZXNwb25zZSBmcm9tIHRoZSBET1RTIHNlcnZl ci48YnI+DQpORVc8YnI+DQombmJzcDsgJm5ic3A7VG8gcmVkaXJlY3QgYSBET1RTIGNsaWVudCB0 byBhbiBhbHRlcm5hdGl2ZSBET1RTIHNlcnZlciBmb3IgYTxicj4NCiZuYnNwOyAmbmJzcDtzaWdu YWwgc2Vzc2lvbiwgdGhlIHNlcnZlciBjYW4gcmV0dXJuIHRoZSBSZXNwb25zZSBDb2RlIDUuMDM8 YnI+DQombmJzcDsgJm5ic3A7KFNlcnZpY2UgVW5hdmFpbGFibGUpIHRvIHRoZSBET1RTIGNsaWVu dCBvciB0aGUgc2VydmVyIGNhbiByZXR1cm48YnI+DQombmJzcDsgJm5ic3A7dGhhdCBSZXNwb25z ZSBDb2RlIGluIGEgbm90aWZpY2F0aW9uIHJlc3BvbnNlIHRvIHRoZSBjbGllbnQuPGJyPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIFRo YW5rcy4gQ2hhbmdlZCB0bzo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VG8gcmVkaXJlY3QgYSBET1RTIGNsaWVudCB0byBhbiBhbHRlcm5h dGl2ZSBET1RTIHNlcnZlciwgdGhlIERPVFMgc2VydmVyIGNhbiByZXR1cm4gdGhlIGVycm9yIFJl c3BvbnNlIENvZGUgNS4wMyAoU2VydmljZSBVbmF2YWlsYWJsZSkgaW4gcmVzcG9uc2UgdG8gYSBy ZXF1ZXN0DQogZnJvbSB0aGUgRE9UUyBjbGllbnQgb3IgY29udmV5IHRoZSBlcnJvciBSZXNwb25z ZSBDb2RlIDUuMDMgaW4gYSB1bmlkaXJlY3Rpb25hbCBub3RpZmljYXRpb24gcmVzcG9uc2UgdG8g dGhlIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NClNlY3Rpb24gNC42OiBTdWdnZXN0IHJlcGxhY2luZyAmcXVvdDtjYW4mcXVv dDsgd2l0aCAmcXVvdDtNQVkmcXVvdDsgb3IgJnF1b3Q7U0hPVUxEJnF1b3Q7IGluIHRoZTxicj4N CmZvbGxvd2luZyBkcmFmdCB0ZXh0Ojxicj4NCiZuYnNwOyAmbmJzcDtSZXF1ZXN0cyBpc3N1ZWQg YnkgbWlzYmVoYXZpbmcgRE9UUyBjbGllbnRzIHRoYXQgZG8gbm90IGhvbm9yIHRoZSBUVEw8YnI+ DQombmJzcDsgJm5ic3A7Y29udmV5ZWQgaW4gdGhlIE1heC1BZ2UgT3B0aW9uIG9yIHJlYWN0IHRv IGV4cGxpY2l0IHJlZGlyZWN0IG1lc3NhZ2VzPGJyPg0KJm5ic3A7ICZuYnNwO2NhbiBiZSByZWpl Y3RlZCBieSBET1RTIHNlcnZlcnMuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIHMvY2FuL01BWS4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KU2VjdGlvbiA3 LjM6IFNpbmNlIHRoZSBQTVRVIGNhbiBjaGFuZ2UgYW5kIGNvdWxkIGJlIGxvd2VyIHRoYXQgdGhl PGJyPg0KdmFsdWVzIHN1Z2dlc3RlZCB0byBiZSBhc3N1bWVkIGluIHRoZSBmaXJzdCBwYXJhZ3Jh cGggb2YgU2VjdGlvbiA3LjMsPGJyPg0KaXQgaXMgZXNzZW50aWFsbHkgaW1wb3NzaWJsZSB0byBj b25mb3JtIHRvIHRoZSBmaXJzdCBzZW50ZW5jZSBhczxicj4NCndyaXR0ZW4uIEkgc3VnZ2VzdCB0 aGUgZm9sbG93aW5nIGNoYW5nZTo8YnI+DQpPTEQ8YnI+DQombmJzcDsgJm5ic3A7VG8gYXZvaWQg RE9UUyBzaWduYWwgbWVzc2FnZSBmcmFnbWVudGF0aW9uIGFuZCB0aGUgc3Vic2VxdWVudDxicj4N CiZuYnNwOyAmbmJzcDtkZWNyZWFzZWQgcHJvYmFiaWxpdHkgb2YgbWVzc2FnZSBkZWxpdmVyeSwg RE9UUyBhZ2VudHMgTVVTVCBlbnN1cmU8YnI+DQombmJzcDsgJm5ic3A7dGhhdCB0aGUgRFRMUyBy ZWNvcmQgZml0cyB3aXRoaW4gYSBzaW5nbGUgZGF0YWdyYW0uPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W01lZF0gV2UgYXJlIGVjaG9pbmcgdGhlIGZvbGxvd2luZyBmcm9tIFNlY3Rpb24gNC4xLjEgb2Yg NjM0Nzo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHByZT7igJxFYWNoIERUTFMgcmVjb3JkIE1VU1QgZml0IHdpdGhpbiBhIHNp bmdsZSBkYXRhZ3JhbS7igJ08bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpORVc8YnI+DQombmJzcDsgJm5i c3A7VG8gYXZvaWQgRE9UUyBzaWduYWwgbWVzc2FnZSBmcmFnbWVudGF0aW9uIGFuZCB0aGUgc3Vi c2VxdWVudDxicj4NCiZuYnNwOyAmbmJzcDtkZWNyZWFzZWQgcHJvYmFiaWxpdHkgb2YgbWVzc2Fn ZSBkZWxpdmVyeSwgRE9UUyBhZ2VudHMgTVVTVCBOT1Q8YnI+DQombmJzcDsgJm5ic3A7c2VuZCBk YXRhZ3JhbXMgZXhjZWVkaW5nIHRoZSBsaW1pdHMgZGlzY3Vzc2VkIGluIHRoaXMgU2VjdGlvbi48 YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KU2VjdGlvbiA4OiBUaGUgZm9sbG93aW5n IHRleHQgc2F5cyB0aGF0IGEgc2VydmVyIG9ubHkgYWNjZXB0cyBtZXNzYWdlczxicj4NCmZyb20g YSBnYXRld2F5LCBhbHRob3VnaCB0aGlzIGlzIGltbWVkaWF0ZWx5IGNvbnRyYWRpY3RlZCBpbiB0 aGUgbmV4dDxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRdIEkgZG9u4oCZdCBzZWUgYSBjb250cmFk aWN0aW9uIGFzIHRoZSBzZW50ZW5jZSB5b3UgcXVvdGVkIGlzIGFuIGV4YW1wbGU6IOKAnElmLCBm b3IgZXhhbXBsZSwg4oCm4oCdPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDo1LjI1cHQiPjxicj4NCnBhcmFncmFwaC4gSSBzdWdnZXN0IHRoZSBjaGFuZ2UgaW5k aWNhdGVkOjxicj4NCk9MRDxicj4NCiZuYnNwOyAmbmJzcDthIERPVFMgc2VydmVyIG9ubHkgYWxs b3dzIERPVFMgc2lnbmFsPGJyPg0KJm5ic3A7ICZuYnNwO2NoYW5uZWwgbWVzc2FnZXMgZnJvbSBh biBhdXRob3JpemVkIERPVFMgZ2F0ZXdheSw8YnI+DQpORVc8YnI+DQombmJzcDsgJm5ic3A7b25s eSBpZiBhIGdhdGV3YXkgaXMgYXV0aG9yaXplZCBkb2VzIGEgRE9UUyBzZXJ2ZXIgYWNjZXB0IERP VFMgc2lnbmFsPGJyPg0KJm5ic3A7ICZuYnNwO2NoYW5uZWwgbWVzc2FnZXMgZnJvbSBpdCw8YnI+ DQo8YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClNlY3Rpb24gOCwgRmlndXJl IDMwOiBTZWVtcyBzbGlnaHRseSBtaXNsZWFkaW5nIGJlY2F1c2UgaXQgbG9va3MgbGlrZTxicj4N CnRoZSBsaW5rIGJldHdlZW4gdGhlIEd1ZXN0IGFuZCBnYXRld2F5IGlzIGJyb2tlbi4gQnV0IGFj Y29yZGluZyB0byB0aGU8YnI+DQp0ZXh0LCB0aGV5IGRpZCBtdXR1YWxseSBhdXRoZW50aWNhdGUu IEkgd291bGQgc3VnZ2VzdCBtb3ZpbmcgdGhlICZxdW90O1gmcXVvdDs8YnI+DQp0byBpbmRpY2F0 ZSBmYWlsdXJlIHRvIGp1c3QgaW5zaWRlIHRoZSBET1RTIGdhdGV3YXkgYm94IHdoZXJlIHRoZSBs aW5rPGJyPg0KZnJvbSB0aGUgY2xpZW50IGFycml2ZXMgYXQgdGhlIGdhdGV3YXkgYm94LjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPltNZWRdIOKAnHjigJ0gaXMgaW4gcmVmZXJlbmNlIHRvIHRoaXMgdGV4 dDo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgdGhpcyBleGFtcGxlLCB0aGUgRE9UUyBnYXRld2F5IG9ubHkgYWxsb3dzIHRoZSBh cHBsaWNhdGlvbiBzZXJ2ZXIgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IEREb1MgYXR0YWNrIGRldGVjdG9yIHRvIHJlcXVlc3QgRERvUyBtaXRpZ2F0aW9uLCBidXQgZG9l cyBub3QgcGVybWl0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoZSB1c2Vy IG9mIHR5cGUgJ2d1ZXN0JyB0byByZXF1ZXN0IEREb1MgbWl0aWdhdGlvbjxvOnA+PC9vOnA+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB5b3Ugd2VyZSBjb25mdXNlZCBieSDigJxtdXR1 YWxseSBhdXRoZW50aWNhdGXigJ0uIENoYW5nZWQgaXQgdG8g4oCccHJvY2VlZCB3aXRoIG11dHVh bCBhdXRoZW50aWNhdGlvbuKAnS48L3NwYW4+PC9pPjwvYj48YnI+DQo8YnI+DQpTZWN0aW9ucyAx MDogSWYgYWxsIHJlZmVyZW5jZXMgdG8gW1JGQzg3ODJdIGluIGEgcmVnaXN0cnkgbmVlZCB0byBi ZTxicj4NCnJlcGxhY2VkIHdpdGggcmVmZXJlbmNlcyB0byBbdGhpcyBkb2N1bWVudF0sIHRoZXJl IGlzIG5vIG5lZWQgdG8gbGlzdDxicj4NCmFsbCB0aGUgb2NjdXJyZW5jZXMgaW4gdGhlIHJlZ2lz dHJ5LiBZb3UgY2FuIGp1c3QgdGVsbCBJQU5BIHRvIGRvIGE8YnI+DQpnbG9iYWwgcmVwbGFjZS48 YnI+DQo8YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPltNZWRdIFNvbWUgdGFibGVzIGFyZSBtYWludGFpbmVkIGFzIHdlIHJlZmVyIHRv IHRoZSDigJxsYWJlbOKAnSBpbiBvdGhlciBzZWN0aW9uLiBXZSB0byByZW1vdmUgdGhlIG9uZSBh Ym91dCBrZXlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KU2VjdGlvbiAxMTo8YnI+DQo8YnI+DQpJIHN1Z2dlc3QgdGhlIGZv bGxvd2luZyBjaGFuZ2U6PGJyPg0KT0xEPGJyPg0KJm5ic3A7ICZuYnNwO0ZvciB0aGlzIGF0dGFj ayB2ZWN0b3I8YnI+DQombmJzcDsgJm5ic3A7dG8gaGFwcGVuLCB0aGUgbWlzYmVoYXZpbmcgY2xp ZW50IG5lZWRzIHRvIHBhc3MgdGhlIHNlY3VyaXR5PGJyPg0KJm5ic3A7ICZuYnNwO3ZhbGlkYXRp b24gY2hlY2tzIGJ5IHRoZSBET1RTIHNlcnZlciwgYW5kIGV2ZW50dWFsbHkgdGhlIGNoZWNrcyBv ZiBhPGJyPg0KJm5ic3A7ICZuYnNwO2NsaWVudC1kb21haW4gRE9UUyBnYXRld2F5Ljxicj4NCk5F Vzxicj4NCiZuYnNwOyAmbmJzcDtGb3IgdGhpcyBhdHRhY2sgPGJyPg0KJm5ic3A7ICZuYnNwO3Rv IHN1Y2NlZWQsIHRoZSBtaXNiZWhhdmluZyBjbGllbnQncyBtZXNzYWdlcyBuZWVkIHRvIHBhc3Mg dGhlIHNlY3VyaXR5PGJyPg0KJm5ic3A7ICZuYnNwO3ZhbGlkYXRpb24gY2hlY2tzIGJ5IHRoZSBE T1RTIHNlcnZlciBhbmQsIGlmIHRoZXkgdHJhbnNpdCBhIERPVFM8YnI+DQombmJzcDsgJm5ic3A7 Z2F0ZXdheSwgdGhlIHNlY3VyaXR5IGNoZWNrcyBvZiB0aGF0IGdhdGV3YXkuPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W01lZF0gVGhhbmtzLiBXZW50IHdpdGggdGhpcyBjaGFuZ2U6DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcRm9yIHRo aXMgYXR0YWNrIHRvIHN1Y2NlZWQsIHRoZSBtaXNiZWhhdmluZyBjbGllbnQncyBtZXNzYWdlcyBu ZWVkIHRvIHBhc3MgdGhlIHNlY3VyaXR5IHZhbGlkYXRpb24gY2hlY2tzIGJ5IHRoZSBET1RTIHNl cnZlciBhbmQsIGlmIHRoZSBjb21tdW5pY2F0aW9uIGludm9sdmVzDQogYSBjbGllbnQtZG9tYWlu IERPVFMgZ2F0ZXdheSwgdGhlIHNlY3VyaXR5IGNoZWNrcyBvZiB0aGF0IGdhdGV3YXku4oCdPG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGUgd2F5IHRoaXMgc2VudGVuY2UgdGFsa3Mg YWJvdXQgbW92aW5nIGFyb3VuZCAmcXVvdDttaXRpZ2F0aW9uIGVmZmljYWN5JnF1b3Q7PGJyPg0K cmVhZHMgdmVyeSBzdHJhbmdlbHkgdG8gbWUuIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIHJlLXdv cmRpbmc6PGJyPg0KT0xEPGJyPg0KJm5ic3A7ICZuYnNwO0EgY29tcHJvbWlzZWQgRE9UUyBjbGll bnQgY2FuIGNvbGx1ZGUgd2l0aCBhIEREb1MgYXR0YWNrZXIgdG8gc2VuZDxicj4NCiZuYnNwOyAm bmJzcDttaXRpZ2F0aW9uIHJlcXVlc3QgZm9yIGEgdGFyZ2V0IHJlc291cmNlLCBnZXQgdGhlIG1p dGlnYXRpb24gZWZmaWNhY3k8YnI+DQombmJzcDsgJm5ic3A7ZnJvbSB0aGUgRE9UUyBzZXJ2ZXIs IGFuZCBjb252ZXkgdGhlIG1pdGlnYXRpb24gZWZmaWNhY3kgdG8gdGhlIEREb1M8YnI+DQombmJz cDsgJm5ic3A7YXR0YWNrZXIgdG8gcG9zc2libHkgY2hhbmdlIHRoZSBERG9TIGF0dGFjayBzdHJh dGVneS48YnI+DQpORVc8YnI+DQombmJzcDsgJm5ic3A7QSBjb21wcm9taXNlZCBET1RTIGNsaWVu dCBjYW4gYmUgY29tbWFuZGVkIGJ5IGEgRERvUyBhdHRhY2tlciB0bzxicj4NCiZuYnNwOyAmbmJz cDthYnVzZSBtaXRpZ2F0aW9uIHJlcXVlc3RzIGZvciBhIHRhcmdldCByZXNvdXJjZS4gVGhpcyBj b3VsZCB1c2UgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyZxdW90O21pdGlnYXRpb24mcXVvdDsgYWJp bGl0aWVzIG9mIHRoZSBET1RTIHNlcnZlciBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlPGJyPg0KJm5i c3A7ICZuYnNwO2F0dGFja2VyIHBvc3NpYmx5IGxlYWRpbmcgdG8gYSBjaGFuZ2VkIGFuZCBtb3Jl IGVmZmVjdGl2ZSBERG9TPGJyPg0KJm5ic3A7ICZuYnNwO2F0dGFjayBzdHJhdGVneS48YnI+DQo8 YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01lZF0g VGhhbmtzLiBJIHByZWZlciB0aGUgT0xEIHdvcmRpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KSGVyZSBpcyBhbm90aGVyICZxdW90O01VU1QmcXVvdDsgdGhhdCBJIHRoaW5r IHNob3VsZCBiZSByZXdvcmRlZCBiZWNhdXNlIHlvdTxicj4NCmNhbm5vdCBndWFyYW50ZWUgY29u Zm9ybWFuY2UgdG8gdGhlIE1VU1QuIEZvciBleGFtcGxlLCB0aGUgc2VydmVyPGJyPg0KY291bGQg aGF2ZSBydW4gb3V0IG9mIHN0YXRlIG1lbW9yeS48YnI+DQpPTEQ8YnI+DQombmJzcDsgJm5ic3A7 VGhhdCBpcywgb25seSBhY3Rpb25zIG9uIElQPGJyPg0KJm5ic3A7ICZuYnNwO3Jlc291cmNlcyB0 aGF0IGJlbG9uZyB0byB0aGUgRE9UUyBjbGllbnQncyBkb21haW4gTVVTVCBiZSBhdXRob3JpemVk PGJyPg0KJm5ic3A7ICZuYnNwO2J5IGEgRE9UUyBzZXJ2ZXIuPGJyPg0KTkVXPGJyPg0KJm5ic3A7 ICZuYnNwO0EgRE9UUyBzZXJ2ZXIgTVVTVCBOT1QgYXV0aG9yaXplIGFjdGlvbnMgZHVlIHRvIGEg RE9UUyBjbGllbnQ8YnI+DQombmJzcDsgJm5ic3A7cmVxdWVzdCB1bmxlc3MgdGhvc2UgYWN0aW9u cyBhcmUgbGltaXRlZCB0byB0aGF0IGNsaWVudCdzIElQPGJyPg0KJm5ic3A7ICZuYnNwO3Jlc291 cmNlcy4gPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPltNZWRdIE5vIHByb2JsZW0uIEkgd2VudCB3aXRoIHRoaXMgY2hhbmdlOg0KPG86cD48 L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnEEg RE9UUyBzZXJ2ZXIgTVVTVCBOT1QgYXV0aG9yaXplIGFjdGlvbnMgZHVlIHRvIGEgRE9UUyBjbGll bnQgcmVxdWVzdCB1bmxlc3MgdGhvc2UgYWN0aW9ucyBhcmUgbGltaXRlZCB0byB0aGF0IERPVFMg Y2xpZW50J3MgZG9tYWluIElQIHJlc291cmNlcy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCk1pc2NlbGxhbmVvdXMgb2Jz ZXJ2YXRpb246IEl0J3MgdG9vIGJhZCB0aGF0IHRoZXJlIHNlZW1zIHRvIGJlPGJyPg0KYWJzb2x1 dGVseSBubyBjb29yZGluYXRpb24gYmV0d2VlbiBET1RTIGFuZCBCR1AgZmxvd3NwZWMuPGJyPg0K PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNZWRd IFdlIHRyaWVkIGluIFJGQzg3ODMgdG8gbWFrZSB1c2Ugb2YgYXR0cmlidXRlcyB0aGF0IGNhbiBi ZSBlYXNpbHkgbWFwcGVkIHRvIEJHUCBGbG93c3BlYy4gVGhlIGdsdWUgYmV0d2VlbiBET1RTIGFu ZCBCR1AgZmxvd3BzZWMgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMsDQogSU1PLiA8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoYW5r cyw8YnI+DQpEb25hbGQ8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K Jm5ic3A7RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAmbmJzcDsgJiM0MzsxLTUwOC0zMzMtMjI3MCAo Y2VsbCk8YnI+DQombmJzcDsyMzg2IFBhbm9yYW1pYyBDaXJjbGUsIEFwb3BrYSwgRkwgMzI3MDMg VVNBPGJyPg0KJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmQzZTNlM0BnbWFpbC5jb20iPmQzZTNlM0Bn bWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93303535A427OPEXCAUBMA2corp_-- From nobody Tue Mar 23 06:57:33 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CBF3A0D98; Tue, 23 Mar 2021 06:57:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Mundy via Datatracker To: Cc: ace@ietf.org, draft-ietf-ace-dtls-authorize.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161650784817.17945.12291269672567824243@ietfa.amsl.com> Reply-To: Russ Mundy Date: Tue, 23 Mar 2021 06:57:28 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-ace-dtls-authorize-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 13:57:28 -0000 Reviewer: Russ Mundy Review result: Ready Issues identified in the earlier review on version 14 have been resolved through the good work of the Working Group and Work Group Chair. Compliments to all involved. From nobody Thu Mar 25 10:39:08 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A18633A2874 for ; Thu, 25 Mar 2021 10:39:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <161669394663.24280.7983563102944027896@ietfa.amsl.com> Date: Thu, 25 Mar 2021 10:39:06 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 17:39:07 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-03-25 Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Charlie Kaufman R2019-12-13 draft-ietf-ace-oauth-params Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 For telechat 2021-04-08 Reviewer LC end Draft Melinda Shore R2021-02-16 draft-ietf-bess-evpn-oam-req-frmwk Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Nancy Cam-Winget 2021-03-16 draft-ietf-acme-authority-token-tnauthlist Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Daniel Franke 2021-03-28 draft-ietf-tls-dtls-connection-id Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Dan Harkins 2021-03-22 draft-ietf-6man-spring-srv6-oam Leif Johansson None draft-ietf-netconf-crypto-types Charlie Kaufman R2019-12-13 draft-ietf-ace-oauth-params Chris Lonvick 2021-03-29 draft-ietf-grow-bmp-local-rib Aanchal Malhotra None draft-ietf-opsawg-l3sm-l3nm David Mandelberg None draft-ietf-lwig-minimal-esp Sandra Murphy R2021-04-05 draft-ietf-dmarc-psd Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Tim Polk None draft-ietf-opsawg-finding-geofeeds Melinda Shore R2021-02-16 draft-ietf-bess-evpn-oam-req-frmwk Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Scott Kelly 2021-04-01 draft-ietf-tcpm-accurate-ecn Tina Tsou 2021-02-15 draft-ietf-idr-eag-distribution Paul Wouters 2021-02-19 draft-ietf-idr-bgp-ls-app-specific-attr Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Catherine Meadows Alexey Melnikov Daniel Migault Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman From nobody Thu Mar 25 15:23:04 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A41C43A0C5B; Thu, 25 Mar 2021 15:22:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: acme@ietf.org, draft-ietf-acme-authority-token-tnauthlist.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161671097161.19931.2101173557579231370@ietfa.amsl.com> Reply-To: Nancy Cam-Winget Date: Thu, 25 Mar 2021 15:22:51 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-acme-authority-token-tnauthlist-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 22:22:52 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the extensions to ACME to allow for a third party Token Authority also act as the authority and authorization of entities to control a resource; the use case and motivating scenario described in the draft is for a telephone authority to be the authority for creating CA types of certificates for (STIR) delegation. The document assumes full knowledge of a set of drafts and is straightforward. I only have a couple of nits but otherwise I think it is ready. NITs: Section 5.2: the "exp" claim is mute on SHOULD vs MUST, it seems that you would want to have such a claim so minimally a SHOULD? Section 5.3: is this optional, may or must? Section 5.4: personal nit, the section should specify this claim to be a MUST, it is implicitly stated but would prefer it to be explicit. Section 6: -I presume that "verify the atc field" is actually verifying that the TNAuthList token is valid? From nobody Fri Mar 26 09:14:37 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700EF3A2236 for ; Fri, 26 Mar 2021 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFHWtZK-AH8n for ; Fri, 26 Mar 2021 09:14:24 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 18E0E3A2237 for ; Fri, 26 Mar 2021 09:14:23 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id q26so5744797qkm.6 for ; Fri, 26 Mar 2021 09:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RNWcoOM9flfqgzJio1uysOukTl/X40B87G9u4Y26qUs=; b=RTakSnKYbaGS28dvPpiL6g3UGD6+VB7VuUanbdDQkCVywGGCJSHTnTfG+YWBnp+1gV LOxqWfiTKxVD6gGwpbODUd31yalB0KxLPJM4b9pjJPpJHqygbmNN2kFA3T+vprZLJ+et w1Iuz8TcSlM6K2hCHZSIVhOhhGIX3OcJmBilGTJ3Tyyukad5Jfld+xuKw4i73QSSE46F Y9tlp/u+BN/qKuvmz5dwvwMrZzppq5+TgKhWmwvHSE8oSTeBqNOXDgCqehvFR56M6MRc GHgCLZpjWx2zBM8d8LHmMRWJGTQweXKZ0OmFxt4yATMluhbhKRnig9289/yOd9YRsZDq quqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RNWcoOM9flfqgzJio1uysOukTl/X40B87G9u4Y26qUs=; b=oEzyi/naO1HVRK3CecXmr0MADhs8DP41xzLTRJkDTAbCDbW+rtqnPScLG6D/d3NHjA EcmhjyDUW/xP+rsfl4QuMbc7fVTkGlwVnIqog5VUkg9zbedFzniQaeaYE98XQRSACt3A h5goajQp2kcOkJ9RI9J+YBBDyNVeUDHS343DOEaLHWNLJ4I0yqPkFkGc6DebW8n3+3dJ WzY/nU5NAbaGsSwxNy8uxwz2HxjfqWANUZyxzujK1MG6zgIWtq/plqLEsHptUf/gLvwf htXqlF+ZoayH/ZvRVZUHrjwDArnqCpEdaD7SLzXgdzF2Bu3bntNgTUS2lFM70IVLnvWb gEiQ== X-Gm-Message-State: AOAM532Xs802MGFEUQ+P8WpaVFEdeOq/kGfUcxK+o145ZXJvRQokdYUX DAh8UcKzXwrBVn592abCiqVbUw== X-Google-Smtp-Source: ABdhPJycybELDJkyTMLclxKTQX8F6W8YOdjOeG+mLBYLPS3lA9KsxVu06FP9xSfhWq6v3zp1SRbJhw== X-Received: by 2002:a05:620a:525:: with SMTP id h5mr14017150qkh.100.1616775262448; Fri, 26 Mar 2021 09:14:22 -0700 (PDT) Received: from [192.168.0.244] (c-68-82-121-87.hsd1.pa.comcast.net. [68.82.121.87]) by smtp.gmail.com with ESMTPSA id 1sm5986681qtw.3.2021.03.26.09.14.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Mar 2021 09:14:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Chris Wendt In-Reply-To: <161671097161.19931.2101173557579231370@ietfa.amsl.com> Date: Fri, 26 Mar 2021 12:14:18 -0400 Cc: secdir@ietf.org, acme@ietf.org, draft-ietf-acme-authority-token-tnauthlist.all@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <161671097161.19931.2101173557579231370@ietfa.amsl.com> To: Nancy Cam-Winget X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-acme-authority-token-tnauthlist-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 16:14:29 -0000 Hi Nancy, Thanks for the review i have addressed the nits and included explicit = MUSTs as referenced. I will release an 08 version soon pending any = other reviews. Thanks! -Chris > On Mar 25, 2021, at 6:22 PM, Nancy Cam-Winget via Datatracker = wrote: >=20 > Reviewer: Nancy Cam-Winget > Review result: Has Nits >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document describes the extensions to ACME to allow for a third = party Token > Authority also act as the authority and authorization of entities to = control a > resource; the use case and motivating scenario described in the draft = is for a > telephone authority to be the authority for creating CA types of = certificates > for (STIR) delegation. The document assumes full knowledge of a set = of drafts > and is straightforward. I only have a couple of nits but otherwise I = think it > is ready. >=20 > NITs: > Section 5.2: the "exp" claim is mute on SHOULD vs MUST, it seems that = you would > want to have such a claim so minimally a SHOULD? >=20 > Section 5.3: is this optional, may or must? >=20 > Section 5.4: personal nit, the section should specify this claim to be = a MUST, > it is implicitly stated but would prefer it to be explicit. >=20 > Section 6: > -I presume that "verify the atc field" is actually verifying that the > TNAuthList token is valid? >=20 >=20 >=20 From nobody Fri Mar 26 10:08:23 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9073A2081; Thu, 25 Mar 2021 05:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1616677032; bh=R3FdQDmLMvwSsV0CwjkfP2IN8SRBYacuaVGfrIelJDg=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=fdvhN4S1B9SMbZtINpZbdj4+kWomfU77GFg/egEs82+GhQmyJnoDaqmn2kzyruHer lzkYQDHPyHwsX+sj81OsiWauZ0/jTZ5Qk2E9V32yIlYDb8/11/F1p0a378x4Cap6uV ZCAS/zU21O99geEt891w9FCbkCCId4TLlJIUcAII= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Mar 25 05:57:11 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E51F3A2078; Thu, 25 Mar 2021 05:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1616677031; bh=R3FdQDmLMvwSsV0CwjkfP2IN8SRBYacuaVGfrIelJDg=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=D0IpQYpy6QO/NMqnnEDyAftu9c+5ZgWo0i31P+WUgoNm3QwKYD6H0WUE63EsqROnA WlyxoY4FfC/fzmknyPb1wvIVUitvdIAWKoYvOKDwEGEglqGlmqTOJiQ7nr6/OcwqyA EXb8e2YhXqjNbIGg2aenzKMuirHKOSOEZ+Dntct8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4683A2078 for ; Thu, 25 Mar 2021 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_dkK41TXgPB for ; Thu, 25 Mar 2021 05:57:05 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A383A2077 for ; Thu, 25 Mar 2021 05:57:05 -0700 (PDT) Received: from [89.187.161.155] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lPPXr-000174-Rq for new-work@ietf.org; Thu, 25 Mar 2021 12:57:04 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <5d251df7-74f8-0add-b44e-c94cec0ae575@w3.org> Date: Thu, 25 Mar 2021 20:57:00 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 26 Mar 2021 10:08:21 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Automotive Working Group (until 2021-04-23/24) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 12:57:14 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgQXV0b21v dGl2ZSBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93M2MuZ2l0aHViLmlvL2F1dG9tb3RpdmUv cGxhbm5pbmcvY2hhcnRlci0yMDIwLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0aGUg Y29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0IGNo YXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBwZXJp b2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAwMzo1OSBVVEMgb24gMjAy MS0wNC0yNAooMjM6NTksIEVhc3Rlcm4gdGltZSBvbiAyMDIxLTA0LTIzKSBvbiB0aGUgcHJvcG9z ZWQgY2hhcnRlci4KUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gcHVibGljLW5ldy13b3JrQHczLm9y ZywKd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlzdHMudzMub3JnL0Fy Y2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNvbW1lbnRzIHNlbnQg aW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVlIFJlcHJlc2VudGF0 aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21tZW50cy4gSWYgeW91 IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRlCnlvdXIgY29tbWVu dHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZS4gRm9yCmV4YW1w bGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEgdGhpcyBsaXN0IGFu ZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlIHJlZmVyIHRvIGl0 IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYgeW91IHNob3VsZCBo YXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9uLCBwbGVhc2UKY29u dGFjdCBUZWQgR3VpbGQsIFczQyBBdXRvbW90aXZlIExlYWQsIGF0IDx0ZWRAdzMub3JnPi4KClRo YW5rIHlvdSwKClh1ZXl1YW4gSmlhLMKgIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoK WzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxp c3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXctd29yawo= From nobody Fri Mar 26 10:08:26 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 376463A23CE; Fri, 26 Mar 2021 10:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1616778373; bh=7l8li9EQt2UW5Nm0c6qYRvPnDpW+A2Z9R8vIyb9z15w=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=PqMxvizG8R0WN/9VBI8AEpSAyMnnM8hwYQ8nUaw9GCcpUPAbHRoijkNP4wnjk4HWV jQg/WC9c5DoLvz6TDv8E+XFr45hrXwVXZfJ2rg/fSfwbdnKRPwFY6XWNEFfefDfgRo mIQEWbEZtkdXjFYJhfZl8KUjJcmibp89f8QVUmEM= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Mar 26 10:06:09 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE41E3A2360; Fri, 26 Mar 2021 10:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1616778368; bh=7l8li9EQt2UW5Nm0c6qYRvPnDpW+A2Z9R8vIyb9z15w=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=KqPgcGNFbSbFCG7Qux4mBMrpFBu57LKfNe/Ea26HKwgcOqmr5ivw04UrGijyO8R8D xKpBcf/AgBjvBhKw/TvzLVPz1+8CDZ/mvr019yysutsTTh/qfsFzHnCFfPWSBknbeD +fhw81ax3BELO/RJZyXuDY2CLxmGNLdvK380NqVA= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F173A237D for ; Fri, 26 Mar 2021 10:06:00 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <161677836053.26846.18126936733206658184@ietfa.amsl.com> Date: Fri, 26 Mar 2021 10:06:00 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 26 Mar 2021 10:08:21 -0700 Subject: [secdir] [new-work] WG Review: Effective Terminology in IETF Documents (term) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 17:06:18 -0000 A new IETF WG has been proposed in the General Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-04-05. Effective Terminology in IETF Documents (term) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Lars Eggert General Area Directors: Lars Eggert Mailing list: Address: terminology@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/terminology Archive: https://mailarchive.ietf.org/arch/browse/terminology/ Group page: https://datatracker.ietf.org/group/term/ Charter: https://datatracker.ietf.org/doc/charter-ietf-term/ The mission of the IETF as specified in BCP 95 is to produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet. IETF documents, including RFCs and Internet-Drafts, are most effective when they use terminology that is clear, precise, and widely accessible to readers from varying backgrounds and cultures. This maximizes the benefits the IETF derives from its core principles, such as its open process and volunteer core. In the years leading up to the chartering of this working group, there has been discussion in the IETF, in other standards organizations, and in the technology industry about the use of certain terms (such as "master/slave" and "blacklist/whitelist") in technical documentation and whether those and other terms have effects on inclusivity. While opinions vary among IETF participants about this topic, there is general agreement that the IETF community would benefit from informational recommendations about using effective and inclusive terminology in IETF documents. The TERM working group is therefore chartered to produce an Informational RFC containing recommendations on the use of inclusive terminology in the technical work produced by IETF participants. The RFC will express general principles for assessing when language is inclusive or exclusive. The principles should match the expectations from a diverse set of IETF participants. The WG will identify and recommend an external, independently-updated resource containing examples of potentially problematic terms and potential alternatives to IETF participants, in order to align its efforts with broader activities by the technology industry. The TERM working group is a focused group aiming to produce a single deliverable. It is designed to complement other efforts at fostering inclusivity in the IETF and will liaise with appropriate external groups, such as other SDOs or industry initiatives, to coordinate. Milestones: Jun 2021 - Adopt draft providing informational terminology recommendations Dec 2021 - Submit informational terminology recommendations to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sat Mar 27 14:39:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5CE3A158B for ; Sat, 27 Mar 2021 14:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 0cI-feRN7Fhk for ; Sat, 27 Mar 2021 14:38:51 -0700 (PDT) Received: from mail-pl1-x664.google.com (mail-pl1-x664.google.com [IPv6:2607:f8b0:4864:20::664]) (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 5B92A3A1589 for ; Sat, 27 Mar 2021 14:38:51 -0700 (PDT) Received: by mail-pl1-x664.google.com with SMTP id l1so2585678plg.12 for ; Sat, 27 Mar 2021 14:38:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=DoTQVmOb1rJCZvvA/sC5aphYcVIV1Ube14FEahjzcIo=; b=PaBDzUN6dStJpi+5theNV+HxPBIw0nAlQMJAlKOJ+rj8H0bNPsyyCxDDOvHNUPF03e Z0zZiV96ie9q89Uqx8dbLDmW/67SP7lQUeOdk0BnCNMOSVQil5F+DPU+SoNR29lARag1 dTOXxDuWmt0BsE76ay1s5UKAO4WWQ4ktGpdDECQp6p02ha8uGCFwEX+U6+flGePaXQey MZX1/AgicBzBtKRkGLVXLlMeIwnQJ6TnI5MFib/oJQWEx3mTxsgm62DNF8qAF4Ud+jBO JSTQM1RuOd40g5Oujcshix5u5IfzMIKO4+U+JVcXbiXMgtiKbGY7y/Uqo2qlqxSY0CKV vH2w== X-Gm-Message-State: AOAM533j/tJ0W3vkMdlrC4oCcQvDxM6T/kGSzyHdBvwLWUAFOMqEXyM3 VVh28EBehT0IuZm7eobOT39pCnonuUO66m10BOmhj9fkI4i22g== X-Google-Smtp-Source: ABdhPJzWlmwI7pn/Scxi5I61GzWx8TVW45j0k/dAg1PkmlbTr8Vg1TztQokHAbRBohzpPgFXpwK9hrWr6iFI X-Received: by 2002:a17:902:968d:b029:e6:faf5:8d0f with SMTP id n13-20020a170902968db02900e6faf58d0fmr20834097plp.71.1616881129198; Sat, 27 Mar 2021 14:38:49 -0700 (PDT) Received: from uriel.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id k89sm4494519pjc.16.2021.03.27.14.38.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Mar 2021 14:38:49 -0700 (PDT) X-Relaying-Domain: mandelberg.org Received: from [10.0.2.211] (sakaar.virgo.mandelberg.org [10.0.2.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 617821C6034; Sat, 27 Mar 2021 17:38:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202103; t=1616881127; bh=kYwcgN4FpEUKP4wu9WuJ03j7My/ulpv05+BmfkHWjd4=; h=To:From:Subject:Date:From; b=kAgAj/vwG0dKYAM4gUeQp9WeP2MPOHAGiTC35O/EwEQWeFlv4U0vTKkLAA87Urs01 7M4oV+xJ9py55+1yhuKdYLJ7+JgDR65vAlu+flFV+jEqUtp8XAoe6oZICEQejBqGNk 7BP9xlaWXs/eNZcBq4tZAbKQE7X78Jmq6dKv18LKVRS/UioSmeePOrgSDhAb97ol1F a66jmk96O5EUuWmeZPhchePAiRNSAbnMGjasw1Dz173xmNtP+ej0wWrUdEhNrVr7pt Tj4mJviXW5Ka7JxKk1R0GzUNisx2XeXuTDdFxQZxog9Fp87+as75TKHeAKWNsQL+7V bC5zXIupRElpw== To: iesg@ietf.org, secdir@ietf.org, draft-ietf-lwig-minimal-esp.all@ietf.org From: David Mandelberg Message-ID: <91f5ebd2-b24f-ca04-eba0-60d0c9b6f401@mandelberg.org> Date: Sat, 27 Mar 2021 17:38:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-lwig-minimal-esp-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2021 21:38:57 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. (Section 3, nit) In the paragraph that includes "However, nonrandom SPI and restricting their possible values MAY lead to privacy and security concerns" , it would be nice to add something like "(see below for more details)". When I first read that paragraph, I was about to comment that it's unclear what the privacy/security concerns are, but then it was explained a few paragraphs below. (Section 4) Am I understanding correctly, that the last paragraph is giving the option of resetting the Sequence Number when rekeying? Does IPSec try to prevent eavesdroppers from determining when rekeying happens? (I really don't know that much about IPSec.) If it does, then resetting the SN could leak that information, if not then there's nothing to leak. From nobody Sat Mar 27 20:43:21 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1DE3A1210; Sat, 27 Mar 2021 20:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNrHcwvHiUcu; Sat, 27 Mar 2021 20:43:10 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 86EFF3A0EBA; Sat, 27 Mar 2021 20:43:09 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id z3so9374904ioc.8; Sat, 27 Mar 2021 20:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iVOrnmdI3LGSwFQ8w8ZSkB6pkiIY0B7SO9ZGjYb3E1s=; b=U61zxgLmn+9TrLASSJgnJRhVGSAYkC9GxIQAQdBaFqMZWAIFz+c7Hk8SojlmV0IshI jbKrkbkkC7hRQNB391i3wL39aU4rxH2YLWY5XZVVWdVqWuMIc2ollxON8uhGWKbZTq3j 1cVDIen+emTWF/13ZCd6AbLqcA95OCOMTJJR7uvESYs5EfEsrH5aadLn3i1P8VFPAJwQ Xuq3r+yQXd2SAd/JA11uj3S1q3FHmEjV/MTuxcgj0tQEYnY2MjSRk839ySUO9+n7fiRA JnJGDZ5ymVubZiRYToLz+clmSxddwxpl7Org667se5a9BlA51qELip9B+JbYHoYW7DqQ 05qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iVOrnmdI3LGSwFQ8w8ZSkB6pkiIY0B7SO9ZGjYb3E1s=; b=q/dGwmnwUM/OfZ3XYhKCOpZDbDFbmi3ByrcIneSKCNay02cXkN8l+imP+QJSZjYMNB HG2TRD3nulMdABIMWkmjdovpH8RJZgzfI4JnOrpcFwmHnOxA2FIHjskK4837EiWrCB6/ ljSExbsmc4yyZ113oWzTZ0pLpo2QwyR5yHTodL1l//PLiwFxP2wX7Tiqx5/OIDtVX4N0 MhFEiKHfBnPxtDGEiozHfSr+mv7YScyRwSL0cDgCf3Nd7GNyYOxQii5uQP0xRCop9qRL eZKzU/B0I2vRIX/4dnDrh0Q3mAS+IEcrXpIX2ImMpKNhLEcsBg/doVxoKcUtl5AUFHyy Z6gA== X-Gm-Message-State: AOAM533lJ0lYbOGL/YBFiqWoFFHbjS7/V+5x/54t1X5Ibx8Gw9drmFYf k0sPNh3mltYw29sClj9dQpnQUqXDcTK9243qg1o= X-Google-Smtp-Source: ABdhPJzf68ysrQP8O0jPo8bpuv4ymhS4Fdt7KZ1yPByYiKn7q64OESoWmQzXvvhMplYqEmM3AiBAZ2kZgm+2/fqbx8M= X-Received: by 2002:a5d:8b09:: with SMTP id k9mr15293656ion.185.1616902987753; Sat, 27 Mar 2021 20:43:07 -0700 (PDT) MIME-Version: 1.0 References: <23514_1616507505_6059F271_23514_186_1_787AE7BB302AE849A7480A190F8B93303535A427@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <23514_1616507505_6059F271_23514_186_1_787AE7BB302AE849A7480A190F8B93303535A427@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Donald Eastlake Date: Sat, 27 Mar 2021 23:42:56 -0400 Message-ID: To: mohamed.boucadair@orange.com Cc: "iesg@ietf.org" , "last-call@ietf.org" , "draft-ietf-dots-rfc8782-bis.all@ietf.org" , secdir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2021 03:43:15 -0000 Hi, Thanks for adopting so many of my suggestions. See below where I have trimmed to points where we disagree that I think I have something to add. On Tue, Mar 23, 2021 at 9:51 AM wrote: > Hi Donald, > >... > > De : Donald Eastlake [mailto:d3e3e3@gmail.com] > Envoy=C3=A9 : mardi 23 mars 2021 05:53 > =C3=80 : iesg@ietf.org; last-call@ietf.org > Cc : draft-ietf-dots-rfc8782-bis.all@ietf.org; secdir > Objet : SECDIR Review draft-ietf-dots-rfc8782-bis-05 > > ... > > Minor Issues / Nits: > >... > > General/Global: All six occurrences of "as a reminder" should be > deleted from the draft. They just add useless words. > > [Med] Except the one about IPv4/IPv6, those were added to address comment= s that we received in the past. I prefer to maintain them. Perhaps I was not clear. I have no problem with the substantive material you have included AFTER the words "as a reminder,". I was mearly suggesting that the literal three word sequence "as a reminder" is three superfluous words that should be removed. > > ... > > Section 4.4.1: > > The following draft text uses "the trailing "=3D" " which implies that a > base 64 encoding ends with exactly one equal sign. But I believe there > can be zero, one, or two equal signs. I suggest the following: > OLD > The truncated output is > base64url encoded (Section 5 of [RFC4648]) with the trailing > "=3D" removed from the encoding, and the resulting value used as > the 'cuid'. > NEW > The truncated output is > base64url encoded (Section 5 of [RFC4648]) with any trailing > equal signs ("=3D") removed from the encoding, and the > resulting value used as the 'cuid'. > > [Med] We meant =E2=80=9Cany trailing=E2=80=9D. Fixed by updating to =E2= =80=9Ctwo trailing "=3D"=E2=80=9D That still seems wrong to me. The initial wording ("the trainling "=3D"") implied exactly one equal sign. The new wording ("the two training "=3D"") implies exactly two equal signs. But there can be zero, one, or two. If you mean "any training "=3D"", which would be good, why don't you say that (or, alternatively, "all trailing")? > >... > > Section 7.3: Since the PMTU can change and could be lower that the > values suggested to be assumed in the first paragraph of Section 7.3, > it is essentially impossible to conform to the first sentence as > written. I suggest the following change: > OLD > To avoid DOTS signal message fragmentation and the subsequent > decreased probability of message delivery, DOTS agents MUST ensure > that the DTLS record fits within a single datagram. > > [Med] We are echoing the following from Section 4.1.1 of 6347: > > =E2=80=9CEach DTLS record MUST fit within a single datagram.=E2=80=9D I don't agree that you are "echoing" RFC 6347. If you were, you would say "To avoid DOTS signal message fragmentation and the subsequent decreased probability of message delivery, the DTLS records MUST fit within a single datagram." If you had said that, I would not have complained. It is a true statement of the bad effects DTLS records not fitting in a datagram. > NEW > To avoid DOTS signal message fragmentation and the subsequent > decreased probability of message delivery, DOTS agents MUST NOT > send datagrams exceeding the limits discussed in this Section. > > ... > > The way this sentence talks about moving around "mitigation efficacy" > reads very strangely to me. I suggest the following re-wording: > OLD > A compromised DOTS client can collude with a DDoS attacker to send > mitigation request for a target resource, get the mitigation efficacy > from the DOTS server, and convey the mitigation efficacy to the DDoS > attacker to possibly change the DDoS attack strategy. > NEW > A compromised DOTS client can be commanded by a DDoS attacker to > abuse mitigation requests for a target resource. This could use the > "mitigation" abilities of the DOTS server for the benefit of the > attacker possibly leading to a changed and more effective DDoS > attack strategy. > > [Med] Thanks. I prefer the OLD wording. I think I understand what you mean by "efficacy" more clearly now but I still think you should fix the grammar by changing "request" in the 2nd line to "requests" (or, if you really mean this to be singular, change the wording to "a mitigation request"). > > ... > Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com From nobody Sun Mar 28 10:40:07 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CF63A1E68; Sun, 28 Mar 2021 10:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 DZGGV1cwdEXK; Sun, 28 Mar 2021 10:39:57 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0643A2205; Sun, 28 Mar 2021 10:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1616953197; bh=afypcv/z2NBpwb1t+NJ7Ais/nqBtuMqBhPBu FbCcHPA=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=WAyQnc8ecd6kYSG0Z77kuY2Ftjnsjdr1/gC3eyJIVjjWRN 1MbyOM/Erynm+3SWXQF/KoppeANlnh4NrAx7LSck31KQ8clAgpQ8mzwqhagLI1feyVd mnIGj44dQBFPG2FYdslbEePzrOJiInGzSZfa5N7A6eKa9Yr6OqG17ypWuqdixCpJ++D Ve92A+ql50EvwE3FKALiiWJG4VzYlHN0PXRwDmHoubY9GxSz1J+T+qz6mFtzmzaT/Ms IB81ds8Fyd8i+pNO9IbgdaDteOR3YUvIkyjC8czcQtvIuxrN4Oab8jG4tS1CCz8Me8N 5S/1pwJw+Jb+U2YajdxrIv8NAxCg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=Wx9d3MtNWDPVRLWxoOZdVyulPBFMGizA8V1TzXS7yrYH7usSO9p0OUfKt+HUqnow8nzdjXlHVq9WYjJw6AH0vhNrzrXnJEYcS1J/OFCL4yyoSFamEQSPpAnWvSMF8hbUM9hSRnLiDLA/pCYyaunL78psGq1ImiP8Y1cgW342Lzfj01IvW4FCTIUCwyyfrnLWkrGQ1ruQtp09/YuJhSoUvUAj/KwFfNA2N6HPszSlpMH0crtEM6rwhL+OlxPz30t+LHqb9HSEVtthgnVgD2tn9zVfEGb4fACRN4XPlxWWuzGviodVe1yYkZ1WUe2l+eR+V+mEDBu9AaGTkTsGoy6LxQ==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.72]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1lQZOE-000Aun-4S; Sun, 28 Mar 2021 13:39:54 -0400 To: Tero Kivinen , secdir@ietf.org Cc: last-call@ietf.org, roll@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> From: Charlie Perkins Message-ID: <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> Date: Sun, 28 Mar 2021 10:39:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <161643127376.6337.10029863442550466574@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956df8303b86ceddf55a4376bde57f06e11c174dff75ae11504350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2021 17:40:00 -0000 Hello Tero, Thanks for your comments, useful as always.  Please see a bit of follow-up below. On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > The title of the draft has some acronyms which are not expanded (AODV, P2P) and > if you expand them the title comes way too long. I would propose a usable > title, which might not need to use all possible acronyms, but would better > explain what this document is trying to do. How about "Supporting Asymmetric Links in Low Power Networks"? Replacing "LLNs" by "Low Power Networks" is probably O.K. because lossy is almost implicit given low power (or, often, reality). > > Nits: > > In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and Lossy > Networks)" defines acronyms differently than what is used everywhere else. In > all other cases the document uses format where the acronym is in parenthesis > after the full text, i.e. "Routing Protocol for Low-Power and Lossy Networks > (RPL) [RFC6550]" format. I would propose using the same format also for here. Done. > > In section 1 there is acronym DAG which is not expanded, expand it on first > use. I think that sentence reads better just omitting DAG. > Also there are unexpanded acronyms DAO, P2MP, which are not used anywhere > else, perhaps just expand them here. In same paragraph there is also acronym > MOP which is not expanded here on its first use, but it is expanded later. > Expand it here on its first use. Done, except that I thought it would be better to exhibit the acronym DAO since it is well known to readers familiar with RPL. > > What is the difference between different reserve bits X and r in sections > 4.1/4.2 and 4.3? I made them all to be reserved bits 'X'. > > Period missing from the end of sentence of the Option Length description in > Section 4.3. Done. > > In the IANA considerations section I propose add a note to RFC editor saying > that the sentences saying " The parenthesized numbers are only suggestions." > needs to be removed prior publication. > > Done! Naturally Yours, Charlie P. From nobody Sun Mar 28 20:06:51 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BD83A2E3B; Sun, 28 Mar 2021 20:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.4 X-Spam-Level: X-Spam-Status: No, score=-4.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu 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 mQemrYLLA-Xp; Sun, 28 Mar 2021 20:06:44 -0700 (PDT) Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD003A2E36; Sun, 28 Mar 2021 20:06:44 -0700 (PDT) Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.16.0.43/8.16.0.43) with SMTP id 12T36ewo013673; Sun, 28 Mar 2021 23:06:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=JHUAPLDec2018; bh=2g8WIHk+lVfEeyZCgOsXrKlNdAHb2payaulJZojWpeE=; b=X3MaO6YfuzsUTyyzAAy/vkyWmtItEfaW7e//tWut5WJk7uyBAXvtOffTKxM9sR83yFOa NbB+143V4uEWKRlsEI0gnOKxcLk3KcifqyvZ8bMdRAWmcUnQW1Xg186Ho+JJltetgDwj guvi664flUdQ1mKpPkCclqTibpydQgZ7RPObXpEGJwbooNGR+LtwvRB2wziSg4JyAnN+ ++RMrhqtQvhELyzRJocnC2CeS5Klbz3mgwz7sLxUsvgnecddUZY/YuxzUr5BzVwWl3J9 bH1z4tnizKWM1PAlONIJ43oRZvWZ3hhVW3y3nI+yJDPPveEmtuqPY/FfuWbBnM+k7e7D FA== Received: from aplex01.dom1.jhuapl.edu (aplex01.dom1.jhuapl.edu [128.244.198.5]) by aplegw01.jhuapl.edu with ESMTP id 37hwr90xea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 28 Mar 2021 23:06:40 -0400 X-CrossPremisesHeadersFilteredBySendConnector: aplex01.dom1.jhuapl.edu Received: from aplex01.dom1.jhuapl.edu (128.244.198.5) by aplex01.dom1.jhuapl.edu (128.244.198.5) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 28 Mar 2021 23:06:39 -0400 Received: from aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50]) by aplex01.dom1.jhuapl.edu ([fe80::19f5:dcc5:c696:1a50%25]) with mapi id 15.00.1497.012; Sun, 28 Mar 2021 23:06:39 -0400 From: "Birrane, Edward J." To: Christian Huitema , "secdir@ietf.org" CC: "draft-ietf-dtn-bpsec-default-sc.all@ietf.org" , "dtn@ietf.org" Thread-Topic: [EXT] Secdir early review of draft-ietf-dtn-bpsec-default-sc-02 Thread-Index: AQHXHF7Ddo4z96DY4Ey55zJNNRc1HqqaUgaw Date: Mon, 29 Mar 2021 03:06:39 +0000 Message-ID: <0807ea6d35fa4788ad6ce12480f1a78c@aplex01.dom1.jhuapl.edu> References: <161611713427.19367.10392386702864224514@ietfa.amsl.com> In-Reply-To: <161611713427.19367.10392386702864224514@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.244.198.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: aplex01.dom1.jhuapl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-28_14:2021-03-26, 2021-03-28 signatures=0 Archived-At: Subject: Re: [secdir] [EXT] Secdir early review of draft-ietf-dtn-bpsec-default-sc-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 03:06:49 -0000 Q2hyaXN0aWFuLA0KDQogIFRoYW5rIHlvdSBzbyBtdWNoIGZvciB0aGlzIGVhcmx5IHNlY3VyaXR5 IHJldmlldyENCg0KICBNeSByZXNwb25zZXMgdG8geW91ciBjb21tZW50cyBhcmUgaW5jbHVkZWQg YmVsb3cgYW5kIGVudW1lcmF0ZWQgd2l0aCB0aGUgY29udmVudGlvbiBDIyBmb3IgY2xhcml0eS4N Cg0KDQo+IFRoZSBmaXJzdCBuaXQgcmVnYXJkcyB0aGUgdGFibGUgb2YgQklCLUhNQUMtU0hBMiBT ZWN1cml0eSBQYXJhbWV0ZXJzIGluDQo+IHNlY3Rpb24gMy4zLjQuIFRoZSBkZWZhdWx0IHZhbHVl IGZvciB0aGUgU0hBIFZhcmlhbnQgaXMgc3BlY2lmaWVkIGFzICIyNTYiLCBidXQNCj4gc2VjdGlv bg0KPiAzLjMuMSBvbmx5IGRlZmluZXMgdmFsdWVzIDUsIDYgYW5kIDcgZm9yIHRoYXQgcGFyYW1l dGVyLiBJIGFzc3VtZSB0aGF0IHRoZQ0KPiBpbnRlbnQgaXMgdG8gZGVmYXVsdCB0byBITUFDMjU2 L1NIQTI1NiwgYnV0IGluIHRoYXQgY2FzZSB0aGUgZGVmYXVsdCBzaG91bGQNCj4gYmUgNSwgbm90 IDI1Ni4NCg0KQzE6IEFncmVlZCwgdGhpcyBpcyBhbiBlcnJvciBpbiB0aGUgLTAyIHZlcnNpb24g b2YgdGhlIGRvY3VtZW50LCB3aGljaCBoYXMgYmVlbiBjb3JyZWN0ZWQgaW4gdGhlIC0wMyB2ZXJz aW9uLg0KDQoNCj4gVGhlIHNlY29uZCBuaXQgcmVnYXJkcyB0aGUgZGlzY3Vzc2lvbiBvZiBhdXRo ZW50aWNhdGlvbiBhbmQgY29uZmlkZW50aWFsaXR5IGluDQo+IHNlY3Rpb24gNC4xLiBBRUFEIGFs Z29yaXRobXMgZGlzdGluZ3Vpc2ggYmV0d2VlbiBhdXRoZW50aWNhdGVkIGRhdGEgYW5kDQo+IGVu Y3J5cHRlZCBkYXRhLiBUaGUgdGV4dCBleHByZXNzZXMgYSBkaWZmZXJlbnQgY29uY2VwdCxzZXBh cmF0ZSBkZWZpbml0aW9ucw0KPiBvZiAic2NvcGUgb2YgY29uZmlkZW50aWFsaXR5IiBhbmQgInNj b3BlIG9mIGF1dGhlbnRpY2F0aW9uIi4gSSBzdWdnZXN0IHRoYXQNCj4gdGhlc2UgcGFyYWdyYXBo cyBiZSByZXdyaXR0ZW50IHRvIHNwZWNpZnkgdGhhdCAidGhlIHNjb3BlIG9mIGF1dGhlbnRpY2F0 aW9uIGlzDQo+IGFsd2F5cyB0aGUgdW5pb24gb2YgdGhlIGFkZGl0aW9uYWwgZGF0YSBhbmQgdGhl IHNjb3BlIG9mIGNvbmZpZGVudGlhbGl0eS4iDQoNCkMyOiBBZ3JlZWQuIFRoZSAtMDMgdmVyc2lv biBvZiB0aGUgZG9jdW1lbnQgaW5jbHVkZXMgYSBjbGFyaWZpY2F0aW9uIHRoYXQgdGhlICJzY29w ZSBvZiBhdXRoZW50aWNhdGlvbiIgdG8gbm90ZSB0aGF0IGl0IGluY2x1ZGVzIHRoZSBzY29wZSBv ZiBjb25maWRlbnRpYWxpdHkgaW4gYWRkaXRpb24gdG8gb3RoZXIgZGF0YS4NCg0KDQoNCiA+IFRo ZXNlIGFyZSBzbWFsbCBpc3N1ZXMuIE15IHJlYWwgY29uY2VybiB3aXRoIHRoaXMgZG9jdW1lbnQg aXMgdGhlIG92ZXJhbGwNCj4gY29tcGxleGl0eSBvZiB0aGUgQnVuZGxlIFByb3RvY29sIGFuZCB0 aGUgU2VjdXJpdHkgc3BlY2lmaWNhdGlvbi4gVGhlDQo+IHByb3RvY29scyBhcHBlYXIgc3BlY2lm aWVkIGZvciBtYXhpbXVtIGZsZXhpYmlsaXR5LiBNZXNzYWdlcyBjYW4gYmUgcmVsYXllZC4NCj4g UmVsYXlzIGNhbiBhZGQgdGhlaXIgb3duIHNlY3VyaXR5IGJsb2NrcyB0byB0aGUgYnVuZGxlLiBB dXRoZW50aWNhdGlvbiBhbmQNCj4gZW5jcnlwdGlvbiBjYW4gYXBwbHkgdG8gZGlmZmVyZW50IGJs b2NrcyBpbiB0aGUgYnVuZGxlLiBNZXNzYWdlcyBjYW4gYmUNCj4gZnJhZ21lbnRlZC4gTm9kZXMg Y2FuIGNob29zZSB0byBhcHBseSBkaWZmZXJlbnQgbGV2ZWwgb2Ygc2VjdXJpdHkgdG8NCj4gZGlm ZmVyZW50IGJ1bmRsZXMsIG9yIHRvIGRpZmZlcmVudCBibG9ja3MgaW4gdGhlIHNhbWUgYnVuZGxl LiBJIHN1cHBvc2UgdGhhdA0KPiB0aGVzZSBjaG9pY2VzIGFyZSBqdXN0aWZpZWQgYnkgYXBwbGlj YXRpb24gcmVxdWlyZW1lbnRzLCBidXQgYWxsIHRoaXMNCj4gY29tcGxleGl0eSBtYXkgZW5kIHVw IGNhdXNpbmcgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMsIGFuZCBwb3RlbnRpYWwgc2VjdXJpdHkN Cj4gZmFpbHVyZXMuDQoNCkMzOiBBZ3JlZWQgLSB0aGVyZSBpcyBhZGRpdGlvbmFsIGNvbXBsZXhp dHkgaW4gdGhlIERUTiBzZWN1cml0eSBzdWl0ZSBpbiBnZW5lcmFsLiBJIHNlZSB0aGlzIGFzIG1v cmUgb2YgYSBjb21tZW50IG9uIHRoZSBvdmVyYWxsIERUTiBlY29zeXN0ZW0gYW5kIG5vdCBhIHJl Y29tbWVuZGVkIGFjdGlvbiBvbiB0aGUgZGVmYXVsdCBzZWN1cml0eSBjb250ZXh0IGRvY3VtZW50 Lg0KDQoNCiANCj4gVGhlIHdheSBDQk9SIGVuY29kaW5nIGFyZSB1c2VkIGJyaW5ncyBhbm90aGVy IHNvdXJjZSBvZiBjb21wbGV4aXR5LiBDQk9SDQo+IGFsbG93cyBmb3IgZGlmZmVyZW50IHdheXMg b2YgZW5jb2RpbmcgdGhlIHNhbWUgZGF0YS4gVGhlIGJ1bmRsZSBzZWN1cml0eQ0KPiBkb2N1bWVu dCBhbmQgdGhpcyBhbGdvcml0aG0gc3BlY2lmaWNhdGlvbiBkb2N1bWVudCByZXF1ZXN0IHRoYXQg c29tZSBkYXRhDQo+IHBhcnRzIGJlIHJlLWVuY29kZWQgaW4gdGhlICJjYW5vbmljYWwiIENCT1Ig Zm9ybWF0IGJlZm9yZSBhdXRoZW50aWNhdGlvbg0KPiB0YWdzIGFyZSBjb21wdXRlZCBvciB2ZXJp ZmllZC4gRXhwZXJpZW5jZSBpbiBvdGhlciBkb21haW5zIHNob3dzIHRoYXQNCj4gcmVseWluZyBv biBjYW5vbml6YXRpb24gYmVmb3JlIGF1dGhlbnRpY2F0aW9uIGlzIHZlcnkgZnJhZ2lsZSwgYW5k IGEgc291cmNlIG9mDQo+IGludGVyb3BlcmFiaWxpdHkgZmFpbHVyZXMuIEl0IHdvdWxkIGJlIG11 Y2ggbW9yZSByb2J1c3QgdG8gYXNzdW1lIHRoYXQNCj4gYXV0aGVudGljYXRlZCBvYmplY3RzIGFy ZSBpbW11dGFibGUsIGFuZCB0aGF0IHRoZSB3aXJlIGZvcm1hdCBvZiB0aGVzZQ0KPiBvYmplY3Rz IGlzIGZlZCBkaXJlY3RseSBpbnRvIHRoZSBoYXNoIGFsZ29yaXRobS4NCg0KQzQ6IFRoZSBkZWZh dWx0IHNlY3VyaXR5IGNvbnRleHQgZG9lcyBub3QsIGl0c2VsZiwgaW1wb3NlIHN0cmljdGVyIGNh bm9uaWNhbGl6YXRpb24gYWxnb3JpdGhtcyBhcyB0aGV5IHJlbGF0ZSB0byBDQk9SIC0gdGhhdCBp cyBkb25lIGJ5IHRoZSBCUFNlYyBzcGVjaWZpY2F0aW9uLiBJIHNlZSB0aGlzIGFzIG1vcmUgb2Yg YSBjb21tZW50IG9uIHRoZSBCUFNlYyBkb2N1bWVudCBhbmQgbm90IGEgcmVjb21tZW5kZWQgYWN0 aW9uIG9uIHRoZSBkZWZhdWx0IHNlY3VyaXR5IGNvbnRleHQgZG9jdW1lbnQuDQoNCg0KDQo+IFRv IG1pdGlnYXRlIHRoZSByaXNrIG9mIGludGVyb3BlcmFiaWxpdHkgZmFpbHVyZXMsIEkgc3VnZ2Vz dCBhZGRpbmcgdGVzdCB2ZWN0b3JzDQo+IHRvIHRoZSBzcGVjaWZpY2F0aW9uLiBFYWNoIHRlc3Qg Y2FzZSBzaG91bGQgc3RhcnQgd2l0aCBhIGNsZWFyIHRleHQgdGVzdCBidW5kbGUsDQo+IGFwcGx5 IGVpdGhlciBhdXRoZW50aWNhdGlvbiBvciBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24gYWNjb3Jk aW5nIHRvIHNvbWUNCj4gdmFyaWF0aW9ucyBvZiB0aGUgYXV0aGVudGljYXRpb24gb3IgQUFEIHNj b3BlIGZsYWdzLCBhbmQgcHJvZHVjZSBhIHJlc3VsdC4NCj4gRGlmZmVyZW50IHRlc3QgdmVjdG9y cyBtaWdodCBzdGFydCB3aXRoIGRpZmZlcmVudCBtb2RlIG9mIENCT1IgZW5jb2RpbmcsIHRvDQo+ IHRlc3QgdGhlIGNhbm9uaXphdGlvbiBwcm9jZXNzLiBUaGlzIGtpbmQgb2YgaW52ZXN0bWVudCBt aWdodCBzYXZlIGEgbG90IG9mDQo+IHRpbWUgdG8gZnV0dXJlIGRldmVsb3BlcnMhDQoNCkM1OiBJ IGFncmVlIHRoYXQgYSB2YXJpZXR5IG9mIENCT1IgcmVwcmVzZW50YXRpb25zIG9mIGJ1bmRsZXMs IGJsb2Nrcywgc2VjdXJpdHkgYmxvY2tzLCBhbmQgcGFyYW1ldGVyL3Jlc3VsdCBjb21iaW5hdGlv bnMgd291bGQgYmUgd2VsY29tZWQgYnkgZnV0dXJlIGRldmVsb3BlcnMhIFNpbmNlIHRoaXMgZGVm YXVsdCBzZWN1cml0eSBjb250ZXh0IGRvY3VtZW50IHVzZXMgd2VsbC1rbm93biBhbGdvcml0aG1z IEkgdGhpbmsgcmVwZWF0aW5nIEFFUyBhbmQgSE1BQy9TSEEgdGVzdCB2ZWN0b3JzIGFyZSBub3Qg bmVjZXNzYXJ5IGZvciB0aGlzIGRvY3VtZW50LCBhbmQgZ2VuZXJhbCB0ZXN0IHZlY3RvcnMgcmVs YXRlZCB0byBwb3B1bGF0aW5nIHNlY3VyaXR5IGJsb2NrcyBzaG91bGQgbm90IGJlIHByZXNlbnQg KGFuZCB0aHVzLCByZXBlYXRlZCkgZm9yIGFsbCBvdGhlciBzZWN1cml0eSBjb250ZXh0IGRvY3Vt ZW50cyBiZWluZyBjb25zaWRlcmVkLiBJbnN0ZWFkIG9mIGFkZGluZyB0ZXN0IHZlY3RvcnMgdG8g dGhpcyBkb2N1bWVudCwgSSBwcm9wb3NlIHRha2luZyB0aGUgcmVxdWVzdCB0byB0aGUgRFROIFdH IGZvciBob3cgdGhpcyBtb3JlIGxhcmdlbHktc2NvcGVkIGluZm9ybWF0aW9uIGNvdWxkIGJlIGJl c3QgZG9jdW1lbnRlZC4gDQoNCg0KIA0KPiBOb3QgYSBjb21tZW50IG9uIHRoaXMgZHJhZnQsIGJ1 dCBJIHNlZSBsb3Qgb2YgcG90ZW50aWFsIGlzc3VlcyB3aXRoDQo+IGZyYWdtZW50YXRpb24uIEkg dW5kZXJzdGFuZCB0aGF0IGluIGEgRGVsYXkgVG9sZXJhbnQgTmV0d29yayxyZWxheXMgbmVlZCB0 bw0KPiBiZSBhYmxlIHRvIGZyYWdtZW50IG1lc3NhZ2VzLiBUaGUgZHJhZnQgY29ycmVjdGx5IHBv aW50cyBvdXQgdGhhdCBpZiBhbg0KPiBhdXRoZW50aWNhdGVkIG1lc3NhZ2UgaXMgZnJhZ21lbnRl ZCwgYXV0aGVudGljYXRpb24gY2FuIG9ubHkgYmUgcmVjZWl2ZWQNCj4gd2hpbGUgYWxsIGZyYWdt ZW50cyBhcmUgcmVjZWl2ZWQuIEhvd2V2ZXIsIHRoaXMgd291bGQgbm90IHByb3RlY3QgZnJvbQ0K PiBhdHRhY2tzIGFnYWluc3QgZnJhZ21lbnRhdGlvbiBzaW1pbGFyIHRvIHRob3NlIHNlZW4gaW4g SVAsIElQdjYgYW5kIFRDUC4gSSB0aGluaw0KPiB0aGF0IHNvbWUga2luZCBvZiBzZWN1cmUgZnJh Z21lbnRhdGlvbiBwcm90b2NvbCBuZWVkIHRvIGJlIHN0dWRpZWQgYW5kDQo+IHNwZWNpZmllZCBi eSB0aGUgd29ya2luZyBncm91cC4NCj4gDQoNCkM2OiBTaW1pbGFyIHRvIEM1LCBJIHRoaW5rIHRo aXMgdG9waWMgaXMgbGFyZ2VyIGluIHNjb3BlIHRoYW4gdGhlIGRlZmF1bHQgc2VjdXJpdHkgY29u dGV4dCBkb2N1bWVudCBhbmQgYWdyZWUgaXQsIGxpa2UgQzUsIHNob3VsZCBiZSBicm91Z2h0IHRv IHRoZSBEVE4gV0cuDQoNCi1FZA0KDQotLS0NCkVkd2FyZCBKLiBCaXJyYW5lLCBJSUksIFBoLkQu DQpFbWJlZGRlZCBBcHBsaWNhdGlvbnMgR3JvdXAgU3VwZXJ2aXNvcg0KU3BhY2UgRXhwbG9yYXRp b24gU2VjdG9yDQpKb2hucyBIb3BraW5zIEFwcGxpZWQgUGh5c2ljcyBMYWJvcmF0b3J5DQooVykg NDQzLTc3OC03NDIzIC8gKEYpIDQ0My0yMjgtMzgzOQ0K From nobody Mon Mar 29 11:33:26 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951853A1DE6; Mon, 29 Mar 2021 11:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iisc.ac.in 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 rknlJGOvDftl; Mon, 29 Mar 2021 11:33:15 -0700 (PDT) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-eopbgr1390049.outbound.protection.outlook.com [40.107.139.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39683A1DE3; Mon, 29 Mar 2021 11:33:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aAEkruyxXUSiZGh0kJzZW6d2IDmTkyOB9ZHFmCDOClH80k+YDvbmmFoaT9awAHzNgvtbEur2Ma77QfA/z4qR6K4dEHsVi/3oo03y8ZftzfVvwg2CMjcnIIL8w1dkioFFo9TXjWr2Lxo7zK3NTwnXZ5gbf/S+kEWdWmMOUrE+VRYWa0GlTr/4WsfkJJnHnQmo5sQHo+MA+s5vP6EmjDgkG1Uy3jXX0B5wLpGsrg3O7tF0/zERwxDEGUO1C8ZzMXM4ZSDHhsTJu4Ds77etV5NVPbp7RBzu6+IrlgS40gykge2lYJGzKWnIIh7HqT7srgN3isz7utqUIQf+iFGW0zV7Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+VLdeYXK21mOZ17PlboLDVB0FisnuTI6u9NFpjTGj6Y=; b=TMcwRhmTr5YTnygcf6xnM+7+317BdX9LTiTAr1EnlVzMeofOiShLkuRsMf3adCmxZE7lo2dj2V1NTQZ6YlFjQVK4dYdKdP9NgAKxSZ9DCojsZmbvRtZvwOostN4lGlCaSP2luFlAZ1gmh0jCSeOHv7p+yK9I7M7hyWgiQklHa3f5J9DYKPUhxBPHEvxXrqCsoOPmdDc2Xc5m+rnvoVkJkQz3SbdmsnOOmp08GneOgOHVk/SIIXrgN+AQ0T58JLDpVM1WgikCWxn65BE+Rgmf1+Qa9iBgp+WOSyFERxn2d09ulgjuMlINZPNyZoPEzCBNVCqVrYL/YlK1+0HR/KRBig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iisc.ac.in; dmarc=pass action=none header.from=iisc.ac.in; dkim=pass header.d=iisc.ac.in; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iisc.ac.in; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+VLdeYXK21mOZ17PlboLDVB0FisnuTI6u9NFpjTGj6Y=; b=cE/ZOSIWwAjyd08DJ1P1gt1TIg/xehq8oAjuRz+Qj30rXbo+GMORNHZEf4GFZdolhzs3ShHuzfiXSAinvmzXWAORVQwcHW4gKTVBPV9dIjj7W44Yvl7jKMD8a/NBpGPF6yBEEm9h6mZ4E2ral4S2ojAJbJqeXKqV6kUe9zv8G+o= Authentication-Results: earthlink.net; dkim=none (message not signed) header.d=none;earthlink.net; dmarc=none action=none header.from=iisc.ac.in; Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) by MA1PR0101MB1653.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:2b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.29; Mon, 29 Mar 2021 18:33:06 +0000 Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::ad8f:f621:c8b:70c5]) by MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::ad8f:f621:c8b:70c5%4]) with mapi id 15.20.3977.033; Mon, 29 Mar 2021 18:33:06 +0000 Date: Tue, 30 Mar 2021 00:03:05 +0530 From: "S.V.R.Anand" To: Charlie Perkins Cc: Tero Kivinen , secdir@ietf.org, last-call@ietf.org, roll@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org Message-ID: <20210329183304.GB6408@iisc.ac.in> References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [49.206.11.189] X-ClientProxiedBy: MA1PR0101CA0064.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:20::26) To MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from iisc.ac.in (49.206.11.189) by MA1PR0101CA0064.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:20::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.25 via Frontend Transport; Mon, 29 Mar 2021 18:33:06 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 35c9abf3-6617-4467-572b-08d8f2e11875 X-MS-TrafficTypeDiagnostic: MA1PR0101MB1653: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iTimx7Et2uqbezZlec0eViNd7dx4poLPZM55emSwMfn16xpjl8oGAT167wJ6xDZw/RdAaqm9scZcR3iBLCcRVODsvglwxpHr/MWJX3cd6UVZh5cBhEJCx+DYnA8VbLDPpOPoOvgTFQRoFF1QCEeODOF5h1COrQPq2V6uQY3gdcbZ4m4VhUYX0ZaAE6xe5gnOKnLWBS/bY2WZQmYJu2Ou+Xb/aGXYWjL1NvX+LH7aOpo6BBk5mXnOUvmOz3u5lD5Fd4t1CkO3CsniOpL6BdaGwNaMTL+Sov13p7sXleP83gmREepg7VzZ0gerGm3UcyCA4bnsPHoPmjy+aLFe1KsRCVCcnmyOXGFB48MeRZwAMgBfpan9455AXyNoR7CbjXY0oaIGiHNuVY8oorbz5STtwdti62Zf6yZbYuA9l7w6YJQafo0ncTwoK3voP81RpryPKrL5fghXwEzxAaBkE+LNvwUPpxnpchxykhFTpejePjfO+ntOSRsIxSPy5cK2nPDRCdDgsEV16tJSDGa84cz40mPxjCj01m2z6d1cDLg6QRdrWwfhqwOWIJywC5rRCdQW5C/zTgH/UivNvVruNl3iLcl5LDYBw0ZjTkFlH3lTFYelkNq1A5ePx3NMzt0NTwTj0OFjrRekW39Wosego6zElQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(136003)(396003)(376002)(39850400004)(36756003)(38100700001)(6916009)(52116002)(2616005)(55236004)(478600001)(83380400001)(55016002)(8936002)(1006002)(7696005)(186003)(4326008)(8676002)(316002)(66946007)(66556008)(66476007)(86362001)(33656002)(2906002)(26005)(1076003)(956004)(786003)(5660300002)(53546011)(16526019); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?hzu8CBGfAbwfEk4ZOFZSpQSIsYhNmcJkLXJ6VuGiEvy4qUYUU2L0RSEYjZKw?= =?us-ascii?Q?ZJa3m1Ve6VwWn2doZq6yZkOKmzla7U9KDYZlCsmxo50BQpc01fBsVtSOV/eW?= =?us-ascii?Q?lZ6+dt5oy9a4UV6OWC0hYx/H9ZY8df/PexqHdMWC4LQvO4T4ar2T/n+kuo7a?= =?us-ascii?Q?qdre3uarNDed2c5n1Znjw47GyREjsTK9I7LgJtCfqHYJpNYSLWjVf4k7Rv0u?= =?us-ascii?Q?PFcMSDu2QXseygNMOJSpACDR9Pe0JCzjewviv7uQqyq+1Gfy9S5ux0T1DtHG?= =?us-ascii?Q?k+ifbzehmEbRwwAvy9QufdTxEdmktO1XgUkurH6MxrJhp6D2mNR2g5kILEQK?= =?us-ascii?Q?tNLPXVfM3nVwMMdA/mPr1mKpfovntTpJ3EY2spQUE5guYZzpFIz3GalGks3b?= =?us-ascii?Q?av1M5Cbh1eRszyUXDanrFCXAbyYhZPGjLCJxwcRb4WfYtLI7j9wTzivrq5R1?= =?us-ascii?Q?J6LH4z3kwtmH7yUvlVjC0pv0njGf2MxfOlTj888Hbq9A8odmNlo9J+A9VY1l?= =?us-ascii?Q?SDnGbNPDQmAxFL6HvLoG8v2BKk3Xjkc8Gyta2QkM85/4goGDRPZ1+YvU5Tp7?= =?us-ascii?Q?VkbGU3jRe4jZBWD4HHcPLVaXPPU40XqUfWXVt3cB/TCJifYiSvR9YtFikV4E?= =?us-ascii?Q?pFYhWOX0Ct9fQ4zLbPxtgSh+XVj2oyvNTJ/lPgKwb92AFH7JX7D+5UmGbrbq?= =?us-ascii?Q?IcE/qGpyFJfjspRDVbHFh4FvZoLWaPkb4wW9/NpynVkzmrlKPJBUY6bXYyCa?= =?us-ascii?Q?kQMOzQYEJZgAPG/lGyQTtLTHd7otL/e0cbjbpCbONqB384AqG7GrJAbmNRD8?= =?us-ascii?Q?pZ1i554U6FvAmIRtoeL+7yXNVp42owqF53eRVPCEzY/eYHzS1SySmpzN00eh?= =?us-ascii?Q?Pxkc27qd8tHfRx7p0gqCkuHuAvWSykzxcLdPuICUs9tIK96yaM7jKz6X9Olj?= =?us-ascii?Q?3so9esICDSr0RAy4JQRZlblppOCISQxj/Rc/0g3FwTtDZNBpoyelNP4Vrr+a?= =?us-ascii?Q?07zxGAIzY5QdOO12B0GNbuGO1KMhhTuVCNTHiWBI8h+dw24WjXYABpxfEdQq?= =?us-ascii?Q?SroSWwtPK8pNGh22Fpd9hpLQRAJ6AKJ5e49eQx13ZY2aT56SQUREFIceh65y?= =?us-ascii?Q?WIWwPlzTjkdbUPCZDEHFtv/D4V30YljBdYA2HQ4mv3NEznNV7AaGUJeEE1KQ?= =?us-ascii?Q?oefHsxbgDbSuaHRpSUtn7RsUMy/gLUYJw46gNUz1uUZEu88FISbB4FHYYxRG?= =?us-ascii?Q?rrmC71rRBIYSCBBxoRKzH4bmQHNMwGica6E0H7MwCJJTRWrOQOjr2nV9ArC3?= =?us-ascii?Q?DqIwKltfVStG2EX3gY1lqQF3?= X-OriginatorOrg: iisc.ac.in X-MS-Exchange-CrossTenant-Network-Message-Id: 35c9abf3-6617-4467-572b-08d8f2e11875 X-MS-Exchange-CrossTenant-AuthSource: MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2021 18:33:06.6001 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 2Ueilucd9qBy96/xPXMj994SMXWPaaQg4Rgwx/DSfoV7K/NBLb67uNIAYvcVmZSN1AzS9Zr9H3FpcYrhNM2CaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR0101MB1653 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 18:33:21 -0000 Hello, I prefer to retain AODV-RPL in the title. AODV-RPL acronym has already been referred by research community in their publications, and roll community uses this acronym to refer to this draft. Also, I feel AODV and RPL acronyms are familiar to the wireless and low power and lossy networks world. How about "AODV-RPL Extensions for Asymmetric Links in Low Power Networks", or "AODV-RPL Support for Asymmetric Links in LLNs" ? Regards Anand On 21-03-28 10:39:53, Charlie Perkins wrote: > > > Hello Tero, > > Thanks for your comments, useful as always. Please see a bit of > follow-up below. > > > On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > >The title of the draft has some acronyms which are not expanded (AODV, P2P) and > >if you expand them the title comes way too long. I would propose a usable > >title, which might not need to use all possible acronyms, but would better > >explain what this document is trying to do. > > How about "Supporting Asymmetric Links in Low Power Networks"? Replacing > "LLNs" by "Low Power Networks" is probably O.K. because lossy is almost > implicit given low power (or, often, reality). > > > > > >Nits: > > > >In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and Lossy > >Networks)" defines acronyms differently than what is used everywhere else. In > >all other cases the document uses format where the acronym is in parenthesis > >after the full text, i.e. "Routing Protocol for Low-Power and Lossy Networks > >(RPL) [RFC6550]" format. I would propose using the same format also for here. > Done. > > > > >In section 1 there is acronym DAG which is not expanded, expand it on first > >use. > I think that sentence reads better just omitting DAG. > > > > Also there are unexpanded acronyms DAO, P2MP, which are not used anywhere > >else, perhaps just expand them here. In same paragraph there is also acronym > >MOP which is not expanded here on its first use, but it is expanded later. > >Expand it here on its first use. > > Done, except that I thought it would be better to exhibit the acronym > DAO since it is well known to readers familiar with RPL. > > > > > >What is the difference between different reserve bits X and r in sections > >4.1/4.2 and 4.3? > I made them all to be reserved bits 'X'. > > > > >Period missing from the end of sentence of the Option Length description in > >Section 4.3. > Done. > > > > >In the IANA considerations section I propose add a note to RFC editor saying > >that the sentences saying " The parenthesized numbers are only suggestions." > >needs to be removed prior publication. > > > > > > Done! > > Naturally Yours, > Charlie P. > From nobody Mon Mar 29 15:51:28 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 722E63A2486; Mon, 29 Mar 2021 15:51:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Lonvick via Datatracker To: Cc: draft-ietf-grow-bmp-local-rib.all@ietf.org, grow@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161705827740.13468.11344469654269107377@ietfa.amsl.com> Reply-To: Chris Lonvick Date: Mon, 29 Mar 2021 15:51:17 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-grow-bmp-local-rib-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 22:51:18 -0000 Reviewer: Chris Lonvick Review result: Has Nits Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. The authors state in the Security Considerations section that the same considerations that are documented in Section 11 of RFC 7854 also apply to this document. I see no reason to doubt that and I believe that is appropriate for this document. The second and third sentences of the Security Considerations section may need to be reworked. Although I skimmed the rest of the document, these were the only nits I could see. For the second sentence, rather than: Implementations of this protocol SHOULD require to establish sessions with authorized and trusted monitoring devices. Perhaps, Implementations of this protocol SHOULD require +monitored routers+ to establish +secure+ sessions with authorized and trusted monitoring -devices-+stations+. The term "monitoring devices" is not used anywhere else in the document, and only once in RFC 7854. On the other hand "monitoring stations" is used extensively in both. For the third sentence, rather than: It is also believed that this document does not add any additional security considerations. Perhaps, It is also believed that this document does not add any +features that require any+ additional security considerations. Best regards, Chris From nobody Tue Mar 30 02:15:12 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477AA3A2C85; Tue, 30 Mar 2021 02:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 7RPmN9c5EHrp; Tue, 30 Mar 2021 02:14:57 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C483A2C83; Tue, 30 Mar 2021 02:14:56 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 5418A1B000F7; Tue, 30 Mar 2021 12:14:53 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1617095693; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EOzJ/V8r3iGO5We2YHQcYZ6zQATj38RsWJ+rWQyiG6o=; b=I3CEQRH2/CQD8/dhL12/8p9lnepFBANe3HTSR75JPSBXl3OV6bG3JozbaVxonI1w+yuR7d hfLNawZHPUq+l24K4dUaVMNREJwXVDvR44eUr+tbivAGsKHD0vFJlH3UaHvl/+HNrtbFLe E7jThQEKPZ1zA4v9XOad57hfpQ7VMvGn/4i22JxQ/TCps85b4qgvvHJRcKLqqaN1FCona0 gHR5Pt6pSq/rZlQUwDvyOrifc+cX6ILO+iOAU8XsYQLl9yhkOa5O5GhpU0UglgxErwhLUb CAmJeKAmf4exfOEE7msisAzKrF2itNzpSqb+30LEruTSdO9eVI04fJhOp6rzog== Received: by fireball.acr.fi (Postfix, from userid 15204) id 22D7925C0BEB; Tue, 30 Mar 2021 12:14:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24674.60429.90879.499696@fireball.acr.fi> Date: Tue, 30 Mar 2021 12:14:53 +0300 From: Tero Kivinen To: Charlie Perkins Cc: secdir@ietf.org, last-call@ietf.org, roll@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org In-Reply-To: <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1617095693; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EOzJ/V8r3iGO5We2YHQcYZ6zQATj38RsWJ+rWQyiG6o=; b=ES27MLoen1/kx5u/v4i0754DmiKVBOvSIyE8VWnKRMNOv+RGLLDV1n+tdHgCOBz8ciRbO3 9MrGbTz1v+JOErWS1dLvByVpuRxUxSGJf9Jieqh01GPQr7JKpjhqANHR/67tSasB3kxfUU gMZ7Y0CjzBsJKC6mbLPbXWSUTCcKcfVEYTwuvJanOSaDTMN5t6BXAD1OAkYia8hLS7Pf6q PpVMVcpjpE4IhqCHqjHGSambdce08qbnVHvsfugES7YcJDQge3ychneAudpurjRUnck5ps iRUqaEHew/3O0Umj82D/wzSbe4nMHANTqTU2Y7gLKwTXFi5UY/x8nNs+yQ1LsA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1617095693; a=rsa-sha256; cv=none; b=ePKU+voWuD3904ZIaQ9bKMdyIQ+VbaEEGsO/v0SmnF4qslfu3zj5RjqGq66ogNtdh/0Qax H1+Arl6pjPXCPAsPhWoShEUjkEiXRTfpUQ9nMoNGigp2QF9rwRtXEV5Fe1GE1sOGX18eqd s2bTMwSnTz9d9P33aimN0yzsdJ//hiVitKs4uo9ovNLyD7MHUKSj37+A+35f68hzGu9j4+ nBz98bHgHl/9mMh3U72Zztpdze3pZIx2nYVyrbbTTGA3CmGSQqd3TOSHKfCqWy/OO7zc3G Lo1V7UUomSZHJ0T9p9i9QGsgduq0qmIL1BfHXintGRez6ZSutnusDh9lo95P3g== Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 09:15:03 -0000 Charlie Perkins writes: > Hello Tero, >=20 > Thanks for your comments, useful as always.=A0 Please see a bit of=20= > follow-up below. >=20 >=20 > On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > > The title of the draft has some acronyms which are not expanded (AO= DV, P2P) and > > if you expand them the title comes way too long. I would propose a = usable > > title, which might not need to use all possible acronyms, but would= better > > explain what this document is trying to do. >=20 > How about "Supporting Asymmetric Links in Low Power Networks"=3F Repl= acing=20 > "LLNs" by "Low Power Networks" is probably O.K. because lossy is almo= st=20 > implicit given low power (or, often, reality). Thats much better. From that I can even understand what is the difference between this and previous work, i.e., that the important difference is the asymmetric, not p2p or aodv etc... > > Nits: --=20 kivinen@iki.fi From nobody Tue Mar 30 17:33:37 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531723A05F8; Tue, 30 Mar 2021 17:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ih-h8vVHRNwK; Tue, 30 Mar 2021 17:33:27 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 60C3A3A0553; Tue, 30 Mar 2021 17:33:26 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id 7so17805625qka.7; Tue, 30 Mar 2021 17:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B1mVjeZX9T2anRk5DQhirBXG4Cicb3E9e84hwrdP9JM=; b=N96R4Fvr4PYggiMc5OynJTAHHu72oONKNJu9AyWvEcMbB/agcDlF4qTHiQqfuMgUB9 dnNAS853qvEb2PLDCLpt5rZtqd9wbXujYAn5QV0nHTYfY4FdldjR9k+qpKP7iCsU/u/Y dE6bSuoMf8lij/TRIrkyBOxuer1AmnApK2kRl+fWDq2U1IvRiLGZu2egNVhLLdry7aZB ZN8ph3jwJR+0d0EDndAsShsdbRWoI8behyErGoXGC6pNc8uggcUk5MZytYoBZnNmXgiq GCdo3oKlzh9N2hrXYRdTHGVY77Sk7MNDIiuBoxxKJsyjaicA+ImmnO7WBnEdF6xq03Rp QHdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B1mVjeZX9T2anRk5DQhirBXG4Cicb3E9e84hwrdP9JM=; b=S/8tzEZpnDGWsbTA8WmZED5o6PF7+wCxA4F6Du6ABUd5b4R8s/YF3HNxGDJsMmp5yt FDujGYOubtxGIEUmlaxclE9SrO/jwITL0JoRCqkXDZ8TiMZ36zl/WVbzMDjXKx+0IF81 sjB+QDa2dIH4Uh9JZL3YM0k0NSzipp7eDiON3M+2YjNZutmNo/es05T6BWnU8u6oCDA4 XzWMV5qUQ6pUiT+qJOaYTXiicZauDp7SYWI24CHhCj6bS+UyqjW9tvPcoR4U/Q3D2xDE nDaL6+IDnOVH++7EvtgpnSf9VOUiMiVJU/tOh0lm8bf+264zgeUnHda1CDyn0ugvjoE2 mFKg== X-Gm-Message-State: AOAM530tobu5gxyqaUrcp2u6zdL3kuiIRTxADTJZtRrbN9O4I9vRDkO/ cjbssniJOM9SKryoBtQZVCzlRkQ8G8JI+mGQDP8= X-Google-Smtp-Source: ABdhPJwLaEOrKkK4pXJYzsd36W3G1VY96kgf/6RGdH7Tn0/ssqoKQfmNCdW4O9UATg0pfQpvsU/aYqgvxccTMFJuObg= X-Received: by 2002:ae9:eb4d:: with SMTP id b74mr931928qkg.45.1617150804553; Tue, 30 Mar 2021 17:33:24 -0700 (PDT) MIME-Version: 1.0 References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> <20210329183304.GB6408@iisc.ac.in> In-Reply-To: <20210329183304.GB6408@iisc.ac.in> From: satish anamalamudi Date: Wed, 31 Mar 2021 06:03:12 +0530 Message-ID: To: "S.V.R.Anand" Cc: Charlie Perkins , Tero Kivinen , draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="00000000000040f44505beca4371" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 00:33:31 -0000 --00000000000040f44505beca4371 Content-Type: text/plain; charset="UTF-8" Dear all, In my opinion, it is good to include AODV-RPL acronym within the title of the draft. Regards, Satish On Tue, Mar 30, 2021 at 12:03 AM S.V.R.Anand wrote: > Hello, > > I prefer to retain AODV-RPL in the title. AODV-RPL acronym has already > been referred by research community in their publications, and roll > community uses this acronym to refer to this draft. Also, I feel AODV > and RPL acronyms are familiar to the wireless and low power and lossy > networks world. > > How about "AODV-RPL Extensions for Asymmetric Links in Low Power > Networks", or "AODV-RPL Support for Asymmetric Links in LLNs" ? > > Regards > Anand > > > On 21-03-28 10:39:53, Charlie Perkins wrote: > > > > > > Hello Tero, > > > > Thanks for your comments, useful as always. Please see a bit of > > follow-up below. > > > > > > On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > > >The title of the draft has some acronyms which are not expanded (AODV, > P2P) and > > >if you expand them the title comes way too long. I would propose a > usable > > >title, which might not need to use all possible acronyms, but would > better > > >explain what this document is trying to do. > > > > How about "Supporting Asymmetric Links in Low Power Networks"? Replacing > > "LLNs" by "Low Power Networks" is probably O.K. because lossy is almost > > implicit given low power (or, often, reality). > > > > > > > > > >Nits: > > > > > >In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power > and Lossy > > >Networks)" defines acronyms differently than what is used everywhere > else. In > > >all other cases the document uses format where the acronym is in > parenthesis > > >after the full text, i.e. "Routing Protocol for Low-Power and Lossy > Networks > > >(RPL) [RFC6550]" format. I would propose using the same format also for > here. > > Done. > > > > > > > >In section 1 there is acronym DAG which is not expanded, expand it on > first > > >use. > > I think that sentence reads better just omitting DAG. > > > > > > > Also there are unexpanded acronyms DAO, P2MP, which are not used > anywhere > > >else, perhaps just expand them here. In same paragraph there is also > acronym > > >MOP which is not expanded here on its first use, but it is expanded > later. > > >Expand it here on its first use. > > > > Done, except that I thought it would be better to exhibit the acronym > > DAO since it is well known to readers familiar with RPL. > > > > > > > > > >What is the difference between different reserve bits X and r in > sections > > >4.1/4.2 and 4.3? > > I made them all to be reserved bits 'X'. > > > > > > > >Period missing from the end of sentence of the Option Length > description in > > >Section 4.3. > > Done. > > > > > > > >In the IANA considerations section I propose add a note to RFC editor > saying > > >that the sentences saying " The parenthesized numbers are only > suggestions." > > >needs to be removed prior publication. > > > > > > > > > > Done! > > > > Naturally Yours, > > Charlie P. > > > -- *With Regards,* *Dr. Satish Anamalamudi, PhD.,* --00000000000040f44505beca4371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

In my=C2=A0opinion, it is good to include AODV-RPL acronym within the t= itle of the draft.

Regar= ds,
Satish=C2=A0

On Tue, Mar 30, 2021 at 12:03 A= M S.V.R.Anand <anandsvr@iisc.ac.i= n> wrote:
Hello,

I prefer to retain AODV-RPL in the title. AODV-RPL acronym has already
been referred by research community in their publications, and roll
community uses this acronym to refer to this draft. Also, I feel AODV
and RPL acronyms are familiar to the wireless and low power and lossy
networks world.

How about "AODV-RPL Extensions for Asymmetric Links in Low Power
Networks", or "AODV-RPL Support for Asymmetric Links in LLNs"= ; ?

Regards
Anand


On 21-03-28 10:39:53, Charlie Perkins wrote:
>
>
> Hello Tero,
>
> Thanks for your comments, useful as always.=C2=A0 Please see a bit of<= br> > follow-up below.
>
>
> On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote:
> >The title of the draft has some acronyms which are not expanded (A= ODV, P2P) and
> >if you expand them the title comes way too long. I would propose a= usable
> >title, which might not need to use all possible acronyms, but woul= d better
> >explain what this document is trying to do.
>
> How about "Supporting Asymmetric Links in Low Power Networks"= ;? Replacing
> "LLNs" by "Low Power Networks" is probably O.K. be= cause lossy is almost
> implicit given low power (or, often, reality).
>
>
> >
> >Nits:
> >
> >In section 1 the text "RPL [RFC6550] (Routing Protocol for Lo= w-Power and Lossy
> >Networks)" defines acronyms differently than what is used eve= rywhere else. In
> >all other cases the document uses format where the acronym is in p= arenthesis
> >after the full text, i.e. "Routing Protocol for Low-Power and= Lossy Networks
> >(RPL) [RFC6550]" format. I would propose using the same forma= t also for here.
> Done.
>
> >
> >In section 1 there is acronym DAG which is not expanded, expand it= on first
> >use.
> I think that sentence reads better just omitting DAG.
>
>
> >=C2=A0 Also there are unexpanded acronyms DAO, P2MP, which are not= used anywhere
> >else, perhaps just expand them here. In same paragraph there is al= so acronym
> >MOP which is not expanded here on its first use, but it is expande= d later.
> >Expand it here on its first use.
>
> Done, except that I thought it would be better to exhibit the acronym<= br> > DAO since it is well known to readers familiar with RPL.
>
>
> >
> >What is the difference between different reserve bits X and r in s= ections
> >4.1/4.2 and 4.3?
> I made them all to be reserved bits 'X'.
>
> >
> >Period missing from the end of sentence of the Option Length descr= iption in
> >Section 4.3.
> Done.
>
> >
> >In the IANA considerations section I propose add a note to RFC edi= tor saying
> >that the sentences saying " The parenthesized numbers are onl= y suggestions."
> >needs to be removed prior publication.
> >
> >
>
> Done!
>
> Naturally Yours,
> Charlie P.
>
--
<= div>











<= div>With Regards,
Dr. Satish Anamalamudi, PhD.,

--00000000000040f44505beca4371-- From nobody Tue Mar 30 21:33:44 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A174C3A186D; Tue, 30 Mar 2021 21:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 Ur02LKtLwbaO; Tue, 30 Mar 2021 21:33:30 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FB63A186B; Tue, 30 Mar 2021 21:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1617165210; bh=mDognXpabH03upzPJG1pkLjGvaIj8Vm3Yp6Y XPmIOYM=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=fTiYHjY3E9COmpy9zkp5z4Gr0YHfKPqlN Ok3r3+DVnxfDAMCrqYPtXLoKwkKAiuYN2Bh6CGOIM9xqYn9x2NEKGtLpXj8iYPryiol UU5RllybZuG6uXiVRyBbpyGPmp+XmZ/vuoBtj8qZJzUTSgz83z7Qw3KqOdqcu8RPeMv 5zzR1qaopfvbQV/A6+IRl7CZzIBItaL7EisM43EmtmHW1EvP+xCfJn2HXl8h+Hr3xlH AikQPRGUoCgbi5qAb3cMMInmF+aZ0o0ER8mL49e1T4Pzm73G5UTP9V4c0GUEnnlyOKl hv0IiqfP1dvcoBrB93Q8VU8FZ/S24L+TaOGXTz1PQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=aqLMa+ClIaBvpYKi8LCVwl1ud76lMQeDlC4PmbCnwljOHIZuU0o28J5IV0xB8D7TWHC8h5Ps9rqOkLR7zxRiy0U9wc8++UdBKFRZ0P5gZwruPBJ9SIkADEDI8gK+F1PF4Uy9ks8LGlOeVdS7Mo9qY+CsQZsrLKGOo/eCIQX5kfhzJnDyxxreA32JQ/+eQCXaAoHgVBuxlV81GykgoSxzWBooT+F4kc9A48mLjzAaKXvirgMTBPiqZzkZeQkGWHORblwn9sYDXJBWjoaVQXkniFAB0zEO/3upcZpou28EfniU06oZGs86xByzNJZ4ydrLLVPhfedH4yFMB07QxC/NHA==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.72]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1lRSXl-000Bb3-P8; Wed, 31 Mar 2021 00:33:25 -0400 To: satish anamalamudi , "S.V.R.Anand" Cc: Tero Kivinen , draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org, secdir@ietf.org References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> <20210329183304.GB6408@iisc.ac.in> From: Charlie Perkins Message-ID: <2ec8689d-0aca-a334-e115-ae5f130e53ed@earthlink.net> Date: Tue, 30 Mar 2021 21:33:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8AFC79D068A381D11D3EE26F" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956df8303b86ceddf55bdb418515c1af68515813527482891b0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 04:33:35 -0000 This is a multi-part message in MIME format. --------------8AFC79D068A381D11D3EE26F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Satish, How about "Supporting Asymmetric Links in Low Power Networks: AODV-RPL"? It still fits on one line, and seems to resolve your request as well as Tero's request. Naturally Yours, Charlie P. On 3/30/2021 5:33 PM, satish anamalamudi wrote: > Dear all, > > In my opinion, it is good to include AODV-RPL acronym within the title > of the draft. > > Regards, > Satish > > On Tue, Mar 30, 2021 at 12:03 AM S.V.R.Anand > wrote: > > Hello, > > I prefer to retain AODV-RPL in the title. AODV-RPL acronym has already > been referred by research community in their publications, and roll > community uses this acronym to refer to this draft. Also, I feel AODV > and RPL acronyms are familiar to the wireless and low power and lossy > networks world. > > How about "AODV-RPL Extensions for Asymmetric Links in Low Power > Networks", or "AODV-RPL Support for Asymmetric Links in LLNs" ? > > Regards > Anand > > > On 21-03-28 10:39:53, Charlie Perkins wrote: > > > > > > Hello Tero, > > > > Thanks for your comments, useful as always.  Please see a bit of > > follow-up below. > > > > > > On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > > >The title of the draft has some acronyms which are not expanded > (AODV, P2P) and > > >if you expand them the title comes way too long. I would > propose a usable > > >title, which might not need to use all possible acronyms, but > would better > > >explain what this document is trying to do. > > > > How about "Supporting Asymmetric Links in Low Power Networks"? > Replacing > > "LLNs" by "Low Power Networks" is probably O.K. because lossy is > almost > > implicit given low power (or, often, reality). > > > > > > > > > >Nits: > > > > > >In section 1 the text "RPL [RFC6550] (Routing Protocol for > Low-Power and Lossy > > >Networks)" defines acronyms differently than what is used > everywhere else. In > > >all other cases the document uses format where the acronym is > in parenthesis > > >after the full text, i.e. "Routing Protocol for Low-Power and > Lossy Networks > > >(RPL) [RFC6550]" format. I would propose using the same format > also for here. > > Done. > > > > > > > >In section 1 there is acronym DAG which is not expanded, expand > it on first > > >use. > > I think that sentence reads better just omitting DAG. > > > > > > >  Also there are unexpanded acronyms DAO, P2MP, which are not > used anywhere > > >else, perhaps just expand them here. In same paragraph there is > also acronym > > >MOP which is not expanded here on its first use, but it is > expanded later. > > >Expand it here on its first use. > > > > Done, except that I thought it would be better to exhibit the > acronym > > DAO since it is well known to readers familiar with RPL. > > > > > > > > > >What is the difference between different reserve bits X and r > in sections > > >4.1/4.2 and 4.3? > > I made them all to be reserved bits 'X'. > > > > > > > >Period missing from the end of sentence of the Option Length > description in > > >Section 4.3. > > Done. > > > > > > > >In the IANA considerations section I propose add a note to RFC > editor saying > > >that the sentences saying " The parenthesized numbers are only > suggestions." > > >needs to be removed prior publication. > > > > > > > > > > Done! > > > > Naturally Yours, > > Charlie P. > > > > -- > > > > > > > * > * > * > * > * > * > * > * > * > * > *With Regards,* > *Dr. Satish Anamalamudi, PhD., > * > * > * --------------8AFC79D068A381D11D3EE26F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Satish,

How about "Supporting Asymmetric Links in Low Power Networks: AODV-RPL"?

It still fits on one line, and seems to resolve your request as well as Tero's request.

Naturally Yours,
Charlie P.


On 3/30/2021 5:33 PM, satish anamalamudi wrote:
Dear all,

In my opinion, it is good to include AODV-RPL acronym within the title of the draft.

Regards,
Satish 

On Tue, Mar 30, 2021 at 12:03 AM S.V.R.Anand <anandsvr@iisc.ac.in> wrote:
Hello,

I prefer to retain AODV-RPL in the title. AODV-RPL acronym has already
been referred by research community in their publications, and roll
community uses this acronym to refer to this draft. Also, I feel AODV
and RPL acronyms are familiar to the wireless and low power and lossy
networks world.

How about "AODV-RPL Extensions for Asymmetric Links in Low Power
Networks", or "AODV-RPL Support for Asymmetric Links in LLNs" ?

Regards
Anand


On 21-03-28 10:39:53, Charlie Perkins wrote:
>
>
> Hello Tero,
>
> Thanks for your comments, useful as always.  Please see a bit of
> follow-up below.
>
>
> On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote:
> >The title of the draft has some acronyms which are not expanded (AODV, P2P) and
> >if you expand them the title comes way too long. I would propose a usable
> >title, which might not need to use all possible acronyms, but would better
> >explain what this document is trying to do.
>
> How about "Supporting Asymmetric Links in Low Power Networks"? Replacing
> "LLNs" by "Low Power Networks" is probably O.K. because lossy is almost
> implicit given low power (or, often, reality).
>
>
> >
> >Nits:
> >
> >In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and Lossy
> >Networks)" defines acronyms differently than what is used everywhere else. In
> >all other cases the document uses format where the acronym is in parenthesis
> >after the full text, i.e. "Routing Protocol for Low-Power and Lossy Networks
> >(RPL) [RFC6550]" format. I would propose using the same format also for here.
> Done.
>
> >
> >In section 1 there is acronym DAG which is not expanded, expand it on first
> >use.
> I think that sentence reads better just omitting DAG.
>
>
> >  Also there are unexpanded acronyms DAO, P2MP, which are not used anywhere
> >else, perhaps just expand them here. In same paragraph there is also acronym
> >MOP which is not expanded here on its first use, but it is expanded later.
> >Expand it here on its first use.
>
> Done, except that I thought it would be better to exhibit the acronym
> DAO since it is well known to readers familiar with RPL.
>
>
> >
> >What is the difference between different reserve bits X and r in sections
> >4.1/4.2 and 4.3?
> I made them all to be reserved bits 'X'.
>
> >
> >Period missing from the end of sentence of the Option Length description in
> >Section 4.3.
> Done.
>
> >
> >In the IANA considerations section I propose add a note to RFC editor saying
> >that the sentences saying " The parenthesized numbers are only suggestions."
> >needs to be removed prior publication.
> >
> >
>
> Done!
>
> Naturally Yours,
> Charlie P.
>
--











With Regards,
Dr. Satish Anamalamudi, PhD.,


--------------8AFC79D068A381D11D3EE26F-- From nobody Tue Mar 30 22:13:57 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5D93A19B1; Tue, 30 Mar 2021 22:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjN-92X3bEtI; Tue, 30 Mar 2021 22:13:46 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 EBBD63A19A5; Tue, 30 Mar 2021 22:13:41 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id c4so18270089qkg.3; Tue, 30 Mar 2021 22:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MDt8XTPzDp03QtAo2D7J1y3lERhlzCxiqD7J+cioF3Q=; b=RBo/gZh+4Rhg3Z3WrJJ0OOR+lVNxyo9QVfotpDm8F0DOafed+B1V3ypaevZi1wNgYq 8LYfiLanqP4iz/P5IJSWz+VQCvKI3NXki5qTBbVDg/HM1FOR12H74tfhMOi9nIWYOVOP ZO3qiEMc2JaENFhp7wfGsPN+/najLP5zb7CnHyVJGUhyvoTaHO2k9+o/iH5UK/ocYnq/ iafRYXd6mZTPkJZjuwMr8iPh/oiNYiz3i7LnuVcx48YwjaXsFVq19hvnlPblnRPwqTZ+ 6sjh9iTi6d/ecMdDiDUuXuO+dcKPjyOefgrGXyqkFjSj44wEZb5lRTb9YIkjVnH/3mmf ld9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MDt8XTPzDp03QtAo2D7J1y3lERhlzCxiqD7J+cioF3Q=; b=OWDUkQXtvH0dWgd6QGBjKdd4TNCuL84Fd97g4tf+AqKItJjFeneOExKYkJYuza+lD9 ALw98yPG+1Slf6Ed0gu2WwK9Etyzc9rbV0ovHKIIAmGavBLc4bdyZagoM8n52gCrA3C6 uxGF8U3SeIevopNXSLIed6dCUUFsioymKWQg3rEel7Ef2/5vlEBMG363Nkpfu+8N0AfT kp+OgFI43DaupB8fGAuPPU2Ot+uq/2ZEhDxjF85RzapF5tBUpVI8sf3Fmvd6kN+G0pli i/jVq7XKX9/r/m1FjhdD4mpi5BYZaR1bvhsYN73IaeMX43NUFWNljrR3tuD77dKCouCX X4TA== X-Gm-Message-State: AOAM533oZwwzsJqTWs+2csstiWmxFDEQjE5vVa4XRccX33Zflrjm3jDb Cqlb7q6DGCwJDyQJfGq0SxVU7enCiztEDaCvsNo= X-Google-Smtp-Source: ABdhPJwAPy/4BB+/uVKb0yGP0gjbuEd8Lu9pPuatE0Djq8rVH2UT4VCVNpbOFVpBushL3t9pRs4ahKj5P1iKHBNzp9s= X-Received: by 2002:a05:620a:941:: with SMTP id w1mr1556802qkw.484.1617167619842; Tue, 30 Mar 2021 22:13:39 -0700 (PDT) MIME-Version: 1.0 References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> <20210329183304.GB6408@iisc.ac.in> <2ec8689d-0aca-a334-e115-ae5f130e53ed@earthlink.net> In-Reply-To: <2ec8689d-0aca-a334-e115-ae5f130e53ed@earthlink.net> From: satish anamalamudi Date: Wed, 31 Mar 2021 10:43:28 +0530 Message-ID: To: Charlie Perkins Cc: "S.V.R.Anand" , Tero Kivinen , draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="00000000000085e5d205bece2dd5" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 05:13:51 -0000 --00000000000085e5d205bece2dd5 Content-Type: text/plain; charset="UTF-8" Hello Charlie, Yes, the AODV-RPL draft is mainly proposed to support asymmetric link in constrained LLN network. Implementation of asymmetric links is crucial in constrained network resources. Regards, Satish On Wed, Mar 31, 2021 at 10:03 AM Charlie Perkins < charles.perkins@earthlink.net> wrote: > Hello Satish, > > How about "Supporting Asymmetric Links in Low Power Networks: AODV-RPL"? > > It still fits on one line, and seems to resolve your request as well as > Tero's request. > > Naturally Yours, > Charlie P. > > > > On 3/30/2021 5:33 PM, satish anamalamudi wrote: > > Dear all, > > In my opinion, it is good to include AODV-RPL acronym within the title of > the draft. > > Regards, > Satish > > On Tue, Mar 30, 2021 at 12:03 AM S.V.R.Anand wrote: > >> Hello, >> >> I prefer to retain AODV-RPL in the title. AODV-RPL acronym has already >> been referred by research community in their publications, and roll >> community uses this acronym to refer to this draft. Also, I feel AODV >> and RPL acronyms are familiar to the wireless and low power and lossy >> networks world. >> >> How about "AODV-RPL Extensions for Asymmetric Links in Low Power >> Networks", or "AODV-RPL Support for Asymmetric Links in LLNs" ? >> >> Regards >> Anand >> >> >> On 21-03-28 10:39:53, Charlie Perkins wrote: >> > >> > >> > Hello Tero, >> > >> > Thanks for your comments, useful as always. Please see a bit of >> > follow-up below. >> > >> > >> > On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: >> > >The title of the draft has some acronyms which are not expanded (AODV, >> P2P) and >> > >if you expand them the title comes way too long. I would propose a >> usable >> > >title, which might not need to use all possible acronyms, but would >> better >> > >explain what this document is trying to do. >> > >> > How about "Supporting Asymmetric Links in Low Power Networks"? Replacing >> > "LLNs" by "Low Power Networks" is probably O.K. because lossy is almost >> > implicit given low power (or, often, reality). >> > >> > >> > > >> > >Nits: >> > > >> > >In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power >> and Lossy >> > >Networks)" defines acronyms differently than what is used everywhere >> else. In >> > >all other cases the document uses format where the acronym is in >> parenthesis >> > >after the full text, i.e. "Routing Protocol for Low-Power and Lossy >> Networks >> > >(RPL) [RFC6550]" format. I would propose using the same format also >> for here. >> > Done. >> > >> > > >> > >In section 1 there is acronym DAG which is not expanded, expand it on >> first >> > >use. >> > I think that sentence reads better just omitting DAG. >> > >> > >> > > Also there are unexpanded acronyms DAO, P2MP, which are not used >> anywhere >> > >else, perhaps just expand them here. In same paragraph there is also >> acronym >> > >MOP which is not expanded here on its first use, but it is expanded >> later. >> > >Expand it here on its first use. >> > >> > Done, except that I thought it would be better to exhibit the acronym >> > DAO since it is well known to readers familiar with RPL. >> > >> > >> > > >> > >What is the difference between different reserve bits X and r in >> sections >> > >4.1/4.2 and 4.3? >> > I made them all to be reserved bits 'X'. >> > >> > > >> > >Period missing from the end of sentence of the Option Length >> description in >> > >Section 4.3. >> > Done. >> > >> > > >> > >In the IANA considerations section I propose add a note to RFC editor >> saying >> > >that the sentences saying " The parenthesized numbers are only >> suggestions." >> > >needs to be removed prior publication. >> > > >> > > >> > >> > Done! >> > >> > Naturally Yours, >> > Charlie P. >> > >> > -- > > > > > > > > > > > > *With Regards,* > > *Dr. Satish Anamalamudi, PhD., * > > > -- *With Regards,* *Dr. Satish Anamalamudi, PhD.,* --00000000000085e5d205bece2dd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Charlie,

Yes, the AODV-RPL draft is mainly proposed to support asymmetric = link in constrained LLN network. Implementation of asymmetric links is cruc= ial in constrained network resources.

Regards,
Satish

On Wed, Mar 31, 20= 21 at 10:03 AM Charlie Perkins <charles.perkins@earthlink.net> wrote:
=20 =20 =20
Hello Satish,

How about "Supporting Asymmetric Links in Low Power Networks: AODV-RPL"?

It still fits on one line, and seems to resolve your request as well as Tero's request.

Naturally Yours,
Charlie P.



On 3/30/2021 5:33 PM, satish anamalamudi wrote:
=20
Dear all,

In my=C2=A0opinion, it is good to include AODV-RPL acronym within the title of the draft.

Regards,
Satish=C2=A0

On Tue, Mar 30, 2021 at 12:03 AM S.V.R.Anand <anandsvr@iisc.ac.in> wrote:
Hello,

I prefer to retain AODV-RPL in the title. AODV-RPL acronym has already
been referred by research community in their publications, and roll
community uses this acronym to refer to this draft. Also, I feel AODV
and RPL acronyms are familiar to the wireless and low power and lossy
networks world.

How about "AODV-RPL Extensions for Asymmetric Links in Low Power
Networks", or "AODV-RPL Support for Asymmetric Links = in LLNs" ?

Regards
Anand


On 21-03-28 10:39:53, Charlie Perkins wrote:
>
>
> Hello Tero,
>
> Thanks for your comments, useful as always.=C2=A0 Please s= ee a bit of
> follow-up below.
>
>
> On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote:
> >The title of the draft has some acronyms which are not expanded (AODV, P2P) and
> >if you expand them the title comes way too long. I would propose a usable
> >title, which might not need to use all possible acronyms, but would better
> >explain what this document is trying to do.
>
> How about "Supporting Asymmetric Links in Low Power Networks"? Replacing
> "LLNs" by "Low Power Networks" is prob= ably O.K. because lossy is almost
> implicit given low power (or, often, reality).
>
>
> >
> >Nits:
> >
> >In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and Lossy
> >Networks)" defines acronyms differently than what is used everywhere else. In
> >all other cases the document uses format where the acronym is in parenthesis
> >after the full text, i.e. "Routing Protocol for Low-Power and Lossy Networks
> >(RPL) [RFC6550]" format. I would propose using th= e same format also for here.
> Done.
>
> >
> >In section 1 there is acronym DAG which is not expanded, expand it on first
> >use.
> I think that sentence reads better just omitting DAG.
>
>
> >=C2=A0 Also there are unexpanded acronyms DAO, P2MP, which are not used anywhere
> >else, perhaps just expand them here. In same paragraph there is also acronym
> >MOP which is not expanded here on its first use, but it is expanded later.
> >Expand it here on its first use.
>
> Done, except that I thought it would be better to exhibit the acronym
> DAO since it is well known to readers familiar with RPL.
>
>
> >
> >What is the difference between different reserve bits X and r in sections
> >4.1/4.2 and 4.3?
> I made them all to be reserved bits 'X'.
>
> >
> >Period missing from the end of sentence of the Option Length description in
> >Section 4.3.
> Done.
>
> >
> >In the IANA considerations section I propose add a note to RFC editor saying
> >that the sentences saying " The parenthesized numbers are only suggestions."
> >needs to be removed prior publication.
> >
> >
>
> Done!
>
> Naturally Yours,
> Charlie P.
>
--











With Regards,
Dr. Satish= Anamalamudi, PhD.,


--
<= div>











<= div>With Regards,
Dr. Satish Anamalamudi, PhD.,

--00000000000085e5d205bece2dd5-- From nobody Tue Mar 30 22:35:33 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264A83A1A80; Tue, 30 Mar 2021 22:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUZ4jjsf0fxF; Tue, 30 Mar 2021 22:35:29 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 9FF7D3A1A7D; Tue, 30 Mar 2021 22:35:28 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id y5so18288520qkl.9; Tue, 30 Mar 2021 22:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PUsHz/4hYJEdx93uiuIw2B/tdb53vJMHZIESJ3V1vr0=; b=mW0NdR2I5QtLpCtFXySNhhW0hENjuo2l61Sv3O2/A4BsLToiLiAs4VNLnHJHcdXuwq 0ilDiLlDbWdu2vq8VwabNZdTEz9ZxqUoeYbP1J2opuUOeRPCTkzXLkd5nvPPppV1VXWh qrpPm+6sKw5m2qoxfdApa5InFkfBfvzl8sPLn+GUSFtUg8DDauKIZfUC1K7yyLxyfQQf 3j9PSVfmWVD9bM59O3dU//4ToKZ+gXyZ59/gJODGSU00ci/EYpAIYgjy7pPDP3adQ8XC QBnUv/0F7Gm7IKGbmLdUafZQFdfWuHsDHt6Y/H6O1/6cvNonoxc48Qw2JKQymA/oYnUO HCRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PUsHz/4hYJEdx93uiuIw2B/tdb53vJMHZIESJ3V1vr0=; b=DNc+Wuo28/+COoIfP7WTkcwNPDn+6GYdsTj3JNmZwKzk9+wK5C42s5AcNAQYN6MVwE S7w6z2BIcmJY+AbsSc19mz6C+WeM2yUjpPQEdzcLUgPUhueoVpGOOy91D4cDRfpYbEhu 70s5sHpYaV6uEUmPZwCArmpr6KIMXEaIXN0S23uoqyniPZ70NsNQGTWQibH4rBUpr+XJ abkAJhh4NGE/IWKMz+EaGxW8Drlfw9GrpkSETeoBgc9U8hEaGFexCKZdRt9gNmqJHOxs uoiL6opN2PX+olkabUAgot0fpuU6XoZilCe4GlHN7p8jdMpaaEn9Kusqkdh8iQQGSdKj DZkA== X-Gm-Message-State: AOAM533rDlO5hndwsDSIkp08BWAtymWZiD0rgSMqw3DV+d3wcHD4p5pb 3Jw9K9PqQzPKkVgQnV/7NjErduD2DX9qqhWXWqowaCAH+Eg= X-Google-Smtp-Source: ABdhPJxiCAv5ShkKWnCgTv04ciWTc7cRLK9jWrvwLLgZyLEPmUSGe+c3BxnVRG4hk054ExNmC3GsWhBeSyhJvyO9Ycw= X-Received: by 2002:a05:620a:55a:: with SMTP id o26mr1618723qko.43.1617168926673; Tue, 30 Mar 2021 22:35:26 -0700 (PDT) MIME-Version: 1.0 References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> In-Reply-To: <8f67d107-7c81-ea4f-42d1-a465f008ae9b@earthlink.net> From: satish anamalamudi Date: Wed, 31 Mar 2021 11:05:15 +0530 Message-ID: To: Charlie Perkins Cc: Tero Kivinen , draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000006a8da505bece7b8b" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-roll-aodv-rpl-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 05:35:32 -0000 --0000000000006a8da505bece7b8b Content-Type: text/plain; charset="UTF-8" Hi, I am supporting with charlie new title. Regards, Satish On Sun, Mar 28, 2021 at 11:10 PM Charlie Perkins < charles.perkins@earthlink.net> wrote: > Hello Tero, > > Thanks for your comments, useful as always. Please see a bit of > follow-up below. > > > On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > > The title of the draft has some acronyms which are not expanded (AODV, > P2P) and > > if you expand them the title comes way too long. I would propose a usable > > title, which might not need to use all possible acronyms, but would > better > > explain what this document is trying to do. > > How about "Supporting Asymmetric Links in Low Power Networks"? Replacing > "LLNs" by "Low Power Networks" is probably O.K. because lossy is almost > implicit given low power (or, often, reality). > > > > > > Nits: > > > > In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and > Lossy > > Networks)" defines acronyms differently than what is used everywhere > else. In > > all other cases the document uses format where the acronym is in > parenthesis > > after the full text, i.e. "Routing Protocol for Low-Power and Lossy > Networks > > (RPL) [RFC6550]" format. I would propose using the same format also for > here. > Done. > > > > > In section 1 there is acronym DAG which is not expanded, expand it on > first > > use. > I think that sentence reads better just omitting DAG. > > > > Also there are unexpanded acronyms DAO, P2MP, which are not used > anywhere > > else, perhaps just expand them here. In same paragraph there is also > acronym > > MOP which is not expanded here on its first use, but it is expanded > later. > > Expand it here on its first use. > > Done, except that I thought it would be better to exhibit the acronym > DAO since it is well known to readers familiar with RPL. > > > > > > What is the difference between different reserve bits X and r in sections > > 4.1/4.2 and 4.3? > I made them all to be reserved bits 'X'. > > > > > Period missing from the end of sentence of the Option Length description > in > > Section 4.3. > Done. > > > > > In the IANA considerations section I propose add a note to RFC editor > saying > > that the sentences saying " The parenthesized numbers are only > suggestions." > > needs to be removed prior publication. > > > > > > Done! > > Naturally Yours, > Charlie P. > > -- *With Regards,* *Dr. Satish Anamalamudi, PhD.,* --0000000000006a8da505bece7b8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I = am supporting with charlie new title.

Regards,
Satish

On Sun, Mar 28, 20= 21 at 11:10 PM Charlie Perkins <charles.perkins@earthlink.net> wrote:
Hello Tero,

Thanks for your comments, useful as always.=C2=A0 Please see a bit of
follow-up below.


On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote:
> The title of the draft has some acronyms which are not expanded (AODV,= P2P) and
> if you expand them the title comes way too long. I would propose a usa= ble
> title, which might not need to use all possible acronyms, but would be= tter
> explain what this document is trying to do.

How about "Supporting Asymmetric Links in Low Power Networks"? Re= placing
"LLNs" by "Low Power Networks" is probably O.K. because= lossy is almost
implicit given low power (or, often, reality).


>
> Nits:
>
> In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Po= wer and Lossy
> Networks)" defines acronyms differently than what is used everywh= ere else. In
> all other cases the document uses format where the acronym is in paren= thesis
> after the full text, i.e. "Routing Protocol for Low-Power and Los= sy Networks
> (RPL) [RFC6550]" format. I would propose using the same format al= so for here.
Done.

>
> In section 1 there is acronym DAG which is not expanded, expand it on = first
> use.
I think that sentence reads better just omitting DAG.


>=C2=A0 =C2=A0Also there are unexpanded acronyms DAO, P2MP, which are no= t used anywhere
> else, perhaps just expand them here. In same paragraph there is also a= cronym
> MOP which is not expanded here on its first use, but it is expanded la= ter.
> Expand it here on its first use.

Done, except that I thought it would be better to exhibit the acronym
DAO since it is well known to readers familiar with RPL.


>
> What is the difference between different reserve bits X and r in secti= ons
> 4.1/4.2 and 4.3?
I made them all to be reserved bits 'X'.

>
> Period missing from the end of sentence of the Option Length descripti= on in
> Section 4.3.
Done.

>
> In the IANA considerations section I propose add a note to RFC editor = saying
> that the sentences saying " The parenthesized numbers are only su= ggestions."
> needs to be removed prior publication.
>
>

Done!

Naturally Yours,
Charlie P.

--
<= div>











<= div>With Regards,
Dr. Satish Anamalamudi, PhD.,

--0000000000006a8da505bece7b8b-- From nobody Wed Mar 31 05:46:58 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E116E3A275D; Wed, 31 Mar 2021 05:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haQ3LIHaEiWV; Wed, 31 Mar 2021 05:46:30 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2087.outbound.protection.outlook.com [40.107.94.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E4A3A2760; Wed, 31 Mar 2021 05:46:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bEMnE39zBUnGXCa6bo6z4YCN6CsxD1p5LBxTNQFfG9eH38CM+n4KwTWj3IdFSezqHGCqyjjaLVLLkxvpk0dHK9fTO2dZtkfGbJBFTSABdR4Qh4T0hkFMcObLXlx9prCfN6N7BAor96vRw9J88WQnLAudq0QxdLS2p+OeVzcSwbxeSU2GNdS6Gjp62IPOXwx/3eadHBSViAH23HtvmGIBQfaudYLs/FAAyYrlras1unCzKGarcKB65TIuLq2YHZSTZuAXlq/FHyy6GSzjqxdT5neiRmnUXyPLdmeSpci1wRCsBHwj15h803bMyl/3iKVOSfgZ1yDOtm3wBLM5RQ0lTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GxBbmdrdbHXEx9hZmOojJ2sDmZxK+VR2ij+/NXICWNo=; b=EP2EerNZn8upFHiUKjd2ZSqW98KIChZRQ+JFaQZ7agXzkKqcKKhK53nhb5hD5/z7wkE4SaJzuoHHdJcOhYhlqYRjwgpodHpfVXZV/LFWpl2tQ90XpiGcu9fHLQ4VEGl/+jRMOUrYc/4zhO3ynV8J2h8SvZLWu2yRC4fTmC6oC1skBQBCxbdNqg5ZF6FcnkA6meBxKF6W1TW55TIqNBVtRk9GT7+yI/oqBrM31Aoz7ihErAPUuKKQi7jOBRBrCpHZrjrlx0QARiViYbjqXlO7+7moiejM2v+duk7YEw6k81cOvnKKdxdT0zqn8lg5acUX7RMYXW6OXPdFeknzgoEiZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GxBbmdrdbHXEx9hZmOojJ2sDmZxK+VR2ij+/NXICWNo=; b=nyzsG4s0oZpukz3ryOL95IhdNJFQLKzm7RUMcZLPw970GUZYBAwWQnZ2K4N3b7V8jg9fFkV8FXIvQgYpx9uAtgoRi/sERRlwxBvcvLoD8DwPFcZUrNO7+k//7d0VvLF5wwruffrjp9Eo5+7Ft7rFYR1F8DKGXyC3OQV5fTpN/B0= Received: from DM6PR15MB2379.namprd15.prod.outlook.com (2603:10b6:5:8a::16) by DM6PR15MB4072.namprd15.prod.outlook.com (2603:10b6:5:2bf::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.33; Wed, 31 Mar 2021 12:46:27 +0000 Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::98bf:c687:dcef:f893]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::98bf:c687:dcef:f893%4]) with mapi id 15.20.3933.039; Wed, 31 Mar 2021 12:46:27 +0000 From: Daniel Migault To: David Mandelberg , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-lwig-minimal-esp.all@ietf.org" , IPsecME WG , "lwip@ietf.org" Thread-Topic: secdir review of draft-ietf-lwig-minimal-esp-03 Thread-Index: AQHXI1GfjWEz1qZlx0uM4o//1Jg8fKqeCHmQ Date: Wed, 31 Mar 2021 12:46:27 +0000 Message-ID: References: <91f5ebd2-b24f-ca04-eba0-60d0c9b6f401@mandelberg.org> In-Reply-To: <91f5ebd2-b24f-ca04-eba0-60d0c9b6f401@mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mandelberg.org; dkim=none (message not signed) header.d=none;mandelberg.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41c67815-556d-483f-b1fa-08d8f443002c x-ms-traffictypediagnostic: DM6PR15MB4072: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cFvt9q27tVyFOba6gJYFXQ66qcdB7mkbSFxCwn1vjzzSUtO6UxujKPXvSC6LSll1uiXJg+CZs2W6tADSZ0ATRwxwd1qdrlrbhtOtw5x/Iiouf0IwpKooDq0xjkOIDOArafWcLvumSF0oqIIlB5x1rOpKo7Tq+BI1IzliJXMeQqBh+8OvwBhzK0XYiVntnZvmxmVJZoqEQdnxX6SDqREy4pu8A/+nnzh3Qe6XKPJhwQwRL429MqFM+zhQU4sq/SWCpokwao2lRfJN19obLsU2WD2mNzexhr42zoKfwknDaC5Zre/yB/HCfr5NNlOlG9C6lbHbet2op0DFoHFAZgXIYh2oTjfJRbipQqSN4DKzv7TnisnvfziJzsmIEO4VXW8OJb0wIlHZkCnAfxB/wFF9pJnbwQJP9gmpnvdTm+Y4LHp8+OuO/PQXvVw+e/TA5UHJucN3pCBeC0cV5M1WFMcM1jjE08aq7LkLVpa0oZAM1071AHadzJ6ntMBtxFhiSEPeNESO4yIGEUDe7zM01uWSQEOB6NQwhiEzbfA+mhaHkAgqtGdbhvs4seeDFizJ9fcZdmmgv4dmQaJepAsaiHYt+AdulfQd5g6KSLWcLghBcB8nJvQ6NfXltRGWtSi+KZnYU+mJ/3h44QTOtuAXi6E9eBDLk1ZLbuj0JCYQAGhF7BQ7ytOJKkUpzKjuEcPwIhCW6RwUh27jGYQWfNMJOpZK+AHGy9u36RzHoghK+Sc9JcsyXlyZrnXcVAv8FUuRaFqu x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2379.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(136003)(376002)(39850400004)(396003)(52536014)(83380400001)(316002)(2906002)(5660300002)(110136005)(26005)(55016002)(478600001)(38100700001)(71200400001)(7696005)(33656002)(86362001)(186003)(9686003)(76116006)(8936002)(8676002)(66446008)(64756008)(66556008)(66476007)(66946007)(6506007)(53546011)(966005)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?NHdCQkVoMjhqMWhFMUs2V3hpMUc2RCtDbUtyeTlhZENNRy9MaGtkVUhDTmhW?= =?utf-8?B?YlVQS01VQmFGS3JEb0FkNW41OUZnaHFhR3dPakFrOS85cUdtVERsMWZ1K0pz?= =?utf-8?B?VUFTZE9idHF6NHhFRmxOQmY3RGNaYzFZWHE2c3R4WlEyK0txazVTdzAxTmFj?= =?utf-8?B?UzIvNktVVTc4aFl5MHJRZ3VzTDJISXBUQWswUmhKUUVEbXFqUGhnT3JQQlJn?= =?utf-8?B?RGNhWnFpcTlhTkZCdnFGSjJjUmhRMUlKN3lTU2x5VEZwYVdWeTJIZHlxak5o?= =?utf-8?B?SVZ6MENpc3hTYXd6V00xQ1lSVU42REZhbkdUTEJEaHB0K3VpMk1zTnBBcHRP?= =?utf-8?B?UGFhR29keGpLRzh4ZzhMdXRUUDBYb3lndXg4b2NwNkVGZG1Lck5jaDQ1Wmha?= =?utf-8?B?QWI5ZXdPelRHZU9hZWk1dUgyMFdwOEhNNzNoa3cwcFZHK2U3di9CVlFxT1dw?= =?utf-8?B?bjZSUHJGMDh0dE9WRC8rSnNzWk9JbDlMODVlVXlxY201QUZjZHBZK25hNmF2?= =?utf-8?B?L3VBay9nL0c4dWtOaDc3UXgvQ1Y0d21INTZ6UE9TQmt1ck9Xak1YM3dMUVBw?= =?utf-8?B?TkF5VUdOZDZoRGt5ZWkvNmkvQXMvcnNXVmhaM05jN3hvWlA3eVNNSUl0VlI4?= =?utf-8?B?UUdXb1FrWGkwQTNVNWk2N2IwVGFSUlR4bWVOZTZhYWpPd0pHejdiOG9Zd3N5?= =?utf-8?B?VGRTeUlPRFZ5TFo3UG5WUUlDYno1Uk9oZk9mQ2V6ZUJZWEgzTXFFYkxidjZW?= =?utf-8?B?QjBTWE8rdTJrY0gyT3NIdXhDUUdMVUtMNjBORDI2UHZvRUlXTHMvNUQvemRZ?= =?utf-8?B?aGpIVTJDaytSNDRqWnRsK0crUG9GakRpbjdkMGFmODdNanRBSEpsSU5MODNW?= =?utf-8?B?empnMHAvempDemxMbVVRTmc2UnlXV1VYaW8ySkc4Uit1VEtKUk1KVGFQbXZO?= =?utf-8?B?YzE0YTY3S0xYajNDYzVOcWxXcFpsczZyd1hQek0yWlllTVZVQnNqYXZoUFNq?= =?utf-8?B?UWNmQ0s0RTJaSHAwYnZ6TzBvbmU0RHdDeHRFSDNPZkQ1STB1bThraHZiRlZx?= =?utf-8?B?c25sRkU3UU51UHNFeVI3VExtVVhEalkvVG1DdFFSQWhQNU5mV0hrV0ZsTUll?= =?utf-8?B?MFFjeFdTVWwvUjRRS05mNU9SOHNsTjE2aWQ5M3NJSHhJV3lUbmF6eTYzNjJa?= =?utf-8?B?emRuODJyYzB5MVQycDB2WUg4VnFMdndEMEQ5NTZCakdMOEVycEJpUUFZdEh3?= =?utf-8?B?eHN2S081WXlWVnpuZjhPL0FEdWh6T2lwMWFQdHp5RERxdmtjK0tqSlQvTkFh?= =?utf-8?B?dUQxSGRiL2grU05vODV1NEhRWTNXeGZJeEQ5bUNkakpsK3duREtxLzFZVys4?= =?utf-8?B?SjJ1TjI4aHc3VlJlL2w4N1htbTU0R2h5Y21Jd1hNMElxdXVHTU9FUDdEN0g3?= =?utf-8?B?R2R0NVF3NzFSa1JGRnMxQUZxTkdVZUZMKzVDQ3VqYldYc0F0NHNFS2FpVHBG?= =?utf-8?B?ek9qcjJBUld2THhJTW1nb2JTMGNDdjJhOXdpUVNwS2VrZGVOWkZxSnkvaU1p?= =?utf-8?B?Wkd4N2Jldk1iQW5tbkhoTUVIQmc0elZMRUtqdDB5WlRZM1h0Qjk1TGdaVlI0?= =?utf-8?B?VU53b0U5ckNBMlFiU3NNamVMQjR0QlFCY2J0dWpxM000U293TzdaQWw2V3h2?= =?utf-8?B?eEk5S1BlMURaYkJBUUNIT2lkSzBLRFJySlRPaFgyNmZkMW90VXFHY0JJWTA4?= =?utf-8?Q?cnt16BJCMnJcXIoYiA=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2379.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41c67815-556d-483f-b1fa-08d8f443002c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2021 12:46:27.5150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qZAQL5H5sb2j6SrUF+VCGCtL8uDH3rHsHwFbu4u6Pjunbqj3ED9Zu5sCdKMcIJfygsvulZms7mJbehet08dqgSWqfaJTrVhGo14uGmC84iw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB4072 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-lwig-minimal-esp-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 12:46:36 -0000 SGkgRGF2aWQsIA0KDQpUaGFua3MgdGhlIHJldmlldy4gSSB0aGluayB0aGUgdGV4dCAgaW4gWzFd IGFkZHJlc3NlcyB5b3VyIGNvbmNlcm4uIEkgd2lsbCBwcm9iYWJseSBwdWJsaXNoIHRoZSBhIG5l dyB2ZXJzaW9uIHRvZGF5LiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlcyBpbmxpbmUuIA0KDQpZb3Vy cywgDQpEYW5pZWwNCg0KWzFdIGh0dHBzOi8vZ2l0aHViLmNvbS9tZ2x0L2RyYWZ0LW1nbHQtbHdp Zy1taW5pbWFsLWVzcC9wdWxsLzEvY29tbWl0cy9mYjkzOTNhMjQ2Mjk4ZTM3YWRjZjI2ODNhZmEy MDYxYTQwYjRlZDg5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYXZpZCBN YW5kZWxiZXJnIDxkYXZpZEBtYW5kZWxiZXJnLm9yZz4gDQpTZW50OiBTYXR1cmRheSwgTWFyY2gg MjcsIDIwMjEgNTozOSBQTQ0KVG86IGllc2dAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1sd2lnLW1pbmltYWwtZXNwLmFsbEBpZXRmLm9yZw0KU3ViamVjdDogc2VjZGlyIHJl dmlldyBvZiBkcmFmdC1pZXRmLWx3aWctbWluaW1hbC1lc3AtMDMNCg0KSSBoYXZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdv aW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBi eSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRo ZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcg aXMgUmVhZHkgd2l0aCBuaXRzLg0KDQooU2VjdGlvbiAzLCBuaXQpIEluIHRoZSBwYXJhZ3JhcGgg dGhhdCBpbmNsdWRlcyAiSG93ZXZlciwgbm9ucmFuZG9tIFNQSSBhbmQgcmVzdHJpY3RpbmcgdGhl aXIgcG9zc2libGUgdmFsdWVzIE1BWSBsZWFkIHRvIHByaXZhY3kgYW5kIHNlY3VyaXR5IGNvbmNl cm5zIiAsIGl0IHdvdWxkIGJlIG5pY2UgdG8gYWRkIHNvbWV0aGluZyBsaWtlICIoc2VlIGJlbG93 IGZvciBtb3JlIGRldGFpbHMpIi4gV2hlbiBJIGZpcnN0IHJlYWQgdGhhdCBwYXJhZ3JhcGgsIEkg d2FzIGFib3V0IHRvIGNvbW1lbnQgdGhhdCBpdCdzIHVuY2xlYXIgd2hhdCB0aGUgcHJpdmFjeS9z ZWN1cml0eSBjb25jZXJucyBhcmUsIGJ1dCB0aGVuIGl0IHdhcyBleHBsYWluZWQgYSBmZXcgcGFy YWdyYXBocyBiZWxvdy4NCg0KPG1nbHQ+DQpUaGF0IGlzIGNvcnJlY3QsIHdlIHJlc3RydWN0dXJl ZCBhIGJpdCB0aGUgc2VjdGlvbiB0byBjbGFyaWZ5IHRoaXMgYnkgaGF2aW5nIGEgc3Vic2VjdGlv biBkZWRpY2F0ZWQgdG8gY29uc2lkZXJhdGlvbnMgb3ZlciB0aGUgZ2VuZXJhdGlvbiBvZiBTUElz LiANCg0KVGhlIGN1cnJlbnQgc2VjdGlvbiBpcyBhdmFpbGFibGUgYXQgWzFdIGFuZCBpcyBtZW50 aW9uZWQgYmVsb3c6DQpbMV0gaHR0cHM6Ly9naXRodWIuY29tL21nbHQvZHJhZnQtbWdsdC1sd2ln LW1pbmltYWwtZXNwL3B1bGwvMS9jb21taXRzL2ZiOTM5M2EyNDYyOThlMzdhZGNmMjY4M2FmYTIw NjFhNDBiNGVkODkNCg0KPHNlY3Rpb24gdGl0bGU9IkNvbnNpZGVyYXRpb25zIG92ZXIgU1BJIGdl bmVyYXRpb24iPg0KDQo8dD5TUEkgdGhhdCBhcmUgbm90IHJhbmRvbWx5IGdlbmVyYXRlZCBvdmVy IDMyIGJpdHMgTUFZIGxlYWQgdG8gcHJpdmFjeSBhbmQgc2VjdXJpdHkgY29uY2VybnMuIA0KQXMg YSByZXN1bHQsIHRoZSB1c2Ugb2YgYWx0ZXJuYXRpdmUgZGVzaWducyByZXF1aXJlcyBjYXJlZnVs IHNlY3VyaXR5IGFuZCBwcml2YWN5IHJldmlld3MuIA0KVGhpcyBzZWN0aW9uIHByb3ZpZGVzIHNv bWUgY29uc2lkZXJhdGlvbnMgdXBvbiB0aGUgYWRvcHRpb24gb2YgYWx0ZXJuYXRpdmUgZGVzaWdu cy4gPC90Pg0KDQo8dD5Ob3RlIHRoYXQgU1BJIHZhbHVlIGlzIHVzZWQgb25seSBmb3IgaW5ib3Vu ZCB0cmFmZmljLCBhcyBzdWNoIHRoZSBTUEkgbmVnb3RpYXRlZCB3aXRoIElLRXYyIDx4cmVmIHRh cmdldD0iUkZDNzI5NiIvPiBvciA8eHJlZiB0YXJnZXQ9IlJGQzc4MTUiLz4gYnkgYSBwZWVyLCBp cyB0aGUgdmFsdWUgdXNlZCBieSB0aGUgcmVtb3RlIHBlZXIgd2hlbiBpdCBzZW5kcyB0cmFmZmlj LiANCkFzIFNQSSBpcyBvbmx5IHVzZWQgZm9yIGluYm91bmQgdHJhZmZpYyBieSB0aGUgcGVlciwg dGhpcyBhbGxvd3MgZWFjaCBwZWVyIHRvIG1hbmFnZSB0aGUgc2V0IG9mIFNQSXMgdXNlZCBmb3Ig aXRzIGluYm91bmQgdHJhZmZpYy4gDQpTaW1pbGFybHksIHRoZSBwcml2YWN5IGNvbmNlcm5zIGFz c29jaWF0ZWQgd2l0aCB0aGUgZ2VuZXJhdGlvbiBvZiBub25yYW5kb20gU1BJIGlzIGFsc28gbGlt aXRlZCB0byB0aGUgaW5jb21pbmcgdHJhZmZpYy48L3Q+DQoNCjx0PldoZW4gYWx0ZXJuYXRlIGRl c2lnbnMgYXJlIGNvbnNpZGVyZWQsIGl0IGlzIGxpa2VseSB0aGF0IHRoZSBudW1iZXIgb2YgcG9z c2libGUgU1BJcyB3aWxsIGJlIGxpbWl0ZWQuIA0KVGhpcyBsaW1pdCBzaG91bGQgYm90aCBjb25z aWRlciB0aGUgbnVtYmVyIG9mIGluYm91bmQgU0FzIC0gcG9zc2libHkgcGVyIElQIGFkZHJlc3Nl cyAtIGFzIHdlbGwgYXMgdGhlIGFiaWxpdHkgZm9yIHRoZSBub2RlIHRvIHJla2V5LiANClNQSSBj YW4gdHlwaWNhbGx5IGJlIHVzZWQgdG8gcHJvY2VlZCB0byBjbGVhbiBrZXkgdXBkYXRlIGFuZCB0 aGUgU1BJIHZhbHVlIG1heSBiZSB1c2VkIHRvIGluZGljYXRlIHdoaWNoIGtleSBpcyBiZWluZyB1 c2VkLiANClRoaXMgY2FuIHR5cGljYWxseSBiZSBpbXBsZW1lbnRlZCBieSBhIFNQSSBiZWluZyBl bmNvZGVkIHdpdGggdGhlIFNlY3VyaXR5IEFzc29jaWF0aW9uIERhdGFiYXNlIChTQUQpIGVudHJ5 IG9uIGEgc3Vic2V0IG9mIGJ5dGVzIChmb3IgZXhhbXBsZSAzIGJ5dGVzKSwgd2hpbGUgdGhlIHJl bWFpbmluZyBieXRlIGlzIGxlZnQgdG8gaW5kaWNhdGUgdGhlIHJla2V5IGluZGV4LiANCjwvdD4N Cg0KDQo8dD5UaGUgdXNlIG9mIGEgc21hbGxlciBudW1iZXIgb2YgU1BJcyBhY3Jvc3MgY29tbXVu aWNhdGlvbnMgY29tZXMgd2l0aCBwcml2YWN5IGFuZCBzZWN1cml0eSBjb25jZXJucy4NClR5cGlj YWxseSBzb21lIHNwZWNpZmljIHZhbHVlcyBvciBzdWJzZXQgb2YgU1BJIHZhbHVlcyBtYXkgcmV2 ZWFsIHRoZSBtb2RlbHMgb3IgbWFudWZhY3R1cmVyIG9mIHRoZSBub2RlIGltcGxlbWVudGluZyBF U1AuIA0KVGhpcyBtYXkgcmFpc2Ugc29tZSBwcml2YWN5IGlzc3VlcyBhcyBhbiBvYnNlcnZlciBp cyBsaWtlbHkgdG8gYmUgYWJsZSB0byBkZXRlcm1pbmUgdGhlIGNvbnN0cmFpbmVkIGRldmljZXMg b2YgdGhlIG5ldHdvcmsuIA0KSW4gc29tZSBjYXNlcywgdGhlc2Ugbm9kZXMgbWF5IGhvc3QgYSB2 ZXJ5IGxpbWl0ZWQgbnVtYmVyIG9mIGFwcGxpY2F0aW9ucyAtIHR5cGljYWxseSBhIHNpbmdsZSBh cHBsaWNhdGlvbiAtIGluIHdoaWNoIGNhc2UgdGhlIFNQSSB3b3VsZCBwcm92aWRlIHNvbWUgaW5m b3JtYXRpb24gcmVsYXRlZCB0byB0aGUgYXBwbGljYXRpb24gb2YgdGhlIHVzZXIuIA0KSW4gYWRk aXRpb24sIHRoZSBkZXZpY2Ugb3IgYXBwbGljYXRpb24gbWF5IGJlIGFzc29jaWF0ZWQgd2l0aCBz b21lIHZ1bG5lcmFiaWxpdGllcywgaW4gd2hpY2ggY2FzZSBzcGVjaWZpYyBTUEkgdmFsdWVzIG1h eSBiZSB1c2VkIGJ5IGFuIGF0dGFja2VyIHRvIGRpc2NvdmVyIHZ1bG5lcmFiaWxpdGllcy4gDQo8 L3Q+DQoNCjx0Pg0KV2hpbGUgdGhlIHVzZSBvZiByYW5kb21seSBnZW5lcmF0ZWQgU1BJIG1heSBy ZWR1Y2UgdGhlIGxlYWthZ2Ugb3IgcHJpdmFjeSBvciBzZWN1cml0eSByZWxhdGVkIGluZm9ybWF0 aW9uIGJ5IEVTUCBpdHNlbGYsIHRoZXNlIGluZm9ybWF0aW9uIG1heSBhbHNvIGJlIGxlYWtlZCBv dGhlcndpc2UgYW5kIGEgcHJpdmFjeSBhbmFseXNpcyBzaG91bGQgY29uc2lkZXIgYXQgbGVhc3Qg dGhlIHR5cGUgb2YgaW5mb3JtYXRpb24gYXMgd2VsbCB0aGUgdHJhZmZpYyBwYXR0ZXJuLiANClR5 cGljYWxseSwgdGVtcGVyYXR1cmUgc2Vuc29ycywgd2luZCBzZW5zb3JzLCB1c2VkIG91dGRvb3Jz IGRvIG5vdCBsZWFrIHByaXZhY3kgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGFuZCBtb3N0eSBvZiBp dHMgdHJhZmZpYyBpcyBleHBlY3RlZCB0byBiZSBvdXRib3VuZCB0cmFmZmljLiANCldoZW4gdXNl ZCBpbmRvb3JzLCBhIHNlbnNvciB0aGF0IHJlcG9ydHMgZXZlcnkgbWludXRlIGFuIGVuY3J5cHRl ZCBzdGF0dXMgb2YgdGhlIGRvb3IgKGNsb3NlZCBvciBvcGVuZWQpIGxlYWtzIHRydWx5IGxpdHRs ZSBwcml2YWN5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBvdXRzaWRlIHRoZSBsb2NhbCBuZXR3b3Jr LiA8L3Q+DQoNCg0KDQo8L3NlY3Rpb24+DQo8L21nbHQ+DQoNCihTZWN0aW9uIDQpIEFtIEkgdW5k ZXJzdGFuZGluZyBjb3JyZWN0bHksIHRoYXQgdGhlIGxhc3QgcGFyYWdyYXBoIGlzIGdpdmluZyB0 aGUgb3B0aW9uIG9mIHJlc2V0dGluZyB0aGUgU2VxdWVuY2UgTnVtYmVyIHdoZW4gcmVrZXlpbmc/ IERvZXMgSVBTZWMgdHJ5IHRvIHByZXZlbnQgZWF2ZXNkcm9wcGVycyBmcm9tIGRldGVybWluaW5n IHdoZW4gcmVrZXlpbmcgaGFwcGVucz8gKEkgcmVhbGx5IGRvbid0IGtub3cgdGhhdCBtdWNoIGFi b3V0IElQU2VjLikgSWYgaXQgZG9lcywgdGhlbiByZXNldHRpbmcgdGhlIFNOIGNvdWxkIGxlYWsg dGhhdCBpbmZvcm1hdGlvbiwgaWYgbm90IHRoZW4gdGhlcmUncyBub3RoaW5nIHRvIGxlYWsuDQoN CjxtZ2x0Pg0KTm8uIFRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBzZWN0aW9uIGludGVuZGVkIHRv IHByZXZlbnQgaW1wbGVtZW50ZXJzIHRvIG9ubHkgY29uc2lkZXIgdGhlIFNOIHRvIGRlZmluZSB0 aGUgbGlmZSB0aW1lIG9mIHRoZWlyIFNBLiBJZiBpbXBsZW1lbnRlciBjaG9vc2UgdG8gdXNlIEVT TiBmb3IgdGhhdCBwdXJwb3NlLCBpdCBtaWdodCBiZSBhIGdvb2QgaW5kaWNhdGlvbiB0aGF0IGEg cmUta2V5IG1lY2hhbmlzbSBpcyBuZWVkZWQuIA0KDQpUaGUgY3VycmVudCB0ZXh0IGhhcyBiZWVu IHVwZGF0ZWQgdG8gY2xhcmlmeSB0aGlzIGJ5IHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KIiIiDQpO b3RlIHRoYXQgdGhlIGxpbWl0IG9mIG1lc3NhZ2VzIGJlaW5nIHNlbnQgaXMgcHJpbWFyaWx5IGRl dGVybWluZWQgYnkgdGhlIHNlY3VyaXR5IGFzc29jaWF0ZWQgd2l0aCB0aGUga2V5IHJhdGhlciB0 aGFuIHRoZSBTTi4NClRoZSBzZWN1cml0eSBvZiBhbGwgZGF0YSBwcm90ZWN0ZWQgdW5kZXIgYSBn aXZlbiBrZXkgZGVjcmVhc2VzIHNsaWdodGx5IHdpdGggZWFjaCBtZXNzYWdlIGFuZCBhIG5vZGUg TVVTVCBlbnN1cmUgdGhlIGxpbWl0IGlzIG5vdCByZWFjaGVkIC0gZXZlbiB0aG91Z2ggdGhlIFNO IHdvdWxkIHBlcm1pdCBpdC4gDQpFc3RpbWF0aW9uIG9mIHRoZSBtYXhpbXVtIG51bWJlciBvZiBw YWNrZXRzIHRvIGJlIHNlbnQgYnkgYSBub2RlIGlzIGFsd2F5cyBjaGFsbGVuZ2luZyBhbmQgYXMg c3VjaCBzaG91bGQgYmUgY29uc2lkZXJlZCBjYXV0aW91c2x5IGFzIG5vZGVzIGNvdWxkIGJlIG9u bGluZSBmb3IgbXVjaCBtb3JlIHRpbWUgdGhhbiBleHBlY3RlZC4gDQpFdmVuIGZvciBjb25zdHJh aW5lZCBkZXZpY2VzLCBpdCBpcyBSRUNPTU1FTkRFRCB0byBpbXBsZW1lbnQgc29tZSByZWtleSBt ZWNoYW5pc21zIChzZWUgPHhyZWYgdGFyZ2V0PSJzZWMtc2VjdXJpdHktY29uc2lkZXJhdGlvbnMi Lz4pLg0KIiIiIA0KDQpSZWdhcmRpbmcgSVBzZWMsIGEgcmVrZXkgbGVhZHMgdG8gdGhlIGNyZWF0 aW9uIG9mIGEgbmV3IFNBLCBzbyBpZiB5b3UgZG8gbm90IHdhbnQgdG8gbGVhayB0aGUgaW5mb3Jt YXRpb24geW91IG1heSBjcmVhdGUgdGhlIG5ldyBTQSBpbiBhZHZhbmNlIGFuZCBvbmx5IHVzZSBp dCBsYXRlci4gSG93ZXZlciwgdGhlIGNyZWF0aW9uIGlzIHBlcmZvcm1lZCB2aWEgYW4gSUtFdjIg ZXhjaGFuZ2Ugd2hpY2ggaXMgbm90IGEgdmVyeSBidXN5IGNoYW5uZWwuIEFzIGEgcmVzdWx0LCBl eGNoYW5nZXMgcGVyZm9ybWVkIG9uIHRoaXMgY2hhbm5lbCBhcmUgcG90ZW50aWFsIHJla2V5IGV4 Y2hhbmdlcy4gQXMgcmVzdWx0LCBpdCBzZWVtcyB0byBtZSBhIGJpdCBoYXJkIHRvIGhpZGUgd2hl biBhIHJla2V5IG9jY3Vycy4gDQpTTiBkbyBub3QgaGF2ZSB0byBiZSByZXNldCB0byAwLiBUaGUg b25seSByZXF1aXJlbWVudCBpcyB0byBpbmNyZWFzZSB0aGVzZSBTTiBmb3IgZWFjaCBwYWNrZXQu IE9uIHRoZSBvdGhlciBoYW5kLCB0aGlzIG1ha2UgaXQgcG9zc2libGUgdG8gbWFpbnRhaW4gdGhl IFNOIG51bWJlciBrZWVwIGdyb3dpbmcgd2hpbGUgU1BJIGFuZCBrZXlzIGFyZSB1cGRhdGVkLi4u IHVudGlsIHlvdSByZWFjaCB0aGUgZW5kLiANCg0KSWYgeW91IG5lZWQgdG8ga2VlcCB0aGUgc2Ft ZSBTUEksIHlvdSBtYXkgZGVsZXRlIHRoZSBTQSBmaXJzdCBiZWZvcmUgc3RhcnRpbmcgYSBuZXcg bmVnb3RpYXRpb24sIHRoaXMgd291bGQgZW5hYmxlIHlvdSB0byByZS11c2UgdGhlIHNhbWUgU1BJ LiAgIA0KPC9tZ2x0Pg0K From nobody Wed Mar 31 10:05:09 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E483A2EBD; Wed, 31 Mar 2021 09:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1617209986; bh=S5HDXxHECUQH9LHIx4r7eVJ95eJhALGQQepmwPi4ntk=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=ju6FvdudTdiz7eTMPo6z+TF3iYbUo89qLfX1ICrY5sAqV0TMKr1nDEr6PcPunfN4q ITtocnXAQQXEhDHZAhNYfBlYAkG5NvwsNLqEnESXhEV555Mf3js9eQ/jOVks6KXJ97 RFKblgek/Gv9/9AFufb2RmhyMZoQFQ1z+RhokZZQ= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Mar 31 09:59:40 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2293A2EC6; Wed, 31 Mar 2021 09:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1617209979; bh=S5HDXxHECUQH9LHIx4r7eVJ95eJhALGQQepmwPi4ntk=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=m026i9ejbBGkzB19SQnlGsPIFin81d3+9Y1dmHtm3wflkrPTFhwI3Uue5n1NX4fkE r8mzMiBhZxjTaheQu5/Gy4DoZEqFGGqiT3GjPc1k9+G/KbeHwpXH2sxvUznenRs4xI FirktUG/3Wz3qhm4C0NfLBwx1mIixnPqHt00Ayz0= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAF23A2E7C for ; Wed, 31 Mar 2021 09:59:33 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <161720997334.20161.14107897009860058549@ietfa.amsl.com> Date: Wed, 31 Mar 2021 09:59:33 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 31 Mar 2021 10:05:08 -0700 Subject: [secdir] [new-work] WG Review: CBOR Object Signing and Encryption (cose) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 16:59:52 -0000 The CBOR Object Signing and Encryption (cose) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-04-07. CBOR Object Signing and Encryption (cose) ----------------------------------------------------------------------- Current status: Active WG Chairs: Matthew Miller Ivaylo Petrov Mike Jones Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: cose@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/cose Archive: https://mailarchive.ietf.org/arch/browse/cose/ Group page: https://datatracker.ietf.org/group/cose/ Charter: https://datatracker.ietf.org/doc/charter-ietf-cose/ CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to create and process signatures, message authentication codes, and encryption using Concise Binary Object Representation (CBOR, RFC 7049) for serialization. COSE additionally describes a representation for cryptographic keys. COSE has been picked up and is being used both by a number of groups within the IETF (i.e., ACE, CORE, ANIMA, 6TiSCH and SUIT) and outside the IETF (i.e., W3C and FIDO). There are a number of implementations, both open source and private, now in existence. The specification has advanced to STD status. The COSE working group will deal with two types of documents going forward: 1. Documents that describe the use of cryptographic algorithms in COSE. 2. Documents which describe additional attributes for COSE. The WG will evaluate, and potentially adopt, documents dealing with algorithms that would fit the criteria of being IETF consensus algorithms. Potential candidates would include those algorithms that have been evaluated by the CFRG and algorithms which have gone through a public review and evaluation process such as was done for the NIST SHA-3 algorithms. Potential candidate would not include national-standards-based algorithms that have not gone through a similar public review process. The WG will produce documents for new attributes only if they are in the list of deliverables below. A re-charter will be required to expand that list. The WG is expected as part of normal processing to review and comment on attributes that are not in charter but are of general public interest. Key management and binding of keys to identities are out of scope for the working group. The COSE WG will not innovate in terms of cryptography. The specification of algorithms in COSE is limited to those in RFCs, active CFRG or IETF WG documents, or algorithms which have been positively reviewed by the CFRG. The working group will coordinate its progress with the ACE, SUIT and CORE working groups to ensure that it is fulfilling the needs of these constituencies to the extent relevant to their work. Other groups may be added to this list as the set of use cases is expanded, in consultation with the responsible Area Director. The WG currently has two work items: 1. One or more documents describing the proper use of algorithms. These algorithms must meet the requirements outlined above. 2. A CBOR encoding of the certificate profile defined in RFC 5280. It is expected that the encoding works with RFC 7925 and takes into consideration any updates in draft-ietf-uta-tls13-iot-profile-00. The encoding may also include other important IoT certificate profiles like IEEE 802.1AR. The main objective is to define a method of encoding current X.509 certificates that meet a specific profile into a smaller format. This encoding is invertible, so they can be expanded and normal X.509 certificate processing can be used. The data structures used for such encoding of X.509 certificates are expected to produce a compact encoding for certificate information, and are not necessarily tied specifically to X.509 certificates. Accordingly, a secondary objective is to reuse these data structures to produce a natively signed CBOR certificate encoding; such a structure is relevant in situations where DER parsing and the machinery to convert between CBOR and DER encodings are unnecessary overhead, such as embedded implementations. The possibility of a joint certificate artifact, conveyed in CBOR encoding but including signatures over both the CBOR and DER encodings, may be explored. CBOR encoding of other X.509 certificate related data structures may also be specified to support relevant functions such as revocation: Certificate Revocation List (RFC 5280) or OSCP Request/Response (RFC 6960); or certificate enrollment: Certificate Signing Request (RFC 2986). draft-mattsson-cose-cbor-cert-compress is expected to be a good starting point for this work. The working group will collaborate and coordinate with other IETF WGs such as TLS, UTA, LAKE to understand and validate the requirements and solution. Milestones: Jun 2021 - Adopt draft for compressed certificate encoding as a Working Group item Dec 2021 - Submit draft for compressed certificate encoding to the IESG for publication _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Mar 31 19:18:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B40B3A0E67 for ; Wed, 31 Mar 2021 19:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 Ok7gnrayhotm for ; Wed, 31 Mar 2021 19:17:52 -0700 (PDT) Received: from mail-qt1-x863.google.com (mail-qt1-x863.google.com [IPv6:2607:f8b0:4864:20::863]) (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 3F2FD3A0E6A for ; Wed, 31 Mar 2021 19:17:52 -0700 (PDT) Received: by mail-qt1-x863.google.com with SMTP id j7so491477qtx.5 for ; Wed, 31 Mar 2021 19:17:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:subject:to:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=tMxLR7NYhfXDxuZEVGj153ZKGkhssDbYAm77VUdJl54=; b=RckqwCUugnqvweHHzTJuTwsg8WCKewWJQCYqTcmtO5nv9ZODze7L4i+FehDme68fO3 fzX0c3xBR8x1taI7Dga7olnkaWHF2VN0nqC+EP+QgbDRGTi+ngsWG1IZCZMRljmPSrcj /lxpG1/8IZuQikQfWDomrjLfAxgUJBOqjPJwc9RjxgWL9qczmbpPiqtlcTpw5gpemEbp MSIJO4FogyRnxXyO8Yv5YcDlX8S8I5fFj+LoDnYDYF/Z7QT2xwTujVTurH9mCq/XZPiL iLu4eM+JWju+Fpr0z4ryur9wFFmDtnTeraCmQl+LIrdDP1RxMijWXkIWRuQOsRrgfCpN YC6Q== X-Gm-Message-State: AOAM532H+YlTkivqYNu+J1F/NZw14zdq3DMW3nHWuK0beEgv9aKRhKaF gpsQGkWLLIFozzE0oHvHdImcI/tYTNV/63BLt53z1RqUoilo6g== X-Google-Smtp-Source: ABdhPJwo35AinhX9ENdcyT+h6lWJPa2TiEGsPo+gtZVZhm2vHmdeArJJIHLv5PawOA9NgcLEg++kWHmy9+CV X-Received: by 2002:ac8:4e0a:: with SMTP id c10mr5313544qtw.381.1617243470275; Wed, 31 Mar 2021 19:17:50 -0700 (PDT) Received: from uriel.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id s188sm1408895qke.7.2021.03.31.19.17.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Mar 2021 19:17:50 -0700 (PDT) X-Relaying-Domain: mandelberg.org Received: from [10.0.2.211] (sakaar.virgo.mandelberg.org [10.0.2.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id E3D2D1C6031; Wed, 31 Mar 2021 22:17:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202103; t=1617243468; bh=LVSOtw2Mz2iefnGFEdGo+xcasQQhc3zmxZX9uTZ4gRM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=InmQc1ZV/SIchGVL8Kvx1cKcNieDJvMynWGIn+Tvc8yvyEwpT32FlV7pW6Cl8g68R TD5Gkups8pnsOken32syE2M4IVCXn5Y4CCU8JjftRIFZzNsdA/GQiZ8zoUZN7nHq0c T5ll52bZgft76XotLkxAJCAvpxHVEfHtgpauZu9hP0yH6+tlMvQ8OkbsljeAQLHqjs 3QePosBxhdyVUD1i16kP2jyeHSM9INpcLQlIrotqdMiNdBLsq1l8Me66L7mn75S/u3 PyTG09OKI0j75AMuTan7z1nscwsUeLgvOXqMFCQdP5Hz244OV3PFBSYIelJGHzVOWR 4l8a6z5ywjQcg== To: Daniel Migault , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-lwig-minimal-esp.all@ietf.org" , IPsecME WG , "lwip@ietf.org" References: <91f5ebd2-b24f-ca04-eba0-60d0c9b6f401@mandelberg.org> From: David Mandelberg Message-ID: <884762c0-f356-c07a-0334-e52c24633dcd@mandelberg.org> Date: Wed, 31 Mar 2021 22:17:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-lwig-minimal-esp-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 02:17:58 -0000 Thanks for the updates and clarification! Op 31-03-2021 om 08:46 schreef Daniel Migault: > Hi David, > > Thanks the review. I think the text in [1] addresses your concern. I will probably publish the a new version today. Please see my responses inline. > > Yours, > Daniel > > [1] https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89 > > -----Original Message----- > From: David Mandelberg > Sent: Saturday, March 27, 2021 5:39 PM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-lwig-minimal-esp.all@ietf.org > Subject: secdir review of draft-ietf-lwig-minimal-esp-03 > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > The summary of the review is Ready with nits. > > (Section 3, nit) In the paragraph that includes "However, nonrandom SPI and restricting their possible values MAY lead to privacy and security concerns" , it would be nice to add something like "(see below for more details)". When I first read that paragraph, I was about to comment that it's unclear what the privacy/security concerns are, but then it was explained a few paragraphs below. > > > That is correct, we restructured a bit the section to clarify this by having a subsection dedicated to considerations over the generation of SPIs. > > The current section is available at [1] and is mentioned below: > [1] https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89 > >
> > SPI that are not randomly generated over 32 bits MAY lead to privacy and security concerns. > As a result, the use of alternative designs requires careful security and privacy reviews. > This section provides some considerations upon the adoption of alternative designs. > > Note that SPI value is used only for inbound traffic, as such the SPI negotiated with IKEv2 or by a peer, is the value used by the remote peer when it sends traffic. > As SPI is only used for inbound traffic by the peer, this allows each peer to manage the set of SPIs used for its inbound traffic. > Similarly, the privacy concerns associated with the generation of nonrandom SPI is also limited to the incoming traffic. > > When alternate designs are considered, it is likely that the number of possible SPIs will be limited. > This limit should both consider the number of inbound SAs - possibly per IP addresses - as well as the ability for the node to rekey. > SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. > This can typically be implemented by a SPI being encoded with the Security Association Database (SAD) entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. > > > > The use of a smaller number of SPIs across communications comes with privacy and security concerns. > Typically some specific values or subset of SPI values may reveal the models or manufacturer of the node implementing ESP. > This may raise some privacy issues as an observer is likely to be able to determine the constrained devices of the network. > In some cases, these nodes may host a very limited number of applications - typically a single application - in which case the SPI would provide some information related to the application of the user. > In addition, the device or application may be associated with some vulnerabilities, in which case specific SPI values may be used by an attacker to discover vulnerabilities. > > > > While the use of randomly generated SPI may reduce the leakage or privacy or security related information by ESP itself, these information may also be leaked otherwise and a privacy analysis should consider at least the type of information as well the traffic pattern. > Typically, temperature sensors, wind sensors, used outdoors do not leak privacy sensitive information and mosty of its traffic is expected to be outbound traffic. > When used indoors, a sensor that reports every minute an encrypted status of the door (closed or opened) leaks truly little privacy sensitive information outside the local network. > > > >
> > > (Section 4) Am I understanding correctly, that the last paragraph is giving the option of resetting the Sequence Number when rekeying? Does IPSec try to prevent eavesdroppers from determining when rekeying happens? (I really don't know that much about IPSec.) If it does, then resetting the SN could leak that information, if not then there's nothing to leak. > > > No. The last sentence of the section intended to prevent implementers to only consider the SN to define the life time of their SA. If implementer choose to use ESN for that purpose, it might be a good indication that a re-key mechanism is needed. > > The current text has been updated to clarify this by the following text: > > """ > Note that the limit of messages being sent is primarily determined by the security associated with the key rather than the SN. > The security of all data protected under a given key decreases slightly with each message and a node MUST ensure the limit is not reached - even though the SN would permit it. > Estimation of the maximum number of packets to be sent by a node is always challenging and as such should be considered cautiously as nodes could be online for much more time than expected. > Even for constrained devices, it is RECOMMENDED to implement some rekey mechanisms (see ). > """ > > Regarding IPsec, a rekey leads to the creation of a new SA, so if you do not want to leak the information you may create the new SA in advance and only use it later. However, the creation is performed via an IKEv2 exchange which is not a very busy channel. As a result, exchanges performed on this channel are potential rekey exchanges. As result, it seems to me a bit hard to hide when a rekey occurs. > SN do not have to be reset to 0. The only requirement is to increase these SN for each packet. On the other hand, this make it possible to maintain the SN number keep growing while SPI and keys are updated... until you reach the end. > > If you need to keep the same SPI, you may delete the SA first before starting a new negotiation, this would enable you to re-use the same SPI. > >