Reviewer: Robert Sparks Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments. This document is ready (but has nits) for publication as a Proposed Standard RFC I found no specific security issues (unless the below tickles something for you). If you touch it again, consider rementioning the greater impact of loss of a PackedAssert. This is more of a question than a nit, but it didn't feel like something to flag as an issue. There's discussion of not using packing unless all PIM routers in the same subnet have announced the Assert Packing Hello Option. What happens in a running environment that is busy using packing when a new PIM router is added? If traffic from that PIM router is seen that is not yet the needed Hello Option, should all senders stop packing until the needed Hello Option arrives, and maybe resend recently packed asserts as unpacked? Nits: The last two paragraphs of the Problem Statement are not part of the problem statement - they are more of a discussion of alternate, likely unsatisfactory, solutions. Maybe they can be removed, or put somewhere else? Third paragraph of section 3.2 says "If the (P) flag is 2". I think you meant 1? At 3.3, it would be more complete to acknowledge that the timing of the delivery of the asserts is also affected, not just the compactness of the encoding. The second bullet in section 3.3.1 took several reads to iron out the logic - this may be an English vs other language convention thing. Consider this alternative: " When any PIM routers on the LAN do not support Assert Packing, implementations MUST send only Asserts and MUST NOT send PackedAsserts under any condition." I think that says the same thing. Additionally, I would go further and say "have not signaled support for Assert Packing" rather than "do not support Assert Packing". The paragraph after that bullet contains "to finally packe PackedAssert". Typo at packe. I found the quotes around "sufficient" very distracting at the last paragraph of 3.3.1. Please consider reconstructing the paragraph to avoid the urge to use the quotes. Maybe unquote the first "sufficient", and define a word called SIZE described by the first two sentences. Then use SIZE in the rest of the instances. This may just be a style comment, but the quoted form brings communication baggage you didn't intend. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
