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

Hin Benjamin,
Thanks for your text. It looks good.

Regards,
Linlin

Linlin Zhou

From: Benjamin Kaduk
Date: 2018-11-13 03:40
To: Linlin Zhou
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)
Hi Linlin,

On Mon, Nov 12, 2018 at 09:11:59AM +0800, Linlin Zhou wrote:
> 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.

Thanks for checking with the other experts; it's good to get this nailed
down!

I would suggest not using RFC 2119 normative language for the MUST, since
that would be duplicating a normative requirement from Section 4.2, and we
usually try to only have normative requirements listed once (to avoid the
risk of two being in conflict with each other).  So maybe:

  The server operator reviews the request offline, and informs the client of
  the outcome of the review by queuing a service message for retrieval via
  the <poll> command; it MAY additionally  use an out-of-band mechanism to
  inform the client of the outcome.

-Benjamin

> 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.
>  
> 

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext