From nobody Thu Feb 18 14:04:25 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 8A77B3A18F9 for ; Thu, 18 Feb 2021 14:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, 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 UpwdQFx1MXrY for ; Thu, 18 Feb 2021 14:04:19 -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 915DE3A18F8 for ; Thu, 18 Feb 2021 14:04:18 -0800 (PST) Received: from [IPv6:2a02:8109:1140:c3d:24:e8:6fea:b904] (unknown [IPv6:2a02:8109:1140:c3d:24:e8:6fea:b904]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id EB9547220B805; Thu, 18 Feb 2021 23:04:14 +0100 (CET) From: Michael Tuexen Message-Id: <843C5471-C391-42C0-BEBA-76D3F63B4023@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_B075FB7D-38FC-4708-8C86-81A2E6C097A9"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 18 Feb 2021 23:04:13 +0100 In-Reply-To: Cc: Gorry Fairhurst , "tsvwg@ietf.org" To: Michael Tuexen References: <0D02994D-0295-4327-A834-B4369676CE2A@fh-muenster.de> <4e316e54-e34f-34dc-bffe-ee969f047dc0@erg.abdn.ac.uk> 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: Thu, 18 Feb 2021 22:04:25 -0000 --Apple-Mail=_B075FB7D-38FC-4708-8C86-81A2E6C097A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8. Feb 2021, at 00:18, Michael Tuexen = wrote: >=20 >=20 >=20 >> On 31. Dec 2020, at 15:37, Gorry Fairhurst = wrote: >>=20 >> Thanks Timo for the review... >>=20 >> On 31/12/2020 10:02, Timo V=C3=B6lker wrote: >>> 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... >>>=20 >>> Checksum: >>> OLD: This field contains the checksum of this SCTP packet. >>> NEW: This field contains the checksum of the SCTP packet. >>>=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. >>>=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. >>>=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)... >>>=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. >>>=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). >>>=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 >>>=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, >>>=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." >>>=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. >>>=20 >>=20 >>=20 >> The word "lessened" seems a little odd in this context, since the = sentenced is already being changed, maybe we could replace this with "be = reduced" or similar? > Fixed. >>=20 >> and .. this: "(i.e., dedicated buffers taken away from this = association):" would seem much clearer as: >>=20 >> "(i.e., dedicated buffers ought not to be taken away from this = association);" >>=20 >>>=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, >>>=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. >>>=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. >>>=20 >>>=20 >>> Section 4 >>>=20 >>> State Diagram >>> * Use send and start, instead of snd and strt. >>> * Add a space after "(B)", "(C)" and "(D)" >>> * There is an arrowhead missing on the line between = SHUTDOWN-RECEIVED and SHUTDOWN-ACK-SENT. >>> * The position of "(B)rcv SHUTDOWN" looks like it belongs to the = arrow that is pointing to CLOSED. >>>=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, >>>=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... >>>=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. >>>=20 >> /which/that/ ? > 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, >>> 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. >>>=20 >>>=20 >>> Section 11 >>>=20 >>> Typo >>> OLD: However, all SCTPs aer expected to provide a... >>> NEW: However, all SCTPs are expected to provide a... >>>=20 >> AGain, in thr orriginal: /all SCTPs/ ... what does this refer to = /SCTP endpoints/ ? something else? > SCTP implementations. Fixed. >>>=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... >>>=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... >>>=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... >>>=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. >>>=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. >>>=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? >>>=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). >>>=20 >>> 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. >>>=20 >> Seems like the correct some rewording is needed... could it be PMTU? >>=20 >> That makes me also to suggest the editors take a look at the terms = /current MTU/, MTU, /path MTU/ and PMTU and ensure these are consistent. > The document now uses consistently only PMTU for path MTU and PMTU. >>=20 >> e.g.:, since you raise this (D) in 6.1 also mentions MTU for = controlling maxburst, is this MTU or PMTU in this case? >>=20 >> if ((flightsize + Max.Burst * MTU) < cwnd) >> cwnd =3D flightsize + Max.Burst * MTU; >>=20 >> And: >> /the current MTU/ - is that also /PMTU/ or maybe /current PMTU/?=20 > Fixed to use current PMTU. >>=20 >>=20 >> In 6.3.3, is this MTU or PMTU (if it's MTU, please say why): >>=20 >> / >> E1) For the destination address for which the timer expires, = adjust >> its ssthresh with rules defined in=20 >> Section 7.2.3 >> and set the >> cwnd <- MTU./ > Fixed. >>=20 >> - E.3 might also refer to /PMTU/ for consistency: >>=20 >> /subject to the MTU >> constraint for the path corresponding/ >> subject to the PMTU corresponding/ > Fixed. >>=20 >> Another example... >> OLD: >> / timer expired but did not fit in one MTU (rule E3 above) SHOULD be/ >> NEW: >> / timer expired, but did not fit in an SCTP packet smaller than the = PMTU (rule E3 above) SHOULD be/ > Fixed. >>=20 >> Note: the word /Path MTU/ and /PMTU/ are not used consistently, but I = think refer to the same. > Yes, they refer to the same. Now PMTU is used consistently. >=20 > The PMTU, when used in the context of packet sizes, describes now the = size maximum size > of the SCTP packet, which is the maximum size of the IP payload, which = can be sent to the > peer without needing IP level fragmentation. >=20 > However, the PMTU is also used in the context of CWND. I guess a term = of maximum chunk size > should be used there and it should be clarified that when sending a = DATA chunk, the chunk > length including the padding should be counted against the CWND. Will = discuss this with the > co-authors and report back. OK. The handling of PMTU in the context has been changed to the maximum = data chunks size and the computation of CWND is described more precisely. Best regards Michael >=20 > Then the usage of PMTU is precisely described. >=20 > Best regards > Michael >>=20 >>=20 >>> Timo >> Gorry >>=20 >=20 --Apple-Mail=_B075FB7D-38FC-4708-8C86-81A2E6C097A9 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 MTgyMjA0MTNaMC8GCSqGSIb3DQEJBDEiBCCYrscRh7RE0ZwQGU1ev+zpWpkLMk1/iBCypvIJna6p 7jCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAjp11odIzaaY5tMDLIhUy1WNjAX1I pwEqgSSZT1Z9EFCojG3HI/Vcah/vU+Qy/uRGEOP6qP73JkhTAAgSCS5Ir2fr4OmNOf70qwGOz0kb Pf7go2HmRDbBYrVkJO6Hqcm9GZ97tcXGoJ7RCBzmCwEBp3xTxkLz1CkpzVkPxiQPTVkYgQ7GetNS OaQK8rmMiR8z6c6z/3CMVLuRkG8DA3NGPqBw0HIcUmd7wipKXvmQh/bKCy7KheUWHbOzpKFcv9pb 23UTXxPWJHmjRN8ZtqC36kWo2a6P2+6VnGOUCpzr7+sRkvJKoEQEMmubHVGbJA4rk9E64qUPLkxb 0xL3SnXYpAAAAAAAAA== --Apple-Mail=_B075FB7D-38FC-4708-8C86-81A2E6C097A9--