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

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 11:05:13 -0700

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.

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 25 Oct 2018 17:45:26 +0800

Dear Eric,
Thanks for your review. Please see my feedbacks below with [Linlin].

Regards,
Linlin

Linlin Zhou
 
From: Eric Rescorla
Date: 2018-10-25 02:05
To: The IESG
CC: regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Eric Rescorla has entered the following ballot position for
draft-ietf-regext-org-11: Discuss

 

 
DETAIL
S 3.4.
 
How does access control work here? If either of these values are set,
then it must be rejected?
[Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are set, these two statuses can coexist in the system. "clientUpdateProhibited" is set by the client and "serverUpdateProhibited" is set by the server.

S 4.1.2.
 
So I can only <info> one org?
[Linlin] Yes, <info> command supports one org id.

S 4.1.2.
 
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
[Linlin] If this sentence makes confusion. How about changing it to "It is up to the server policy to decide 
what optional attributes will be returned of an organization object." or just remove it?

S 3.2.1.

It's not the type that supports the list.
 [Linlin] Yes, thank you for your text.

S 3.4.
 
I'm not following this text. It is set by the server?
[Linlin] Yes, it is set by the server. Benjamin's comment will be adopted. Adding a sentence to clarify. "Other status values that do not begin with either "client" or "server" are server-managed".

S 3.4.
>         processed, but whose requested action is pending, is noted with
 
Who can set this?
 [Linlin] The server can set the error code to 1001 and send the response to the client.
 
S 3.5.
 
see above question about access control
[Linlin] If both the clientXXXProhibited and serverXXXProhibited are set, this situation is permitted.

S 3.6.
 
Who is this a levy on? The server MUST enforce it? What does it do if
there is an error?
 [Linlin] It is up to the servers to manage the organization levels. For example, if client creates a new organization with parentID, the server should validate this ID has no loop relation with others. If validation fails , the server should respond with an error code such as "2305" or other proper error codes.
 
S 4.1.2.
 
Isn't 0 and OPTIONAL redundant?
 [Linlin] Yes. This will be updated.
 
S 4.1.2.
>         attribute is used to define the name of a "custom" type.
 
Are duplicates allowed?
 [Linlin] If you mean the org can have two contacts with the same "admin" type, this is allowed according to the XML schema.
 
S 4.2.1.

S 4.2.5.
 
This also seems duplicative.
[Linlin] Indeed some elements descriptions appear some times in the document. I'd like to have some explanations here again.
This document borrowed the text structure from RFC5731, RFC5732 and RFC5733 of EPP. I think the intension of having some duplicated descriptions is for users' easy reading. When seeing the examples, they do not have to scroll up and down to find the elements definitions. Some descriptions are a little different, although <org:postalInfo> elements appear to be duplicated. Such as, "One or more <org:status> elements" in <info> response and "Zero or more <org:status> elements" in <create> command. Of course putting all the elements definitions in a section is a concise way for the document structure.

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Oct 2018 04:49:33 -0700

On Thu, Oct 25, 2018 at 2:44 AM Linlin Zhou <[email-masked]> wrote:

> ------------------------------
> Linlin Zhou
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Date:* 2018-10-25 02:05
> *To:* The IESG <[email-masked]>
> *CC:* regext-chairs <[email-masked]>; Pieter Vandepitte
> <[email-masked]>; draft-ietf-regext-org
> <[email-masked]>; regext <[email-masked]>
> *Subject:* [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11:
> (with DISCUSS and COMMENT)
> [Linlin] If you mean that clientUpdateProhibited and
> serverUpdateProhibited are set, these two statuses can coexist in the
> system. "clientUpdateProhibited" is set by the client and
> "serverUpdateProhibited" is set by the server.
>
>
That's not what I mean. What I mean is "what is the access control rule
that the server is supposed to apply".

> [Linlin] Yes, <info> command supports one org id.
Ok.

> what optional attributes will be returned of an organization object." or
I don't know, because I don't understand the semantics you are aiming for.
Are the other attributes optional.

> [Linlin] Yes, it is set by the server. Benjamin's comment will be adopted.
> Adding a sentence to clarify. "Other status values that do not begin with
> either "client" or "server" are server-managed".
>
>
> S 3.4.
Sorry, context got lost. Who can set "pendingCreate"?

> this situation is permitted.
Sorry, this is still not clear to me.

>  [Linlin] It is up to the servers to manage the organization levels. For
> example, if client creates a new organization with parentID, the server
> should validate this ID has no loop relation with others. If validation
> fails , the server should respond with an error code such as "2305" or
> other proper error codes.
>
>
OK, that would be good to explain.

>  [Linlin] If you mean the org can have two contacts with the same "admin"
> type, this is allowed according to the XML schema.
>
> S 4.2.1.
> [Linlin] Indeed some elements descriptions appear some times in the
> document. I'd like to have some explanations here again.
> This document borrowed the text structure from RFC5731, RFC5732 and
> RFC5733 of EPP. I think the intension of having some duplicated
> descriptions is for users' easy reading. When seeing the examples, they do
> not have to scroll up and down to find the elements definitions. Some
> descriptions are a little different, although <org:postalInfo> elements
> appear to be duplicated. Such as, "One or more <org:status> elements" in
> <info> response and "Zero or more <org:status> elements" in <create>
> command. Of course putting all the elements definitions in a section is a
> concise way for the document structure.
>
>
It's much harder for implementors because they don't know how to refactor
common code.

-Ekr

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 29 Oct 2018 16:18:36 +0800

Dear Eric,
Please see my feedbacks inline. I've removed the clarified items.

Regards,
Linlin

Linlin Zhou

 
DETAIL
S 3.4.

That's not what I mean. What I mean is "what is the access control rule that the server is supposed to apply".
[Linlin] The EPP statuses defined in draft-ietf-regext-org follows the model used in the other EPP RFC's, including RFC 5731- RFC 5733. The statuses define the command-level access control rules, where each supported transform command (update and delete) includes a corresponding client-settable ("client") and server-settable ("server") that prohibits execution of the command by the client. The client is allowed make an update only to remove the "clientUpdateProhibited" status when the "clientUpdateProhibited" status is set. Client-specific access control rules (e.g., sponsoring client versus non-sponsoring client) is not defined by the statuses, but is up to server policy.

S 4.1.2.

I don't know, because I don't understand the semantics you are aiming for. Are the other attributes optional.
[Linlin] To be consistent with other EPP RFCs, I suggest removing the sentence "It is up to the server policy to decide what attributes will be returned of an organization object."

 
S 3.4.
 
Who can set this?

Sorry, context got lost. Who can set "pendingCreate"?
[Linlin] PendingCreate or PendingXXX statuses are set by servers.

S 3.5.

 
[Linlin] Please see the above response.

S 4.2.1.

[Linlin] The attributes need to be defined differently for the create and the info response, since the info response needs to be more flexible with what is returned based on server policy decisions. Yes, they are the same elements, but whether they are required or optional may be different in a create than in a info response. The attributes are duplicated in the other EPP RFCs (RFC 5731 – 5733) for ease in implementation. Attempting to collapse the attributes will make it more difficult for implementors and will not be consistent with the other EPP RFCs.
 
S 4.2.5.
>         the parent object..

It's much harder for implementors because they don't know how to refactor common code.
[Linlin] Duplicating the attributes is needed to address server policy differences between create and the info response, to make it easier for implementors, and to be consistent with the other EPP RFCs (RFC 5731 - RFC 5733).

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Oct 2018 06:06:00 -0700

On Mon, Oct 29, 2018 at 1:17 AM Linlin Zhou <[email-masked]> wrote:

> [Linlin] The EPP statuses defined in draft-ietf-regext-org follows the
> model used in the other EPP RFC's, including RFC 5731- RFC 5733. The
> statuses define the command-level access control rules, where each
> supported transform command (update and delete) includes a corresponding
> client-settable ("client") and server-settable ("server") that prohibits
> execution of the command by the client. The client is allowed make an
> update only to remove the "clientUpdateProhibited" status when the
> "clientUpdateProhibited" status is set. Client-specific access control
> rules (e.g., sponsoring client versus non-sponsoring client) is not defined
> by the statuses, but is up to server policy.
>
>
I'm sorry, but this still isn't clear. Can you perhaps send some
pseudocode?

> [Linlin] To be consistent with other EPP RFCs, I suggest removing the
> sentence "It is up to the server policy to decide what attributes will be
> returned of an organization object."
>
>
Does that mean the other attributes are mandatory? If so, you need to say
that.

Then you should say so in the text.

>> [Linlin] Please see the above response.
Sorry, still not clear.

>> [Linlin] The attributes need to be defined differently for the create
> and the info response, since the info response needs to be more flexible
> with what is returned based on server policy decisions. Yes, they are the
> same elements, but whether they are required or optional may be different
> in a create than in a info response. The attributes are duplicated in the
> other EPP RFCs (RFC 5731 – 5733) for ease in implementation. Attempting to
> collapse the attributes will make it more difficult for implementors and
> will not be consistent with the other EPP RFCs.
>
>
This is a comment, not a DISCUSS, so you're free to ignore it, but as
someone who as implemented quite a few specifications, I don't agree with
the claim that it would make things more difficult for implementors.
Implementors want to reuse code and if it's a lot of work to see the
difference between two parts of the spec, this leads to mistakes.

> [Linlin] Duplicating the attributes is needed to address server policy
> differences between create and the info response, to make it easier for
> implementors, and to be consistent with the other EPP RFCs (RFC 5731 - RFC
> 5733).
>
>
Again, it's *not* easier for implementors.

-Ekr

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 31 Oct 2018 10:25:42 +0800

Dear Eric,
Please see my feedbaks below.

Regards,
Linlin

Linlin Zhou

 
DETAIL
S 3.4.

I'm sorry, but this still isn't clear. Can you perhaps send some pseudocode? 
[Linlin] Our proposal is to add the lead-in bolded text to match the existing EPP RFC's to the Organization mapping. There has been no issues with the interpretation of the statuses with the EPP RFCs, so it's best to match them as closely as possible. In section 3.4,

An organization object MUST always have at least one associated status 
value. Status values can be set only by the client that sponsors an 
organization object and by the server on which the object resides. A 
client can change the status of an organization object using the EPP 
<update> command. Each status value MAY be accompanied by a string 
of human-readable text that describes the rationale for the status 
applied to the object. 

A client MUST NOT alter status values set by the server. A server 
MAY alter or override status values set by a client, subject to local 
server policies. The status of an object MAY change as a result of 
either a client-initiated transform command or an action performed by 
a server operator.

Status values that can be added or removed by a client are prefixed 
with "client". Corresponding status values that can be added or 
removed by a server are prefixed with "server". The "hold" and 
"terminated" status values are server-managed when the organization 
has no parent identifier [Section 3.6] and otherwise MAY be client- 
managed based on server policy. Status values that 
do not begin with either "client" or "server" are server-managed.

Take "clientUpdateProhibited" for example. 
If status value "clientUpdateProhibited" is set by a client 
then <update> command is not allowed to perform by a client 
If status value "clientUpdateProhibited" is removed by a client or a server 
then no limitation of performing EPP commands 

S 4.1.2.

Does that mean the other attributes are mandatory? If so, you need to say that.
[Linlin] Yes, thank you.
If the element can appear once, the keyword "OPTIONAL" is used to specify it as an optional element.
If the element can appear multiple times, the word "zero" is used to specify it as an optional element.
Other elements are mandatory.

 
S 3.4.
 
Who can set this?

Then you should say so in the text. 
[Linlin] Yes. Please see the above updated text in section 3.4. "Status values that 
do not begin with either "client" or "server" are server-managed."

S 3.5.

 

Sorry, still not clear.
[Linlin] Please see the first issue feedback.

S 4.2.1.

This is a comment, not a DISCUSS, so you're free to ignore it, but as someone who as implemented quite a few specifications, I don't agree with the claim that it would make things more difficult for implementors. Implementors want to reuse code and if it's a lot of work to see the difference between two parts of the spec, this leads to mistakes. 

S 4.2.5.
>         the parent object...

Again, it's *not* easier for implementors
[Linlin] We want to have this document match what has been done in the other EPP RFCs. People always feel convenient with the existing patterns. As implementers of the EPP RFCs, they have been familiar with the EPP spcifications for years and we believe that it makes things easier for implementers.
 
-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Oct 2018 22:23:12 -0500

Trimming to just one potentially problematic suggestion...

> Linlin Zhou
[...]
> [Linlin] Our proposal is to add the lead-in bolded text to match the existing EPP RFC's to the Organization mapping. There has been no issues with the interpretation of the statuses with the EPP RF…

[bold does not work super-well in text/plain mail, but
https://www.ietf.org/mail-archive/web/regext/current/msg01912.html can show
it]

> A client MUST NOT alter status values set by the server. A server 

This seems overly zealous to the point of being harmful.  For example, if a
server sets the status to "ok", a client cannot replace it by
clientLinkProhibited?

-Benjamin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Oct 2018 20:23:27 -0700

On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou <[email-masked]> wrote:

> [Linlin] Our proposal is to add the lead-in bolded text to match the
> existing EPP RFC's to the Organization mapping. There has been no issues
> with the interpretation of the statuses with the EPP RFCs, so it's best to
> match them as closely as possible. In section 3.4,
>
> value.
> *Status values can be set only by the client that sponsors an organization
> object and by the server on which the object resides. A client can change
> the status of an organization object using the EPP <update> command. Each
> status value MAY be accompanied by a string of human-readable text that
> describes the rationale for the status applied to the object. *
>
>
>
>
>
> *A client MUST NOT alter status values set by the server. A server MAY
> alter or override status values set by a client, subject to local server
> policies. The status of an object MAY change as a result of either a
> client-initiated transform command or an action performed by a server
> operator.*
>
> managed based on server policy. *S**tatus values that *
> * do not begin with either "client" or "server" are server-managed.*
>
I think we are talking past each other. The question I am asking is what is
the access control algorithm for changing other values depending on whether
{client,server}UpdateProhibited is set.

-Ekr

>> sentence "It is up to the server policy to decide what attributes will
>> be returned of an organization object."
>>
>>
> [Linlin] We want to have this document match what has been done in the
> other EPP RFCs. People always feel convenient with the existing patterns.
> As implementers of the EPP RFCs, they have been familiar with the EPP
> spcifications for years and we believe that it makes things easier for
> implementers.
>
> -Ekr
>
>>

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 31 Oct 2018 11:37:51 +0800

Dear Benjamin,
"A client MUST NOT alter status values set by the server." The client can set "clientLinkProhibited" but can not alter "ok". "ok" and "clientLinkProhibited" can coexist.

Regards,
Linlin

Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 11:23
To: Linlin Zhou
CC: Eric Rescorla; regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Trimming to just one potentially problematic suggestion...
 
[...]

 
 
-Benjamin

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 31 Oct 2018 15:09:45 +0800

Sorry for correction. The client can set "clientLinkProhibited" but can not alter "ok". "ok" should be removed by the server.

Linlin Zhou
 
From: Linlin Zhou
Date: 2018-10-31 11:37
To: Benjamin Kaduk
CC: Eric Rescorla; draft-ietf-regext-org; regext-chairs; Pieter Vandepitte; iesg; regext
Subject: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Dear Benjamin,
"A client MUST NOT alter status values set by the server." The client can set "clientLinkProhibited" but can not alter "ok". 

Regards,
Linlin

Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 11:23
To: Linlin Zhou
 
[...]

 
 
-Benjamin