+1 Kind regards Pawel
> On 1. Apr 2025, at 21:59, Jasdip Singh <jasd...@arin.net> 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 <kowa...@denic.de> > Date: Tuesday, April 1, 2025 at 12:11 PM > To: Andrew Newton (andy) <a...@hxr.us>, regext@ietf.org <regext@ietf.org> > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
