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

[Brian Haberman <[e-mail]>]

Hi Gunter,
      The removal of IETF Consensus was done to make the IANA 
Considerations for both MLD and IGMP more consistent since they now 
share code point registries created in this document. As a note RFC 4443 
says ICMPv6 Code values are assigned via Standards Action. There was not 
a huge discussion on the mailing list, so I suspect most WG participants 
weren't interested in the IANA-related aspects of IGMP/MLD.

      As for the Security Considerations, the text currently in the 
document comes directly from 3228. I vaguely recall there being an 
emphasis at the time of its publication to have some type of security 
discussion in every RFC, so I suspect that is the genesis of that text. 
If you go back to earlier versions of 3228bis, I had actually taken out 
that text and put this in its place:

This document only defines IANA registy actions and there are no 
associated security issues.

That text was flagged in the Artart review and the reviewer said: "But 
it doesn't mention the compatibility/upgrade issue that was in the old 
document." So the original text was returned to cover those 
compatibility/upgrade issues.

Regards,
Brian

On 8/19/24 5:34 AM, Gunter van de Velde (Nokia) wrote:
> 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