Subject: [Detnet] WG adoption poll draft-geng-detnet-conf-yang

From: Janos Farkas <[email-masked]>
Date: Tue, 18 Sep 2018 19:02:08 +0000

Dear all,

This is start of a two week poll on making draft-geng-detnet-conf-yang-04
a working group document. Please send email to the list indicating
"yes/support" or "no/do not support".  If indicating no, please state
your reservations with the document.  If yes, please also feel free to
provide comments you'd like to see addressed once the document is a WG
document.

The poll ends Oct 3.

Thanks,
János and Lou

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 18 Sep 2018 12:16:36 -0700

Hi Janos, et. al,
the mpls-detnet-header container is based on the solution described in
draft-ietf-detnet-dp-sol-mpls. Analysis of active SFC OAM in the
proposed MPLS data plane solution in draft-mirsky-detnet-oam points to
the potential problem as result the fact that OAM packet doesn't
include d-CW. I believe that this question should be discussed and, if
we agree on the problem statement, properly resolved. Until then, I do
not support the adoption of the model that may not be capable to
support active OAM.

Regards,
Greg
On Tue, Sep 18, 2018 at 12:03 PM Janos Farkas <[email-masked]> wrote:
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 18 Sep 2018 22:00:02 +0000

Yes/Support.
Ethan.

From: Janos Farkas <[email-masked]>
Sent: Tuesday, September 18, 2018 12:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: WG adoption poll draft-geng-detnet-conf-yang

Dear all,

The poll ends Oct 3.

Thanks,
János and Lou

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Wed, 19 Sep 2018 00:27:49 +0000

yes/support

Bingyang Liu

From: detnet [mailto:[email-masked]] On Behalf Of Janos Farkas
Sent: Wednesday, September 19, 2018 3:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Detnet] WG adoption poll draft-geng-detnet-conf-yang

Dear all,

The poll ends Oct 3.

Thanks,
János and Lou

---

From: Mach Chen <[email-masked]>
Date: Wed, 19 Sep 2018 10:13:19 +0000

Yes/Support.

Best regards,
Mach (as co-author)

Dear all,

The poll ends Oct 3.

Thanks,
János and Lou

---

From: Loa Andersson <[email-masked]>
Date: Thu, 20 Sep 2018 15:14:13 +0800

Janos,

Yes - support!

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Sep 2018 08:05:12 +0000

Yes/Support.

Pascal

Dear all,

The poll ends Oct 3.

Thanks,
János and Lou

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 20 Sep 2018 14:23:36 -0400

János,

Yes/support.

Thanks,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 20 Sep 2018 14:42:15 -0400

Greg,

I didn't get the point of section 4.3 in your draft. Are you proposing an
alternative data plane encapsulation?

Also, section 4.2 states that OAM replication is a bad thing. However, if
PR is being used, isn't OAM replication without EF a good thing? After all,
you may get different answers on connected metadata in the OAM depending on
which path was taken.

Cheers,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 20 Sep 2018 14:44:20 -0400

Whoops, that was a typo. I meant "collected metadata", not "connected
metadata".

Cheers,
Andy

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 20 Sep 2018 12:06:59 -0700

Hi Andy,
thank you for your questions. Please find my answers, notes in-lined tagged
GIM>>.

Regards,
Greg

> alternative data plane encapsulation?
GIM>> Mach proposed to define d-ACH and we'll explore this path. Will have
update at IETF-103.

>
> Also, section 4.2 states that OAM replication is a bad thing.
>
GIM>> I'd differentiate between intended testing, monitoring of the
particular or all available paths and inherent multiplication of OAM
packets (it is one of undesirable scenarios considered in the draft). If we
agree on the requirement  "OAM packet MUST share the fate with a data
packet of the monitored flow", then the egress node would receive one and
only one copy of the OAM packet for each packet generated by the ingress
node. If that is not the case, then yes, it is a bad thing.

