[RTG-DIR]Re: Rtgdir last call review of draft-ietf-pim-3810bis-10

[[e-mail]]

Hi Brian, 

Thank you for the follow-up. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Brian Haberman <[e-mail]> Envoyé : lundi 3 juin 
> 2024 16:08 À : BOUCADAIR Mohamed INNOV/NET 
> <[e-mail]>; [e-mail] Cc : 
> [e-mail]; [e-mail]; [e-mail] 
> Objet : Re: Rtgdir last call review of draft-ietf-pim-3810bis-10
> 
> Hi Mohamed,
>       Thanks for the feedback! I will trim all points where I agree 
> with the request. Responses/questions in-line...
> 
> On 5/23/24 4:30 AM, Mohamed Boucadair via Datatracker wrote:
> > Reviewer: Mohamed Boucadair
> > Review result: Has Issues
> >
> > Hi Brian, PIM WG,
> >
> > Thank you for the effort put into the document to maintain MLD
> specs.
> > The scope of the bis is reasonable and adequately described in 
> > Appendix B.2. I would insist more early in the document that
> the main
> > change is associating meaning with fields that are used to be
> reserved, though.
> 
> Are you thinking of a sentence in the Introduction that captures the 
> clarification of how reserved bits are managed?
> 

[Med] Yes, that would be helpful. Thanks. 

> >
> > Please find below some comments, fwiw.
> >
> > # General
> >
> > ## Ops considerations
> >
> > How to determine whether a received MLDv2 message is to be
> interpreted
> > following the rules in the bis or 3810 (that is, the meaning is 
> > actually associated or not with what used to be a reserved
> bit)?
> 
> This document makes 3810 obsolete, so 3810bis is normative.

[Med] Not sure what you meant by "3810bis is normative" given that the document under discussion is the 3810bis. 

> 
> >
> > ## Reserved vs. Unassigned
> >
> > I wonder whether the remaining “Reserved” field can be renamed
> to “Unassigned”
> > to have a provision for future use. Otherwise, I’m assuming
> 8126
> > definition is followed here:
> >
> >        Unassigned:  Not currently assigned, and available for
> assignment
> >              via documented procedures.  While it's generally
> clear that
> >              any values that are not registered are unassigned
> and
> >              available for assignment, it is sometimes useful
> to
> >              explicitly specify that situation.  Note that this
> is
> >              distinctly different from "Reserved".
> >
> >        Reserved:  Not assigned and not available for
> assignment.
> >              Reserved values are held for special uses, such as
> to extend
> >              the namespace when it becomes exhausted.
> "Reserved" is also
> >              sometimes used to designate values that had been
> assigned
> >              but are no longer in use, keeping them set aside
> as long as
> >              other unassigned values are available.  Note that
> this is
> >              distinctly different from "Unassigned".
> >
> >              Reserved values can be released for assignment by
> the change
> >              controller for the registry (this is often the
> IESG, for
> >              registries created by RFCs in the IETF stream).
> 
> Yes, the fields currently called "Reserved" could be changed to 
> "Unassigned".

[Med] ACK.

> 
> >
> > ## pre-RFC5378 work
> >
> > As RFC 3810 was published before 10 November 2008, we may need
> to
> > include a disclaimer for pre-RFC5378 work
> > (https://trustee.ietf.org/documents/trust-legal-provisions/tlp-
> 5/)
> > unless we obtain your approval to grant the BCP78 rights to the
> IETF Trust.
> >
> > Was there any action on that front to reach out the authors?
> 
> I have not made such an attempt. I do know that one author of
> 3810 is retired and no longer an active IETF participant. I can work 
> with the PIM chairs to determine the best path forward.
> 

[Med] Sounds like a plan. Thanks. I guess also that the writeup has to record this point. 

> > # Section 8.2.1:
> >
> > Current:
> >     An SSM-aware host that receives an MLDv1 General Query or
> MLDv1 Group
> >     Specific Query for a multicast address in the SSM range
> SHOULD log an
> >     error.  It is RECOMMENDED that implementions provide a
> configuration
> >     option to disable use of Host Compatibility Mode to allow
> networks to
> >     operate only in SSM mode.  This configuration option SHOULD
> be
> >     disabled by default.
> >
> > ## Any guidance about rate-limiting logging for the same error?
> 
> I will mirror the rate-limiting guidance found in 8.3.1.

[Med] ACK.

> 
> > ## I’m afraid the last part of the sentence is not clear as one
> may
> > interpret it as the configuration knob is not supported at all.
> I
> > suggest to make it explicit that you are talking about the
> knob’s
> > default value. ## Some may object to the use of normative
> language for
> > the local configuration. I think it is fine for this case. ##
> s/
> > implementions/implementation
> 
> s/It is RECOMMENDED that implementations/It is RECOMMENDED that an 
> implementation/
> 
> s/This configuration option SHOULD be disabled by default/The default 
> value for the configuration option SHOULD be disabled or off/

[Med] Thanks.

> 
> Thanks!
> Brian
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.