[regext] Re: PLEASE RESPOND: INTERIM MEETING PLANNING (was: simplifying the extensions rules)

[James Galvin <[e-mail]>]

Thanks to all who have expressed interest in attending.  The chairs note 
10 people, including: Scott Hollenbeck, Mario Loffredo, James Gould, 
Jasdip Singh, Daniel Keathley, Pawel Kowalik, Jody Kolker, Tom Harrison, 
Victor Zhou, Andy Newton.

Andy has expressed a willingness to lead the discussion.  If there are 
no objections the Chairs would appreciate Andy taking on this role.

A Doodle poll has been created with 16 options for a meeting indicated 
from 6 May through 9 May.  If you’ve never done a Doodle poll before 
hopefully it’s self-explanatory.  If you have any questions please let 
the Chairs know.  Please indicate which times you are available.  The 
Chairs will review the selections and choose the best time.  If it turns 
out that none of these times work we’ll pick another week and try 
again.

Please complete the following Doodle poll by Friday, 11 April 2025.

https://doodle.com/group-poll/participate/dLWZVvrb

We’ll announce the results on Monday, 14 April 2025.

Thanks to all!

Antoin and Jim
	

On 2 Apr 2025, at 10:21, James Galvin wrote:

> Speaking as co-Chair:
>
> A virtual interim meeting is certainly an option and available.  
> Meetings can also be held in person but I’m assuming you’re asking 
> for a virtual meeting.  Planning is different if it’s going to be a 
> meeting in person.
>
> Let’s first start with who is willing and would attend the interim 
> meeting?  Let’s make sure we have more than a few people.  Would 
> folks please respond on list if they will attend?  Based on the 
> discussion I’m presuming that Andy, Pawel, Scott, Murray, Jasdip, 
> and Mario are at least interested.
>
> In addition, is there anyone who would like to chair the meeting?  
> It’s not required that one of the co-Chairs do it and it seems to me 
> that the folks in the discussion should be able to manage the meeting 
> themselves.  In addition to managing the discussion you’d have to 
> make sure there’s an attendance record and provide a meeting summary 
> for the record (which really only has to contain action items).  Your 
> Chairs will make sure the meeting gets set up.  Please indicate if 
> you’re willing to lead the discussion.
>
> Finally, note that we’ll need at least two weeks notice for the 
> meeting.  So, once we see that we have a reasonable set of people, I 
> propose to use a Doodle to find a date and time for the meeting.
>
> Thanks,
>
> Jim
>
>
> On 1 Apr 2025, at 15:50, Jasdip Singh wrote:
>
>> Hi all,
>>
>> Since this Extensions draft would be a useful contribution for 
>> clarifying the RDAP extensibility, and that there are other drafts 
>> waiting on it for a more definitive naming guidance, would it be more 
>> productive if we held an interim meeting before the next IETF to 
>> focus on ironing out any disagreements, especially the one about bare 
>> identifiers?
>>
>> Jim/Antoin/Orie, please advise on this matter.
>>
>> Thanks,
>> Jasdip
>>
>>
>> From: Pawel Kowalik <[e-mail]>
>> Date: Tuesday, April 1, 2025 at 12:11 PM
>> To: Andrew Newton (andy) <[e-mail]>, [e-mail] 
>> <[e-mail]>
>> Subject: [regext] Re: simplifying the extensions rules
>> Hi Andy,
>>
>> On 31.03.25 16:50, Andrew Newton (andy) wrote:
>>> Hi all,
>>>
>>> At IETF 122, Pawel brought up the lack of time to discuss the
>>> simplification of the extension rules as outlined in the email 
>>> below.
>>> From what I can tell, the working group agrees with the 
>>> simplification
>>> of rules on writing RDAP extensions, with the exception of Pawel. In
>>> fairness to him, this warrants a bit more discussion as his 
>>> position,
>>> as I understand it, is not a simple "I disagree."
>>>
>>> As I understand it (and Pawel please correct me), his position is 
>>> that
>>> violation of the rules should be NOT RECOMMENDED whereas our 
>>> statement
>>> below implies MUST NOT.
>>
>> [PK] Well, I don't like framing of my position with a lot of 
>> rhetoric.
>> "violation of the rules" sounds so obvious that it should be 
>> forbidden,
>> that it frames directly any disagreement into a difficult position to
>> argument for it.
>>
>> In fact "the rules" set in 2.1 of RFC9083 are no rules, but a
>> recommendation (SHOULD) itself. So I argument actually to keep the
>> status quo of RFC9083 as opposed to defining new rules as now the 
>> change
>> of -05 proposes.
>>
>> Also in the original E-mail you mentioned "complex set of rules" that
>> hinder interoperability without actually any evidence which these are 
>> or
>> would be. I went though all changes in -05 and I didn't find any 
>> point
>> where the rules got simplified in any way.
>>
>> Finally I argument that the provisions of STD 95 are absolutely
>> sufficient to maintain interoperability. By including the changes of
>> -05, even though the document ought to guide extension authors not 
>> the
>> implementations, it might either misguide the implementations which
>> would implement stricter rules and not be able to handle extension 
>> from
>> before extension draft publication as RFC - so the interoperability
>> would suffer in the end.
>>
>>>
>>> IMO, things like NOT RECOMMENDED and SHOULD/SHOULD NOT are nearly
>>> worthless unless they can be qualified. That is, unless we can
>>> describe the conditions for going against a recommendation then 
>>> there
>>> is no clear need to allow doing so. And that isn't just my opinion:
>>> the IESG routinely puts DISCUSSes on docs for this.
>>
>> [PK] That is correct and likely right to do so. Worth mentioning that
>> the -05 document uses "RECOMMENDED" in 9 places and "SHOULD" in 39 so 
>> I
>> really don't take it as a valid criteria to decide whether to change
>> RFC9083 / STD 95 or not.
>>
>>> I probably lack imagination, but I do not see the reason to allow an
>>> extension author to violate the rules. But that is me. The purpose 
>>> of
>>> this message is to gather other opinions.
>>
>> [PK] As mentioned above, "the rules" are recommendations, so there is 
>> no
>> violation taking place.
>>
>> Kind Regards,
>>
>> Pawel
>
>> _______________________________________________
>> regext mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]

> _______________________________________________
> regext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]