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(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)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: