Subject: Re: [tcpm] Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-converter)

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 24 Apr 2019 05:41:45 +0000

Hi Med & WG:

I have reviewed the draft (draft-boucadair-tcpm-dhc-converter) and I think this is a useful option. Configuration of converter address on the endpoint, or for that matter, any configuration element is a pain. In that sense, any steps to eliminate this static configuration will help deployments and therefore I am supportive of this work. Also, FWIW, I was earlier exploring L2 signaling approaches for provisioning the same and I think DHCP option makes lot more sense.  I hope you will find support for this work.

Sri

From: tcpm <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 17, 2019 at 7:05 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Konda, Tirumaleswar Reddy ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, JACQUENET Christian TGI/OLN <[email-masked]<mailto:[email-masked]>>
Subject: [tcpm] Provisioning 0-RTT Converters (draft-boucadair-tcpm-dhc-converter)

Dear all,

Now that the 0-RTT Converter spec is about to be LCed, we would like to ask the WG to consider this draft
https://datatracker.ietf.org/doc/draft-boucadair-tcpm-dhc-converter/ which is useful for the dynamic provisioning of the Converters to CPEs, in particular.

The converters discovery options cannot be defined in the dhc WG because its charter says the following:

“Definitions of new DHCP options that are delivered using standard
mechanisms with documented semantics are not considered a protocol
extension and thus are generally outside of scope for the DHC WG. Such
options should be defined within their respective WGs”

We hope that tcpm can host this work.

Cheers,
Med

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 24 Apr 2019 09:35:28 +0200

Hello,

> 
> 
> I have reviewed the draft (draft-boucadair-tcpm-dhc-converter) and I think this is a useful option. Configuration of converter address on the endpoint, or for that matter, any configuration element is a pain. 

I agree. This DHCP extension is one of the possible ways to disseminate the information about the converter address. I support this draft

Olivier

> 
> 
> From: tcpm <[email-masked] <mailto:[email-masked]>> on behalf of "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "Konda, Tirumaleswar Reddy ([email-masked] <mailto:[email-masked]>)" <[email-masked] <mailto:[email-masked]>>, JACQUENET Christian TGI/OLN <[email-masked] <mailto:[email-masked]>>
> https://datatracker.ietf.org/doc/draft-boucadair-tcpm-dhc-converter/ <https://datatracker.ietf.org/doc/draft-boucadair-tcpm-dhc-converter/> which is useful for the dynamic provisioning of the Converters to CPEs, in particular. 
>  
> _______________________________________________
> tcpm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

-- 

Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>