> However, if PR is being used, isn't OAM replication without EF a good
> thing? After all, you may get different answers on connected metadata in
> the OAM depending on which path was taken.
>
GIM>> It could be one of OAM functions, i.e. controlling PRs to explore
particular path.

---

From: Rodney Cummings <[email-masked]>
Date: Thu, 20 Sep 2018 22:29:37 +0000

Hi folks,

At the moment, I am "no / do not support". 

I am confused by what it means for the WG to adopt this draft.

The draft contains YANG for configuration of IEEE 802.1 features in a node (bridge, router, etc). This includes 802.1CB ("PREOF"), 802.1Qav (credit-based shaper), and so on. There are similar YANG projects in 802.1 for these features.

Therefore, does adoption of this draft mean that IETF DetNet intends to do YANG work that overlaps with 802.1 YANG work?

I would hope that the answer is No.

On a different point, I don't think that topology is part of node configuration (southbound). Topology is not flow or service related, but it is between the Network Operator (controller) and the User... northbound. If I am correct, this draft is starting with an incorrect assumption.

Rodney

From: detnet <[email-masked]> On Behalf Of Janos Farkas
Sent: Tuesday, September 18, 2018 2:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Detnet] WG adoption poll draft-geng-detnet-conf-yang

Dear all, 

The poll ends Oct 3. 

Thanks, 
János and Lou

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Fri, 21 Sep 2018 02:18:08 +0000

Hi Rodney,

Thank you for reviewing the document and giving comments.
The current DetNet YANG is based on the what has been done in DetNet WG, and the attributes defined there can be found in WG charter/DetNet architecture/ DetNet information model.
At the same time, we keep an eye about what is happening in IEEE, and try to make a careful work division with IEEE when we define the YANG model:
1. The 'ietf-detnet-flow' is for DetNet service establishment in the DetNet domain, corresponding to the configuration of MPLS/IP data plane solution.
2. The 'ietf-detnet-topolgy' is the augmentation of 'ietf-te-topolgy', and all the attributes that have been defined in TE topology can be reused.
Obviously, we cannot use IEEE 802.1 YANG to configure an IP/MPLS network. All these work is the extension of current IETF YANG work. The functions or algorithms you have mentioned, including "PREOF" or "credit-based-shaper", are shared features with both DetNet and TSN, and we are not intended to redefine them, and just to offer a tool about how to use them in an IP/MPLS network;.

I agree that ietf-detnet-topology does not belong to the southbound interface (it was also mentioned in the presentation of IETF 102 ), and we ask for WG comments about whether to put it in a separated draft. I think the current answer is to maintain them in the same one.

It is good to hear your comments, and we would like to corporate with IEEE 802.1 YANG guys to make TSN/DetNet coordinate with each other. More communications are always helpful.

Best Regards

Xuesong

>-----Original Message-----
>From: detnet [mailto:[email-masked]] On Behalf Of Rodney Cummings
>Sent: Friday, September 21, 2018 6:30 AM
>To: Janos Farkas <[email-masked]>; [email-masked]
>Subject: Re: [Detnet] WG adoption poll draft-geng-detnet-conf-yang
>
>Hi folks,
>
>The draft contains YANG for configuration of IEEE 802.1 features in a node
>(bridge, router, etc). This includes 802.1CB ("PREOF"), 802.1Qav (credit-based
>shaper), and so on. There are similar YANG projects in 802.1 for these features.
>
>Therefore, does adoption of this draft mean that IETF DetNet intends to do
>YANG work that overlaps with 802.1 YANG work?
>
>On a different point, I don't think that topology is part of node configuration
>(southbound). Topology is not flow or service related, but it is between the
>Network Operator (controller) and the User... northbound. If I am correct, this
>draft is starting with an incorrect assumption.
>
>Rodney
>
>This is start of a two week poll on making draft-geng-detnet-conf-yang-04 a
>working group document. Please send email to the list indicating "yes/support"
>or "no/do not support".  If indicating no, please state your reservations with
>the document.  If yes, please also feel free to provide comments you'd like to
>see addressed once the document is a WG document.
>
>The poll ends Oct 3.
>
>Thanks,
>János and Lou
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Fri, 21 Sep 2018 06:11:51 +0000

