Re: [sidr] WGLC on draft-ietf-sidr-bgpsec-threats-02

[Brian Dickson <[e-mail]>]

s/2414/2418/ - my bad.

On Wed, Aug 15, 2012 at 4:25 PM, Brian Dickson <
[e-mail]> 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 <[e-mail]>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 [[e-mail]]
>> *Sent:* Tuesday, August 14, 2012 5:20 PM
>> *To:* Murphy, Sandra
>> *Cc:* [e-mail]
>> *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 <
>> [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sidr
>>>
>>
>>
>