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

[Toerless Eckert <[e-mail]>]

Thanks, Paul

reply Q/answers inline

On Tue, Mar 14, 2023 at 06:43:13PM -0700, Paul Wouters via Datatracker wrote:
> 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.

I am not sure i correctly parse your concern, maybe rephrase unless the
following rewrite:

From:

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

   The format of each Assert Record is the same as the PIM assert
   message body as specified in Section 4.9.6 of [RFC7761].

To:
 *  Assert Record: formatted according to Figure 4, wich is the same
    as the PIM assert message body as specified in Section 4.9.6 of [RFC7761].
    The number M of Assert Records is determined from the packet size.


> 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?

Reply to Robert in:
  https://mailarchive.ietf.org/arch/msg/pim/6W54T7Cpj_tp_4JqytKnRmiNU6Q

Pls let me know if you see insufficiencies in that answer that would
cause a need for draft text enhancements in your opinion (such as what
i wrote to Robert).

Cheers
    Toerless