Re: [sidr] comments on draft-ietf-sidr-rfc6485bis

[Geoff Huston <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
> 
>> 
>> On 15 Apr 2014, at 12:43 am, Sandra Murphy <[e-mail]> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>