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, this is a command response extension of any object mappi

[regext] regarding draft-ietf-regext-org-01 and draft-ietf-regext-org-ext-01

[James Galvin]

The authors have added the implementation status sections that the 
working group requested.  At this time we need final working group 
review.  The authors are ready to ask for working group last call and in 
order to proceed the Chairs need to see support for these documents on 
the list.


Please indicate your support or comments regarding these documents.

Antoin and Jim

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

Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt

[James Galvin]

Matt - do you have an update of the document or to your comments below?

Working group - are there any other comments or review of this document. 
 We need additional review before we can go to working group last call.


Thanks!

Jim



On 14 Sep 2017, at 13:36, Matthew Pounsett wrote:


On 16 June 2017 at 10:03, Antoin Verschuren  wrote:


Dear authors,

I could finally find some time to make a more thorough personal 
(chair-hat

off) preliminary review on this document.
Here are my comments:



Hi Antoin.  My apologies for taking so long to getting around to 
replying.

:)

I think we've addressed most of your notes either in Jacques's reply 
or in
the latest update, but I wanted to discuss a couple of things 
independently.


" This document describes a simple protocol that allows a third party

   DNS operator to update DS records for a delegation, in a trusted
   manner, without involving the Registrant for each operation.  This
   same protocol can be used by Registrants.”

This sounds dubious. Is the registrant involved or not?
I would say:

" This document describes a simple protocol that allows any
   DNS-operator to update DS records for a delegation, in a trusted
   manner, without involving any intermediate administratieve 
entities

between the DNS-operator and the parent.”



I agree that the wording in the current draft is a bit awkward.  
However,

your suggestion isn't quite correct either, since we're expecting this
draft to be implemented by registrars in a gTLD environment, and they 
are

not the parent.

The intent of the current wording is to point out that this was 
developed

to allow third-party operators to update their customers' DNS without
having to involve the customer, but then to also note that advanced
registrants who want to automate their own DS updates can also use it 
(it's

not limited to third-party operators).

What the API and processes described in the draft really allow is for 
the
registrant or their DNS operator to avoid the *authenticated* web UI 
of
their "Registration Entity", whether that be the registrar or the 
registry,
because nobody implements a way for a regsitrant to add credentials 
for
their DNS operator and we have no reason to expect anyone ever will.  
Even

if they did, there's still a scaling problem for the operator.

I'm going to think about a better way to word this paragraph which 
doesn't
encourage the reader to think we're setting up something that is 
entirely
unauthenticated or unvalidated.   If you have any other suggestions 
I'm

glad to hear them.







1. Introduction:

"After a domain has been registered, one of three parties will
   maintain the DNS zone loaded on the "primary" DNS servers: the
   Registrant, the Registrar, or a third party DNS operator.”

I object to this phrasing, as it suggest an entity performs it’s 
role as

DNS-operator as part of another role he might play. It’s always the
DNS-operator and only the DNS-operator that maintains the DNS zone.
An entity can act as both registrant AND DNS-operator, registrar AND
DNS-operator, or as a standalone DNS-operator, but an entity never
maintains a zone in any other role than as DNS-operator. They should 
be

clearly separated to keep roles and entities clearly defined.
This whole section need a thorough review on definitions of roles and
entities performing multiple roles.

Does this work better?


After a domain has been registered, the DNS operator for the child 
zone on

the "primary" DNS servers might be the registrant, the registrar, or a
third party.




3.2 Establishing a Chain of Trust:

This is the section where I have most problems with.
The bootstrapping of a secure delegation can never be done over an
insecure channel such as DNS without a chain of trust for polling the
initial key.
Unfortunately, I have not followed the discussions for RFC8078, but 
when I
read that now, I think paragraph 3.3 and 3.5 from RFC8078 are a 
terrible
mistake security wise, and a downgrade from previous practice. I 
believe
that insertion of the first key at the parent should always have been 
over
a secure channel, or confirmed over a secure channel, and in the 
absence of
a chain of trust in DNS prior to a secure delegation, the only way to 
do

that is over the secure administrative channel such as EPP or another
proven secure channel which DNS without DNSSEC validation is not.
I challenge RFC8078 that it probably had too little review from 
security
folks, and I don’t want to make the same mistake here, which makes 
it even
less secure by saying "Once the Registrar sees these records it 
SHOULD

start acceptance processing.”
No way. It should never accept a security proof or security inception
process over an insecure channel.

Also, the introduction of this document only states "Update DS 
records”
which I agree with, but Establishing a Chain of Trust is not updating 
but

bootstrapping.



I think we're going to have to continue to disagree, here.  Not only 
has
8078 been

[regext] Additional WGLC for draft-ietf-regext-launchphase

[Antoin Verschuren]

Hi all,

This ia an additional Working Group Last Call for the Launchphase document 
draft-ietf-regext-launchphase.
You can find the latest version of the document here:
https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/

The authors did an excellent job correcting issues that came up during the IESG 
review.
However, some of the comments, especially the comments made by Ben Campbell 
(See the change log in the document) made it necessary to change normative 
language, which may have substantially changed some intent in the document.
We think it’s all fine, but to be sure we didn’t miss anything, we will make an 
additional WGLC.

Since it’s holiday season, this WGLC will end January 5th.
Please review the changes made to the document, and let us know before January 
5th if you have any comments.

Regards,

Jim and Antoin

- --
Antoin Verschuren

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








signature.asc
Description: Message signed with OpenPGP using GPGMail
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext