> -----Original Message----- > From: regext [mailto:[email protected]] On Behalf Of James Galvin > Sent: Friday, January 12, 2018 8:33 AM > To: Registration Protocols Extensions <[email protected]> > Subject: [EXTERNAL] [regext] WGLC: https://datatracker.ietf.org/doc/draft- > ietf-regext-allocation-token > > The document editors have indicated that the following document is ready > for submission to the IESG to be considered for publication as a Proposed > Standard: > > Allocation Token Extension for the Extensible Provisioning Protocol > (EPP) > https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token-05
Comments: Abstract: 1. The text says that "This document describes an Extensible Provisioning Protocol (EPP) extension for including an allocation token or for allocating an object like a domain name to the client", but I have no idea what an "allocation token" is based on reading the abstract. I think it would be better to say something like "This document describes an Extensible Provisioning Protocol (EPP) extension for including a <insert text here>, otherwise known as an "allocation token", or for allocating an object like a domain name to the client". 2. Please change "MAY" to "may" in the abstract. Introduction: same comment re: definition of "allocation token". "It is up to server policy which EPP transform commands and which objects support the allocation token" How does a client learn which commands and objects are supported? Section 2.1 (and 4.1): "The exact format of the Allocation Token is up to server policy." After reading this text I looked at the schema in Section 4.1 to see how it defined the allocationToken element. What I saw in 4.1 confused me a bit. The schema describes the allocationTokenType as an extension of the XML Schema "token" type, but it doesn't include any extensions or restrictions. So why not just do this? <element name="allocationToken" type="token"/> Having said that, without restrictions like minLength or maxLength I see the potential for some client-server interoperability issues. What, for example, is meant by a zero-length token? It's syntactically valid, but meaningless (I think). Might it not be better to have a minLength of 1 and some sufficiently long maxLength? Section 5.1: The title of this section is "XML Namespace", but it seems to be conflating a registration request for an XML namespace and the XML Schema described in Section 4. I'm going to recommend registering both the namespace and the schema in the same way it's done in, for example, RFC 5731. Section 7: These allocation tokens feel like they should be protected in some way. They're retrieved using an <info> command, so they get TLS privacy protection while in transit -- good. What, though, should a client do to protect them while they're sitting around waiting to be used in subsequent EPP commands? At a minimum, I think some text needs to be added here to note that there are risks associated with tokens sitting in some client-side data store. Similarly, are tokens designed to be used for only a single operation? Are there risks associated with reuse? Do they expire? If not, why? Please consider these questions about the tokens as just a sample of the kinds of topics that should be addressed in Section 7. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
