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.
----
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.
----
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:
--
In section 1 there is reference to the Extensible Provisioning Protocol
(EPP) [STD69], but then on 2nd paragraph there is just 5730 without
reference or title of the document.
Change
RFCs 3735 [RFC3735] and 5730 RFC5730 do not describe how extension
to
The guidelines [RFC3735] and base EPP [RFC5730] documents do not
describe how extension ...
--
In section 1 last to paragraph there is RFC 7451 without proper
title to describe what document it is.
Change:
RFC 7451 [RFC7451] filled that gap by defining the Extensions for the
Extensible Provisioning Protocol (EPP) IANA registry [IANA-REG] to
help manage and coordinate the development of EPP extensions.
This update was written to address issues that were identified with
RFC 7451 [RFC7451] over time. Refer to Section 1.1 for more details.
to
Previous version of this document [RFC7451] filled that gap by defining
the Extensions for the Extensible Provisioning Protocol (EPP) IANA
registry [IANA-REG] to help manage and coordinate the development of EPP
extensions.
This update was written to address issues that were identified over time.
Refer to Section 1.1 for more details.
--
In section 2.1 there is no usable title for the RFC8126.
Change:
This registry uses the "Specification Required" policy described in
RFC 8126 [RFC8126].
to
This registry uses the "Specification Required" policy described in
Guidelines for Writing an IANA Considerations Section [RFC8126].
--
Add title for RFC3735:
Note
that Section 2.1 of RFC 3735 [RFC3735] (or its future replacement)
provides specific guidelines for documenting EPP extensions.
to
Note
that Section 2.1 of Guidelines for extending EPP [RFC3735]
provides specific guidelines for documenting EPP extensions.
(And I do not see why we should say "(or its future replacement)"
anywhere in this document. If the RFC is obsoleted by some other
document it is natural that we use that new document.)
and change:
The "Specification Required" policy requires review by a designated
expert. Section 5 of [RFC8126] describes the role of designated
experts and the function they perform. For this registry, acceptable
specifications include RFC documents and proprietary specifications
that meet the "permanent and readily available" requirement described
in Section 4.6 of [RFC8126]. Internet-Draft documents are not
acceptable specifications for this registry.
to
The "Specification Required" policy requires review by a designated
expert. Section 5 of Guidelines for Writing an IANA Considerations
Section [RFC8126] describes the role of designated
experts and the function they perform. For this registry, acceptable
specifications include RFC documents and proprietary specifications
that meet the "permanent and readily available" requirement described
in Section 4.6 of Guidelines for Writing an IANA Considerations
Section [RFC8126]. Internet-Draft documents are not
acceptable specifications for this registry.
--
In section 2.1.1 change:
A high-level description of the role of the designated expert is
described in Section 5.2 of RFC 8126 [RFC8126].
to
A high-level description of the role of the designated expert is
described in Section 5.2 of Guidelines for Writing an IANA
Considerations Section [RFC8126].
and change
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].
to
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 Guidelines for Writing an IANA
Considerations Section [RFC8126].
--
In section 2.1.1 change:
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.
to
Extensions should be evaluated for architectural soundness using the
guidelines described in Guidelines for extending EPP [RFC3735]
(including the Security Considerations section of that document).
(note, there is closing parenthesis missing, and I removed reference to the
future replacements).
--
In section 2.1.1 change:
XML schemas, XML schema
URIs, and XML namespace URIs defined in the extension specification
MUST be registered in the IETF XML Registry using the procedures
described in RFC 3688 [RFC3688].
to
XML schemas, XML schema
URIs, and XML namespace URIs defined in the extension specification
MUST be registered in the IETF XML Registry using the procedures
described in The IETF XML Registry [RFC3688].
--
In section 2.2.1 change:
Document Status: The document status of the specification document.
For RFC documents, the possible set of values includes "Standards
Track", "Informational", "Experimental", "Historic", and "BCP" as
described in Sections 4 and 5 of RFC 2026 [RFC2026]. For documents
that are not RFCs, this will always be "Other".
to
Document Status: The document status of the specification document.
For RFC documents, the possible set of values includes "Standards
Track", "Informational", "Experimental", "Historic", and "BCP" as
described in Sections 4 and 5 of The Internet Standards Process
[RFC2026]. For documents that are not RFCs, this will always be "Other".
--
In section 2.2.1 change:
Internationalized Domain Name (IDN) TLDs MUST be specified in A-label
[RFC5890] format.
to
Internationalized Domain Name (IDN) TLDs MUST be specified in A-label
Internationalized Domain Names for Applications [RFC5890] format.
and
This can be an IPR disclosure
filed with the IETF in accordance with BCP 79 [BCP79] if the
to
This can be an IPR disclosure
filed with the IETF in accordance with IPRs in IETF Technology
[BCP79] if the
--
In section 2.2.3 change:
IESG Approval (Section 4.10 of [RFC8126]) is REQUIRED to remove or
deactivate registrations created through IETF consensus.
to
IESG Approval (Section 4.10 of Guidelines for Writing an IANA
Considerations Section [RFC8126]) is REQUIRED to remove or
deactivate registrations created through IETF consensus.
--
In section 4 change:
This document introduces no new security considerations to EPP.
However, extensions should be evaluated according to the Security
Considerations of RFC 3735 [RFC3735] (or its future replacement) and
STD 69 [STD69].
to
This document introduces no new security considerations to EPP.
However, extensions should be evaluated according to the Security
Considerations of Guidelines for Extending the EPP [RFC3735] and
Extensible Provisioning Protocol [STD69].
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
