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 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 > > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
