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

[Toerless Eckert <[e-mail]>]

Whats the error ? Did you send vom ietf email or amsl ?

I am not aware of any changes to Sandy's status, last email i see on mailing lists from her is 
from Sep 13.

Cheers
    toerless

On Fri, Sep 22, 2023 at 09:10:30AM -0500, Sarah Tarrant wrote:
> 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
> >> 
> > 

-- 
---
[e-mail]