Eric: > This seems to me to be a set of distinct questions from this liaison > statement. It seems to me that there are at least three main cases > here: > > 1. Algorithms which the IETF is working on and is going to recommend > and/or has recommended (Recommended=Y) > 2. Algorithms which the IETF is working on but is not going to recommend. > 3. Algorithms which the IETF is not working on > > Case (1) requires an RFC publication and therefore I think we can ignore > this one for this discussion. Case (3) will not be published as an RFC > and so people who want to implement them just need to rely on the I-D > or whatever other document was provided to the experts, and the > code point reflects that document. > > This leaves us with Case (2). I agree that it's useful for third parties > to be able to distinguish whether a given notional algorithm is > "finished" in the sense that the IETF might publish an updated > version of that algorithm, potentially with a different code point. > That normally happens with RFC publication, but we find ourselves > in the difficult case where an algorithm *is* being worked on in the > IETF but there is real contention about whether it should be published [0], > leaving us in an unfortunate situation. This case should be rare, > however, because algorithms which are adopted are typically > published, and I don't think it's particularly hard to distinguish from > cases like draft-10 of some future version of TLS. > > If this document is published as an IETF RFC, then the problem will go > away. If not, then there will be a number of choices: > > - The ISE can publish the document as an RFC (assuming the ISE > is willing.) > - The external SDO can publish their own document specifying > the algorithm, potentially using some content form this one [1]. > - The external SDO can hold their nose and cite the I-D. > > Of course these are also the exact same choices said SDO > would have if the IETF had never taken up the document in the > first place.
The case we are talking about is an algorithm document that was adopted by the TLS WG. Of course, adoption is not a guarantee that there will be an RFC; however, it does signal to other that the TLS WG is planning to do so. Russ
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
