Benchmarking Methodology for In-Service Software Upgrade (ISSU)
RFC 7654
Yes
(Joel Jaeggli)
No Objection
Alvaro Retana
(Alia Atlas)
(Barry Leiba)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 01 and is now closed.
Alvaro Retana
No Objection
Joel Jaeggli Former IESG member
Yes
Yes
(for -01)
Alia Atlas Former IESG member
No Objection
No Objection
(for -01)
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-08-05 for -01)
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
Barry Leiba Former IESG member
No Objection
No Objection
(for -01)
Ben Campbell Former IESG member
No Objection
No Objection
(for -01)
Benoît Claise Former IESG member
No Objection
No Objection
(2015-08-05 for -01)
- 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)
Jari Arkko Former IESG member
No Objection
No Objection
(for -01)
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-08-04 for -01)
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)
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-08-05 for -01)
- 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)