In essence you are saying that most people are not going to care about the Y/N in the IANA table anyway. Somewhat similar to people not understanding the difference between the different types of RFCs.
That sounds pragmatic. Ciao Hannes On 03/31/2016 06:52 PM, Benjamin Kaduk wrote: > On 03/31/2016 11:20 AM, Hannes Tschofenig wrote: >> Hi Ben, >> >> just think about the mentioned JPAKE extension: what type of deployment >> can you expect? It is something that Thread decided to use. Will Thread, >> as a mesh networking technology, be successful and widely be deployed? >> We don't know yet but if it becomes a technology of choice for use with >> IEEE 802.15.4 then it will be fairly widely used in the IoT sector. I am >> sure the authors of the Thread specifications (and the members of the >> Thread consortium) expect their stuff to be widely used (in IoT -- not >> on the Web). > > Well, for JPAKE in particular, my thoughts focus on my perception that > PAKE of any form is not really central to what TLS does. Given that, I > personally would not advocate for a 'Y' for it, even knowing that it > might see wide use in IoT. > >> Is this something that is good enough for this group? Web guys will >> hardly care about it. A large part of the TLS group is focused on the >> Web use only (at least that's my impression). >> >> From the descriptions provided by Sean I don't know whether this is >> something that would be a "Y" blessing or not. This is what I call >> "sounds nice but ...". >> > > Well, I would expect the authors to put the 'Y' in their IANA > considerations text and see if anyone complained during the last calls. > I further expect that some of the web-centric folks on this list would > complain and probably get the 'Y' removed, but I am not seeing why this > is problematic. > > -Ben >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
