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

["Roque Gagliano (rogaglia)" <[e-mail]>]

Hi Geoff/Sandy,

Agree that we can void the mention on the current status of the known RP. As the due-diligence was done, I am fine.

I think your proposed text  from Geoff goes well with the intention of the original text (at least with the first sentence).It is just a matter of how explicit we want to be in the consequences of not implementing the changes on this document for RP parties. We and go with only his sentence or adding the two sentences:

"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. A relying party that performs a strict validation based on RFC6487 and fails to support the updates described in this document, would incorrectly invalidate RPKI objects that implements the changes in Section 2."

Roque



On Aug 24, 2013, at 12:03 AM, Geoff Huston <[e-mail]> 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" <[e-mail]> 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 [[e-mail]]
>> Sent: Tuesday, July 16, 2013 9:49 AM
>> To: Roque Gagliano (rogaglia)
>> Cc: Murphy, Sandra; [e-mail]
>> 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)" <[e-mail]> 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 <[e-mail]> wrote:
>>> 
>>>> On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" <[e-mail]>
>>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>