Hi Rodney,

Some supplementation and modification:

Ietf-detnet-topology in the document is used for ' device and link capabilities (feature support) and resources (e.g. buffers, bandwidth) ' discovery, so it is the southbound interface. However, it is not part of DetNet flow configuration, and so we think maybe it can be an independent work.

Best Regards
Xuesong

>From: detnet [mailto:[email-masked]] On Behalf Of Gengxuesong
>(Geng Xuesong)
>Sent: Friday, September 21, 2018 10:18 AM
>To: Rodney Cummings <[email-masked]>; Janos Farkas
><[email-masked]>; [email-masked]
>The current DetNet YANG is based on the what has been done in DetNet WG,
>and the attributes defined there can be found in WG charter/DetNet
>architecture/ DetNet information model.
>At the same time, we keep an eye about what is happening in IEEE, and try to
>make a careful work division with IEEE when we define the YANG model:
>1. The 'ietf-detnet-flow' is for DetNet service establishment in the DetNet
>domain, corresponding to the configuration of MPLS/IP data plane solution.
>2. The 'ietf-detnet-topolgy' is the augmentation of 'ietf-te-topolgy', and all the
>attributes that have been defined in TE topology can be reused.
>Obviously, we cannot use IEEE 802.1 YANG to configure an IP/MPLS network. All
>these work is the extension of current IETF YANG work. The functions or
>algorithms you have mentioned, including "PREOF" or "credit-based-shaper",
>are shared features with both DetNet and TSN, and we are not intended to
>redefine them, and just to offer a tool about how to use them in an IP/MPLS
>network;.
>
>I agree that ietf-detnet-topology does not belong to the southbound interface (it
>was also mentioned in the presentation of IETF 102 ), and we ask for WG
>comments about whether to put it in a separated draft. I think the current
>answer is to maintain them in the same one.
>
>It is good to hear your comments, and we would like to corporate with IEEE
>802.1 YANG guys to make TSN/DetNet coordinate with each other. More
>communications are always helpful.
>
>Best Regards
>
>Xuesong
>
>>The draft contains YANG for configuration of IEEE 802.1 features in a
>>node (bridge, router, etc). This includes 802.1CB ("PREOF"), 802.1Qav
>>(credit-based shaper), and so on. There are similar YANG projects in 802.1 for
>these features.
>>
>>Therefore, does adoption of this draft mean that IETF DetNet intends to
>>do YANG work that overlaps with 802.1 YANG work?
>>
>>On a different point, I don't think that topology is part of node
>>configuration (southbound). Topology is not flow or service related,
>>but it is between the Network Operator (controller) and the User...
>>northbound. If I am correct, this draft is starting with an incorrect assumption.
>>
>>Rodney
>>
>>This is start of a two week poll on making
>>draft-geng-detnet-conf-yang-04 a working group document. Please send email
>to the list indicating "yes/support"
>>or "no/do not support".  If indicating no, please state your
>>reservations with the document.  If yes, please also feel free to

---

From: János Farkas <[email-masked]>
Date: Fri, 21 Sep 2018 15:29:05 +0200

Hi Greg, all,

Good to see the discussion on active OAM on the list.

I think it is essentially a basic data plane consideration. You also 
referred to draft-ietf-detnet-dp-sol-mpls. It seems that the data plane 
has to be sorted out first.

Of course, the YANG draft has to be then updated accordingly. I think 
that update could be done when the draft is with the WG, i.e., after WG 
adoption.

Thanks,
Janos

---

From: Norman Finn <[email-masked]>
Date: Fri, 21 Sep 2018 18:19:03 +0000

Yes.  I support adopting this draft.

-- Norm

