Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06

[Martin Casanova <[e-mail]>]

Barry

Thanks for your review. Since James Gould is the main author of this
draft I think it is better if he comments your suggestions.
Nevertheless I try to answer your question about section 3.

RFC 5730 chapter 2.6:

Zero or more OPTIONAL <extValue> elements that can be used to
         provide additional error diagnostic information, including:

         *  A <value> element that identifies a client-provided element
            (including XML tag and value) that caused a server error
            condition.


The <value> element according to RFC 5730 should be used in a server
error condition. Therefore in responses that have normally a result code
starting with 2xxx like

 2004    "Parameter value range error"
 2005    "Parameter value syntax error"
 2306    "Parameter value policy error"

The intent of  draft-ietf-regext-unhandled-namespaces is to redefine the
purpose of the <value> element to be used with successful command
(result code 1xxx) and to use it to return content of the response that
normally would be omitted because the client did not announce the
extension/namespace at client login.
Maybe

XML processing of the <value> element is
       disabled in [RFC5730],

could be formulated more precisely explain this eg:

'The original usage of <value> defined in RFC 5730 returning
client-provded elements in unsuccessful command is redefined by this
document as to return unhanlded namespaces'.. or so..

Thanks again and stay healthy.

Martin Casanova




On 22.01.21 20:22, Barry Leiba wrote:
> 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.
>

-- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone [phone], direct [phone]
[e-mail], www.switch.ch