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

Hi Al, BMWG,
	Thanks for the feedback. We'll work on addressing these in the next revision, after we meet in Berlin. I think your suggestions are great; the comments surrounding Section 3.3 are ones I'd like to review with the other editors first. Thanks again for the thorough review!!

Regards,
Sarah

On Jul 23, 2013, at 11:02 AM, "MORTON JR., ALFRED C (AL)" <[email protected]> wrote:

> 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/
> 
> _______________________________________________
> bmwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bmwg