[regext] Mahesh Jethanandani's Discuss on draft-ietf-regext-ext-registry-epp-07: (with DISCUSS and COMMENT)

[Mahesh Jethanandani via Datatracker <[e-mail]>]

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-regext-ext-registry-epp-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-ext-registry-epp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 2.1.1, paragraph 1
>    If the specification for an extension is an IETF Standards Track
>    document, no review is required by the designated expert.

It appears that the author has already agreed to remove this paragraph
from the document. This DISCUSS has been put in to track and make sure
that it is addressed in the next version.

As noted by the SECDIR reviewer (Tero Kivinen, May 28, 2026, thanks Tero),
IANA normally requests a DE review regardless of RFC status. This sentence
could be read as an instruction to IANA to skip that request, contrary to
standard practice.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.1.1, paragraph 1
>    The IESG should appoint a primary designated expert and a small
>    number of individuals (perhaps 3 - 5) to serve as backup designated
>    experts as described in Section 5.2 of [RFC8126].  The primary
>    designated expert is responsible for conducting all reviews requested
>    by IANA.  The secondary designated experts are responsible for
>    conducting reviews as a consensus-based group if the primary
>    designated expert is unavailable.  In cases where a registration
>    decision could be perceived as creating a conflict of interest for a
>    particular Designated Expert, that Expert SHOULD defer to the
>    judgment of the other Experts.  The designated experts MUST use the
>    existing regext mailing list ([e-mail]) or its successor for
>    public discussion of registration requests.

A SHOULD permits an expert with a perceived conflict of interest to decide
not to recuse in the above paragraph. Conflict-of-interest provisions
in governance contexts are typically mandatory. MUST would better reflect
the intent. I support Éric Vyncke who made a similar ballot comment.

Section 5, paragraph 1
>    Section 2 includes provisions for modifying and deleting existing
>    registration entries by registrants.  Such requests MUST NOT be
>    granted if the requested action has operational implication on other
>    entities that deploy that extension, assuming that those entities can
>    be identified.  This guidance can be overridden if the requested
>    action MUST be taken to comply with actions that are beyond the
>    control of the experts and/or IANA, e.g., to comply with legal
>    actions.  Note that the registry does not include a history mechanism
>    and there is no way to track deleted entries once they have been
>    removed.

The second sentence in this paragraph makes the prohibition conditional:
if affected parties cannot be identified, the constraint does not apply
and the removal could proceed despite potential operational impact.
If this is the intended policy, a brief rationale should be provided.
If not, the language should be tightened.

No reference entries found for these items, which were mentioned in the text:
[RFC5730].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1
>    RFCs 3735 [RFC3735] and 5730 RFC5730 do not describe how extension
>    development can be managed and coordinated.  This has led to a
>    situation in which server operators can develop different extensions
>    to address similar needs, such as the provisioning of Value Added Tax
>    (VAT) information.  Clients then need to support multiple extensions
>    that serve similar purposes, and interoperability suffers as a
>    result.

s/RFC5730/[RFC5730]/

You are missing the square brackets.

Section 2.1.1, paragraph 1
>    Extensions should be evaluated for architectural soundness using the
>    guidelines described in RFC 3735 [RFC3735] (or its future
>    replacement, including the Security Considerations section of that
>    document.  Expert evaluation should explicitly include consideration
>    of the privacy consequences of proposed extensions, and, at a
>    minimum, ensure that any privacy considerations are fully documented
>    in the relevant specification(s).

s/(or its future replacement/(or its future replacement)/)

You are missing the closing parenthesis.