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 <http://verisigninc.com/> On 11/23/17, 12:42 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> 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 <changePoll:who> 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 <changePoll:who> element instead if the first sentence leads with the <changePoll:who> element. I’ll change it to reference the <changePoll:who> 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, this is a command response extension of any object mapping, and the Object Attributes section provides extra information on the general attributes used within the extension. This is consistent with what has been done in other extensions like the RGP extension (RFC 3915) and the DNSSEC Extension (RFC 5910). The more complex attributes are more fully defined in section 2 and referenced from section 3, and the rest of the attributes are defined under the commands 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. How about changing the sentence to “This extension adds operation detail of EPP Object Mapping operations [section 2.1] to an EPP poll response, as described in [RFC5730], that is an extension of the EPP Object Mapping info response.”? The key point is that this is truly an extension of the object’s info response that is used in an EPP poll response. you say "Object Mapping" with uppercases, and before you had "object mapping". Please double check the whole documenthe and apply some uniform formatting. I will revise it to lowercase “object mapping” throughout the document. 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. I changed transaction to operation. 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? I believe that a “Dates and Times” section needs to be added to section 2 to address this generically. 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. The reason why is because these are the only known external case identifiers that can be referenced. The abstract includes sample use cases but not an exhaustive list. The “custom” enumerated value with the “name” attribute can be used for new cases. If “court” and “bulk” are common cases with external identifiers, then they can be added, but I don’t believe this is the case. 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? I thought about this one, and yes this is a grey area. I believe it’s more important to keep the use of the required “after” state here. The use of the “before” state is optional and I don’t want to add complexity by adding support for it here. In this case, the operation is identifying to the client that the specified record that is included was purged from the system. 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. Thanks for additional cases that can be considered for inclusion. I believe that there is a long list of possible cases, but I have a concern with attempting to focus too much on the cases that the extension can support instead of focusing on the elements of the extension itself. The extension has been made generic enough to apply to a very large set of cases. Implementation status: you can add Net::DRI as a client if you like, it implements all the draft. Thanks again for the work on Net::DRI, and we can certainly add Net::DRI to the Implementation Status section. Can you provide the following key values to add to the draft or you can also submit a pull request to the EPP-Allocation-Token-Specification GitHub project (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git) if you want to define it yourself? 1. Organization 2. Description 3. Level of maturity 4. Coverage 5. Licensing 6. Contact 7. URL -- Patrick Mevzek p...@dotandco.com _______________________________________________ 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
