[pim] Re: Paul Wouters' Discuss on draft-ietf-pim-3228bis-06: (with DISCUSS)

["Gunter van de Velde (Nokia)" <[e-mail]>]

Hi Brian,

I have a question regarding the recent change involving the removal of the IETF Consensus path for IANA assignments. Specifically, I am interested in understanding if there has been any effort to validate and reach consensus on the relevance of the original RFC3228 security section, particularly in relation to the motivation behind this proposed change in 3228bis. Has there been a review to ensure that the decision to eliminate the IETF Consensus path and retain only the standards track is well-founded?

Thank you for your attention to this matter. I look forward to your insights.
Brgds,
G/


-----Original Message-----
From: Brian Haberman <[e-mail]> 
Sent: Wednesday, August 7, 2024 9:35 PM
To: Paul Wouters <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [pim] Re: Paul Wouters' Discuss on draft-ietf-pim-3228bis-06: (with DISCUSS)


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Paul,
      Some follow up below...

On 8/7/24 3:19 PM, Paul Wouters via Datatracker wrote:
> Paul Wouters has entered the following ballot position for
> draft-ietf-pim-3228bis-06: Discuss
>
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positi
> ons%2F&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7Cf13ee5fa65574b
> 6057f808dcb7180f20%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638586
> 561166060422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6MYQ3P95kU9cHnPM6
> s7QOWQZe87KwjblIqOgQTOwujE%3D&reserved=0
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-pim-3228bis%2F&data=05%7C02%7Cgunt
> er.van_de_velde%40nokia.com%7Cf13ee5fa65574b6057f808dcb7180f20%7C5d471
> 7519675428d917b70f44f9630b0%7C0%7C0%7C638586561166069507%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C0%7C%7C%7C&sdata=45DzGEXVeqsMVvSEFSj%2FSDIt9U%2FTKSoCzFl%2By
> hO%2Fu88%3D&reserved=0
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I find it a bit odd that the reason for why the IANA registration 
> policies are changed to Standards Track is only listed in the Security 
> Considerations. I think this belongs in the Abstract and / or Introduction.

That isn't the primary purpose of this revision to 3228. There have been new fields created within the IGMP and MLD headers that need consistent policies for assignment. That is why the Abstract calls out revised IANA Considerations for these protocols.

If it would help, I could add a sentence to the Introduction that explicitly mentions dropping the IETF Consensus method for allocating codepoints.

>
> In the Security Considerations it lists that the justification is more 
> or less that middleware screws up unknown values, so by making it 
> harder to make registrations, this will reduce the bad impact of this misbehaving middleware.
> I guess my question is if this is really the appropriate action for 
> the IETF to take in response to badly engineered middleware boxes. I 
> am assuming the old registration policy had a justification that is 
> still valid but now thrown under the bus. Has there been any 
> discussion of this on an IETF list? For example have known middlware 
> vendors been approached to try and get their implementations updated?

The Security Considerations section is virtually unchanged from 3228, modulo dropping the IETF Consensus path for IANA assignments.

Regards,
Brian