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

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 12 Nov 2018 09:11:59 +0800

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Nov 2018 13:40:25 -0600

Hi Linlin,

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

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

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 13 Nov 2018 08:51:14 +0800

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

 

-Benjamin
 
> [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
[email-masked]
https://www.ietf.org/mailman/listinfo/regext