Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Mon, Oct 29, 2018 at 09:55:22AM +0800, Linlin Zhou wrote:
> Dear Benjamin,
> Please see my feedbacks below. I've removed the clarified items.
> 
> Regards,
> Linlin
> 
> 
> Linlin Zhou
>  
> From: Benjamin Kaduk
> Date: 2018-10-25 02:34
> To: Linlin Zhou
> CC: iesg; regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
> Subject: Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >  
> > Some of the element descriptions (e.g., <org:postalInfo>) appear to be
> > duplicated in several places and are also rather long in prose form.  Is
> > there value in attempting to consolidate the structural definition to a
> > single place in the document and just refer to that structure from the
> > places where it can appear?
> > [Linlin] 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 sounds like it is not worth making this change for this document, then.
> Thanks for the background explanation!
> [Linlin] On one hand, the duplicated elements are needed to address the server policy differences to make it easier for implementors. And on the other hand, it is consistent with the other EPP RFCs (RFC 5731 - 5733).
> 
> >  
> > Section 4.1.2
> >  
> > The <org:addr> restrictions seem somewhat contrived/artificially
> > restricted; for example, there are postal addresses in the US with no
> > associated city.  Whether an organization would want to use such an address
> > as its contact location is another question, but I don't have a clear model
> > of what sort of constraints are intended to be applied by this element.
> > [Linlin] Sorry that I am not familiar with the US address. If no city is available, how about municipal or county information?
>  
> The type of place I'm thinking of would usually be referred to as
> "unincorporated DeKalb County" or occasionally "unincorporated Chicago"
> with some associated municipal or city information.  (As something of a
> side note, I currently reside in Saint Louis city, which is not part of any
> county; there is a distinct Saint Louis County that covers the surrounding
> areas.  Addresses can be hard; just like (personal) names!)
> [Linlin] Thanks for your information. Learnt a lot.
>  
> > This <postalInfo> element have the same structure with the <postalInfo> defined in RFC5733. This is an existing XML schema in the running EPP system. Domain registries and registrars have already implemented it. Acturally this is an optional info here. You can have no <postalInfo>, one <postalInfo> or two <postalInfo> elements.
>  
> I definitely do not want to suggest diverging the definition of
> <postalInfo> from RFC5733, so please treat this entire conversation as a
> side note with no actions to take.
> [Linlin] Ok. Thank you.
>  
> > Section 4.2.2
> >  
> > Is there value in an example of the 2305-error response?
> > [Linlin] I think the example of 2305 error would like follows,
> > S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
> > S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> 
> > S: <response> 
> > S: <result code="2305"> 
> > S: <msg lang="en">Object association prohibits operation</msg> 
> > S: </result> 
> > S: <trID> 
> > S: <clTRID>ABC-12345</clTRID> 
> > S: <svTRID>54321-XYZ</svTRID> 
> > S: </trID> 
> > S: </response> 
> > S:</epp>
> >  
> > This example is much the similar with the existing one except for the "code" and "msg".
>  
> This is true, which suggests that there is not much value in having the
> additional example.  Thank you for showing me what it would look like,
> though.
> [Linlin] OK.
>  
> > Section 4.2.5
> >  
> > The elements in <org:add>/<org:rem> vs. <org:chg> seem to be disjoint sets;
> > what factors went into deciding to split them this way?
> > [Linlin] From my understanding, <org:add>/<org:rem> are used for the one-multiple relations. And <org:chg> is used for the one-one replacement.
> >  
> > Section 4.3
> >  
> >              The status of the corresponding object MUST clearly reflect
> >    processing of the pending action.  [...]
> >  
> > It's not entirely clear how this sentence is to be interpreted.  From
> > context, I assume that the intent is that <info> queries and similar must
> > report that the appropriate pendingFoo status values, but a literal reading
> > would seem to have this sentence be a requirement that the server change
> > what it reports for the object status, once the action is actually taken.
> > (Which is also something desired, but arguably already required by other
> > text.)
> >  [Linlin] The "transform command" is mentioned in the previous text. So the status means "status in the response", no need to perform the <info> query. So how about changin like "The status in the response of the corresponding object...".
>  
> I think that's an improvement, thanks.  (There might be further
> improvements possible, but we probably don't need to look for them.)
> [Linlin] Yes, thank you.
>  
> >    The status of the organization object after returning this response
> >    MUST include "pendingCreate".  The server operator reviews the
> >    request offline, and informs the client of the outcome of the review
> >    either by queuing a service message for retrieval via the <poll>
> >    command or by using an out-of-band mechanism to inform the client of
> >    the request.
> >  
> > I don't think the "either" is appropriate; the earlier text *requires* the
> > service message, and allows for additional optional notification
> > mechanisms.
> >  [Linlin] This <poll>mechanism is supported in section 2.9.2.3 of RFC5730. So this is a easy and convinient way to inform the clients.
>  
> I'm saying that the choice for the server is not "do X or do Y", it's: "do
> X, then either do Y or don't do Y".  The word "either" here implies that it
> is sometimes acceptable to not do X (where X is the queuing of the service
> message).
> [Linlin] In my understanding, I think the text means do X or do Y. You can have two choices to inform the result by <poll> of EPP command or by out-of-band actions. The following <poll> response is an example using <poll> mechanism. Of course you can also send an email to to contact of the organization.
> The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:)
> 

Perhaps I am misreading, but I see this text in Section 4.2 that says that
the server MUST always send a service message to notify the client:

                                                                   Once
   the action has been completed, the client MUST be notified using a
   service message that the action has been completed and that the
   status of the object has changed.  Other notification methods MAY be
   used in addition to the required service message.

The text here in Section 4.3 says:

   The status of the organization object after returning this response
   MUST include "pendingCreate".  The server operator reviews the
   request offline, and informs the client of the outcome of the review
   either by queuing a service message for retrieval via the <poll>
   command or by using an out-of-band mechanism to inform the client of
   the request.

which would allow either the service message, or an out-of-band mechanism,
or both mechanisms used together.

My issue with the document is that the document is internally inconsistent
-- in Section 4.2 it says "always do X", but Section 4.3 contradicts that
by saying "you could do X, or you could not do X and do Y instead".  An
implementor has to pick whether to believe Section 4.2 or Section 4.3, and
we should not force them to make such a choice.

-Benjamin