Reviewer: Jon Geater Review result: Has Nits *Executive summary:* I see no obvious security problems _introduced_ by this document. Indeed, it’s trying to help plug holes caused by earlier work, which is to be applauded. In light of this I see no reason to object to the document, although the spectre of unreliable HBH processing remains a bit unsettling. I believe it would be an improvement for the security considerations section to include guidance that no security-relevant information should be included in HBH since there is no guarantee that it will be actioned, or fail close. *Observations:* * The document only has one author. Given numerous opinionated assertions about what is "realistic" and "useful" it would be good to see evidence that the broad IPv6 community agrees with the proposed limits (I acknowledge section 8 has good cover for this). * I’m a little confused why this would be “Informational” rather than Standards Track for 3 primary reasons: it claims to extend RFC8504; it includes a lot of normative language; it claims a primary benefit in interoperability. All of these imply a benefit to establishing some more formal normative content. I understand this changed along the life of the document but it now seems a little confused in that regard. * In contrast, the document is very discursive. Is all the justification and external referencing really necessary? While this is a great way of defending choices and establishing (rough) consensus, a specification document just needs to tell people what to do in a way that ensures they all do it the same. This discussion will go out of date eventually. * It’s interesting to me that this document is almost 3 years old by this point, had WGLC issues from at least 1 year ago, and has not been discussed officially at (at least) the past 3 IETF meetings. There has been modest discussion on the list and I am satisfied with the shepherd’s review but I think that emphasises the ‘Informational’ decision. Is there adoption/implementer support? * Many of the recommendations say a server SHOULD not do things unless it is sure every node on the route is able to deal with it. How can it possibly know this? Surely these amount to prohibitions (or a dare….) Why not be brave and say “this is the limit”? * Page 5: “The intent of default limits is to establish an expected baseline of support.” – again suggests this should be on Standards Track otherwise isn’t it essentially meaningless? * All in all this seems to point much more to a problem with the definition of HBH rather than the need for a new document. Coming back to my legitimate area of expertise the rather uncertain treatment of HBH options is troubling if they ever carry security sensitive information. In some ways it feels very similar to X.509 V3 extensions and the critical flag. But in and of itself it does not make the situation worse and offers some ideas for limited improvements. *Nits:* * Grammar/typo in Introduction: "[...] including a myriad of use cases those are obviously outside the realm of ever being realistic or useful [...]" should be "[...] including myriad use cases that are obviously outside the realm of ever being realistic or useful [...]" * typo top of page 5: “limited is exceeded” should be “limit is exceeded” * grammar/typo: “The potential for this DOS attack exists routers, hosts, and intermediate nodes.”. Missing “in”? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
