Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll

[Patrick Mevzek]

On Thu, Jan 4, 2018, at 22:41, Gould, James wrote:
> Patrick,
> 
> You will pleased to know that after attempting to write the new section 
> describing the expected behavior for the state attribute, that I agree 
> with you.  How about the following text for the new State section 2.2?

It seems to nicely explain things, so I am happy with it.

Thanks for your changes and patience.

-- 
  Patrick Mevzek

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

Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll

[Gould, James]

Patrick,

You will pleased to know that after attempting to write the new section 
describing the expected behavior for the state attribute, that I agree with 
you.  How about the following text for the new State section 2.2?

The state attribute reflects the state of the object "before" or "after" the 
operation. The state is defined using the OPTIONAL "state" attribute of the 
 element, with the possible values "before" or "after" 
and with a default value of "after". The server MAY support both the "before" 
state and the "after" state of the operation, by using one poll message for the 
"before" state and one poll message for the "after" state. The "before" state 
poll message MUST be inserted prior to the "after" state poll message.

For operations in Section 2.1 that don't have an "after" state, the server MUST 
use the "before" state poll message. For example, for the "delete" operation 
with the "op" attribute set to "purge", or the "autoPurge" operation, the 
server includes the state of the object prior to being purged in the "before" 
state poll message.

For operations in Section 2.1 that don't have a "before" state, the server MUST 
use the "after" state poll message. For example, for the "create" operation, 
the server includes the state of the object after creation in the "after" state 
poll message.
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 1/3/18, 7:06 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Wed, Jan 3, 2018, at 14:08, Gould, James wrote:
> I can add a subsection in section 2 to describe the expected before for 
> both the create and the delete (purge) to ensure that the servers 
> implement it consistently and the clients know what to expect.  Do you 
> agree?

I think we will agree to remain in disagreement on the subject itself,
as you put the protocol over the semantics and I do the opposite.

However putting more text and explanations as you suggest would certainly
help implementers to better understand things, so this will be welcome I am 
sure.

-- 
  Patrick Mevzek

___
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

Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll

[Patrick Mevzek]

On Wed, Jan 3, 2018, at 14:08, Gould, James wrote:
> I can add a subsection in section 2 to describe the expected before for 
> both the create and the delete (purge) to ensure that the servers 
> implement it consistently and the clients know what to expect.  Do you 
> agree?

I think we will agree to remain in disagreement on the subject itself,
as you put the protocol over the semantics and I do the opposite.

However putting more text and explanations as you suggest would certainly
help implementers to better understand things, so this will be welcome I am 
sure.

-- 
  Patrick Mevzek

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

Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll

[Gould, James]

Patrick,

Sorry again about the long delay in my review of your feedback.  Thank you for 
doing the detailed review.  I include my responses to your feedback embedded 
below.

  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 11/23/17, 12:42 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

Hello James and Kal,

Here are my comments on the draft:

The abstract is almost longer than the introduction,
and I believe it should be the opposite.

I prefer this sentence in the abstract:
notifying clients of operations on client sponsored
   objects that were not initiated by the client through EPP. 

over this one in the introduction:
to notify clients of operations they are not
   directly involved in, on objects that the client sponsors.
   
I think the given clients are directly involved as they are
the sponsors on the objects being operated. I think it is best
to say something like in the abstract, which is that the goal
of this extension is to notify clients of operations conducted
on objects they sponsor and which were not initiated by them.
(please rephrase that in proper English).

Ok, we’ll look at the abstract and introduction.  

"Using this extension clients can more easily keep"
A missing "," after extension?

Agreed, I’ll add the missing ‘,’.  

"a poll message can be inserted"
The whole purpose of the extension is to add these poll messages,
so maybe being more affirmative like "one or more poll messages
are inserted".

I would love to be more affirmative, but the definition of “client needs” and 
what the server can do in what iteration is a gap that may not meet the more 
affirmative language.  The goal is certainly that a poll message is inserted 
for all changes that the client needs to be notified of, but I don’t believe 
the draft can force the server policy.  

Also, RFC5730 speaks about the poll *command* but otherwise it is
about *service messages*, so it is maybe better to align
the terminology.

Since RFC 5730 explicitly refers to the poll command and that is understood 
terminology in the industry, I believe it’s best to stick to the poll command 
and response terminology.  

2.1

For transfer, why is the op attribute optional, especially since
it has no default value?
RFC5730 defines 5 transfer sub-operations with no extension possible,
so I believe here the op attribute should be mandatory
   
As for restore that has a sub operation case too, I think the same
reasoning apply.

How about changing the language in describing the “transfer” and “restore” and 
“custom” operations to require the setting of the “op” attribute as in: 

Transfer operation as defined in [RFC5730] that MUST set the "op" attribute 
with one of the possible transfer type values that include "request", 
"approve", "cancel", or "reject".
Restore operation as defined in [RFC3915] that MUST set the "op" attribute with 
one of the possible restore type values that include "request" or "report".
Custom operation that MUST set the "op" attribute with the custom operation 
name.

2.2 Maybe a little rephrasing to be clearer, I suggest:
"The  element defines who executed the operation,
for audit purposes."

Agreed, I’ll make that change.

Further below, you capitalize who as Who but I see no reason to
do that.

That is chaptalized since it referring to the term being defined.  It may be 
better to refer to the  element instead if the first sentence 
leads with the  element.  I’ll change it to reference the 
 element instead of the capitalized Who.  

