Re: [Gen-art] Gen-ART LC review of draft-ietf-bmwg-issu-meth-01

Sarah Banks <sbanks@encrypted.net> Wed, 01 July 2015 19:29 UTC

Return-Path: <sbanks@encrypted.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B3E1B2B1F; Wed, 1 Jul 2015 12:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJn1GVx_vTeR; Wed, 1 Jul 2015 12:29:19 -0700 (PDT)
Received: from firefly.encrypted.net (firefly.encrypted.net [72.13.81.186]) by ietfa.amsl.com (Postfix) with ESMTP id 38BD61B2B2B; Wed, 1 Jul 2015 12:29:19 -0700 (PDT)
Received: from firefly.encrypted.net (localhost [127.0.0.1]) by firefly.encrypted.net (Postfix) with ESMTP id 3292D33DE0; Wed, 1 Jul 2015 12:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at encrypted.net
Received: from firefly.encrypted.net ([127.0.0.1]) by firefly.encrypted.net (firefly.encrypted.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j2y-dXdUxei; Wed, 1 Jul 2015 12:29:19 -0700 (PDT)
Received: from divinaair.global.tektronix.net (66-7-254-66.static-ip.telepacific.net [66.7.254.66]) by firefly.encrypted.net (Postfix) with ESMTPSA id 9024833DBD; Wed, 1 Jul 2015 12:29:18 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5AD4FA24-9CC5-4A69-882B-A3CE20823499"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Sarah Banks <sbanks@encrypted.net>
In-Reply-To: <0d5201d0b428$1b604590$5220d0b0$@gmail.com>
Date: Wed, 01 Jul 2015 12:29:18 -0700
Message-Id: <31168F63-A7E7-4223-8405-ABA2C42E3A68@encrypted.net>
References: <0d5201d0b428$1b604590$5220d0b0$@gmail.com>
To: Roni Even <ron.even.tlv@gmail.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/1ZE6-Yz9pHzR16p_tEdj_e-TNWg>
Cc: gen-art@ietf.org, draft-ietf-bmwg-issu-meth.all@tools.ietf.org, ietf@ietf.org
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-bmwg-issu-meth-01
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2015 19:29:21 -0000

Hi Roni,
	Thanks for your review of the draft, and comments below. With regards to the lack of any specific procedure, the idea was to provide several procedures, and allow the tester to choose, based on their testing needs/topology/etc. However, once a test has been chosen, we felt it best to have SOMETHING defined as required output, otherwise, how would you be able to compare ISSU results across vendors, apples to apples? To that end, we specified a short list of required info for the report, and then a longer list of optional information to include. So part of the info is required, and part isn't, and since part is, we chose to describe both in normative language. Does this make sense?

Thanks
Sarah

> On Jul 1, 2015, at 11:02 AM, Roni Even <ron.even.tlv@gmail.com> wrote:
> 
>  <>I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < <>http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>.
> 
> Please resolve these comments along with any other Last Call comments you may receive.
> 
> Document:  draft-ietf-bmwg-issu-meth-01
> Reviewer: Roni Even
> Review Date: 2015–7-1
> IETF LC End Date: 2015–7-2
> IESG Telechat date: 
>  
> Summary: This draft is ready for publication as an Informational  RFC.
> 
>  
> 
>  
> Major issues:
>  
> Minor issues:
>  
> According to the abstract this document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event. My reading is that it captures the typical procedures and as such is an informational document. It does not recommend any specific procedure yet it RECOMMEND in section 7 defines normative recommendation of which parameters SHOULD be reported in what I understand is a written statement.  I was wondering if all parameters are needed and when you can report only part of them , maybe just make it non normative 
> 
>  
> Nits/editorial comments:
>