On Wed, Sep 18, 2013 at 3:16 PM, Murphy, Sandra <sandra.mur...@parsons.com> wrote: > Looks like this is the final word. > > Consensus of the wglc is that the document is good to go, with revisions. > > Draft authors, could you please submit a new version with the wording > suggested below? >
draft-authors: "Y U NO SEND DRAFT UPDATE?" :) > 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 implement the changes in Section 2. > > Note this includes one nit change of "implements" to "implement". > > Please also consider the nits mentioned in the message: > http://www.ietf.org/mail-archive/web/sidr/current/msg06124.html > > --Sandy, speaking as wg co-chair > > > ________________________________________ > From: Roque Gagliano (rogaglia) [rogag...@cisco.com] > Sent: Monday, August 26, 2013 4:18 AM > To: Geoff Huston; Murphy, Sandra > Cc: Andy Newton; sidr@ietf.org list > Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00 > > 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 <g...@apnic.net> 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" <sandra.mur...@parsons.com> >> 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 [a...@arin.net] >>> Sent: Tuesday, July 16, 2013 9:49 AM >>> To: Roque Gagliano (rogaglia) >>> Cc: Murphy, Sandra; sidr@ietf.org >>> 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)" <rogag...@cisco.com> 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 <a...@arin.net> wrote: >>>> >>>>> On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" <rogag...@cisco.com> >>>>> 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 >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