Then you list 3 possible cases for the content of the who attributes,
but since it is just a normalizedString, the consumer of such poll
messages has no indication in which of these 3 cases we are, or others.
Maybe it would be better to add an attribute to the who element,
like "type" that remains free text but will allow the registry
to explain what the who content is about with such values
as "identifier" (and/or "roid" and/or "gurid" for example°),
"name" or maybe better "individual", and "role", or "batch".

The main question is whether a client will need or want to know this?  This is 
somewhat similar to the domain:crID and domain:upID in RFC 5731, where the 
client may use the information for capturing but they will not drive logic on 
it.  We certainly do need to capture who made the change, but I’m not convinced 
that adding a “type” is needed by the client.   

I found the whole section 2 to not be clear enough. You state that
it is an extension to object mappings and then you discuss only two
attributes, while others are discussed later in section 3.

Yes, 

Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll

[Antoin Verschuren]

James,

Same for this one.
Jim and I were going to send out a formal WGLC on this document, but we didn’t 
see a reply to this extensive review yet.
What do you want us to do, wait for you to have treated Patrick’s comments, or 
consider them as part of WGLC (Which may have a deadline)?

Jim and Antoin

- --
- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392






Op 23 nov. 2017, om 06:42 heeft Patrick Mevzek  het volgende 
geschreven:

> Hello James and Kal,
> 
> Here are my comments on the draft:
> 
> The abstract is almost longer than the introduction,
> and I believe it should be the opposite.
> 
> I prefer this sentence in the abstract:
> notifying clients of operations on client sponsored
>   objects that were not initiated by the client through EPP.
> 
> over this one in the introduction:
> to notify clients of operations they are not
>   directly involved in, on objects that the client sponsors.
> 
> I think the given clients are directly involved as they are
> the sponsors on the objects being operated. I think it is best
> to say something like in the abstract, which is that the goal
> of this extension is to notify clients of operations conducted
> on objects they sponsor and which were not initiated by them.
> (please rephrase that in proper English).
> 
> "Using this extension clients can more easily keep"
> A missing "," after extension?
> 
> "a poll message can be inserted"
> The whole purpose of the extension is to add these poll messages,
> so maybe being more affirmative like "one or more poll messages
> are inserted".
> 
> Also, RFC5730 speaks about the poll *command* but otherwise it is
> about *service messages*, so it is maybe better to align
> the terminology.
> 
> 2.1
> 
> For transfer, why is the op attribute optional, especially since
> it has no default value?
> RFC5730 defines 5 transfer sub-operations with no extension possible,
> so I believe here the op attribute should be mandatory
> 
> As for restore that has a sub operation case too, I think the same
> reasoning apply.
> 
> 2.2 Maybe a little rephrasing to be clearer, I suggest:
> "The  element defines who executed the operation,
> for audit purposes."
> 
> Further below, you capitalize who as Who but I see no reason to
> do that.
> 
> Then you list 3 possible cases for the content of the who attributes,
> but since it is just a normalizedString, the consumer of such poll
> messages has no indication in which of these 3 cases we are, or others.
> Maybe it would be better to add an attribute to the who element,
> like "type" that remains free text but will allow the registry
> to explain what the who content is about with such values
> as "identifier" (and/or "roid" and/or "gurid" for example°),
> "name" or maybe better "individual", and "role", or "batch".
> 
> I found the whole section 2 to not be clear enough. You state that
> it is an extension to object mappings and then you discuss only two
> attributes, while others are discussed later in section 3.
> 
> 
> 3.1.2
> 
> Should be retitled about service messages and poll commands, as this
> sentence is wrong:
> This extension adds transaction detail of the operations to the EPP
>poll response,
> There is no  poll response, but just a poll response with
> a service message it has nothing to do with the info command.
> 
> you say "Object Mapping" with uppercases, and before you
> had "object mapping". Please double check the whole documenthe
> and apply some uniform formatting.
> 
> This sentence is not clear:
> "This extension adds transaction detail of the operations"
> Which operations? Why using the term "transaction"?
> Did you want instead to clearly speak about "transform
> operations" like you do elsewhere.
> 
> changePoll:date : please specify in what timezone it SHOULD
> or MUST be.
> RFC5731 section 2.4 says about date and times:
> Date and time attribute values MUST be represented in Universal
>   Coordinated Time (UTC) using the Gregorian calendar.
> Maybe you should do the same here for homogeneity?
> 
> changepoll:caseId has only two specified values for its type
> attribute (UDRP and URS) but if we go back to the abstract
> where you listed possible cases, you listed UDRP and URS,
> but also court directed actions, and bulk updates.
> So why not also add types "court" and "bulk" for example
> That would make the informal abstract and the formal technical
> specification more closely aligned.
> 
> 
> 
> I am not sure to understand the example for the autopurge.
> If the registry deletes a domain with an immediate purge I expect the
> domain not to exist anymore. But in your example you show the "after"
> state
> and there you have a domain:name and a domain:clID still... but the
> domain
> should not exist anymore.
> In my view you should have the before state with all domain:infDatq, and
> for the
> after state, there should be no domain data anymore.
> I agree it creates a problem as you loose the domain 

[regext] Request for Working Group Last Call for draft-ietf-regext-change-poll

[Gould, James]

This was discussed at the regext WG meeting at IETF-100.

—

JG

[id:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext