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

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 04 May 2016 15:23:59 +0200

I have read this document, understand the reasoning behind it, but disagree with the problem statement.

The reason why we have the registry/registrar model is that we did want competition in the registrar business, and that the domain holders and otherwise should use registrars that do have support for various (new) things instead of using registrars that did not implement what is needed.

If the authors of this draft do think that market economy have failed, then say so. Don't hide it behind words about what one must do as a DNS operator which is not true. It is needed if the registrant have chosen SOME registrars, and if the registrant have registered domain names in SOME TLDs.

There are registrars that allow technical contacts (so that the DNS operator do not have to use the registrant when interacting with the registrar), have restful APIs for the transactions needed (although not a standardised one), and remove signatures for domains that are transferred away from the registrar.

The claims that for example a DNS operator have to do this and that in this document is simply not true for all registrars, all TLDs or all registrants.

Some people do the right thing.

I.e. it is very important the reason for some feature like this -- that will impact the founding ideas why we invented the registry/registrar system -- is correct.

And at least that story should be told in a correct way in this draft.

Because the ability for DNS operators and others to bypass the registrars, which seems to be the goal here, will definitely impact the reasoning behind the model we use today for domain name registration if accepted and implemented.

   Patrik

On 26 Apr 2016, at 17:01, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Registration Protocols Extensions of the IETF.
>
>         Title           : Third Party DNS operator to Registrars/Registries Protocol
>         Authors         : Jacques Latour
>                           Olafur Gudmundsson
>                           Paul Wouters
>                           Matthew Pounsett
> 	Filename        : draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt
> 	Pages           : 10
> 	Date            : 2016-04-26
>
> Abstract:
>    There are several problems that arise in the standard
>    Registrant/Registrar/Registry model when the operator of a zone is
>    neither the Registrant nor the Registrar for the delegation.
>    Historically the issues have been minor, and limited to difficulty
>    guiding the Registrant through the initial changes to the NS records
>    for the delegation.  As this is usually a one time activity when the
>    operator first takes charge of the zone it has not been treated as a
>    serious issue.
>
>    When the domain on the other hand uses DNSSEC it necessary for the
>    Registrant in this situation to make regular (sometimes annual)
>    changes to the delegation in order to track KSK rollover, by updating
>    the delegation's DS record(s).  Under the current model this is prone
>    to Registrant error and significant delays.  Even when the Registrant
>    has outsourced the operation of DNS to a third party the registrant
>    still has to be in the loop to update the DS record.
>
>    There is a need for a simple protocol that allows a third party DNS
>    operator to update DS and NS records in a trusted manner for a
>    delegation without involving the registrant for each operation.
>
>    The protocol described in this draft is REST based, and when used
>    through an authenticated channel can be used to establish the DNSSEC
>    Initial Trust (to turn on DNSSEC or bootstrap DNSSEC).  Once DNSSEC
>    trust is established this channel can be used to trigger maintenance
>    of delegation records such as DS, NS, and glue records.  The protocol
>    is kept as simple as possible.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Dave Piscitello <[email-masked]>
Date: Wed, 4 May 2016 14:00:01 +0000

> On May 4, 2016, at 9:23 AM, Patrik Fältström <[email-masked]> wrote:
> 

By “problem statement”, I think you mean the text in the Introduction, and I will +1 with amplification.

The introduction would benefit from a clear problem statement, but I think it would be most helpful to explain the problem you’re seeking to mitigate without encumbering it at all with history/perspective.  Instead, can you unbiasedly explain

- the current workflow
- the aspects of the workflow that you think are impedances (the problem)
- why the impedances beg for a solution
- how the proposed protocol solves the problem

Personally, I don’t see that it’s going to be helpful to discuss market failure in a proposed standard. The registrar/registry model tends to be interpreted in many conversations as singularly an ICANN thing, which is entirely incorrect. Moreover, registration in the domain world is typically one of many services a business entity offers. Explaining this carefully may help in the introduction, since you’re trying to tease out that name service is separate from registration service, right?

> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Bill Woodcock" <[email-masked]>
Date: Wed, 4 May 2016 10:12:00 -0400

I think I'm in the middle on this one.  

