Hi Peter,

I’m not Roman (duh) but I noticed a closely-related issue in my review of 07 
(not complete yet) and since you’re already talking about it here, I thought 
I’d crash the party instead of starting a different thread with my ballot.

On Feb 28, 2025, at 11:26 AM, Peter Thomassen <peter=40desec...@dmarc.ietf.org> 
wrote:

Hi Roman,

Thank you very much for your review!

On 2/27/25 20:31, Roman Danyliw via Datatracker wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Peter E. Yee for the GENART Review.

** Section 6.2.

   The expert review should validate that the RRtype and
   Scheme do not conflict with any existing allocations.

Is this the totality of the guidance for the expert reviewer, lack of 
duplication?

Is more detail required given the size of the code point space?

The intention was to have the expert use their expertise to arrive at a 
judgment. Indeed, ensuring non-conflict applies equally to every new rrtype and 
is nothing worth saying.

The authors thus propose to remove that sentence, so only the following remains:

NEW
  Registration requests are to be recorded by IANA after Expert Review
  [RFC8126].

Does this change make sense to you?

As I said I’m not Roman :-) but… that change does not make sense to me. RFC 
8126 is indeed the place to look for details. It has a handy checklist [1] 
which says among other things,


   7.  If you're using a policy that requires a designated expert
       (Expert Review or Specification Required), understand Section 
5<https://www.rfc-editor.org/rfc/rfc8126.html#section-5>
       and provide review guidance to the designated expert (see
       Section 5.3<https://www.rfc-editor.org/rfc/rfc8126.html#section-5.3>).


The tl;dr (but please DO read the relevant sections) is that if you choose 
Expert Review as your policy, you have to provide guidance for the expert. I 
suppose you COULD make that guidance “use your expertise!” but customarily the 
guidance is somewhat more prescriptive. One example I happen to have at my 
fingertips is [2]. (Neither an endorsement nor particularly close to your 
specialization, just an example.)

—John

[1] https://www.rfc-editor.org/rfc/rfc8126.html#section-1.3
[2] https://www.rfc-editor.org/rfc/rfc7370.html#section-4
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to