yes - I quite agree that your first set of comments were entirely within scope for this update to RFC6485, and well made. I will get around to a response to indicate how these issues will be integrated into the draft.
Geoff On 17 Apr 2014, at 1:31 am, Sandra Murphy <sa...@tislabs.com> wrote: > Ruefully, I note that the chairs requested that the comments be limited to > those needed to introduce the correction. > > It is ironic that it was a discussion at IETF76 Nov 09 about this very part > of draft-ietf-sidr-rpki-algs-01 that led the Security AD to instruct the wg > to produce a transition plan that became RFC6916. > > I withdraw this comment. > > My other comments, however, were focussed on incomplete melding of the > correction with the existing text. RC6485 mentions only one OID and > algorithm so there was no question of what OID and algorithm should be used > wherever such things were mentioned. Now, with three OIDs and algorithms, > the text needs to be clear as to what is used where. > > --Sandy, speaking as regular ol' member > > > On Apr 15, 2014, at 6:00 PM, Geoff Huston <g...@apnic.net> wrote: > >> >> On 15 Apr 2014, at 12:43 am, Sandra Murphy <sa...@tislabs.com> 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
