Thanks for the review, Tero. My responses can be found below.

Scott

> -----Original Message-----
> From: Tero Kivinen via Datatracker <[email protected]>
> Sent: Thursday, May 28, 2026 12:00 PM
> To: [email protected]
> Cc: [email protected]; [email protected];
> [email protected]
> Subject: [regext] draft-ietf-regext-ext-registry-epp-07 ietf last call Secdir
> review
> 
> Document: draft-ietf-regext-ext-registry-epp
> Title: Extension Registry for the Extensible Provisioning Protocol
> Reviewer: Tero Kivinen
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> Firstly this document has intended status of Standard Track, but
> it does not provide any kind of protocol, it just describes the
> processing rules for the IANA allocations for the EPP extensions
> registry.
> 
> The Change Log of the draft says that
> 
>   "Changed intended status from Informational to BCP."
> 
> but the section 1.1 says:
> 
>    *  The intended status has been changed from Informational to
>       Standards Track.
> 
> and the status is marked as Standard Track.
> 
> I think BCP (or informational) should be better status for this document
> than standard track.

[SAH] RFC 7451 was an Informational RFC. The working group decided to change 
the intended status of this draft (its replacement), to BCP. Med requested the 
change from BCP to Standards Track during AD review. I'll defer to his judgment 
to address your suggestion.

> ----
> 
> In addition to that there is text in section 2.1.1 saying
> 
>    If the specification for an extension is an IETF Standards Track
>    document, no review is required by the designated expert.
> 
> This is problematic. IANA will send review requests to designated
> experts even if the document comes from the IETF Standards Track
> document, and I think designated expert should review also those
> documents.
> 
> Note, that standard track documents can also come from completely
> unrelated working groups or area director sponsored documents, and
> it is good idea to get at least some expert to actually check that
> request (or at least bring it up to the group of people who
> know something about EPP extensions).
> 
> I do not see any reason why IETF Standard Track documents should
> not receive similar review than other documents by the designated
> expert. Hopefully those documents are properly made and there is
> no problems for the designated expert to approve those, but people
> writing those IETF Standard Track documents are not experts in the
> IANA registries, thus having designated expert helping them and
> reviewing their document is good thing.

[SAH] That's a good catch. You're right, IANA will normally request a review 
for Standards Track documents, too. That sentence can be removed.

> ----
> 
> In addition of those two bigger issues, there are several cases
> where RFC numbers are used without any useful title or text
> describing which document they refer to. This makes it harder for
> the newcomers to read IETF documents, as to be able to read a document
> you first need to have the mapping from 10000 RFC numbers to the
> titles of those RFCs. To make documents easier to read for people
> who are not experts in that area (i.e., who do not have the RFC
> number mappings memorized), add short title before referencing
> an RFC. The RFC number can still stay in the actual reference
> link.
> 
> Below is the list of such cases in this document, and proposed text
> to correct those:

[SAH] I'm going to defer to Med for this one, too. In my experience the RFC 
Editor commonly accepts citations as currently found in the draft.

Scott

_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to