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

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 23 Aug 2013 18:09:18 +0000

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 [[email-masked]]
Sent: Tuesday, July 16, 2013 9:49 AM
To: Roque Gagliano (rogaglia)
Cc: Murphy, Sandra; [email-masked]
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)" <[email-masked]> 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 <[email-masked]> wrote:
>
>> On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" <[email-masked]>
>> 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
>>
>
>

---

From: Geoff Huston <[email-masked]>
Date: Sat, 24 Aug 2013 08:03:36 +1000

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" <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Andy Newton <[email-masked]>
Date: Sun, 25 Aug 2013 14:40:06 +0000

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" <[email-masked]> 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
>
>
>
>> 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.
>> 
>> "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>

---

From: Geoff Huston <[email-masked]>
Date: Mon, 26 Aug 2013 07:22:41 +1000

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

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 26 Aug 2013 08:18:56 +0000

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