[pim] Paul Wouters' No Objection on draft-ietf-pim-assert-packing-10: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-pim-assert-packing-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-assert-packing/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

        M: The number of Assert Records in the message. Derived from the length
        of the packet carrying the message.

I find it a bit odd that this section describes packet fields, and then lists a
"field" that is not a real field but a derivation. Can this not be written
without the "M:" classifier and outside of the list describing the packet
fields? This occurs a number of times in the document.

Like Robert Sparks, I am interested his question from the secdir review:

   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?