Re: [auth48] AUTH48 email

[[e-mail]]

Hi Sarah, 
Sorry for the late response. 
I didn't receive the previous emails, but I didn't set any restriction for my email receiving. I'll contact our IT to check if there is something wrong with the email system.
I'd like to use the name "Zheng (Sandy) Zhang" if it's feasible. 
Thank you very much!
Best regards,
Sandy



Original


From: MichaelMcBride <[e-mail]>
To: 张征00007940;
Date: 2023年09月24日 13:11
Subject: AUTH48 email

Hi Sandy,
 
Yes, please send and email the the rfc editor (Sandy) and maybe cc the rest of the people on this list below.
 
Thanks,
mike
 
 
-----Original Message-----
From: Sarah Tarrant <[e-mail]> 
Sent: Friday, September 22, 2023 7:11 AM
To: ubject: 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
>> 
>