From nobody Sun Feb 7 15:14:31 2021 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB1D3A144A for ; Sun, 7 Feb 2021 15:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_SOFTFAIL=0.665, 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 SKSNvFZD58Lj for ; Sun, 7 Feb 2021 15:14:24 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DC03A1448 for ; Sun, 7 Feb 2021 15:14:23 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:a004:7954:2662:6313] (unknown [IPv6:2a02:8109:1140:c3d:a004:7954:2662:6313]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8DEFD72246344; Mon, 8 Feb 2021 00:14:18 +0100 (CET) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_51E736DD-D41F-4AA7-A5EF-18B92B513CD9"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 8 Feb 2021 00:14:16 +0100 In-Reply-To: <0D02994D-0295-4327-A834-B4369676CE2A@fh-muenster.de> Cc: "tsvwg@ietf.org" To: =?utf-8?Q?Timo_V=C3=B6lker?= References: <0D02994D-0295-4327-A834-B4369676CE2A@fh-muenster.de> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-rfc4960-bis-08 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 23:14:29 -0000 --Apple-Mail=_51E736DD-D41F-4AA7-A5EF-18B92B513CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Timo, thank you very much for the detailed review. See my comments in-line. Best regards Michael > On 31. Dec 2020, at 11:02, Timo V=C3=B6lker = wrote: >=20 > Hi, >=20 > Here is my review for the RFC4960bis draft = (draft-ietf-tsvwg-rfc4960-bis-08). >=20 > My list starts with minor issues (typos, etc.) followed by comments = about some terms. >=20 >=20 > *Typos, Wording* >=20 > Section 3.1 >=20 > Verification Tag: > OLD: The receiver of this packet uses the Verification Tag to validate = the sender of this SCTP packet. On transmit, the value of this = Verification Tag MUST be set to... > NEW: The receiver of an SCTP packet uses the Verification Tag to = validate the sender of this packet. On transmit, the value of the = Verification Tag MUST be set to... Fixed. >=20 > Checksum: > OLD: This field contains the checksum of this SCTP packet. > NEW: This field contains the checksum of the SCTP packet. Fixed. >=20 >=20 > Section 3.2 >=20 > Chunk Type encoding > OLD: ...and report the unrecognized chunk in an 'Unrecognized Chunk = Type'. > NEW: ...and report the unrecognized chunk in an ERROR chunk using the = 'Unrecognized Chunk Type' cause of error. Fixed by using and report the unrecognized chunk in an ERROR chunk using the = 'Unrecognized Chunk Type' error cause. This is consistent with other places in the text. Also fixed the other = similar text in the same table. >=20 > Text about padding in a chunk repeats. First described in the = description for Chunk Length field and then directly below the = description of the chunk fields. I suggest to remove it in the = description of the Chunk Length field, but to keep the relevant part for = the field. > OLD: The Chunk Length field does not count any chunk padding. Chunks = (including Type, Length, and Value fields) are padded... > NEW: The value in the Chunk Length field does not include any chunk = padding. However, it does include padding of any variable-length = parameter except the last parameter in the chunk. Fixed. >=20 >=20 > Section 3.2.1 >=20 > Start the enumeration with the word Parameter. > OLD: The total length of a parameter (including Type, Parameter = Length, and Value fields)... > NEW: The total length of a parameter (including Parameter Type, = Length, and Value fields)... Changed to using Parameter for all three. >=20 > The text about Parameters begins like any chunk may include = parameters. If this generic form was used by intention, I suggest to = rewrite the part below Table 3, which refers to specific chunks. > OLD: Please note that in all four cases, an INIT ACK or COOKIE ECHO = chunk is sent. > NEW: Please note that, when an INIT or INIT ACK chunk is received, in = all four cases, an INIT ACK or COOKIE ECHO chunk is sent in response, = respectively. Fixed. >=20 > This continues in Section 3.2.2. > OLD: If the receiver of an INIT ACK chunk detects unrecognized = parameters and has to report them according to Section 3.2.1, it SHOULD = bundle the ERROR chunk containing the 'Unrecognized Parameters' error = cause with the COOKIE ECHO chunk sent in response to the INIT ACK chunk. > NEW: If the receiver of any other chunk (e.g., INIT ACK) detects = unrecognized parameters and has to report them according to Section = 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized = Parameters' error cause with a chunk sent in response (e.g., COOKIE = ECHO). Fixed. >=20 >=20 > Section 3.3.2 >=20 > Table 5 and 6 lists all specified parameters for the INIT chunk, = including the Host Name Address parameter. The text before the tables = "The INIT chunk contains the following parameters" does not match to the = text after the tables "An INIT chunk MUST NOT contain the Host Name = Address parameter". > OLD: The INIT chunk contains the following parameters. > NEW: The following parameters are specified for the INIT chunk. > OLD: Host Name Address Optional 11 > NEW: Host Name Address Deprecated 11 Fixed. >=20 > I find the text about known parameters that are not optional = parameters difficult to understand, since based on the tables, I assumed = not optional means mandatory. > OLD: If an INIT chunk is received with known parameters that are not = optional parameters of the INIT chunk, > NEW: If an INIT chunk is received with parameters that are specified = for the INIT chunk, Changed to If an INIT chunk is received with all mandatory parameters that are specified for the INIT chunk, then the receiver SHOULD process the INIT = chunk and send back an INIT ACK. >=20 >=20 > Section 3.3.3 >=20 > It seems like the position of tables 7 and 8 should be directly after = this paragraph "The parameter part of INIT ACK is formatted similarly to = the INIT chunk. It uses two extra variable parameters: The State Cookie = and the Unrecognized Parameter." Cleaned up to be consistent with the description of the INIT chunk. >=20 > The description for the Advertised Receiver Window Credit in the INIT = chunk contains an additional half sentence. > OLD: ...SHOULD NOT be lessened (i.e., dedicated buffers taken away = from this association). > NEW: ...SHOULD NOT be lessened (i.e., dedicated buffers taken away = from this association); however, an endpoint MAY change the value of = a_rwnd it sends in SACK chunks. Fixed. >=20 > Similar to my suggestion for the Section 3.3.2 > OLD: If an INIT ACK chunk is received with known parameters that are = not optional parameters of the INIT ACK chunk, > NEW: If an INIT ACK chunk is received with parameters that are not = specified for the INIT ACK chunk, Changed to: If an INIT ACK chunk is received with all mandatory parameters that are specified for the INIT ACK chunk, then the receiver SHOULD process the INIT ACK chunk and send back a COOKIE ECHO chunk. >=20 >=20 > Section 3.3.3.1.2 >=20 > Type seems to me the better word here. > OLD: ...an unrecognized parameter that has a value that indicates it = SHOULD be reported to the sender. > NEW: ...an unrecognized parameter that has a type that indicates it = SHOULD be reported to the sender. Fixed. >=20 >=20 > Section 3.3.7 >=20 > OLD: ...but they MUST be placed before the ABORT in the SCTP packet or = they will be ignored by the receiver. > NEW: ...but they MUST be placed before the ABORT in the SCTP packet, = otherwise they will be ignored by the receiver. Fixed. >=20 >=20 > Section 4 >=20 > State Diagram > * Use send and start, instead of snd and strt. Fixed > * Add a space after "(B)", "(C)" and "(D)" Fixed > * There is an arrowhead missing on the line between SHUTDOWN-RECEIVED = and SHUTDOWN-ACK-SENT. Fixed > * The position of "(B)rcv SHUTDOWN" looks like it belongs to the arrow = that is pointing to CLOSED. Fixed >=20 >=20 > Section 5.1.6 >=20 > In Figure 4 > OLD: DATA [TSN=3Dinitial TSN_A > NEW: DATA [TSN=3Dinit TSN_A > OLD: DATA [TSN=3Dinit TSN_Z > NEW: DATA [TSN=3Dinit TSN_Z, Fixed. >=20 >=20 > Section 6.4 >=20 > Remove space. > OLD: When a receiver of a duplicate DATA chunk sends a SACK to a = multi- homed endpoint... > NEW: When a receiver of a duplicate DATA chunk sends a SACK to a = multi-homed endpoint... Fixed. >=20 >=20 > Section 6.7 >=20 > The text reads like the sender should treat all data chunks not = acknowledged in an SACK as missing. I assume the highest acknowledged = TSN should take into account (as Section 7.2.4 describes). > OLD: All DATA chunks with TSNs not included in the Gap Ack Blocks = reported by a SACK MUST be treated as "missing" by the sending endpoint. > NEW: All DATA chunks with TSNs not included in the Gap Ack Blocks = which are smaller than the highest acknowledged TSN reported by a SACK = MUST be treated as "missing" by the sending endpoint. Fixed. >=20 >=20 > Section 8.4 >=20 > It seems an "Otherwise" is missing and a "process" should be removed. > OLD: 3) ..., indicating that the Verification Tag is not reflected. > NEW: 3) ..., indicating that the Verification Tag is not reflected. = Otherwise, Fixed. > OLD: 4) If the packet contains a COOKIE ECHO in the first chunk, = process it MUST be processed as described in Section 5.1. > NEW: 4) If the packet contains a COOKIE ECHO in the first chunk, it = MUST be processed as described in Section 5.1. Fixed. >=20 >=20 > Section 11 >=20 > Typo > OLD: However, all SCTPs aer expected to provide a... > NEW: However, all SCTPs are expected to provide a... Fixed. >=20 >=20 > Section 11.1.10 >=20 > OLD: 11.1.10. Request HeartBeat > NEW: 11.1.10. Request HeartBeat > OLD: Instructs the local endpoint to perform a HeartBeat on the... > NEW: Instructs the local endpoint to perform a heartbeat on the... Fixed. >=20 >=20 > Section 11.1.14 >=20 > Typo > OLD: payload protocol-id: The 32 bit unsigned integer that was sent to = be sent to the peer... > NEW: payload protocol-id: The 32 bit unsigned integer that was set to = be sent to the peer... Fixed. >=20 >=20 > Section 14.2 >=20 > Remove space. > OLD: Mapping Array: An array of bits or bytes indicating which out-of- = order TSNs have been received (relative to the Last Rcvd TSN). If no = gaps exist, i.e., no out-of- order packets... > NEW: Mapping Array: An array of bits or bytes indicating which = out-of-order TSNs have been received (relative to the Last Rcvd TSN). If = no gaps exist, i.e., no out-of-order packets... Fixed. >=20 >=20 > *Terms, Comprehension* >=20 > Far End > Only Section 2.5.7 and 9.2 use the term "far end". I assume it is a = synonym to, for example, the term "peer endpoint". If so, I suggest to = use "peer end" or "peer endpoint" in these sections as well. Replaced by peer endpoint. >=20 > RECEIVE_UNSENT, RECEIVE_UNACKED > I do not understand what a RECEIVE_UNSENT and RECEIVE_UNACKED (Section = 11.1.14 and 11.1.15) is used for. A sentence before listening the = attributes would be helpful. Added for RECEIVE_UNSENT: This primitive reads a user message, which has never been sent, into the buffer specified by ULP. Added for RECEIVE_UNACKED: This primitive reads a user message, which has been sent and has not = been acknowledged by the peer, into the buffer specified by ULP. >=20 > Protection of Non-SCTP-Capable Hosts > I might misunderstand Section 12.4, but for me it seems all paragraphs = except the first one are not about protecting Non-SCTP-Capable Hosts. = Does the last three paragraph belong to a Section 12.5, which title is = missing? No, the methods are intended to protect hosts, which do not support = SCTP. This text was already in RFC 4960. We can chat about the attacks... >=20 > Chunk Bundling Option > If I disable an option called chunk bundling, I would assume that SCTP = does not bundle chunks at all. Section 2.5.5 describes that chunks are = still bundled. Also, I guess this only applies to DATA chunks. A name = like "Delay for DATA Chunk Bundling" would make it clearer. (Section = 11.1.5 describes the no-bundle flag, which refers to that option). I made the description clearer:
no-bundle flag:
instructs SCTP not to delay the sending of DATA chunks for this = user data just to allow it to be bundled with other outbound DATA chunks. When faced with network congestion, SCTP might still bundle the data, = even when this flag is present.
> MTU > For me, MTU describes the maximum size of an IP packet. Often, this = document uses MTU as the maximum size of an SCTP packet. As the maximum = size of an SCTP packet is not always the MTU minus IP header, why not = using an own term? For example, Maximum SCTP Packet Size (MSPS). I = think, this would help to make the text clearer. > For example, Section 6.1 contains > "the sender SHOULD create a SACK and bundle it with the outbound DATA = chunk, as long as the size of the final SCTP packet does not exceed the = current MTU." > which seems wrong to me. I think replacing MTU with MSPS is the = simplest solution. I have replaced MTU with PMTU. The document uses the term PMTU now as = the maximum IP payload size, which is the maximum SCTP packet size, which can reach the peer without = IP-level fragmentation. >=20 > Timo --Apple-Mail=_51E736DD-D41F-4AA7-A5EF-18B92B513CD9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAy MDcyMzE0MTZaMC8GCSqGSIb3DQEJBDEiBCB5xX6hsaPSF3jO9U7TiyzdVr/ErzUYSEVImPqZq+iD EDCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAqpmVh3xGDsRSkzXo7HHqNI30aGlB yVJov2y2n2FI46508p+E7PmjskrKXDuK1gsRzb1pJtk8BoQAgU8ILZNl8h0XqHhuDLMmLmEfBNg3 ibnfMBwNhoQZqooSClVrA+fv2C38cb1cPJIkFYH7uD0rt813L6KrFb24BAFcvJz0L0eMG18vyyt6 QkSmv8cuwVCpkkcqNKvZd3sNttb2XmnJnEYZRROjMwtrEaVbF7xsFYpKPkQSvDxmv/SfZRwqC2uv YxOBqNDrsyt14AVvByiGZDzMou3vGeuvhrO+zQcmOZM8F6xLDUWdHyGrXtHGqz+jCvUKemr2CvIU r67E3BbqMwAAAAAAAA== --Apple-Mail=_51E736DD-D41F-4AA7-A5EF-18B92B513CD9--