- I agree that the document would be improved by sticking to technical matters, and not discussing market failure.  That's just asking for controversy. 

- I believe that it's reasonable to raise the bar for minimum acceptable service over time, provided that it doesn't raise the lowest available cost in the market.  This is how we achieve progress. RFC-compliance is not legally or regulatorily mandated, so I see no harm in defining a protocol that moves the state-of-the-art forward. 

- I very much believe that a standardized protocol in this area would be very useful. It's a little late in the day for the -best case- to be an unstandardized, vendor-specific API. 
    
                -Bill

> On May 4, 2016, at 10:01, Dave Piscitello <[email-masked]> wrote:
> 
>

---

From: Dave Piscitello <[email-masked]>
Date: Wed, 4 May 2016 15:49:48 +0000

> On May 4, 2016, at 10:12 AM, Bill Woodcock <[email-masked]> wrote:
> 

+!

> - I believe that it's reasonable to raise the bar for minimum acceptable service over time, provided that it doesn't raise the lowest available cost in the market.

Agree in the context of making a protocol available. Whether lowest available cost is the most important factor when you’re trying to achieve a universal adoption is perhaps a conversation best held over drinks.

>  This is how we achieve progress. RFC-compliance is not legally or regulatorily mandated, so I see no harm in defining a protocol that moves the state-of-the-art forward. 

+1

> 
> - I very much believe that a standardized protocol in this area would be very useful.

+1

> It's a little late in the day for the -best case- to be an unstandardized, vendor-specific API. 
> 
>                -Bill
> 
>

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 4 May 2016 12:29:57 -0400

On 4 May 2016 at 09:23, Patrik Fältström <[email-masked]> wrote:

> The reason why we have the registry/registrar model is that we did want
> competition in the registrar business, and that the domain holders and
> otherwise should use registrars that do have support for various (new)
> things instead of using registrars that did not implement what is needed.
>
> If the authors of this draft do think that market economy have failed,
> then say so. Don't hide it behind words about what one must do as a DNS
> operator which is not true. It is needed if the registrant have chosen SOME
> registrars, and if the registrant have registered domain names in SOME TLDs.
>

I think there's some misunderstanding of the problem involved. We already
have some (I think) improved text for the Abstract and Introduction in the
pipeline, but let me address the specific misunderstanding I see here.

This is not about registrars that don't provide modern service.  This is
about the fact that the market should allow users to select a DNS Operator
who is not their Registrar, and that DNS Operator should not be impeded
from providing good service to the Registrant because of the RRR model we
have set up.   As it currently stands, a DNS Operator must become a
Registrar, and require all of their customers to make the DNS Operator
their Registrar of record, if the DNS Operator wants to DNSSEC sign zones
on any kind of scale, because there is no standard way for them to submit
DS record updates at scale otherwise.

> There are registrars that allow technical contacts (so that the DNS
> operator do not have to use the registrant when interacting with the
> registrar), have restful APIs for the transactions needed (although not a
> standardised one), and remove signatures for domains that are transferred
> away from the registrar.
>

Some very small percentage of Registrars have APIs for managing
registrations, yes.   I have never heard of a non-ccTLD-Registrar that
allows anyone other than the Registrant to submit changes to a delegation.
I suspect that the intersection of those two groups is vanishingly small.

E ven so, there is 1) no standard way to discover the Registrar that should
accept such changes in a way that can be automated, and 2) no standard API
for Registrars to accept those changes.

>
> Because the ability for DNS operators and others to bypass the registrars,
> which seems to be the goal here, will definitely impact the reasoning
> behind the model we use today for domain name registration if accepted and
> implemented.
>

This is not about bypassing the Registrars.  Nobody has asked for the
ability to register domains directly with the Registry.  This is about
allowing DNS Operators to do the job they've been hired to do by the
Registrants.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 04 May 2016 18:45:42 +0200

> pipeline, but let me address the specific misunderstanding I see here.

Good!

> have set up.

Agree, but this might with the current model imply the user also have to select a good registrar. I.e. from my perspective whether a registrar allow this independent DNS Operator or not is one of the criteria that should be used when registrants do select registrar.

In practice, as you write below which I will comment on in detail, that does not happen.

