s/2414/2418/ - my bad. On Wed, Aug 15, 2012 at 4:25 PM, Brian Dickson < [email protected]> wrote:
> I'll try to be more clear: > > I do not believe comments regarding _any_ version of the draft in > question, have been adequately addressed (on the mailing list, or in > person, or in the document). > > There are a number of topics of contention, and I believe it is the duty > of the chairs, not my responsibility, to track the specific items in > question. > > To quote from RFC 2414, section 3.3: > > It is occasionally appropriate to revisit a topic, to re-evaluate > alternatives or to improve the group's understanding of a relevant > decision. However, unnecessary repeated discussions on issues can be > avoided if the Chair makes sure that the main arguments in the > discussion (and the outcome) are summarized and archived after a > discussion has come to conclusion. > > I would respectfully point out the dates of the discussion, and a few of the > subject lines, as follows: > > "BGP Thread Model ID" (between 10/29/2011 and 11/14/2011, covering a number > of intertwined issues, where the author effectively states that he will only > change the text at the direction of the Chair(s), and where there are a > significant number of participants who express a desire to have the text > changed.) > > "Route Leaks message to IDR" (3/21/2012 onward) > > Also, given that draft-dickson-sidr-route-leak-solns exists and has not > expired, and that IDR has been asked to review the route-leaks issue, and > have themselves asked GROW to take a look at it, it would be more appropriate > to have the -threats- doc refer to this draft, and to the ongoing IETF > process of codifying route-leaks, rather than disingenuously continuing to > state that nothing codifies route-leaks in the IETF. > > (Technically, discussions in the mailing list archive are IETF materials, at > the very least, as are current unexpired I-D docs.) > > Even without going into whether or not it is codified officially, the > codification can easily be incorporated into the -threats- doc, in the > residual threats. > > The importance of this is that in considering the body of work of the WG, and > in particular potentially deploying BGPSEC (in whatever form it emerges), > operators _must_ be given all the necessary information, including whether > BGPSEC protects against threats that actually exist. Pretending the threats > do not exist, by not detailing them in the "Residual Threats" section, is > really not what I would consider IETF-worthy. > > So, in summary: > > - if the chairs cannot find a volunteer to summarize and track the major > issues related to WG discussion (on-list and in-person) that affect the > -threats- doc, their duty is to do it themselves. > > - I would like to see an assertion on each major issue, the following: > > --- has it been discussed to death? > > --- has consensus been reached (either way) about whether it should be > included in the -threats- doc? > > --- has the threats doc adequately addressed the issue (and if so, in which > section)? > > What I am contending is, that one or more issues have either reached an > impasse (and thus the -threats- doc, as such, does not have rough consensus), > or have a consensus which the doc does not incorporate adequately. > > Is that enough to act on? > > Oh, and in case it isn't abundantly clear: > > I do not support moving the document forward in its current state. > > Brian > > > On Wed, Aug 15, 2012 at 1:56 PM, Murphy, Sandra > <[email protected]>wrote: > >> Brian, I can see that you think that some people brought up some issues >> some time ago on some previous version(s) that have not been addressed. >> >> Unfortunately, that's not clear enough for the chairs or authors to take >> action. >> >> It would help if you could provide more specifics. >> >> --Sandy, speaking as wg co-chair >> >> ------------------------------ >> *From:* Brian Dickson [[email protected]] >> *Sent:* Tuesday, August 14, 2012 5:20 PM >> *To:* Murphy, Sandra >> *Cc:* [email protected] >> *Subject:* Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02 >> >> I have reviewed the draft. >> >> It remains vague and incomplete, in the Residual Threats section. This, >> despite extensive discussion (since the -00 version) on the list regarding >> very specific, very real, residual threats. >> >> It not only fails to discuss them, it fails to enumerate them. >> >> The extensive discussion is in the archives, and contains substantive >> comments from at least 1/4 active participants in SIDR, including those >> with the greatest degree of operational and/or implementation experience. >> >> I would request that the WGLC be retracted until the authors decide to >> address those previous comments. >> >> Chairs: There should not be a need to re-raise the particulars - if the >> authors got shot down before, and fail to include text or address the >> complaints, I fail to see why they are submitting this, or the chair(s) are >> doing a WGLC. >> >> The objective of a threats model should be to model the threats, and >> identify known weaknesses. If it is substantially incomplete, it is not >> ready to go. It fails to accomplish its _only_ goal. >> >> Excluding threats from this doc, because the solution does not address >> them, is beyond ridiculous. It is laughable. >> >> Sorry if this offends the authors. The authors' work is at issue, not >> the authors themselves. They are fine and upstanding individuals. This ID, >> in its current form, however, is, IMHO, junk. >> >> Brian >> >> On Tue, Aug 14, 2012 at 12:19 PM, Murphy, Sandra < >> [email protected]> wrote: >> >>> The authors have indicated that they believe the draft >>> >>> Threat Model for BGP Path Security >>> draft-ietf-sidr-bgpsec-threats-02 >>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-02 >>> >>> is ready for a working group last call. >>> >>> This starts the two week working group last call. It will end on Aug >>> 28. Please review the draft and send comments to the list. >>> >>> --Sandy >>> _______________________________________________ >>> sidr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/sidr >>> >> >> >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
