On 15 Apr 2014, at 12:43 am, Sandra Murphy <[email protected]> wrote:
> And one "I forgot": > > CAs and RPs SHOULD be capable of supporting a transition to allow for > the phased introduction of additional encryption algorithms and key > specifications, > > Is this any different than the algorithm agility in RFC6916? If so, I'd think > a reference would be good. If not, could you explain? > Yes, I could explain. <explanation> The RFC numbers should be a huge hint here. So why didn't RFC6485 have a reference to what was a non-existent document at that time? Do I really need to answer that question? </explanation> So why doesn't RFC6485bis fix all this, as you are suggesting here? So should a reference to RFC6916 be included in this draft? Well on the one hand I can't see why not, but... All this started out as a potential erratum note to RFC6485, and following advice from <random AD> that this constituted a technical change that was beyond the scope of an erratum, a bis update to RFC6485 itself was called for, with a narrow scope to address this particular issue. Section 8 of the draft describes the nature of the change, to allow the IESG and IETF LC review of this bis document to concentrate on precisely that change, as advised in the WG meeting at the time from <random AD>. But it seems that you are advocating an expanded brief for this bis document and when cleaning up the references to related work then we should also look at the rest of the document to see how it meshes with later published RFCs as well. Right? (Parenthetically, the expanding scope of this work is a worry, and I can't help but wonder if all this is productive use of everyone's time. Maybe we should also be reflecting on http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/ and contemplate the nature of the difference between adequacy and a quest for perfection.) Thanks, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