And that I completely agree with. And that is what I mean when I say that what I see has happened is that the market economy forces and ideas we implemented does not work.

Not that, as I write in the draft, that a DNS Operator must [always] go via the registrant to update DS (and in some cases, because of the registry policy, you can not even send the DS, it must be DNSKEY -- a difference that does not even depend on the registrar being used).

> As it currently stands, a DNS Operator must become a

As a registrar I can tell you not even that helps :-P ;-)

> registrations, yes.

Which to me indicate there is some interest to provide API. Of course, as you say not standardised API.

> I have never heard of a non-ccTLD-Registrar that

Most registrars are registrars for both ccTLDs and non-ccTLDs, so it is a bit unclear to me what parties you talk about there.

What I agree with is that not all registrars do allow a tech contact to be added to the domain in question.

But they do exist.

And some do get customers just because of this!

> for Registrars to accept those changes.

I agree with both of these.

> allowing DNS Operators to do the job they've been hired to do by the

It is removing one of the [few] differences that exists between the products registrars provide. I.e. the only thing I disagree with you on is whether the DNS Operator the registrant have chosen should be able to do whatever they want regardless of how crappy registrar the registrant has chosen. I am afraid removing [too many] differences between the registrars will lead to a pretty ugly situation. And conclusion that the registry/registrar model we did choose after a long discussion where competition was a goal regarding .COM domain names.

   Patrik

---

From: Roger D Carney <[email-masked]>
Date: Wed, 4 May 2016 19:22:11 +0000

Good Afternoon,

Thanks, for the update on the ongoing edits Matthew.

+1 on cleanup, the next version should remove the marketing, sales pitch, scare tactics and stick with the technical elements.

I think the "problem statement" is starting to become clearer as this thread continues. It does not sound like there is an issue with the current RRR model, but an issue with the current methods/processes of DNSSEC related zone updates, at scale, when the authoritative zone is being managed by some entity other than the registrar of record. 

Additionally, the contracts and policies (and subsequent audits) between ICANN and Registries and Registrars do mandate RFC compliance. This proposed internet draft, today, is not part of that mandate but could possibly be in the future.

Thanks
Roger

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Patrik Fältström
Sent: Wednesday, May 04, 2016 11:46 AM
To: Matthew Pounsett <[email-masked]>
Cc: [email-masked]
Subject: Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt

On 4 May 2016, at 18:29, Matthew Pounsett wrote:

> I think there's some misunderstanding of the problem involved. We 
> already have some (I think) improved text for the Abstract and 
> Introduction in the pipeline, but let me address the specific misunderstanding I see here.

Good!

> This is not about registrars that don't provide modern service.  This 
> is about the fact that the market should allow users to select a DNS 
> Operator who is not their Registrar, and that DNS Operator should not 
> be impeded from providing good service to the Registrant because of 
> the RRR model we have set up.

> As it currently stands, a DNS Operator must become a Registrar, and 
> require all of their customers to make the DNS Operator their 
> Registrar of record, if the DNS Operator wants to DNSSEC sign zones on 
> any kind of scale, because there is no standard way for them to submit 

>> registrar), have restful APIs for the transactions needed (although 
>> not a standardised one), and remove signatures for domains that are 
>> transferred away from the registrar.
>

> I have never heard of a non-ccTLD-Registrar that allows anyone other 
> than the Registrant to submit changes to a delegation.

But they do exist.

> E ven so, there is 1) no standard way to discover the Registrar that 
> should accept such changes in a way that can be automated, and 2) no 
> standard API for Registrars to accept those changes.

>> Because the ability for DNS operators and others to bypass the 
>> registrars, which seems to be the goal here, will definitely impact 
>> the reasoning behind the model we use today for domain name 
>> registration if accepted and implemented.
>

   Patrik

---

From: "John Levine" <[email-masked]>
Date: 4 May 2016 22:19:20 -0000

>What I agree with is that not all registrars do allow a tech contact to be added to the domain in question.

Every ICANN registrar allows, indeed requires, a tech contact on every
domain.  But that doesn't help because in most cases the tech contact
doesn't have login access to the account.  Even giving the tech
contact a login isn't much of a solution -- I have plenty of customers
where I run the DNS but someone else runs the web site, and if there
are tech problems with the domain they're much more likely to be with
the web site so they'd be the tech contact.

