Hi Everyone,
Thanks Alvaro, David and Behcet for the careful review. Draft-14 has been posted. Response to comments: 1) 262 For IPv4 PIM Packed Null-Register messages or PIM Packed Register- 263 Stop messages, the DR may perform Path MTU Discovery, but for IPv6 264 this is mandatory. Is there a reason to not use Normative language? IPv4 SHOULD...IPv6 MUST... For IPv6 PIM Packed Null-Register messages or PIM Packed Register-Stop messages, the DR MUST perform Path MTU Discovery. For IPv4 the DR SHOULD perform Path MTU Discovery. 2) 239 When the DR switches to Data Registers from Null-Registers, it should 240 start a Packed_Register_Probe_Time timer. [] "it should start a Packed_Register_Probe_Time timer" "should"? Should this be SHOULD or MUST? If "SHOULD", when it is ok to not start the timer? “When the DR switches to Data Registers from Null-Registers, it MUST start a Packed_Register_Probe_Time timer. “ This is only one of the ways to detect an upgrade/downgrade. We were hoping to leave it up to the implementation, but the timer method would be probably the best. 3) Authors: Also, the headers in Figures 2 and 3 should be updated to the one in Figure 5/rfc8736: >> Changed as suggested. Nits/editorial comments: Nits: >From IETF ID nits tool: ** Downref: Normative reference to an Informational RFC: RFC 3446 >> I had it as an informative reference in Draft#11, but we received a review comment to change it to normative: https://datatracker.ietf.org/doc/draft-ietf-pim-null-register-packing/11/ The PIM Packed Null-Register format should be enabled only if it is supported by all PIM Anycast RP with MSDP members in the RP set for the RP address. s/multiple PIM Null-Registers [RFC7761] and Register-Stops [RFC7761]/ multiple PIM Null-Registers and Register-Stops [RFC7761] Changed as Suggested ... > Flag Bit 7 in PIM common header is defined as Capability bit but in Figure 1 > and throughout the draft it is marked as P bit not as C bit That is meant to be the Packed Capability, hence "P". But you bring up a good point in that the terminology is not consistent. The text should be consistent in using "packet capability" (vs just "capability"). The draft now explicitly defines the P-bit as “Packing Capability”. [EoR] Thanks, Ananya From: Alvaro Retana <[email protected]> Date: Wednesday, February 15, 2023 at 11:22 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, Ananya Gopal (ananygop) <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Ramakrishnan Chokkanathapuram Sundaram (ramaksun) <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [IANA #1266260] Last Call: <draft-ietf-pim-null-register-packing-13.txt> (PIM Null-Register packing) to Proposed Standard On February 15, 2023 at 12:36:24 PM, David Dong wrote: David: Hi! Your question triggered a quick review: > IANA Question --> Should the Flag Bits for each of these message types be > set to: "0-7: Reserved" ? In short, the answer is: No, they should be set to "0-3: Reserved". We're using the extended types defined in rfc8736, so the next available types are 13.0 and 13.1. Authors: Also, the headers in Figures 2 and 3 should be updated to the one in Figure 5/rfc8736: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type |Subtype| FB | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Subtypes Sorry for missing this before. Thanks! Alvaro.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
