Re: [CCAMP] 答复: Webex meeting changed: Optical impairments draft

[Dieter Beller <[e-mail]>]

Hi Gert, all,

there has been consensus to support the 3 options as currently defined 
in the YANG model (see 
https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang).

Stating that the organizational-mode option is under discussion is 
passing a wrong message to the CCAMP WG!

The situation is the following: there is rough consensus that the 
organizational-mode option is valuable and there is only one single 
person continuously disagreeing because of another
preference.


Thanks,
Sergio and Dieter


On 10.11.2020 11:09, Gert Grammel wrote:
>
> Hi Fatai,
>
> The group managed to find agreement on the Application code and the 
> explicit mode whereas Organizational codes are under discussion. In 
> essence, the question is whether non-standard organizations can define 
> their own codes along the same lines as ITU-T did (case-A) or if 
> additional parameters need to be made explicit (case-B).
>
> Regards
>
> Gert
>
> *From: *Fatai Zhang <[e-mail]>
> *Date: *Friday, November 6, 2020 at 08:01
> *To: *Daniele Ceccarelli <[e-mail]>, Italo Busi 
> <[e-mail]>, Gert Grammel <[e-mail]>, 
> "[e-mail]" <[e-mail]>, CCAMP <[e-mail]>
> *Cc: *Dieter Beller <[e-mail]>
> *Subject: *答复: [CCAMP] Webex meeting changed: Optical impairments draft
>
> *[External Email. Be cautious of content]*
>
> Hi all,
>
> I think there are too many options (three!) , which introduces too 
> much flexibility and complexity to this document and the real world.
>
> If “only application codes” can work, why the others are necessary?
>
> I think we can try if we could keep only one option and remove the 
> other options to keep it simple , because we could treat e.g., 
> “organization mode” as proprietary implementation since it is really 
> proprietary  among some organization.
>
> Thanks
>
> Fatai
>
> *发件人:*Daniele Ceccarelli [mailto:[e-mail]]
> *发送时间:* 2020年11月2日 23:51
> *收件人:* Italo Busi <[e-mail]>; 'Gert Grammel' 
> <[e-mail]>; [e-mail]; [e-mail]
> *抄送:* Dieter Beller <[e-mail]>
> *主题:* RE: [CCAMP] Webex meeting changed: Optical impairments draft
>
> Hi,
>
> Sorry to jump in but I’m having hard times to understand what the 
> issue is. What is wrong with the actual modes? I asked if it was 
> possible to merge 2 of them and go down to 2 but it was proven not 
> possible.
>
> Moreover this is no longer just author’s agreement since the draft is 
> a WG document.
>
> What italo says below is correct. We decided that all the modes are 
> optional, hence the model needs to be self-consistent and all 
> permutations should be allowed.
>
>
> But once again, it’s not clear to me what the issue is, could you 
> please elaborate it a bit?
>
> Cheers,
>
> Daniele
>
> *From:* Italo Busi <[e-mail] <mailto:[e-mail]>>
> *Sent:* den 2 november 2020 12:42
> *To:* 'Gert Grammel' <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *Cc:* Dieter Beller <[e-mail] 
> <mailto:[e-mail]>>
> *Subject:* RE: [CCAMP] Webex meeting changed: Optical impairments draft
>
> Hi Gert,
>
> Just an high level comment: the initial agreement between the 
> co-authors was that to define three modes (application code, 
> organization mode and explicit mode) all as being optional.
>
> Therefore, IMHO, the YANG model for each mode should be 
> self-consistent to give implementers the freedom to implement either:
>
>   * Only application codes
>   * Only organization modes
>   * Only explicit modes
>   * Both application codes and organization modes
>   * Both application codes and explicit modes
>   * Both organizational modes and explicit modes
>   * All options (application code, organizational mode and explicit mode)
>
> Please find some detailed comments of mine in line below.
>
> My 2 cents
>
> Italo
>
> *From:* Gert Grammel [mailto:[e-mail] 
> <mailto:[e-mail]>]
> *Sent:* domenica 1 novembre 2020 12:02
> *To:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>
> *Cc:* Dieter Beller <[e-mail] 
> <mailto:[e-mail]>>; Italo Busi <[e-mail] 
> <mailto:[e-mail]>>
> *Subject:* Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
> It would be good to tune the heat of the down by a few centigrade. Why 
> spending time writing definitions, getting agreement  and rewriting 
> again in less than 24h?  The core of the discussion is where to hang 
> parameters in a YANG-tree in a consistent manner. How exciting is this?
>
> The minimum we should strive for in IETF is to come up with a 
> consistent model. To do so, it is good engineering practice to first 
> agree on the problem. That said, I am happy that apparently the Case-A 
> and Case-B description laid out in my previous mail turned out not to 
> be contentious.
>
> About the issue of “organizational mode”:
>
>  1. Case-A: AFAIK the most common and Transponder Model today is
>     OpenConfig, which uses a single identifier for the
>     operational-mode. The use is simple because it can be used as a
>     matching criteria to make sure the two transponders at each end
>     interoperate (given the OLS is within spec).
>  2. Case-B: proposes a series of additional criteria that must be met
>     by adding explicit parameters such as frequency range, power-range
>     etc. So the simple matching rule is no more sufficient and
>     additional parameters must be checked to assess compatibility.
>
> I think it is a fair ask to hear from the CCAMP-WG if we are happy to 
> ditch the OpenConfig way and  implement Case-B.
>
> //
>
> /[[Italo Busi] ] I am not an expert of OpenConfig but Dieter has 
> already confirmed that the latest definition in github 
> (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=44077b9a-1b9c42d9-44073b01-861fcb972bfc-e503d80e6efd81dd&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1dV-vxg_$>) 
> is aligned with existing implementations (I assume, based on his 
> working experience, he was also considering OpenConfig implementations)./
>
> //
>
> /Anyhow, OpenConfig experts can provide their comments on this 
> definition, if they think it is not correct./
>
> About the issue of “where to put the explicit parameters”:
>
>  1. Case-A: puts all explicit parameters in the explicit mode and
>     provides a leafref to Organizational modes. Explicit min/max
>     parameters can be liked to an Organizational mode by referencing
>     the organizational mode from the explicit mode. Organizational
>     modes continue to be used just like Application codes as a
>     matching condition.
>
> *//*
>
> /[[Italo Busi] ] The references between the explicit mode and the 
> application code/organization modes have been added as informative to 
> represent the fact that an explicit mode can support zero, one or more 
> application codes and/or zero, one or more organization modes. It was 
> not intended to provide additional information wrt the application 
> code or organization mode definitions and I think it should not be 
> used in that way to avoid creating inconsistencies (see comment below)./
>
>  2. Case-B: puts a subset of the parameters also defined in the
>     explicit mode into the Organizational mode. By doing so we now
>     have duplicated parameters in operational and explicit mode.
>
> Structurally this creates a conflict, because it is not clear which 
> definition takes precedence in a matching condition. It is this 
> structural issue we need to address to move forward.
>
> /[[Italo Busi] ] I think you have spotted a potential technical issue 
> with the current definition of the leafref between an explicit mode 
> and an application code or organization mode but this is independent 
> from the fact that explitic parameters are defined or not for the 
> application mode./
>
> /This inconsistency could apply also to parameters that are implicitly 
> defined by the organization mode (or even by an application code). For 
> example, the YANG model allows an explicit mode which supports one 
> type of FEC to claim support of an application code or of an 
> organization model which (implicitly) requires a different type of FEC./
>
> /If the client requests the interface to operate according to a given 
> application code or organization mode, I think that the expectation is 
> that the FEC defined for that application code or organization mode is 
> being used./
>
> //
>
> /I think to resolve this issue we should either clarify the rules an 
> implementation MUST follow to avoid reporting inconsistent information 
> or some precedence rules (considering both implicit and explicit 
> parameters) or remove the leafref./
>
> About the parameter set of the “Organizational mode”:
>
>  1. Case-A: allows to use any set of explicit parameters to add more
>     information to organizational modes as a reference
>
> //
>
> /[[Italo Busi] ] The YANG model for application codes and organization 
> modes should be self-consistent to supports implementations that do 
> not implement the explicit-mode. Moreover, using the leafref to 
> provide more information would be a potential source of inconsistency 
> (see comment above)/
>
>  2. Base-B: allows a small subset of parameters to be used to further
>     define the organizational mode. This set is fixed as described in
>     case-B.
>
> As the selection criteria for the set of parameters has not been 
> disclosed, it is difficult to understand whether the list remains such 
> short or is growing much longer over time. It would be good to get the 
> sense of the WG on that aspect too.
>
> /[[Italo Busi] ] According to the latest definition in github 
> (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=c4b9f9f1-9b22c0b2-c4b9b96a-861fcb972bfc-7ad4277e89b62b88&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1TYJhR0h$>) 
> the current list is complete./
>
> //
>
> /Those who have implemented organization modes (including OpenConfig 
> experts) can provide their comment if they think this list is not 
> complete./
>
> //
>
> Cheers
>
> Gert
>
> *From: *CCAMP <[e-mail] <mailto:[e-mail]>> 
> on behalf of Dieter Beller <[e-mail] 
> <mailto:[e-mail]>>
> *Organization: *Nokia
> *Date: *Saturday, October 31, 2020 at 10:28
> *To: *Italo Busi <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>, CCAMP <[e-mail] 
> <mailto:[e-mail]>>
> *Subject: *Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
> *[External Email. Be cautious of content]*
>
> Thanks, Italo, for your contribution to the technical discussion!
>
> I would like to emphasize that the text on GitHub ( see 
> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=2c758499-73eebdda-2c75c402-861fcb972bfc-3975d7433728ea76&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1W1fns7e$>) 
> tries
> to provide the technical justification for the modeling approach taken 
> for the organizational mode option - here is the text, which was 
> referenced in Italo's mail:
>
> *Organizational Mode:*
> Organizations like operator groups, industry fora, or equipment 
> vendors can define organizational modes, which will allow these 
> organizations to make use of advanced transceiver capabilities going 
> beyond existing standardized application codes. Such an organizational 
> mode is identified by the organization-identifier attribute defining 
> the scope and an operational-mode that is meaningful within the scope 
> of the organization. Hence, the two attributes must always be 
> considered together. Two transceivers are inter-operable, if they have 
> at least one (organization-identifier, operational-mode) pair in 
> common and if the supported carrier frequency and power attributes 
> have a matching range. This is a necessary condition for path 
> computation in the context of organizational modes. An operational 
> mode is a transceiver preset (a configuration with well-defined 
> parameter values) subsuming several transceiver properties including:
> • FEC type
> • Modulation scheme
> • Encoding (mapping of bit patterns to symbols in the constellation 
> diagram)
> • Baud rate (symbol rate)
> • Carrier bandwidth (typically measured in GHz)
>
> The major reason for these transceiver presets is the fact that the 
> attribute values typically cannot be configured independently and are 
> therefore advertised as supported operational mode capabilities.
> It is the responsibility of the organization to assign operational 
> modes and to ensure that operational modes are unique and not 
> ambiguous within the scope of the organization.
> In addition to the transceiver properties subsumed by the operational 
> mode, optical power and carrier frequency related properties are 
> modeled separately, i.e., outside of the operational mode. This 
> modeling approach allows transponders using different transceiver 
> variants (e.g. optical modules) with slightly different power and/or 
> frequency range properties to interoperate without defining separate 
> operational modes. Different optical modules (pluggables) from 
> different suppliers typically have slightly different input and output 
> power ranges or may have slightly different carrier frequency tuning 
> ranges.
> The received channel power and the received total power are two 
> parameters that can be measured by the receiver and can be provided by 
> the transceiver in order to allow a controller to determine the 
> expected performance of the end-to-end service taking into account the 
> optical impairments along the path.
>
>
> Moreover, implementations exist that are based on the same modeling 
> approach and hence it is *already field proven!*
>
>
> Thanks,
> Dieter
>
> On 30.10.2020 17:14, Italo Busi wrote:
>
>     Hi Gert,
>
>     Let me try to look at this issue from a different perspective.
>
>     I think the objective of our work is to define a YANG model for
>     the optical specification methodologies which are used in the
>     field to represent the capabilities of the transponders.
>
>     I do not think that it is in the scope of our work to discuss the
>     optical specification methodologies other than understanding how
>     they could be used for path computation (ensuring interoperability
>     between the sender and receiver) and modelled using YANG.
>
>     As far as I have understood from past discussion, we have agreed
>     to support three optical specification methodologies which are
>     used by existing optical interfaces implementations and we have
>     named them as application code (ITU-T G.698.2), organizational
>     mode and explicit mode.
>
>     After some rounds of discussions and questions for clarification,
>     the latest proposed text to describe the behavior of the
>     organization mode has been prepared on github:
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=fe2bb22f-a1b08b6c-fe2bf2b4-861fcb972bfc-7c29789e806b744e&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1RUYzMO4$>
>
>     I think this updated description has improved the clarity of how
>     the operational mode are implemented and, in particular that:
>
>     "Two transceivers are inter-operable, if they have at least one
>     (organization-identifier, operational-mode) pair in common and if
>     the supported carrier frequency and power attributes have a
>     matching range."
>
>     As a consequence, I think that the YANG model defined in "Case A"
>     below does not work (since it does not provide enough information
>     to check that " the supported carrier frequency and power
>     attributes have a matching range ") while the one defined in "Case
>     B" works properly.
>
>     This text describing the operational mode behavior has been
>     provided by people who have implemented it.
>
>     Therefore, I think we can update the draft with the changes
>     discussed in the last few weeks incorporating the definitions
>     capturing our current understanding of how these optical
>     specification methodologies (application code, organizational mode
>     and explicit mode) behave and the YANG model aligned with our
>     current understanding (i.e., based on "Case B" below).
>
>     Since we are not yet in WG LC stage, we still have plenty of time
>     to update both the description and the YANG model based on the
>     feedbacks we receive from data plane experts.
>
>     My 2 cents
>
>     Italo (as co-author of the draft)
>
>     -----Original Message-----
>
>     From: Gert Grammel [mailto:[e-mail]
>     <mailto:[e-mail]>]
>
>     Sent: giovedì 29 ottobre 2020 17:34
>
>     To: [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>
>     Subject: Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
>     We discussed today a difference in the interpretation of the model
>     related to
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=30d0fc94-6f4bc5d7-30d0bc0f-861fcb972bfc-5d5353826774237a&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29__;JSUlJSUlJQ!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1eeOzXrI$>
>     and its interpretation. The different interpretation lead to
>     different computation requirements.
>
>     The design team appreciates feedback which of both Cases is
>     preferred and what consideration led to the preference
>
>     Case A:
>
>     ======
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues#issuecomment-677768528
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=af80a102-f01b9841-af80e199-861fcb972bfc-509d8509e721d1cb&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*23issuecomment-677768528__;JSUlJSUlJQ!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1fp5UCUX$>
>     from August 20 documented the structure of the model:
>
>     +--ro supported-modes* [mode-id]
>
>           +--ro mode-id
>
>           +--ro (mode)?
>
>           |  +--:(G.698.2)
>
>           |  |  +--ro standard-mode?                standard-mode
>
>           |  +--:(organizational-mode)
>
>           |  |  +--ro operational-mode?             operational-mode
>
>           |  |  +--ro organization-identifier?      vendor-identifier
>
>     ➢|  +--:(explicit-mode)
>
>     ➢|    +--ro supported-standard-mode*? leafref
>
>           |     +--ro modulation-types                   identityref
>
>           |     ......
>
>     This snippet would allow to use standard mode or operational mode
>     as a simple matching criteria for compatibility i.e. two
>     transponders with Operational-mode=X and suitable line parameters
>     would interoperate.
>
>     In case of “explicit” mode, the set of parameters provided, can
>     support one or more application code/organizational mode, that
>     means this set of parameters if applied to configure the
>     transceiver, is aligned with one or more application
>     code/organizational mode.
>
>     (Note that there are no additional parameters associated to the
>     organizational mode in this case)
>
>     Case B:
>
>     ======
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/blob/master/ietf-optical-impairment-topology.tree
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=dacf1e95-855427d6-dacf5e0e-861fcb972bfc-13a67d7f67153c4a&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fblob*2Fmaster*2Fietf-optical-impairment-topology.tree__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1ToD0jv4$>
>     contains additional parameters to the Operational Mode that are
>     also replicated in the explicit mode. Those parameters are related
>     to the min/max ranges which are allowed.
>
>       +--ro supported-mode* [mode-id]
>
>                     +--ro mode-id                      string
>
>                     +--ro (mode)
>
>                        +--:(G.698.2)
>
>                        |  +--ro standard-mode?         standard-mode
>
>                        +--:(organizational-mode)
>
>                        |  +--ro organizational-mode
>
>                        |     +--ro operational-mode?
>
>                        |     |       operational-mode
>
>                        |     +--ro organization-identifier?
>
>                        |     |       organization-identifier
>
>                        |     +--ro min-central-frequency?
>
>                        |     |       frequency-thz
>
>                        |     +--ro max-central-frequency?
>
>                        |     |       frequency-thz
>
>                        |     +--ro minimum-channel-spacing?
>
>                        |     |       frequency-ghz
>
>                        |     +--ro tx-channel-power-min?      dbm-t
>
>                        |     +--ro tx-channel-power-max?      dbm-t
>
>                        |     +--ro rx-channel-power-min?      dbm-t
>
>                        |     +--ro rx-channel-power-max?      dbm-t
>
>                        |     +--ro rx-total-power-max?        dbm-t
>
>                        +--:(explicit-mode)
>
>                           +--ro explicit-mode
>
>                              +--ro supported-modes
>
>                              |  +--ro supported-application-codes*
>
>                              |  |       -> ../../mode-id
>
>                              |  +--ro supported-organizational-modes*
>
>                              |          -> ../../mode-id
>
>                              +--ro line-coding-bitrate?
>
>                              |       identityref
>
>                          <snip>
>
>                              +--ro min-central-frequency?
>
>                              |       frequency-thz
>
>                              +--ro max-central-frequency?
>
>                              |       frequency-thz
>
>                              +--ro minimum-channel-spacing?
>
>                              |       frequency-ghz
>
>                              +--ro tx-channel-power-min?
>
>                              |       dbm-t
>
>                              +--ro tx-channel-power-max?
>
>                              |       dbm-t
>
>                              +--ro rx-channel-power-min?
>
>                              |       dbm-t
>
>                              +--ro rx-channel-power-max?
>
>                              |       dbm-t
>
>                              +--ro rx-total-power-max?
>
>                                      dbm-t
>
>     In this case, interoperability can only be provided if the
>     organizational code on each side match AND all other explicit
>     parameters defined in the organizational-code have a matching range.
>
>     (Note that min/max parameters are associated to the organizational
>     mode AND to the explicit mode in this case)
>
>     Juniper Business Use Only
>
>     _______________________________________________
>
>     CCAMP mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/ccamp
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=e2f70c1c-bd6c355f-e2f74c87-861fcb972bfc-c52544a2ca4d215d&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fccamp__*3B*21*21NEt6yMaO-gk*21Qf7o1-a2YfLkPqzntQzH4eVYGLpUDj-1ysELXfiLRhkWu-G-RrJBibxJipiVa6Bx*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1bI5nQgy$>
>