I agree that the first half of this document should be replaced with a
few sentences that note that there are many cases where the operator
of a DNS zone does not have credentials to update the parent zone,
with TLD registries being a common but not the only example, which
makes DNSSEC hard.  Hence this document designs a standard way for
a zone operator to install and maintain DNSSEC information in the
parent zone.

R's,
JOhn

---

From: Dave Piscitello <[email-masked]>
Date: Thu, 5 May 2016 12:26:45 +0000

I like this: succinct, accurate.

On May 4, 2016, at 6:19 PM, John Levine <[email-masked]<mailto:[email-masked]>> wrote:

there are many cases where the operator

A side observation. A very large number of domain registration records created at ICANN accredited domain registrars have identical information for all required points of contacts. I think the ship has sailed with respect to restoring the unique purposes intended for each.

---

From: Hugo Salgado-Hernández <[email-masked]>
Date: Thu, 19 May 2016 14:59:10 -0400

Hi Olafur.  Some comments below.

In "4.4.1. Initial Trust Establishment (Enable DNSSEC validation)"
I'm concerned on having an "out-of-band" validation of the right
DS/DNSKEY value. Using only the CDS record through DNS is weaker
than current method, when there's an EPP from the registrar or a
registrant confirmation through its domain control panel of the right
key. I think it could be solved using this initial POST including
in the restful API call the CDS/DS/DNSKEY or CDNSKEY value as a
request parameter, which can be matched with DNS.

In "4.5.1. Setup Initial Establishment with Challenge", I'm wondering
if the right method should be GET instead of POST. I'm not a REST
expert, but I'd expect a read-only operation to be GET. Although its
true that some registrar could associate the token in the moment of
the call, also the registrar could have pre-generated tokens already
associated with domains. So this call is a GET of that value.
Also, I think it could have an "expiration datetime" in the response,
after which the DNS operator should ask again for a new value.

Regards,

Hugo

On 11:02 26/04, Olafur Gudmundsson wrote:
> 
> This version is identical to version that was used for the call for adoption 
> the track was changed to Standards track. 
> 
> A version 01 is in the works and will be published soon. 
> 
> Olafur (for editors) 
> 
> > On Apr 26, 2016, at 11:01 AM, [email-masked] wrote:
> > 
> >

---

From: Jacques Latour <[email-masked]>
Date: Tue, 24 May 2016 16:06:46 +0000

>From: regext [mailto:[email-masked]] On Behalf Of Hugo Salgado-
>Hernández
>Sent: May-19-16 2:59 PM
>To: Olafur Gudmundsson
>Cc: [email-masked]
>I'm concerned on having an "out-of-band" validation of the right DS/DNSKEY
>value. Using only the CDS record through DNS is weaker than current method,
>when there's an EPP from the registrar or a registrant confirmation through its
>domain control panel of the right key. I think it could be solved using this
>initial POST including in the restful API call the CDS/DS/DNSKEY or CDNSKEY
>value as a request parameter, which can be matched with DNS.
>

We are working under the concept that the CDS records present in the zone file are indications of intention to sign/unsign/update the DS records of the domain in the parent zone and not based on who issues the request to perform the action.

The CDS is public, already available at the child, any actor could get the CDS and supply with the POST request.

>In "4.5.1. Setup Initial Establishment with Challenge", I'm wondering if the right
>method should be GET instead of POST. I'm not a REST expert, but I'd expect a
>read-only operation to be GET. Although its true that some registrar could
>associate the token in the moment of the call, also the registrar could have
>pre-generated tokens already associated with domains. So this call is a GET of
>that value.

POST to create a new entry (new challenge), I think it's the right action.

>Also, I think it could have an "expiration datetime" in the response, after which
>the DNS operator should ask again for a new value.
>

Good point, this could be based on the parent policy, the presence or not of an expiration datetime.

>> This version is identical to version that was used for the call for
>> adoption the track was changed to Standards track.
>>
>> > Please note that it may take a couple of minutes from the time of
>> > submission until the htmlized version and diff are available at
>tools.ietf.org.
>> >