Support for Adjustable Maximum Router Lifetimes per Link
RFC 8319
Yes
No Objection
Recuse
Note: This ballot was opened for revision 03 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
I like what the document does, but it could really really do with a good editing pass; I've sent some nits / comments to Suresh off-list. Some bits I was unable to parse, but I trust Suresh to fix them. I'm a bit surprised it doesn't mention RFC7772 - it feels very related to me, but I may just be wrong!
(Terry Manderson; former steering group member) Yes
(Adam Roach; former steering group member) (was Discuss) No Objection
Thanks for addressing my discuss and comment. I find the formulation in the document being updated problematic, but you've done a deft job of not repeating the error in this document.
(Alexey Melnikov; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
Editorial Comments: - Abstract: Please mention the fact this updates 4861 in the abstract. - Given that there are at least a few "should" and "must" instances in lower case, please consider using the boilerplate from 8174 rather than 2119.
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
I'm just testing something, and wanted to get a protocol trace. Will look at draft later.
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
Just one quick question to double-check: Are the defaut values in RFC4861 still recommended or not? Maybe note this in the text to avoid any confusion! Also, as already noted in the sphepherd write-up, the abstract should mention the update.
(Spencer Dawkins; former steering group member) No Objection
Everyone likely knows this, but is it worth adding a suggestion to retry rejected RAs with a Router Lifetime of more than 9000 seconds, with a new RA that uses 9000 seconds? 5. Host Behavior Legacy hosts on a link with updated routers may have issues with a Router Lifetime of more than 9000 seconds. In the few implementations we have tested with general purpose operating systems, there does not seem to be any issues with setting this field to more than 9000, but there might be implementations that incorrectly (since RFC4861 requires receivers to handle any value) reject such RAs. I think this meshes with Mirja's suggestion to state whether 9000 is still the default ...
(Suresh Krishnan; former steering group member) Recuse
I am an author.