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

From: "Gould, James" <[email-masked]>
Date: Wed, 15 Nov 2017 03:03:06 +0000

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

—

JG

[id:[email-masked]]

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com<http://verisigninc.com/>

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 23 Nov 2017 06:42:09 +0100

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 <changePoll:who> 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
   <info> poll response,
There is no <info> 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 name itself
in the message, but I still think there should be no domain
data if it was purged.
What do you think?

As a more generic note, you may include a non exhaustive list of
cases to show when such messages could be produced:
- for out of band contact eligibility tests by registry, contact
data may change
- when a domain name is transfered in-bailiwick hosts get transfered
too, that could add service messages for them. But then which registrars
should get the messages about the hosts? The one before or after the
transfer? Both?
- for out of band domain tests by registry, like technical ones
related to resolution
- for contacts being automatically purged by a registry after
some time of non-use
- etc.

Implementation status: you can add Net::DRI as a client if you like,
it implements all the draft.

-- 
  Patrick Mevzek
  [email-masked]