________________________________
From: detnet [[email-masked]] on behalf of Janos Farkas [[email-masked]]
Sent: Tuesday, September 18, 2018 12:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Detnet] WG adoption poll draft-geng-detnet-conf-yang

Dear all,

The poll ends Oct 3.

Thanks,
János and Lou

---

From: Kiran.Makhijani <[email-masked]>
Date: Fri, 21 Sep 2018 21:36:45 +0000

Yes. Support.
Kiran

Dear all,

The poll ends Oct 3.

Thanks,
János and Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 25 Sep 2018 09:56:01 -0400

Hi Rodney,

> I am confused by what it means for the WG to adopt this draft.

Adoption of any draft basically means that the WG is formally working on 
the document/topic.  As an individual draft, the draft authors have 
control of a documents contents.  Once a draft is a WG document, control 
shifts to the WG  and the editors/authors are responsible for ensuring a 
document reflects consensus of the WG. Authors do have flexibility in 
how they do this. For example, proposing changes in on list prior to 
publication of a new version, or simply putting such changes in a new 
version for review by the WG are both common practices.

> The draft contains YANG for configuration of IEEE 802.1 features in a node (bridge, router, etc). This includes 802.1CB ("PREOF"), 802.1Qav (credit-based shaper), and so on. There are similar YANG…

I would expect that there be similarities in configuring DetNet and TSN 
services, but I do agree, we (DetNet and the IETF) should not be 
defining specifics of technology standardized by other bodies as part of 
our normal business.  Now if we synchronize with that other SDO, and 
they agree that we do some complementary work, this is fine -- but I 
don't believe this is the case here.

> I would hope that the answer is No.

I do think it is fair to sort out the inter-SDO related contents prior 
to adoption so that we don't send mixed signals to the IEEE or the 
market.  Can you, either on-list or off-list to authors, state 
specifically which parts of the document/tree you think should be removed?

> On a different point, I don't think that topology is part of node configuration (southbound). Topology is not flow or service related, but it is between the Network Operator (controller) and the Us…
This sounds like a topic that could get sorted post adoption, do you agree?

Thanks,
Lou
> Rodney
>
> From: detnet<[email-masked]>  On Behalf Of Janos Farkas
> To:[email-masked]
> Cc:[email-masked]

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 26 Sep 2018 02:30:16 +0000

Hi Rodney ,

Although I’m still confused about what part of the current DetNet YANG may overlap IEEE YANG, I agree with Lou that it is reasonable to clarify the relationship between IETF/DetNet YANG and IEEE/TSN YANG.  In order to clear this up and make an agreement, could you give some suggestions about how to build up communication between these two SDO,  in order to move the work forward together?

Best Regards
Xuesong

From: detnet [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, September 25, 2018 9:56 PM
To: Rodney Cummings <[email-masked]>; Janos Farkas <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Detnet] WG adoption poll draft-geng-detnet-conf-yang

Hi Rodney,

Hi folks,

Adoption of any draft basically means that the WG is formally working on the document/topic.  As an individual draft, the draft authors have control of a documents contents.  Once a draft is a WG document, control shifts to the WG  and the editors/authors are responsible for ensuring a document reflects consensus of the WG.  Authors do have flexibility in how they do this. For example, proposing changes in on list prior to publication of a new version, or simply putting such changes in a new version for review by the WG are both common practices.

I would expect that there be similarities in configuring DetNet and TSN services, but I do agree, we (DetNet and the IETF) should not be defining specifics of technology standardized by other bodies as part of our normal business.  Now if we synchronize with that other SDO, and they agree that we do some complementary work, this is fine -- but I don't believe this is the case here.

I do think it is fair to sort out the inter-SDO related contents prior to adoption so that we don't send mixed signals to the IEEE or the market.  Can you, either on-list or off-list to authors, state specifically which parts of the document/tree you think should be removed?

Thanks,
Lou

Rodney

From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Janos Farkas

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

