Benchmarking Methodology for In-Service Software Upgrade (ISSU)
draft-ietf-bmwg-issu-meth-02
Yes
(Joel Jaeggli)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Barry Leiba)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 01 and is now closed.
Joel Jaeggli Former IESG member
Yes
Yes
(for -01)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -01)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-08-05 for -01)
Unknown
Section 3: OLD Note that, a given vendor implementation may or may not permit the abortion of the in-progress ISSU at particular stages. NEW Note that, a given vendor implementation may or may not permit halting the in-progress ISSU at particular stages. OLD the test plan document should reflect these and other relevant details and SHOULD be written with close attention NEW the test plan document should reflect these and other relevant details and should be written with close attention
Alvaro Retana Former IESG member
No Objection
No Objection
(for -01)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -01)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -01)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2015-08-05 for -01)
Unknown
- Some discrepancies regarding MUST, SHOULD, MAY One one side: The hardware configuration of the DUT SHOULD be identical to the one expected to be or currently deployed in production One the other side: the feature, protocol timing and other relevant configurations should be matched to the expected production environment. Note: potentially some other discrepancie with lower/upper case MUST/SHOULD/MAY - expand "NSR" nits: - point missing in the abstract - section 1 title is wrongly formatted
Deborah Brungard Former IESG member
No Objection
No Objection
(for -01)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -01)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-08-04 for -01)
Unknown
In section 3, when "other checks" are described, I'd like to see an explicit mention of a check to ensure the device is authorized to install the software/firmware. There have been numerous attacks against just about every vendor where counterfeit hardware is deployed and runs the firmware, OS, etc. issued. Fraud can be a big issue and it isn't always talked about, but this should definitely be a security consideration. I do think it fits in the subsections of section 3. The statement added can be as simple as, "check performed to ensure the device is authorized to install the firmware".
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -01)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-08-05 for -01)
Unknown
- I was a bit surprised there was no reference to software signing here (only checksums are mentioned). The difference is that signature verification can also sometimes require e.g. an OCSP lookup to check for revocation and that could I guess impact on benchmarking. (The secdir reviewer also made this point.) - Kathleen makes a good point in her comment too.
Terry Manderson Former IESG member
No Objection
No Objection
(for -01)
Unknown