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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
