[regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 24 October 2018 18:05 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBE2124C04; Wed, 24 Oct 2018 11:05:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: regext-chairs@ietf.org, pieter.vandepitte@dnsbelgium.be, Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>, draft-ietf-regext-org@ietf.org, regext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154040431305.6967.8110836894354286749.idtracker@ietfa.amsl.com>
Date: Wed, 24 Oct 2018 11:05:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/rGahtLqTxNIFrROIpIG2rY_Aas8>
Subject: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 18:05:13 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-regext-org-11: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



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

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3624


This DISCUSS should be easy to clear. I have noted a few points where
I do not believe that the spec is sufficiently clear to implement.

DETAIL
S 3.4.
>   
>      o  clientUpdateProhibited, serverUpdateProhibited: Requests to update
>         the object (other than to remove this status) MUST be rejected.
>   
>      o  clientDeleteProhibited, serverDeleteProhibited: Requests to delete
>         the object MUST be rejected.

How does access control work here? If either of these values are set,
then it must be rejected?


S 4.1.2.
>      C:        <org:id>res1523</org:id>
>      C:      </org:info>
>      C:    </info>
>      C:    <clTRID>ABC-12345</clTRID>
>      C:  </command>
>      C:</epp>

So I can only <info> one org?


S 4.1.2.
>   
>      o  One or more <org:status> elements that contain the operational
>         status of the organization, as defined in Section 3.4.
>   
>      o  An OPTIONAL <org:parentId> element that contains the identifier of
>         the parent object, as defined in Section 3.6.

It's not clear to me what's really optional here, because you say
above that it's up to the server but then you label some stuff here as
OPTIONAL


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

S 3.2.1.
>      object.  A client can change the role of an organization object using
>      the EPP <update> command.
>   
>   3.2.1.  Role Type
>   
>      An organization role MUST have a type which supports a list of

Editorial: I found this confusing. I think you want to say "MUST have
a type field. This may have any of the values listed in ...."

It's not the type that supports the list.




S 3.4.
>         rejected.
>   
>      o  linked: The organization object has at least one active
>         association with another object.  The "linked" status is not
>         explicitly set by the client.  Servers should provide services to
>         determine existing object associations.

I'm not following this text. It is set by the server?


S 3.4.
>         has been processed for the object, but the action has not been
>         completed by the server.  Server operators can delay action
>         completion for a variety of reasons, such as to allow for human
>         review or third-party action.  A transform command that is
>         processed, but whose requested action is pending, is noted with
>         response code 1001.

Who can set this?


S 3.5.
>         association with another object.  The "linked" status is not
>         explicitly set by the client.  Servers SHOULD provide services to
>         determine existing object associations.
>   
>      o  clientLinkProhibited, serverLinkProhibited: Requests to add new
>         links to the role MUST be rejected.

see above question about access control


S 3.6.
>      not defined for the top level reseller, namely the registrar of the
>      registry.  An N-tier reseller has a parent reseller and at least one
>      child reseller.  A reseller customer has a parent reseller and no
>      child resellers.
>   
>      Loops MUST be prohibited.  For example: if organization A has B as

Who is this a levy on? The server MUST enforce it? What does it do if
there is an error?


S 4.1.2.
>         email address.
>   
>      o  An OPTIONAL <org:url> element that contains the URL to the website
>         of the organization.
>   
>      o  Zero or more OPTIONAL <org:contact> elements that contain

Isn't 0 and OPTIONAL redundant?


S 4.1.2.
>         organization object.  Contact object identifiers MUST be known to
>         the server before the contact object can be associated with the
>         organization object.  The required "type" is used to represent
>         contact types.  The type values include "admin", "tech",
>         "billing", "abuse", and "custom".  The OPTIONAL "typeName"
>         attribute is used to define the name of a "custom" type.

Are duplicates allowed?


S 4.2.1.
>         status of the organization, as defined in Section 3.4.
>   
>      o  An OPTIONAL <org:parentId> element that contains the identifier of
>         the parent object, as defined in Section 3.6.
>   
>      o  Zero to two <org:postalInfo> elements that contain postal-address

These rules looks duplicative of <info>. Is there a way to collapse
them?


S 4.2.5.
>      where at least one child element MUST be present:
>   
>      o  An OPTIONAL <org:parentId> element that contains the identifier of
>         the parent object.
>   
>      o  Zero to two <org:postalInfo> elements that contain postal-address

This also seems duplicative.