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).
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 ...". Ciao Hannes On 03/31/2016 06:03 PM, Benjamin Kaduk wrote: > On 03/31/2016 08:45 AM, Hannes Tschofenig wrote: >> Hi Sean, >> >> What is the requirement for adding a spec to the list with the value >> IETF Recommended = "Y" (or to change an entry from "Y" to "N")? >> >> You mention two conditions: >> >> * IETF has consensus >> * Are reasonably expected to be supported by widely used >> implementations such as open-source libraries >> >> Of course, with all our work we expect them to be supported by widely >> used implementations. The future is unpredicable and therefore not a > > I don't think it's universally true that we expect all our work to be > supported by widely used implementations. Sometimes we standardize > things that are kind of niche cases and not expected to be widely used. > (This also somewhat relates to the question, already raised, of how to > turn a 'Y' back to a 'N' for things we decide we don't like any more.) > >> good item for making a judgement. I realy find document authors who have >> less interest to get their stuff deployed. > > ...but I do agree that predictions of the future do not make good > criteria here. > >> Getting IETF consensus on specifications has turned to be easier than >> most people expect and the IETF published RFCs that have not received a >> lot of review. Large amount of review is not a pre-condition for consensus. > > I think that documents introducing things that get a 'Y' should > explicitly say that in the IANA considerations, so the IETF consensus > explicitly includes support for the 'Y', and not all documents published > with IETF consensus need to go for the 'Y'. Which is not to say that > putting in such an IANA considerations section will magically cause > people to read the document at IETF last call, of course, but I do have > confidence that the IESG (if no one else) will ask whether the TLS > working group has been consulted for something trying to set the 'Y' column. > >> While your idea sounds good it suffers from practical issues. I am >> worried that the process will not be too fair and may favor a certain >> type of community. >> > > At the risk of making predictions of the future, it's not clear to me > that the proposal will be any less fair than the current state of > affairs (which is not perfect, either). > > -Ben >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
