comments on draft-banks-bmwg-issu-meth-01

BMWG,

Some comments on draft-banks-bmwg-issu-meth-01

Al (as a participant)

-=-=-=-=-=-=-=-=-=-=-=-=-
ISSU Comments

Sec 1. describing "expectations"
Comment: need to make this a bit more clear whose expectations these are, as in "not the BMWG's". It would be reasonable to characterize these as "Some Operator's expectations" if that's the case. Also that this list is information to motivate the work, not an implicit set of requirements on ISSU.

Sec 3.1
"...downloading
      software can skew timing results based on factors that are often not
      comparative in nature."
Suggest: 
... often not viable for comparisons.

later in Sec 3.1
"...Where such mechanisms are made
      available by the product, they should be verified, by the tester,
      with the perspective of avoiding operational issues in production."
Suggest:
... should be verified by the tester before proceeding (see Section 3.2), as would be done in an operational environment.
( I see this is also covered in 3.2, so refer the reader there)

Section 3.2
"In this second phase, the requested software package is loaded into
      the pertinent components of a given forwarding device (typically the
      RP in standby state)."
Suggest:  (because you refer to this RP later by name)
      In this second phase, the requested software package is loaded into
      the pertinent components of a given forwarding device (typically the
     secondary  RP in standby state).  
     ^^^^^^^^^^

Section 3.3
"In this phase, the secondary RP takes over, forcing the RP which was
      previously designated as primary, to adopt the standby role. At this
      point, the new primary RP drives the required updates to other
      specific components and forces warm-updates or re-initializations
      with the new software, as applicable. In addition, the now-standby
      RP will be updated with the desired software."
Suggest:
   In this phase, the secondary RP takes over, forcing the RP 
      previously designated as primary to adopt the standby role. At this
      point, the new primary RP drives the required updates to other
      specific components and forces warm-updates or re-initializations
      with the new software, as applicable. In addition, the now-standby
      RP will be updated with the desired software.
Add:
     This phase is complete when ... (required updates are complete, 
     including the now-standby RP ??)
 
Section 4.2
spell-out NMS at first use.

Sections 4 and 5:
The current practice in BMWG is to use the template originated 
in RFC 1242 to define terms and benchmarks (metrics).
 - some form of template to organize material here would help.
 - is the RFC 1242 template still preferred, or should others be used?

Section 5.3
s/mastership/primary control/