Thanks for the publication request for this document; here's my AD
review. None of this is a big thing, just some easy tweaks. It will
need a revised I-D, though, so I'll set the substate accordingly.
The Abstract goes into more detail than the Abstract needs to or
should. The Introduction correctly explains the details, but the
Abstract shouldn’t. I suggest trimming the Abstract thus (but please
do use your judgment on this):
NEW
The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
includes a method for the client and server to determine the objects
to be managed during a session and the object extensions to be used
during a session. The services are identified using namespace URIs,
and an “unhandled namespace” is one that is associated with a service
not supported by the client in question. This document defines an
operational practice that enables the server to return information
associated with unhandled namespace URIs that is compliant with the
negotiated services defined in RFC 5730.
END
— Section 1.1 —
Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.
Indentation and white space in examples are provided only to
illustrate element relationships and are not a REQUIRED feature of
this protocol.
That’s not a BCP 14 usage of “required”, and should be in lower case.
— Section 3 —
XML processing of the <value> element is
disabled in [RFC5730],
Where and how is this stated in 5730? I can’t find anything, but
perhaps I just don’t know where to look. It would be good to add a
section number to the citation.
— Section 8.2 —
Please change the Registrant Name to “IETF” (you may leave the email
address as it is), as that’s how the IESG prefers to designate it (the
IETF
— Section 10 —
Nit: make it “This document does not provide…”
That aside, I would be surprised if we don’t get some pushback about
this section, so maybe we should think about it a bit more. I accept
that there are likely no security issues raised by this operational
practice, but it would be good to address that more directly. This is
proposing that a server return information to a client that indicates
that the server believes a particular service is not supported by the
client. You should call that out, and consider whether that could
expose anything that could be used by an attacker — or that could be
misused to create an attack. Or, could an attacker do something
related to this practice that would allow it to disrupt some
legitimate communication?
The answer to all of that might be “no”, but it would be good to… as
we used to say in school, show your work.
--
Barry
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
