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

["Linlin Zhou" <[e-mail]>]

Dear Benjamin,
I have confirmed with others about this wording. Your understanding is right that "service message" means using the <poll> mechanism. So I suggest changing the text in section 4.3 like,
The server operator reviews the request offline, and MUST inform the client of the outcome of the review either by queuing a service message for retrieval via the <poll> command and MAY use an out-of-band mechanism to inform the client of the outcome.

Regards,
Linlin


Linlin Zhou
 
From: Linlin Zhou
Date: 2018-11-01 10:57
To: Benjamin Kaduk
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin,
I re-read the two paragraphs again and again. And I think I have the thought in mind that "service message" may be the key words to make you confused. 
In section 4.2, "the client MUST be notified using a service message", this "service message" has a relatively broad meaning, that it means the in-band or out-or-band service message. And "MUST" means you must send the message whether online or offline to the client.
If the above understanding is proper, In section 4.3 "either by queuing a service message for retrieval via the <poll> command...", this "service message" is not specified for <poll> excusively. 
Of course, I'll try to confirm with other EPP experts in parallel.

Regards,
Linlin


Linlin Zhou
 
From: Linlin Zhou
Date: 2018-10-31 13:45
To: Benjamin Kaduk
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin,
Please see my feedbacks below.

Regards,
Linlin


Linlin Zhou
 

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > Section 4.3
> > 
> >    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.

[Linlin] I can understand your concerns now. I think I had better propose a thread and ask the author or other EPP experts for confirmation. Once I get the feedback, I'll have a response. Thank you.