Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00

yes, but whats "old" and "new" is relative to when this draft is read. If you want it to read logically 3, 5 or 10 years from now I'd gently suggest that we generalise the text. After all its not the daily news, its an update to a technical spec that is supposed to last a little longer than just today. Or are we really just writing postit notes that folk are supposed to forget the day after tomorrow? (3/4 :-))

Geoff

On 26/08/2013, at 12:40 AM, Andy Newton <andy@arin.net> wrote:

> You are exactly right, but I think Rogue's text connects the dots on using
> old RP software.
> 
> -andy
> 
> On 8/23/13 6:03 PM, "Geoff Huston" <gih@apnic.net> wrote:
> 
>> Wouldn't it be better to note that: As an update to RFC6487, this
>> document broadens the class of certificates that conform to the RPKI
>> profile by explicitly including within the profile those certificates
>> that contain a policy qualifier as described here.
>> 
>> Geoff
>> 
>> 
>> 
>> On 24/08/2013, at 4:09 AM, "Murphy, Sandra" <Sandra.Murphy@parsons.com>
>> wrote:
>> 
>>> Speaking as working group chair:
>>> 
>>> I can't be certain that this indicates a promise to modify the draft or
>>> not.  Roque, Andy, could you comment?
>>> 
>>> If so, a new version is needed and I'll say so on the list.
>>> If not, I'll have to ask for resolution on list.
>>> 
>>> Speaking as regular ol' member (and a bit as wg chair, as I'm not clear
>>> about the intent of the new text):
>>> 
>>> I don't think this text hurts anything, but I am puzzled about the
>>> intent.  If "all known" implementations comply, why mention the problem?
>>> OTOH, it might serve to forestall AD/IESG questions.
>>> 
>>> So I agree with Andy's observation, though I'd say a heading "Backward
>>> Compatibility Considerations" rather than "Interoperability
>>> Considerations" suits the situation better.
>>> 
>>> (Apologies - searching for the thread, I found these comments stuck in
>>> my draft folder from 17 July.)
>>> 
>>> --Sandy
>>> 
>>> P.S.  
>>> 
>>> "strick"->"strict"
>>> "RPKI signed objects" -> "RPKI objects" <because you mean CA certs as
>>> well and signed objects might be taken to mean only ROAs and
>>> ghostbusters and manifests etc>
>>> "implements"->"include" or "contain" or...
>>> "RP"-> relying party (or you'll have to define the acronym somewhere)
>>> Not sure what ""as in IDR" means.
>>> 
>>> ________________________________________
>>> From: Andy Newton [andy@arin.net]
>>> Sent: Tuesday, July 16, 2013 9:49 AM
>>> To: Roque Gagliano (rogaglia)
>>> Cc: Murphy, Sandra; sidr@ietf.org
>>> Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00
>>> 
>>> This sounds fine to me, though it is really an interoperability
>>> considerations section thingy. The IETF does those now, right? :)
>>> 
>>> -andy
>>> 
>>> On 7/16/13 4:55 AM, "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
>>> wrote:
>>> 
>>>> Thanks Andy.
>>>> 
>>>> Do you think we need to add something in the security section about the
>>>> transition?
>>>> 
>>>> Something like:
>>>> 
>>>> "A RP that performs a strick validation based on RFC6487 and fails to
>>>> support the updates described in this document, would incorrectly
>>>> invalidate RPKI signed objects that implements the changes in Section
>>>> 2.
>>>> At the time of this writing, all known RP software suites (you can
>>>> mention them as in IDR) were tested and supported the updates on this
>>>> document"
>>>> 
>>>> Roque
>>>> 
>>>> On Jul 15, 2013, at 7:07 PM, Andy Newton <andy@arin.net> wrote:
>>>> 
>>>>> On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
>>>>> wrote:
>>>>> 
>>>>>> Before sending my support to advance to the IESG, I wanted to ask the
>>>>>> author if they have tested the effects of this change on existing RP
>>>>>> tools. Do they really set the certificate as invalid?
>>>>> 
>>>>> Yes, we have tested against the three RP suites. One did not require a
>>>>> change while the other two required simple one line changes. Current
>>>>> releases of all three now accommodate it.
>>>>> 
>>>>> -andy
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>> 
> 
> 