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
