Ballot for draft-irtf-icnrg-pathsteering
Yes
No Objection
Recuse
Note: This ballot was opened for revision 02 and is now closed.
Ballot question: "Is this draft ready for publication in the IRTF stream?"
I reviewed this document for the IRSG; the changes in -02 addressed my comments from that review, thanks! This document is IMO ready for publication.
I'm a No Objection with a couple of comments, but I applaud ICNRG for taking this work on at all - I understand it's a difficult problem. I imagine many readers already know what a FIB is, but perhaps it should be expanded on first use. I'm a little confused by error handling in 2.3. ISTM that what's being described is more like IF consumer has requested normal LNPM FIB lookup when an invalid path label is detected THEN do the normal lookup when an invalid path label is detected ELSE respond to the Interest with an Interest-Return Is that wrong? Perhaps this would be clearer if the order of the decisions were reversed in the text. But, ignoring that, why would responding to the Interest be a SHOULD? More succinctly, I read SHOULDs as MUST UNLESS - what foreseeable conditions would justify forwarder not responding to the Interest? And, of course, if the consumer hasn't requested normal LNMP FIB lookup, and the forwarder doesn't respond with an Interest Return, what is the effect of that decision - what happens next for the consumer, the forwarder, and the interest? Does the Interest just keep sending data that the forwarder doesn't forward? In 2.5, "This should match the scalability of today's commercial routers that support up to 4096 physical and logical interfaces and usually do not have more than a few hundred active ones." is an assertion of fact - it should probably say "This matches the scalability of today's commercial routers that support up to 4096 physical and logical interfaces and usually do not have more than a few hundred active ones. Thank you for the level of detail in the Security Considerations section.
Am co-author