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 On 26/08/2013, at 12:40 AM, Andy Newton <[email protected]> wrote: > 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
