Re: [auth48] [AD] AUTH48: RFC-to-be 9466 <draft-ietf-pim-assert-packing-12> for your review

[Michael McBride <[e-mail]>]

H Sarah,

Yes, that is a valid email address for Sandy. Sometimes .cn emails bounce for me as well. Let's see if it bounces now.

Thanks,
mike


-----Original Message-----
From: Sarah Tarrant <[e-mail]>
Sent: Friday, September 22, 2023 7:11 AM
To: RFC Editor <[e-mail]>; Yisong Liu <[e-mail]>; [e-mail]; [e-mail]; Michael McBride <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [AD] AUTH48: RFC-to-be 9466 <draft-ietf-pim-assert-packing-12> for your review

Hi Authors,

We received a bounce message for Zheng(Sandy) Zhang <[e-mail]>. Do you know if this is still a valid email address? Please provide us with updated contact information.

Thank you,
RFC Editor/st

> On Sep 21, 2023, at 10:59 AM, Sarah Tarrant <[e-mail]> wrote:
>
> Greetings,
>
> Just a friendly weekly reminder that this document awaits your attention.
>
> Please see the document-specific questions and AUTH48 announcement in this thread and let us know if we can be of assistance as you begin the AUTH48 review process.
>
> Please note that the AUTH48 status page of this document is viewable at:
> http://www.r/
> fc-editor.org%2Fauth48%2Frfc9466&data=05%7C01%7Cmichael.mcbride%40futu
> rewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8ff2a3b240189c753a1
> d5591fedc%7C1%7C1%7C638309886488749747%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=gDGVp5ODeK7zcPGuSe911fLJIAv4NfhZ%2FAsClWZGkTY%3D&reserved=
> 0
>
> AUTH48 FAQs are available at https://www.rfc-editor.org/faq/#auth48.
>
> We look forward to hearing from you at your earliest convenience.
>
> Thank you.
> RFC Editor/st
>
>> On Sep 14, 2023, at 3:24 PM, [e-mail] wrote:
>>
>> Authors and *AD,
>>
>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>
>> *AD, please review question #1.
>>
>>
>> 1) <!-- [rfced] *AD - Please review the diff between version 11 and
>> version 12 (note that version 11 was approved for publication) and
>> let us know if you approve the following changes:
>>
>> - change in Section 2 (L5 to L3)
>> - deleted text in Section 3.3.1
>>
>> https://aut/
>> hor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-pim-assert-packing-12
>> &data=05%7C01%7Cmichael.mcbride%40futurewei.com%7Cb143facb73b7416782f
>> b08dbbb75b52f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C6383098864
>> 88749747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
>> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d0IyutNbIAhXVRRP
>> DpZPrxlF7MHY7NvergXFKZeINXo%3D&reserved=0
>> -->
>>
>>
>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear
>> in the title) for use on https://www.rfc-editor.org/search.
>> -->
>>
>>
>> 3) <!-- [rfced] This is a question for author Zheng Zhang. Please let
>> us know how you would like your name to appear in the Authors'
>> Addresses section for this document. We will make note of your
>> preference for future documents as well.
>>
>> This form is used in this document and 9279:
>>  Zheng(Sandy) Zhang
>>
>> This form was used in 8916:
>>  Zheng Zhang
>>
>> If we keep the form with "Sandy", may we add a space before the first
>> parentheses (i.e., "Zheng (Sandy) Zhang")?
>> -->
>>
>>
>> 4) <!-- [rfced] Please review "PIM-SM shared LAN networks" in the
>> following sentences from the abstract and introduction and let us know if "PIM-SM"
>> is needed in this context. We see "shared LAN network" used elsewhere
>> in the document, and PIM-SM is used in the next sentence of the
>> abstract (included for context). Or should this text be updated to
>> "When PIM-SM is used in shared LAN networks" or something similar?
>>
>> Original:
>>  In PIM-SM shared LAN networks, there is often more than one upstream
>> router.  When PIM Sparse Mode (PIM-SM), including PIM Source
>> Specific-Specific Multicast (PIM-SSM), is used, this can lead to
>> duplicate IP multicast packets being forwarded by these PIM routers.
>>  ...
>>  In PIM-SM shared LAN networks, there is typically more than one
>> upstream router.
>>
>> Perhaps (remove "PIM-SM" from "PIM-SM shared LAN networks"):
>>  In shared LAN networks, there is often more than one upstream
>> router.  When PIM Sparse Mode (PIM-SM), including PIM Source
>> Specific-Specific Multicast (PIM-SSM), is used, this can lead to
>> duplicate IP multicast packets being forwarded by these PIM routers.
>>  ..
>>  In shared LAN networks, there is typically more than one  upstream
>> router.
>>
>> Or (recast sentences):
>>  When PIM Sparse Mode (PIM-SM), including PIM Source
>> Specific-Specific  Multicast (PIM-SSM), is used in shared LAN
>> networks, there is often more  than one upstream router. This can
>> lead to duplicate IP multicast packets  being forwarded by these PIM routers.
>>  ..
>>  When PIM-SM is used in shared LAN networks, there is typically more
>> than one  upstream router.
>> -->
>>
>>
>> 5) <!-- [rfced] In Terminology section (i.e., Section 1.2), would you
>> like to list the abbreviations in alphabetical order? Or do you
>> prefer the current order?
>> -->
>>
>>
>> 6) <!-- [rfced] Should "assert process" here be updated to "assert processing"?
>> Or is the current correct?
>>
>> Original:
>>  ... there may be multiple upstream routers, which can cause
>> duplicate  multicast traffic to be forwarded and assert process to occur.
>> -->
>>
>>
>> 7) <!-- [rfced] Should "PIM assert small packets" here be updated to
>> "small PIM assert packets"?
>>
>> Original:
>>  The PIM
>>  routers need to process a large number of PIM assert small packets
>> in  a very short time.  As a result, the device load is very large.
>>
>> Perhaps:
>>  The PIM
>>  routers need to process a large number of small PIM assert packets
>> in  a very short time.  As a result, the device load is very large.
>> -->
>>
>>
>> 8) <!-- [rfced] Please review "something not possible equally with"
>> here. Is the intent "something not possible"?
>>
>> Original:
>>  For example various L2 technologies for rings provide sub 50  msec
>> failover mechanisms, something not possible equally with an L3
>> subnet based ring.
>> -->
>>
>>
>> 9) <!-- [rfced] Please review "Assert packing introduces" here.
>> Should this read "This document introduces..."? Or something else?
>>
>> Original:
>>  Assert packing introduces two new PIM Assert message encodings
>> through the allocation and use of two flags in the PIM Assert message
>> header [I-D.ietf-pim-rfc8736bis], the Packed (P) and the Aggregated
>>  (A) flags.
>> -->
>>
>>
>> 10) <!-- [rfced] Would it be helpful to use the same phrasing at the
>> beginning of these sentences?
>>
>> Original:
>>  If the (P)acked flag is 0, the message is a (non-packed) PIM Assert
>> message as specified in [RFC7761].  See Section 4.2.  In this case,
>> the (A) flag MUST be set to 0, and MUST be ignored on receipt.
>>
>>  If the (P) flag is 1, then the message is called a PackedAssert
>> message and the type and hence encoding format of the payload is
>> determined by the (A) flag.
>>
>>  If A=0, then the message body is a sequence of assert records.  This
>> is called a "Simple PackedAssert" message.  See Section 4.3.
>>
>>  If A=1, then the message body is a sequence of aggregated assert
>> records.  This is called an "Aggregated PackedAssert".  See  Section
>> 4.4.
>>
>> Perhaps:
>>  If the P flag is 0,...
>>
>>  If the P flag is 1,...
>>
>>  If the A flag is 0,...
>>
>>  If the A flag is 1,...
>>
>> Or:
>>  If P=0,...
>>
>>  If P=1,...
>>
>>  If A=0,...
>>
>>  If A=1,...
>> -->
>>
>>
>> 11) <!-- [rfced] Please review "RP Aggregation Records" here. Is the intended meaning "RP Aggregated Assert Records"?
>>
>> Original:
>>  RP Aggregation Records provide a more compact encoding than the
>> Simple PackedAssert message format for (*,G) flows.
>>
>> Perhaps:
>>  RP Aggregated Assert Records provide a more compact encoding than the
>>  Simple PackedAssert message format for (*,G) flows.
>> -->
>>
>>
>> 12) <!-- [rfced] FYI - We have updated this sentence as follows for
>> clarity. Please review.
>>
>> Original:
>>  It is out of scope of this specification for which conditions,  such
>> as data-triggered asserts or Assert Timer (AT) expiry-  triggered
>> asserts, or under which conditions (such as high load)  an
>> implementation will send PackedAsserts instead of Asserts.
>>
>> Perhaps:
>>  The conditions for which (e.g., data-triggered asserts or Assert
>> Timer (AT) expiry-triggered asserts) or under which (e.g., high
>>  load) an implementation will send PackedAsserts instead of Asserts
>> are out of scope for this specification.
>> -->
>>
>>
>> 13) <!-- [rfced] Is "of their [RFC7761] implementation" needed here?
>> "Implementations" is used at the beginning of the sentence; perhaps
>> it does not need to be repeated. Also, please review "[RFC7761]
>> implementation". Is the intent "implementations using PIM-SM [RFC7761]" or "PIM-SM [RFC7761] implementations"?
>>
>> Original:
>>  Implementations that introduce support for assert  packing from day
>> one of their [RFC7761] implementation MAY omit  this configuration
>> option.
>>
>> Perhaps:
>>  PIM-SM [RFC7761] implementations that introduce support for assert
>> packing from day one MAY omit this configuration option.
>> -->
>>
>>
>> 14) <!-- [rfced] Please review "from other reasons". Should this be
>> updated to "for other reasons", "from other sources", or something else?
>>
>> Original:
>>  Asserts/PackedAsserts created from reception-triggered assert
>> records  should be scheduled for serialization with a higher priority
>> than  those created from other reasons.
>> -->
>>
>>
>> 15) <!-- [rfced] Would it be helpful to split up this long sentence to improve readability?
>>
>> Original:
>>  If there are one or more reception-triggered Assert/PackedAssert
>> messages already serializing and/or scheduled to be serialized on the
>> outgoing interface, then the router can use the time until the last
>> of those messages will have finished serializing for PIM processing
>> of further conditions that may result in additional reception-
>> triggered assert records as well as packing of these assert records
>> without introducing additional delay.
>>
>> Perhaps:
>>  If one or more reception-triggered Assert/PackedAssert messages are
>> already serializing or are scheduled to be serialized on the outgoing
>> interface, then the router can use the time until the last of those
>> messages has finished serializing for PIM processing of further
>> conditions. This may result in additional reception-triggered assert
>> records and the packing of these assert records without introducing
>> additional delay.
>> -->
>>
>>
>> 16) <!-- [rfced] May we update "condition" to "case" or "situation" here?
>>
>> Original:
>>  Delay in sending PackedAsserts beyond what was discussed in prior
>> subsections can still be beneficial when it causes the overall amount
>> of (possible) duplicate IP multicast packets to decrease in a
>> condition with large number of (S,G) and/or (*,G), compared to the
>> situation in which an implementation only sends Assert messages.
>> -->
>>
>>
>> 17) <!-- [rfced] Should the sentence starting with "Including..." be
>> part of the definition of the OptionType field?
>>
>> Original:
>>  *  OptionType TBD: PIM Packed Assert Capability Hello Option
>>
>>  Including the PIM OptionType TBD indicates support for the ability
>> to  receive and process all the PackedAssert encodings defined in
>> this  document.
>>
>> Current:
>>  OptionType:  40 (Packed Assert Capability)
>>
>>  Including the PIM OptionType 40 indicates support for the ability to
>> receive and process all the PackedAssert encodings defined in this
>> document.
>>
>> Perhaps:
>>  OptionType:  40 (Packed Assert Capability). Indicates support for the
>>     ability to receive and process all the PackedAssert encodings defined
>>     in this document.
>> -->
>>
>>
>> 18) <!-- [rfced] The text below Figure 1 includes a definition of the
>> OptionType field. Would it be helpful to readers to also include a
>> definition of the OptionLength field? If so, please provide the text.
>> -->
>>
>>
>> 19) <!-- [rfced] Should "IP and IPv6" here be updated to "IPv4 and
>> IPv6"? Or is the current correct?
>>
>> Original:
>>  The Encoded-Group and Encoded-Unicast address formats are  specified
>> in Section 4.9.1 of [RFC7761] for IP and IPv6.
>> -->
>>
>>
>> 20) <!-- [rfced] To avoid awkward hyphenation, we updated "non assert
>> packing capable PIM routers" to "PIM routers that are not capable of
>> assert packing". Also, please clarify "if this field was used". Can
>> this phrase be removed? Or is the intent "if this field is set to a
>> value other than zero" or something else? Note that this text appears
>> twice in the document.
>>
>> Original:
>>  Set to zero on transmission. Serves to make non assert packing
>> capable PIM routers fail in parsing the message instead of  possible
>> mis-parsing if this field was used.
>> -->
>>
>>
>> 21) <!-- [rfced] FYI - We moved the "P" and "A" definitions under
>> Figure 3 to appear after the "7 6 5 4 3 2" definition as they are
>> flag bits. This also matches the order of the definitions under Figure 5.
>> -->
>>
>>
>> 22) <!-- [rfced] We have two questions about the text below.
>>
>> - All of the definitions in the list following Figure 3 are fields in
>> the figure, except for the entry for M. M has its own entry but is
>> also defined in the last sentence of the "Assert Record" defintion.
>> Should the entry for M be removed? Or is the current okay?
>>
>> - The sentence following the "Assert Record" entry seems redundant
>> with the first sentence in the "Assert Record" definition. Please
>> review and let us know if any updates are needed.
>>
>> Original:
>>  *  M: The number of Assert Records in the message.  Derived from the
>>     length of the packet carrying the message.
>>
>>  *  Assert Record: formatted according to {FIG-MESSAGE-SIMPLE}}, which
>>     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.
>>
>>  The format of each Assert Record is the same as the PIM assert
>> message body as specified in Section 4.9.6 of [RFC7761].
>>
>> Perhaps:
>>  Assert Record:
>>     Formatted according to Figure 3, which 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 by the packet size.
>> -->
>>
>>
>> 23) <!-- [rfced] FYI - In the list of definitions following Figures 6
>> and 7, we moved the "Reserved" definition entry to correspond with
>> the order of the fields in the figure.
>> -->
>>
>>
>> 24) <!-- [rfced] In the list of definitions following Figure 8,
>> should "Group Address and Reserved" be updated to "Group Address"?
>> The Reserved field has its own entry in the list of definitions.
>>
>> Original:
>>  *  Group Address and Reserved:
>>
>>     As specified in Section 4.9.6 of [RFC7761].
>>
>>  *  Reserved: Set to zero on transmission.  Ignored upon receipt.
>>
>> Perhaps:
>>  Group Address:
>>     As specified in Section 4.9.6 of [RFC7761].
>>
>>  Reserved:
>>     Set to zero on transmission.  Ignored upon receipt.
>> -->
>>
>>
>> 25) <!-- [rfced] May we update "should have the Source Address 0" to
>> "has Source Address 0"?
>>
>> Original:
>>  If this number is not 0 and one of the (*,G) assert records to  be
>> encoded should have the Source Address 0, then 0 needs to be  encoded
>> as one of the Source Address fields.
>>
>> Perhaps:
>>  If this number is not 0 and one of the (*,G) assert records to  be
>> encoded has Source Address 0, then 0 needs to be  encoded as one of
>> the Source Address fields.
>> -->
>>
>>
>> 26) <!-- [rfced] IANA Considerations
>>
>> a) FYI - We updated the titles of Section 4.1 and Figure 1, as well
>> as some text in Sections 3, 3.1, and 4.1, to use the IANA-registered
>> name "Packed Assert Capability". Please review.
>>
>> b) May we remove the row with "2-7: Unassigned" in Table 2 as these
>> are not assigned by this document? The introductory text says "IANA
>> has assigned the following two flag bits...". Also, this will change
>> when other bits are assigned in the registry in the future.
>> -->
>>
>>
>> 27) <!-- [rfced] We have a few questions about this sentence.
>>
>> - The sentence is difficult to parse. May we recast as follows for clarity?
>>
>> - Will it be clear to readers what "them" and "they" refer to?
>>
>> - Please clarify "[RFC7490] with IP repair tunnels" and "[RFC7431]
>> for IP multicast". May we update to include the mechanisms defined in
>> [RFC7490] and [RFC7431]? See suggested text below.
>>
>> Original:
>>  The mere fact that by operating at the IP layer, different solutions
>> for IP unicast and multicast are required makes them more difficult
>> to operate, they typically require more expensive hardware and
>> therefore most often, they are not even available on the target
>> equipment, such as [RFC7490] with IP repair tunnels for IP unicast or
>> [RFC7431] for IP multicast.
>>
>> Perhaps:
>>  When operating at the IP layer, different solutions  for IP unicast
>> and multicast are required. This makes them more difficult  to
>> operate, and they typically require more expensive hardware.
>>  Therefore, they frequently are not even available on the target
>> equipment, such as Remote Loop-Free Alternate (LFA) Fast Reroute
>> (FRR) [RFC7490]  with IP repair tunnels for IP unicast or
>> Multicast-only Fast  Reroute (MoFRR) [RFC7431] for IP multicast.
>> -->
>>
>>
>> 28) <!-- [rfced] May we update "interface that is in a VRF changing"
>> and "in a same time" as follows for clarity?
>>
>> Original:
>>  The configuration of multicast-enabled VRF (VPN  routing and
>> forwarding) or interface that is in a VRF changing may  cause many
>> assert packets to be sent in a same time.
>>
>> Perhaps:
>>  The configuration of multicast-enabled VPN Routing and Forwarding
>> (VRF)  or changes to the interface that is in  a VRF may cause many
>> assert packets to be sent at the same  time.
>> -->
>>
>>
>> 29) <!-- [rfced] Are the parentheses needed with "(possible)" and
>> "(more advanced)" in these sentences? Or can they be removed?
>>
>> Original:
>>  Delay in sending PackedAsserts beyond what was discussed in prior
>> subsections can still be beneficial when it causes the overall amount
>> of (possible) duplicate IP multicast packets to decrease in a
>> condition with large number of (S,G) and/or (*,G), compared to the
>> situation in which an implementation only sends Assert messages.
>>  ...
>>  This delay can simply be used in implementations because it can not
>> support the (more advanced) mechanisms described above, and this
>> longer delay can be achieved by some simpler mechanism (such as only
>> periodic generation of PackedAsserts) and still achieves an overall
>> reduction in duplicate IP multicast packets compared to sending only
>> Asserts.
>>
>> Also, are the parentheses needed with "(non AssertCancel)",
>> "(non-packed)", and "(not packed)" in these sentences? Or can they be removed?
>>
>> Original:
>>  Loss of
>>  (non AssertCancel) PackedAssert impacts duplicates for all flows
>> packed into the PackedAssert and  ...
>>  As specified in
>>  Section 3.2, both flags in a (non-packed) PIM Assert message are
>> required to be set to 0.
>>  ...
>>  If the (P)acked flag is 0, the message is a (non-packed) PIM Assert
>> message as specified in [RFC7761].
>>  ...
>>  Instead, sending and receiving of PackedAssert  messages as
>> specified in the following subsections are logically new
>> packetization options for assert records in addition to the (not
>>  packed) [RFC7761] Assert Message.
>> -->
>>
>>
>> 30) <!-- [rfced] Terminology
>>
>> a) Should "metric-preference and metric" here read "Metric Preference
>> and Metric" per the usage elsewhere in the document (i.e.,
>> capitalization and no hyphen)?
>>
>> Original:
>>  The PIM assert message carries information about a single multicast
>> source and group, along with the corresponding metric-preference and
>> metric of the route towards the source or PIM Rendezvous Point (RP).
>>
>> Perhaps:
>>  The PIM assert message carries information about a single multicast
>> source and group, along with the corresponding Metric Preference and
>> Metric of the route towards the source or PIM Rendezvous Point (RP).
>>
>>
>> b) We note inconsistencies in the terms listed below. We chose the
>> form on the right per usage in RFC 7761.  Please let us know any objections.
>>
>> PIM assert message vs. PIM Assert message
>>
>> assert message vs. Assert message
>>
>>
>> c) We note inconsistencies in the terms below throughout the text.
>> Should these be uniform? If so, please let us know which form is preferred.
>>
>> PIM Assert state vs. PIM assert state
>>  Note: We see mixed use in RFC 7761.
>>
>> PIM Asserts vs. PIM asserts
>>
>> Assert vs. assert (used as a noun, not in context of "Assert
>> message", etc.)
>>  Examples:
>>  "reception of asserts"
>>  "triggered the assert"
>>  "single non-packed Assert"
>>  "instead of Asserts"
>>
>>
>> d) We see instances of both "assert record" (lowercase) and "Assert Record"
>> (capitalized) in the document. The capitalized form is consistently
>> used in the context of "Source Aggregated Assert Record" and "RP
>> Aggregated Assert Record"; the field name is also consistently
>> capitalized (Figures 3 and 5). Please review the following instances
>> and let us know if these should remain capitalized or if they should be lowercased.
>>
>> Original:
>>  *  M: The number of Assert Records in the message.  Derived from the
>> length of the packet carrying the message.
>>  ...
>>  The number M of Assert Records is
>>  determined from the packet size.
>>  ...
>>  The format of each Assert Record is the same as the PIM assert
>> message body as specified in Section 4.9.6 of [RFC7761].
>>
>>
>> e) FYI - We updated "YANG model" to "YANG data model" per recent
>> guidance from Benoit Claise and the YANG Doctors.
>> -->
>>
>>
>> 31) <!-- [rfced] FYI, we have added expansions for the following
>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
>> review each expansion in the document carefully to ensure correctness.
>>
>>  DetNet - Deterministic Networking
>>  MVPN - Multicast VPN
>> -->
>>
>>
>> 32) <!-- [rfced] Please review the "Inclusive Language" portion of
>> the online Style Guide
>> <https://ww/
>> w.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05
>> %7C01%7Cmichael.mcbride%40futurewei.com%7Cb143facb73b7416782fb08dbbb7
>> 5b52f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638309886488749747
>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
>> Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XcjVk855ou%2F9ZWXVcgPUht
>> BNMulNLjoY8mybpoL2v8A%3D&reserved=0>
>> and let us know if any changes are needed.
>>
>> Note that our script did not flag any words in particular, but this
>> should still be reviewed as a best practice.
>> -->
>>
>>
>> Thank you.
>>
>> RFC Editor/st/rv
>>
>>
>>
>>
>> On Sep 14, 2023, at 1:20 PM, [e-mail] wrote:
>>
>> *****IMPORTANT*****
>>
>> Updated 2023/09/14
>>
>> RFC Author(s):
>> --------------
>>
>> Instructions for Completing AUTH48
>>
>> Your document has now entered AUTH48.  Once it has been reviewed and
>> approved by you and all coauthors, it will be published as an RFC.
>> If an author is no longer available, there are several remedies
>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>
>> You and you coauthors are responsible for engaging other parties
>> (e.g., Contributors or Working Group) as necessary before providing
>> your approval.
>>
>> Planning your review
>> ---------------------
>>
>> Please review the following aspects of your document:
>>
>> *  RFC Editor questions
>>
>> Please review and resolve any questions raised by the RFC Editor that
>> have been included in the XML file as comments marked as
>> follows:
>>
>> <!-- [rfced] ... -->
>>
>> These questions will also be sent in a subsequent email.
>>
>> *  Changes submitted by coauthors
>>
>> Please ensure that you review any changes submitted by your
>> coauthors.  We assume that if you do not speak up that you agree to
>> changes submitted by your coauthors.
>>
>> *  Content
>>
>> Please review the full content of the document, as this cannot change
>> once the RFC is published.  Please pay particular attention to:
>> - IANA considerations updates (if applicable)
>> - contact information
>> - references
>>
>> *  Copyright notices and legends
>>
>> Please review the copyright notice and legends as defined in RFC 5378
>> and the Trust Legal Provisions (TLP -
>> https://trustee.ietf.org/license-info/).
>>
>> *  Semantic markup
>>
>> Please review the markup in the XML file to ensure that elements of
>> content are correctly tagged.  For example, ensure that <sourcecode>
>> and <artwork> are set correctly.  See details at
>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>
>> *  Formatted output
>>
>> Please review the PDF, HTML, and TXT files to ensure that the
>> formatted output, as generated from the markup in the XML file, is
>> reasonable.  Please note that the TXT will have formatting
>> limitations compared to the PDF and HTML.
>>
>>
>> Submitting changes
>> ------------------
>>
>> To submit changes, please reply to this email using 'REPLY ALL' as
>> all the parties CCed on this message need to see your changes. The
>> parties
>> include:
>>
>> *  your coauthors
>>
>> *  [e-mail] (the RPC team)
>>
>> *  other document participants, depending on the stream (e.g.,
>>    IETF Stream participants are your working group chairs, the
>>    responsible ADs, and the document shepherd).
>>
>> *  [e-mail], which is a new archival mailing list
>>    to preserve AUTH48 conversations; it is not an active discussion
>>    list:
>>
>>   *  More info:
>>
>> https://mai/
>> larchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe
>> 6P8O4Zc&data=05%7C01%7Cmichael.mcbride%40futurewei.com%7Cb143facb73b7
>> 416782fb08dbbb75b52f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638
>> 309886488749747%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dUHn4sYTG
>> yAOBJqY18gXHYqZmiQGj0dmsQN3vLbPB00%3D&reserved=0
>>
>>   *  The archive itself:
>>
>> https://mai/
>> larchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C01%7Cm
>> ichael.mcbride%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0
>> fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638309886488749747%7CUnknow
>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ra9FrrSg1VeSpqk71b2lo9ZyGGHpc2xpF
>> 3yvHefb9dc%3D&reserved=0
>>
>>   *  Note: If only absolutely necessary, you may temporarily opt out
>>      of the archiving of messages (e.g., to discuss a sensitive matter).
>>      If needed, please add a note at the top of the message that you
>>      have dropped the address. When the discussion is concluded,
>>      [e-mail] will be re-added to the CC list and
>>      its addition will be noted at the top of the message.
>>
>> You may submit your changes in one of two ways:
>>
>> An update to the provided XML file
>> - OR -
>> An explicit list of changes in this format
>>
>> Section # (or indicate Global)
>>
>> OLD:
>> old text
>>
>> NEW:
>> new text
>>
>> You do not need to reply with both an updated XML file and an
>> explicit list of changes, as either form is sufficient.
>>
>> We will ask a stream manager to review and approve any changes that
>> seem beyond editorial in nature, e.g., addition of new text, deletion
>> of text, and technical changes.  Information about stream managers
>> can be found in the FAQ.  Editorial changes do not require approval from a stream manager.
>>
>>
>> Approving for publication
>> --------------------------
>>
>> To approve your RFC for publication, please reply to this email
>> stating that you approve this RFC for publication.  Please use 'REPLY
>> ALL', as all the parties CCed on this message need to see your approval.
>>
>>
>> Files
>> -----
>>
>> The files are available here:
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466.xml&data=05%7C01%7Cmichael.mcbrid
>> e%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8ff2a3b240
>> 189c753a1d5591fedc%7C1%7C1%7C638309886488749747%7CUnknown%7CTWFpbGZsb
>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>> %7C3000%7C%7C%7C&sdata=yHhGAQ0%2FrKPrX7WfP8Y%2BE%2FFw106Gn4d0g%2BnxPJ
>> Mv3Lw%3D&reserved=0
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466.html&data=05%7C01%7Cmichael.mcbri
>> de%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8ff2a3b24
>> 0189c753a1d5591fedc%7C1%7C1%7C638309886488749747%7CUnknown%7CTWFpbGZs
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>> D%7C3000%7C%7C%7C&sdata=kbOawG30uFiIkq21xhPfp414Nr5lRonFQUu0JEoXvks%3
>> D&reserved=0
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466.pdf&data=05%7C01%7Cmichael.mcbrid
>> e%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8ff2a3b240
>> 189c753a1d5591fedc%7C1%7C1%7C638309886488749747%7CUnknown%7CTWFpbGZsb
>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>> %7C3000%7C%7C%7C&sdata=A1sd%2BM6%2FozzVXVbdyaDbKjR5ItWRQQ14D1rEn%2FZU
>> rIY%3D&reserved=0
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466.txt&data=05%7C01%7Cmichael.mcbrid
>> e%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8ff2a3b240
>> 189c753a1d5591fedc%7C1%7C1%7C638309886488749747%7CUnknown%7CTWFpbGZsb
>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>> %7C3000%7C%7C%7C&sdata=mGKW8NCfrxLk9j%2FW3xenLhULmfPx8B2SNQAIUkNdIoY%
>> 3D&reserved=0
>>
>> Diff file of the text:
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466-diff.html&data=05%7C01%7Cmichael.
>> mcbride%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8ff2
>> a3b240189c753a1d5591fedc%7C1%7C1%7C638309886488749747%7CUnknown%7CTWF
>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>> Mn0%3D%7C3000%7C%7C%7C&sdata=KbgGCHTr7nw9l2Q0Wv8XqjA7igLisGv2WJpairJd
>> 9PQ%3D&reserved=0
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466-rfcdiff.html&data=05%7C01%7Cmicha
>> el.mcbride%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8
>> ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638309886488905975%7CUnknown%7C
>> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
>> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=mnVI0mALknY3uOeaIku8gq7IR%2FUZfDD%2F%
>> 2FB1RMWtJgEk%3D&reserved=0 (side by side)
>>
>> Alt-diff of the text (allows you to more easily view changes where
>> text has been deleted or moved):
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466-alt-diff.html&data=05%7C01%7Cmich
>> ael.mcbride%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638309886488905975%7CUnknown%7
>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
>> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tMaAEn1Nxn0vv8duBkvRPY6wSNY6cKmR685u
>> TUEH%2FGw%3D&reserved=0
>>
>> Diff of the XML:
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466-xmldiff1.html&data=05%7C01%7Cmich
>> ael.mcbride%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee
>> 8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638309886488905975%7CUnknown%7
>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
>> VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GvgB4SddXmv0YtIb2ffCXHyJnNHpJVC1lti0
>> RoUFxRU%3D&reserved=0
>>
>> The following files are provided to facilitate creation of your own
>> diff files of the XML.
>>
>> Initial XMLv3 created using XMLv2 as input:
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466.original.v2v3.xml&data=05%7C01%7C
>> michael.mcbride%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C
>> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638309886488905975%7CUnkno
>> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
>> LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oLRdxWV0wLKIIUjQEZB6C%2FYbIlpg87
>> 7Gd4gjZF237GE%3D&reserved=0
>>
>> XMLv3 file that is a best effort to capture v3-related format updates
>> only:
>> https://www/
>> .rfc-editor.org%2Fauthors%2Frfc9466.form.xml&data=05%7C01%7Cmichael.m
>> cbride%40futurewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8ff2a
>> 3b240189c753a1d5591fedc%7C1%7C1%7C638309886488905975%7CUnknown%7CTWFp
>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
>> n0%3D%7C3000%7C%7C%7C&sdata=3eSq70%2B0jNBTne9D%2BjyEbIKgvcsuvrWQe4RuM
>> CpSlko%3D&reserved=0
>>
>>
>> Tracking progress
>> -----------------
>>
>> The details of the AUTH48 status of your document are here:
>> https://www/
>> .rfc-editor.org%2Fauth48%2Frfc9466&data=05%7C01%7Cmichael.mcbride%40f
>> uturewei.com%7Cb143facb73b7416782fb08dbbb75b52f%7C0fee8ff2a3b240189c7
>> 53a1d5591fedc%7C1%7C1%7C638309886488905975%7CUnknown%7CTWFpbGZsb3d8ey
>> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
>> 00%7C%7C%7C&sdata=Vi4dE6XUTw%2F7UmBhZhs3lvzhbfpMVlC9wr%2BdeUCZimM%3D&
>> reserved=0
>>
>> Please let us know if you have any questions.
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC9466 (draft-ietf-pim-assert-packing-12)
>>
>> Title            : PIM Assert Message Packing
>> Author(s)        : Y. Liu, Ed., T. Eckert, Ed., M. McBride, Z. Zhang
>> WG Chair(s)      : Stig Venaas, Mike McBride
>>
>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>>
>