Re: [auth48] AUTH48: RFC-to-be 9279 <draft-ietf-pim-igmp-mld-extension-08> for your review

[Mahesh Sivakumar <[e-mail]>]

The latest update looks good to me. Thanks Stig for taking care of this.

Reuben,

I approve of the latest update as well.

Cheers
Mahesh

On Thu, Jul 28, 2022 at 8:53 AM <[e-mail]> wrote:

> Thanks Stig for the reminder.
>
> To Reuben, I approve the latest update. Thank you!
>
> Best regards,
>
> Sandy
>
>
> Original
> *From: *StigVenaas(svenaas) <[e-mail]>
> *To: *Reuben Esparza <[e-mail]>;Stig Venaas (svenaas) <svenaas=
> [e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;张征00007940;
> [e-mail] <[e-mail]>;
> *Cc: *Karen Moore <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <
> [e-mail]>;
> *Date: *2022年07月28日 22:34
> *Subject: **RE: AUTH48: RFC-to-be 9279
> <draft-ietf-pim-igmp-mld-extension-08> for your review*
> Hi Reuben
>
> I approve the latest update, everything looks great!
>
>
> Mahesh, Sandy and Hitoshi, please have a look and see whether you can approve, or if any further changes are needed.
>
> Thanks,
> Stig
>
> > -----Original Message-----
> > From: Reuben Esparza <[e-mail]>
> > Sent: Tuesday, July 26, 2022 2:04 PM
> > To: Stig Venaas (svenaas) <svenaas=[e-mail]>;
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Cc: Karen Moore <[e-mail]>; [e-mail]; pim-
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: AUTH48: RFC-to-be 9279 <draft-ietf-pim-igmp-mld-extension-
> > 08> for your review
> > Importance: High
> >
> > Hi Authors,
> >
> > I’ll be handling this document for Karen while she’s out.
> >
> >
> > Stig, we’ve made the updates to this document. Once we receive your final
> > approval, along with that of Mahesh, Sandy, and Hitoshi, we’ll be able to
> > continue with the publication process for this document.
> >
> >
> > Please review the document carefully to ensure satisfaction, as we do not
> > make changes once it has been published as an RFC.
> >
> > Please contact us with any further updates you may have.  We will await
> > approvals from each author prior to moving forward in the publication
> > process.
> >
> > A diff file highlighting only the AUTH48 updates is available at:
> >
> > https://www.rfc-editor.org/authors/rfc9279-auth48diff.html
> >
> > The text, XML, and comprehensive diff files are available at:
> >
> > https://www.rfc-editor.org/authors/rfc9279.txt
> > https://www.rfc-editor.org/authors/rfc9279.pdf
> > https://www.rfc-editor.org/authors/rfc9279.html
> > https://www.rfc-editor.org/authors/rfc9279.xml
> > https://www.rfc-editor.org/authors/rfc9279-diff.html
> >
>
> > Note that it may be necessary for you to refresh your browser to access the
> > most recent version.
> >
> > The AUTH48 status page for this document is available here:
> >
> > https://www.rfc-editor.org/auth48/rfc9279
> >
> > Thank you.
> >
> > RFC Editor/re
> >
> >
> > > On Jul 25, 2022, at 1:13 PM, Stig Venaas (svenaas)
> > <svenaas=[e-mail]> wrote:
> > >
> > > Thank you Karen for the quick update.
> > >
>
> > > The latest version looks great, except for two issues with the text in section
> > 4.
> > >
> > > Broken new text:
> > > The No-op TLV is a No-Operation TLV that MUST be ignored during
>
> > processing. This TLV may be used to verify that the extension mechanism has
> > been implemented correctly. correctly implement this extension mechanism.
>
> > Note that there is no alignment requirement, so there is no need to use this
> > Extension Type to provide alignment.
> > >
> > > The text "correctly implement this extension mechanism" needs to be
> > removed.
> > >
> > > Also, I think this change should be considered:
> > >
> > > OLD:
> > > No-op Type:
> > > 2 octets. The type of the No-op TLV extension is value 0.
> > >
> > > NEW:
> > > No-op Type:
> > > 2 octets. The type of the No-op TLV extension is 0.
> > >
>
> > > Including the word value may cause confusion, because we also talk about
> > value in a different context right below.
> > >
> > > Thanks,
> > > Stig
> > >
> > >> -----Original Message-----
> > >> From: Karen Moore <[e-mail]>
> > >> Sent: Friday, July 22, 2022 5:22 PM
> > >> To: Stig Venaas (svenaas) <svenaas=[e-mail]>;
> > >> [e-mail]; [e-mail];
> > [e-mail];
> > >> [e-mail]
> > >> Cc: [e-mail]; [e-mail]; [e-mail];
> > >> [e-mail]; [e-mail]
> > >> Subject: Re: AUTH48: RFC-to-be 9279
> > >> <draft-ietf-pim-igmp-mld-extension-
> > >> 08> for your review
> > >> Importance: High
> > >>
> > >> Hello Stig,
> > >>
> > >> Thank you for your reply.  We have updated our files accordingly,
> > >> including your suggestion for Table 1 in Section 8.
> > >>
> > >> The updated XML file is here:
> > >> https://www.rfc-editor.org/authors/rfc9279.xml
> > >>
> > >> The updated output files are here:
> > >> https://www.rfc-editor.org/authors/rfc9279.txt
> > >> https://www.rfc-editor.org/authors/rfc9279.pdf
> > >> https://www.rfc-editor.org/authors/rfc9279.html
> > >>
> > >> This diff file shows all changes made during AUTH48:
> > >> https://www.rfc-editor.org/authors/rfc9279-auth48diff.html
> > >>
> > >> This diff file shows all changes made to date:
> > >> https://www.rfc-editor.org/authors/rfc9279-diff.html
> > >>
> > >> Note that it may be necessary for you to refresh your browser to view
> > >> the most recent version. Please review the document carefully to
> > >> ensure satisfaction as we do not make changes once it has been
> > published as an RFC.
> > >>
> > >> Please contact us with any further updates or with your approval of
> > >> the document in its current form.  We will await approvals from each
> > >> author prior to moving forward in the publication process.
> > >>
> > >> For the AUTH48 status of this document, please see:
> > >> https://www.rfc-editor.org/auth48/rfc9279
> > >>
> > >> Thank you,
> > >>
> > >> RFC Editor/kc
> > >>
> > >>> On Jul 21, 2022, at 11:46 AM, Stig Venaas (svenaas)
> > >> <svenaas=[e-mail]> wrote:
> > >>>
> > >>> Dear RFC editor
> > >>>
> > >>> Thanks for your proposed changes, they mostly look good.
> > >>>
> > >>> Please see answers to the questions inline. I also have some
> > >>> comments
> > >> below there.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: [e-mail] <[e-mail]>
> > >>>> Sent: Thursday, July 21, 2022 12:43 AM
> > >>>> To: [e-mail]; [e-mail];
> > >>>> [e-mail]; [e-mail]
> > >>>> Cc: [e-mail]; [e-mail];
> > >>>> [e-mail]; [e-mail];
> > >>>> [e-mail]
> > >>>> Subject: Re: AUTH48: RFC-to-be 9279
> > >>>> <draft-ietf-pim-igmp-mld-extension-
> > >>>> 08> for your review
> > >>>> Importance: High
> > >>>>
> > >>>> Authors,
> > >>>>
> > >>>> While reviewing this document during AUTH48, please resolve (as
> > >>>> necessary) the following questions, which are also in the XML file.
> > >>>>
> > >>>> 1) <!-- [rfced] We have updated this sentence as follows.  Please
> > >>>> let us know if any corrections are needed.
> > >>>>
> > >>>>
> > >>>> Current:
> > >>>> This document defines a registry for such TLVs, while other
> > >>>> documents will define the specific types and their values, and their
> > semantics.
> > >>>>
> > >>>> Perhaps:
> > >>>> This document defines a registry for such TLVs. Other documents
> > >>>> will define their specific types, and their values and semantics.
> > >>>> -->
> > >>>
> > >>> Thanks, this is good.
> > >>>
> > >>>>
> > >>>> 2) <!-- [rfced] "implementations correctly implement" seems a bit
> > >>>> redundant.
> > >>>> Would "implementations correctly deploy" work here?  Alternatively,
> > >>>> please consider whether the "perhaps" text is accurate.
> > >>>>
> > >>>> Original:
> > >>>>  This TLV may be useful for verifying that  implementations
> > >>>> correctly implement this extension mechanism.
> > >>>>
> > >>>> Perhaps:
> > >>>>  This TLV may be used to verify that the extension mechanism  has
> > >>>> been implemented correctly.
> > >>>
> > >>> Yes, this is better.
> > >>>
> > >>>> -->
> > >>>>
> > >>>>
>
> > >>>> 3) <!-- [rfced] For readability, may we update this sentence as follows?
> > >>>>
> > >>>> Original:
> > >>>>     contents of this
> > >>>>     field is according to the specification of the Extension Type.
> > >>>>
> > >>>> Suggested:
>
> > >>>>     The specification defining the Extension Type describes the contents
> > >>>>     of this field.
> > >>>> -->
> > >>>
> > >>> Thanks, that is better. This change should be made in section 3.
> > >>> There is a mistake in section 4. This sentence is there at the very
> > >>> end of
> > >> section 4, but should be removed.
> > >>>
> > >>> Original:
> > >>>  Value:
> > >>>  This field contains the value. As this Extension Type is always
> > >>> ignored, the
> > >> value can be arbitrary data.
> > >>>     The number of octets used MUST match the specified length.
> > >>> Contents
> > >> of this field is according to the
> > >>>     specification of the Extension Type.
> > >>>
> > >>> New:
> > >>>  Value:
> > >>>  This field contains the value. As this Extension Type is always
> > >>> ignored, the
> > >> value can be arbitrary data.
> > >>>     The number of octets used MUST match the specified length.
> > >>>
> > >>>
> > >>>>
> > >>>> 4) <!-- [rfced] Please consider whether the following update would
> > >>>> improve clarity.
> > >>>>
> > >>>> Original:
> > >>>>  An implementation could add a large number of minimal TLVs in a
> > >>>> message to increase the cost of processing the message to magnify a
> > >>>> Denial of Service attack.
> > >>>>
> > >>>> Perhaps:
> > >>>>  An implementation could add a large number of minimal TLVs in a
> > >>>> message to increase the cost of processing the message.  This
> > >>>> would magnify a denial-of-service attack.
> > >>>> -->
> > >>>
> > >>> Yes, that works.
> > >>>
> > >>> There is an issue with your proposed changes in section 7 I believe.
> > >>>
> > >>> Text after your change:
> > >>>  This document extends the IGMP and MLD message formats, allowing
> > >>> for  a variable number of TLVs.  Implementations must take care not
> > >>> exceed  the packet boundary when parsing the TLVs, because an
>
> > >>> attacker could  intentionally specify a TLV with a length exceeding the
> > boundary.
> > >>>
> > >>> I  believe the word "to" needs to be added to the second sentence so
> > >>> that
> > >> it becomes "not to exceed".
> > >>>
> > >>> New:
> > >>>  This document extends the IGMP and MLD message formats, allowing
> > >>> for  a variable number of TLVs.  Implementations must take care not
> > >>> to exceed  the packet boundary when parsing the TLVs, because an
>
> > >>> attacker could  intentionally specify a TLV with a length exceeding the
> > boundary.
> > >>>
> > >>> The contents of section 8 is fine, but I wonder if the table should
> > >>> be made
>
> > >> to look more like IANA's table. But I am also fine with what you proposed.
> > >>>
> > >>> They put the experimental use types together like this:
> > >>>
>
> > >>>      +------------------+------------+-------------------------+-----------+
> > >>>      | 65534-65535| variable | Reserved for          |              |
>
> > >>>      |                         |                | Experimental Use |              |
> > >>>
> > >>> +-------------------+-----------+-------------------------+---------
> > >>> +-------------------+-----------+-------------------------+--
> > >>> +
> > >>>
> > >>> Thanks,
> > >>> Stig
> > >>>
> > >>>>
> > >>>> Thank you.
> > >>>>
> > >>>> RFC Editor
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Jul 21, 2022, at 12:37 AM, [e-mail] wrote:
> > >>>>
> > >>>> *****IMPORTANT*****
> > >>>>
> > >>>> Updated 2022/07/21
> > >>>>
> > >>>> 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/rfc9279.xml
> > >>>>  https://www.rfc-editor.org/authors/rfc9279.html
> > >>>>  https://www.rfc-editor.org/authors/rfc9279.pdf
> > >>>>  https://www.rfc-editor.org/authors/rfc9279.txt
> > >>>>
> > >>>> Diff file of the text:
> > >>>>  https://www.rfc-editor.org/authors/rfc9279-diff.html
> > >>>>  https://www.rfc-editor.org/authors/rfc9279-rfcdiff.html (side by
> > >>>> side)
> > >>>>
> > >>>> Diff of the XML:
> > >>>>  https://www.rfc-editor.org/authors/rfc9279-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/rfc9279.original.v2v3.xml
> > >>>>
> > >>>> XMLv3 file that is a best effort to capture v3-related format
> > >>>> updates
> > >>>> only:
> > >>>>  https://www.rfc-editor.org/authors/rfc9279.form.xml
> > >>>>
> > >>>>
> > >>>> Tracking progress
> > >>>> -----------------
> > >>>>
> > >>>> The details of the AUTH48 status of your document are here:
> > >>>>  https://www.rfc-editor.org/auth48/rfc9279
> > >>>>
> > >>>> Please let us know if you have any questions.
> > >>>>
> > >>>> Thank you for your cooperation,
> > >>>>
> > >>>> RFC Editor
> > >>>>
> > >>>> --------------------------------------
> > >>>> RFC9279 (draft-ietf-pim-igmp-mld-extension-08)
> > >>>>
>
> > >>>> Title            : Internet Group Management Protocol version 3 (IGMPv3)
> > and
> > >>>> Multicast Listener Discovery version 2 (MLDv2) Message Extension
> > >>>> Author(s)        : M. Sivakumar, S. Venaas, Z. Zhang, H. Asaeda
> > >>>> WG Chair(s)      : Stig Venaas, Mike McBride
> > >>>>
> > >>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> > >>>>
> > >>>
> > >
> >
> >
> >
> >
>
>
>