Hi Scott, Tero, all, Please inline.
Cheers, Med > -----Message d'origine----- > De : Scott Hollenbeck <[email protected]> > Envoyé : jeudi 28 mai 2026 18:34 > À : 'Tero Kivinen' <[email protected]>; [email protected] > Cc : [email protected]; last- > [email protected]; [email protected] > Objet : RE: [regext] draft-ietf-regext-ext-registry-epp-07 ietf > last call Secdir review > > > 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. > [Med] I suggest to keep the current track for reasons already listed in https://mailarchive.ietf.org/arch/msg/regext/2EiYENIhQnkz_J9MDnKoy6zrQGI/. > > ---- > > > > 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. [Med] Exactly. This is a matter of editorial taste. > > Scott ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
