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

[Sarah Tarrant <[e-mail]>]

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.rfc-editor.org/auth48/rfc9466
> 
> 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://author-tools.ietf.org/iddiff?url2=draft-ietf-pim-assert-packing-12
>> -->
>> 
>> 
>> 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://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>> 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>> 
>>   *  The archive itself:
>>      https://mailarchive.ietf.org/arch/browse/auth48archive/
>> 
>>   *  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/authors/rfc9466.xml
>> https://www.rfc-editor.org/authors/rfc9466.html
>> https://www.rfc-editor.org/authors/rfc9466.pdf
>> https://www.rfc-editor.org/authors/rfc9466.txt
>> 
>> Diff file of the text:
>> https://www.rfc-editor.org/authors/rfc9466-diff.html
>> https://www.rfc-editor.org/authors/rfc9466-rfcdiff.html (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/authors/rfc9466-alt-diff.html
>> 
>> Diff of the XML: 
>> https://www.rfc-editor.org/authors/rfc9466-xmldiff1.html
>> 
>> 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/authors/rfc9466.original.v2v3.xml 
>> 
>> XMLv3 file that is a best effort to capture v3-related format updates 
>> only: 
>> https://www.rfc-editor.org/authors/rfc9466.form.xml
>> 
>> 
>> Tracking progress
>> -----------------
>> 
>> The details of the AUTH48 status of your document are here:
>> https://www.rfc-editor.org/auth48/rfc9466
>> 
>> 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
>> 
>