Dear all,

document.

The poll ends Oct 3.

Thanks,

János and Lou

detnet mailing list

[email-masked]<mailto:[email-masked]>

---

From: Rodney Cummings <[email-masked]>
Date: Wed, 26 Sep 2018 17:01:13 +0000

Thanks Lou,

> I do think it is fair to sort out the inter-SDO related contents prior to adoption so 
> that we don't send mixed signals to the IEEE or the market.  Can you, either on-list or off-list 
> to authors, state specifically which parts of the document/tree you think should be removed?

I was not clear regarding my question on WG adoption. My concern is exactly what you describe
above. I have no problem at all with one SDO doing YANG work for another SDO's standards, as long as
the two SDOs agree to that YANG roadmap. I didn't know whether WG adoption of this document reflects
that sort of inter-SDO agreement.

My concern is to avoid overlap. If two SDOs develop YANG for the same feature, that is 
potentially painful to product implementers (which includes me). I think we can avoid that sort of 
overlap with communication from both sides on this mailing list. I don't think we need formal 
liaisons or similar.

Specifically, in draft-geng-detnet-conf-yang, my concern is Section 4 and associated YANG.
I assume that "flow configuration" is intended to be southbound. If it is southbound, these 
nodes directly overlap with YANG in progress for 802.1CB (in P802.1CBcv).

I suppose my higher level question is:
	For YANG, which SDO is addressing which topic?

For example, is IETF DetNet planning to address northbound interfaces?

If the answer is Yes, then I have no problem keeping the topology content in this draft.
Maybe we will transition that topology content to a northbound-oriented draft, but that can 
be decided later.

If the answer is Yes, what are we doing with the northbound work that has been published thus far
in 802.1Qcc?

Maybe we will transition that northbound work from 802.1 TSN to IETF DetNet over time, in order to
avoid future overlap. Maybe we will keep that topic in 802.1 TSN. Whichever we decide, it would be
helpful to make it clear, so that we can avoid drafts that overlap unintentionally.

Rodney

From: Lou Berger <[email-masked]> 
Sent: Tuesday, September 25, 2018 8:56 AM
To: Rodney Cummings <[email-masked]>; Janos Farkas <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Detnet] WG adoption poll draft-geng-detnet-conf-yang

Hi Rodney, 

Hi folks,

Thanks,
Lou

Rodney

From: detnet mailto:[email-masked] On Behalf Of Janos Farkas
Sent: Tuesday, September 18, 2018 2:02 PM
To: mailto:[email-masked]
Cc: mailto:[email-masked]
Subject: [Detnet] WG adoption poll draft-geng-detnet-conf-yang

Dear all, 

The poll ends Oct 3. 

Thanks, 
János and Lou

_______________________________________________
detnet mailing list
mailto:[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMDaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=2bVCH_eyGhx0Ye6DEdYw9o1jxRMHrpLcmVAKoLkozvI&s=cpbNBNL99UFQw8_gmcvSsl_COAbsahIZa0g0oFBSAGE&e=

---

From: Mach Chen <[email-masked]>
Date: Thu, 27 Sep 2018 09:00:04 +0000

Hi Rodney,

Thanks for the detailed clarification!

Please see my response inline...

> Sent: Thursday, September 27, 2018 1:01 AM
> To: Lou Berger <[email-masked]>; Janos Farkas
> > market.  Can you, either on-list or off-list to authors, state specifically which
> parts of the document/tree you think should be removed?
> 
> I was not clear regarding my question on WG adoption. My concern is exactly
> what you describe above. I have no problem at all with one SDO doing YANG
> work for another SDO's standards, as long as the two SDOs agree to that
> YANG roadmap. I didn't know whether WG adoption of this document
> reflects that sort of inter-SDO agreement.
> 
> My concern is to avoid overlap. If two SDOs develop YANG for the same
> feature, that is potentially painful to product implementers (which includes
> me). I think we can avoid that sort of overlap with communication from both
> sides on this mailing list. I don't think we need formal liaisons or similar.

I can't agree more. 

> I assume that "flow configuration" is intended to be southbound. If it is
> southbound, these nodes directly overlap with YANG in progress for 802.1CB
> (in P802.1CBcv).

The flow configuration in draft-geng-detnet-conf-yang only covers the DetNet flow (layer 3) related parameters. And I assume that P802.1CBcv intends to configure TSN flow(layer 2) related parameters. Why do think they directly overlap? Are you proposing a single model for both DetNet and TSN flow configuration?

> 	For YANG, which SDO is addressing which topic?

My personal opinion is that IEEE TSN addresses TSN specific configuration, and IETF DetNet WG addresses DetNet specific configuration. For the common part (both apply to TSN and DetNet), more discussions and collaboration between the two SDOs are needed. 

1 ) For flow configuration, since the encapsulations are different, DetNet and TSN should have their own configuration models. 

