[bmwg] Fwd: Re: New Version Notification - draft-ietf-bmwg-dsmterm-13.txt

BMWG,

The message below summarizes progress on resolving IESG
the feedback from IESG review on the dsmterm draft.
Note that DISCUSS ballots are blocking comments, so we're
working to resolve them in detail with the relevant Area Director.

A full summary of votes and other action is viewable here:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6799&rfc_flag=0

(posting this on the list will hopefully save some time
in our very full agenda)

Al
bmwg co-chair

>Date: Wed, 28 Jun 2006 11:59:09 -0400
>To: david.kessens@nokia.com, housley@vigilsec.com
>From: Al Morton <acmorton@att.com>
>Subject: Re: New Version Notification - draft-ietf-bmwg-dsmterm-13.txt
>Cc: Dan Romascanu <dromasca@avaya.com>
>
>At 03:50 PM 6/27/2006, ID Tracker wrote:
>>New version (-13) has been submitted for draft-ietf-bmwg-dsmterm-13.txt.
>>http://www.ietf.org/internet-drafts/draft-ietf-bmwg-dsmterm-13.txt
>
>Russ,
>
>Regarding Tero's comments, which were the basis for your DISCUSS
>on the -12 draft, the following actions have been taken in this
>version:
>
>Tero wrote:
>>This document defines terminology, so it does not really have any
>>   security issues to cover.  The security considerations section does
>>   warn against doing benchmarking on devices or systems connected to
>>   production networks.  Perhaps it should also say that benchmarking
>>   services MUST be disabled by default, which would require a
>>   configuration change in order to perform benchmarking.  This is real
>>   concern if these services enable amplification attacks.  For example,
>>   send one packet, and get more than one packet back.
>
>"Disabling benchmarking services" is not an actionable
>requirements for the tester, since the DUT/SUT
>configuration is not unique to benchmarking, except for
>BMWG's private address space (another means which protects
>live networks from BMWG testing).
>
>"Benchmarking services" on a DUT/SUT are incompatible with
>"black box testing", and black box is where we live and work,
>therefore such services are an unfamiliar concept.
>
>The Editors and I have attempted to resolve this comment directly
>with Tero, but he has not responded.
>
>Proposed Resolution:  No Action.
>
>Tero wrote:
>>The document uses MUST/SHOULD in situations that are not possible to
>>   verify whether it was followed or not.  For example the section 2
>>   says: "RFC 1242 ... SHOULD be consulted before attempting to make
>>   use of this document".  This use of "SHOULD" ought to be changed to
>>   "should".  There are several others that ought to be changed too.
>
>This comment has been fully addressed in -13 version.
>
>Proposed Resolution:  Changes adopted in -13.
>
>FYI - The COMMENTS lodged against the draft have also been fully
>addressed in verion -13.
>
>Please reconsider your DISCUSS position.
>
>thanks,
>Al

_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg