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 <[email protected]> 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" <[email protected]> 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 [[email protected]] >> Sent: Tuesday, July 16, 2013 9:49 AM >> To: Roque Gagliano (rogaglia) >> Cc: Murphy, Sandra; [email protected] >> 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 protected]> 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 protected]> wrote: >>> >>>> On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" <[email protected]> >>>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