2 ) For topology discovery: the current DetNet topology model is an augmentation to ietf-te-topology model, it is defined as southbound, may be used as northbound.  Since the bandwidth, PREOF capabilities, queuing delays, queuing algorithms, processing delays etc. parameters are needed for and transparent to both TSN and DetNet. Seems a common model can work for both TSN and DetNet. 

So, for topology model, do we plan to define a common model for both TSN and DetNet? Or define dedicated topology models for TSN and DetNet respectively? 

3) There will be another model: transport QoS model (is not included in the current draft), which may have some common design and parameters for both TSN and DetNet. 

> Maybe we will transition that topology content to a northbound-oriented
> draft, but that can be decided later.
> 
> If the answer is Yes, what are we doing with the northbound work that has
> been published thus far in 802.1Qcc?
> 
> Maybe we will transition that northbound work from 802.1 TSN to IETF
> DetNet over time, in order to avoid future overlap. Maybe we will keep that
> topic in 802.1 TSN. Whichever we decide, it would be helpful to make it clear,
> so that we can avoid drafts that overlap unintentionally.

If DetNet plans to define northbound model, I agree with the principle. 

Best regards,
Mach
> Adoption of any draft basically means that the WG is formally working on the
> document/topic.  As an individual draft, the draft authors have control of a
> documents contents.  Once a draft is a WG document, control shifts to the
> WG  and the editors/authors are responsible for ensuring a document
> reflects consensus of the WG.  Authors do have flexibility in how they do this.
> For example, proposing changes in on list prior to publication of a new
> version, or simply putting such changes in a new version for review by the
> WG are both common practices.
> 
> 
> services, but I do agree, we (DetNet and the IETF) should not be defining
> specifics of technology standardized by other bodies as part of our normal
> business.  Now if we synchronize with that other SDO, and they agree that
> we do some complementary work, this is fine -- but I don't believe this is the
> case here.
> 
> 
> 
> I do think it is fair to sort out the inter-SDO related contents prior to adoption
> so that we don't send mixed signals to the IEEE or the market.  Can you,
> either on-list or off-list to authors, state specifically which parts of the
> document/tree you think should be removed?
> 
> 
> 
> 
> Network Operator (controller) and the User... northbound. If I am correct,
> this draft is starting with an incorrect assumption.
> working group document. Please send email to the list indicating
> "yes/support" or "no/do not support".  If indicating no, please state your
> reservations with the document.  If yes, please also feel free to provide
> comments you'd like to see addressed once the document is a WG
> document.
> 
> The poll ends Oct 3.
> 
> Thanks,
> János and Lou
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_detnet&d=DwMDaQ&c=I_0YwoKy7z5L
> MTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupsw
> WYdnboKbZ8k&m=2bVCH_eyGhx0Ye6DEdYw9o1jxRMHrpLcmVAKoLkozvI&s
> =cpbNBNL99UFQw8_gmcvSsl_COAbsahIZa0g0oFBSAGE&e=
> 
>