Subject: [weirds] draft-ietf-weirds-bootstrap IANA Considerations

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Aug 2014 21:09:07 -0700

While we wait for Peter, I thought I'd take a crack at this.  Maybe he'll
just agree with what I say.  :-)

So here's what I propose for a complete replacement of what's in that
section now.

IANA Considerations

IANA has already created registries for top-level domain names and their
registries [DOMAINREG], Autonomous System numbers [ASREG], IPv4 network
blocks [IPV4REG] and IPv6 network blocks [IPV6REG].  The management
policies of these registries are established and maintained under other
arrangements and are not germane to this specification.

In order to support implementations of the RDAP protocol, IANA is requested
to generate, periodically, copies of the contents of these registries
according to the format described in this document.  RDAP clients can then
download this information from IANA and use it as configuration data to
determine where to send particular queries.

The frequency with which the generated versions of these registries needs
to be updated will depend on the frequency with which the registry receives
new or updated entries.  IANA should strive to produce a new generated
version as frequently as practicable, as stale copies of the generated
content can render information critical to some security applications
unreachable.

---

From: Andy Newton <[email-masked]>
Date: Wed, 6 Aug 2014 19:18:04 +0000

On Aug 6, 2014, at 12:09 AM, Murray S. Kucherawy <[email-masked]> wrote:

> While we wait for Peter, I thought I'd take a crack at this.  Maybe he'll just agree with what I say.  :-)
> 
> So here's what I propose for a complete replacement of what's in that section now.
> 
> IANA Considerations
> 
> IANA has already created registries for top-level domain names and their registries [DOMAINREG], Autonomous System numbers [ASREG], IPv4 network blocks [IPV4REG] and IPv6 network blocks [IPV6REG].  The management policies of these registries are established and maintained under other arrangements and are not germane to this specification.
> 
> In order to support implementations of the RDAP protocol, IANA is requested to generate, periodically, copies of the contents of these registries according to the format described in this document.  RDAP clients can then download this information from IANA and use it as configuration data to determine where to send particular queries.
> 
> The frequency with which the generated versions of these registries needs to be updated will depend on the frequency with which the registry receives new or updated entries.  IANA should strive to produce a new generated version as frequently as practicable, as stale copies of the generated content can render information critical to some security applications unreachable.

This looks to me.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Aug 2014 14:15:53 -0700

This looks what to you?

On Wed, Aug 6, 2014 at 12:18 PM, Andy Newton <[email-masked]> wrote:

> > In order to support implementations of the RDAP protocol, IANA is
> requested to generate, periodically, copies of the contents of these
> registries according to the format described in this document.  RDAP
> clients can then download this information from IANA and use it as
> configuration data to determine where to send particular queries.
> >
> > The frequency with which the generated versions of these registries
> needs to be updated will depend on the frequency with which the registry
> receives new or updated entries.  IANA should strive to produce a new
> generated version as frequently as practicable, as stale copies of the
> generated content can render information critical to some security
> applications unreachable.
>
> This looks to me.
>
> -andy
>
>

---

From: Andy Newton <[email-masked]>
Date: Wed, 6 Aug 2014 22:15:50 +0000

> This looks what to you?

Like I didn’t read what I wrote. It looks good to me.

-andy

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 6 Aug 2014 21:47:05 -0400

> So here's what I propose for a complete replacement of what's in that section now.

I have the following comments:
- this one is more in line with what I wrote previously (not the last version but before). so I'm fine in general. however I see two issues:
 + I'm not sure frequency or period is the right way to look at this. In some ways, it is for IANA to decide how to "sync" the two set of registries. So I would remove the notions of frequency/periodicity all over.
 + the "copy of the content" is not quite right, since: 
  = the rdap servers data will not be the same as whois server data
  = since we don't want to go into imposing the registration policies, then we don't want to impose to IANA that the "source" registries are "copied". they may have different content (i.e. indexes). 

I'm happy to provide new text if people agree with my comments above.

Marc.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Aug 2014 22:14:28 -0700

On Wed, Aug 6, 2014 at 6:47 PM, Marc Blanchet <[email-masked]>
wrote:

>  + I'm not sure frequency or period is the right way to look at this. In
> some ways, it is for IANA to decide how to "sync" the two set of
> registries. So I would remove the notions of frequency/periodicity all over.
>

I think we need to say something about expecting the downloadable version
to be a recent copy of the table and periodically updated.  Otherwise, they
might think they run the extraction once and they're done.  Although we're
trying to navigate a minefield of what we can and can't say, we do need to
be precise about the parts we can discuss in order for RDAP to function
properly.

>   = the rdap servers data will not be the same as whois server data

I was under the impression that all RDAP clients need is a JSON version of
what's in that table (or a subset of that).  If that's not the case then
yes, please set the text (and me) straight.

>   = since we don't want to go into imposing the registration policies,
> then we don't want to impose to IANA that the "source" registries are
> "copied". they may have different content (i.e. indexes).
>

I thought the current text goes deliberately in the direction of not even
talking about registration policies.  We know they have the data we need
already, so we just need them to give it to us in the form described here.
We don't need to say anything about the nature or details of the underlying
database.  Is that inferred from the text I proposed?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2014 13:15:08 -0000

>to be a recent copy of the table and periodically updated.

Why not just say that?  The RDAP data should be updated frequently enough to reflect the
current state of the registry, or something like that.

>yes, please set the text (and me) straight.

They currently have a web WHOIS server, but the RDAP server is
different, since the former speaks HTML and RDAP speaks json.  I think
we have to request of IANA that they allow registries to provide RDAP
bootstrap data in the form of URI prefixes, and they give us that,
json-ized.

R's,
John

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 7 Aug 2014 10:51:40 -0400

> current state of the registry, or something like that.

right. And in fact, the question is not "frequently enough" is more about being in sync, while (not all data is in sync). Moreover, we may end up with different entries in the two registries (i.e. a tld may be in the "source" registry but not in the rdap one), so the wording here needs to be updated.

> bootstrap data in the form of URI prefixes, and they give us that,

right, that is what I meant.  

And we may have situations, now or later, that some tlds may not have a whois entry but only an rdap entry. Therefore, copy of the content is again not fully appropriate.

Marc.

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 8 Aug 2014 18:20:21 +0200

> So here's what I propose for a complete replacement of what's in that section now.

The goal was to _not_ give instructions. 

> IANA has already created registries for top-level domain names and their registries [DOMAINREG], Autonomous System numbers [ASREG], IPv4 network blocks [IPV4REG] and IPv6 network blocks [IPV6REG].…

That looks good, as it is a statement of fact.

> In order to support implementations of the RDAP protocol, IANA is requested to generate, periodically, copies of the contents of these registries according to the format described in this document.

With the above we stepping into ‘instruction territory’. I would just describe what the requirement is:

In order to support implementations of the RDAP protocol, the content of these registries need to be made available in the format described in this document, using the protocol described in [REF]. RDAP clients can then use it as configuration data to determine where to send particular queries.

> 
> The frequency with which the generated versions of these registries needs to be updated will depend on the frequency with which the registry receives new or updated entries. 

Perhaps:

In order to maintain coherency, the RDAP bootstrap data should be updated whenever new or updated data enters the registries.

—

It occurs to me that when this is ready we should inform ICANN and the NRO that the specification is done and that they could consider to define an SLA in order to perform these functions. 

—Olaf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 8 Aug 2014 11:38:16 -0700

This looks good to me, plus what John said about allowing entries to
include the template/location of an RDAP server.

On Fri, Aug 8, 2014 at 9:20 AM, Olaf Kolkman <[email-masked]> wrote:

> registries according to the format described in this document.
>
> In order to support implementations of the RDAP protocol, the content of
> these registries need to be made available in the format described in this
> document, using the protocol described in [REF]. RDAP clients can then use
> it as configuration data to determine where to send particular queries.
>
>
>
> >
> receives new or updated entries.
>
> Perhaps:
>
> In order to maintain coherency, the RDAP bootstrap data should be updated
> whenever new or updated data enters the registries.
>
>
>
>
> —
>
> It occurs to me that when this is ready we should inform ICANN and the NRO
> that the specification is done and that they could consider to define an
> SLA in order to perform these functions.
>
> —Olaf
>
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Aug 2014 06:57:52 -0700

> include the template/location of an RDAP server.

So do we have consensus on this text?  Can Marc and Guillaume proceed to
incorporate it into the bootstrap document so that everything else can get
updated and we can proceed to our WGLCs?

Our first do-or-die milestone is September 5, which is only about three
weeks away...

-MSK

---

From: Guillaume Leclanche <[email-masked]>
Date: Mon, 11 Aug 2014 09:59:26 -0400

Le 2014-08-11 09:57, Murray S. Kucherawy a écrit :

On Fri, Aug 8, 2014 at 11:38 AM, Murray S.
Kucherawy <[email-masked]>
wrote:

This looks good to me, plus what John said about
allowing entries to include the template/location of
an RDAP server.

So do we have consensus on this text?  Can Marc and
Guillaume proceed to incorporate it into the bootstrap
document so that everything else can get updated and we
can proceed to our WGLCs?

I'm working on it :)

Guillaume

Our first do-or-die milestone is September 5, which is
only about three weeks away...

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Aug 2014 07:14:41 -0700

> updated and we can proceed to our WGLCs?

That's half of what we need.  :-)  The other half is agreement from the
working group.  That's what I was hoping to gauge here.

-MSK

---

From: Guillaume Leclanche <[email-masked]>
Date: Tue, 12 Aug 2014 11:49:55 -0400

Le 2014-08-11 09:57, Murray S.
Kucherawy a écrit :

Hello,

here's a proposal for the whole IANA considerations section. Some
justifications:

1) IANA is really requested to create new registries, that can not
technically be copies of the existing ones where whois server info
can be found: this document does not have the same entries nor
structure as the existing registries, so it can not just be
converted.

2) The text regarding the policies is Murray's proposal as everyone
here agreed with it

3) The last paragraph tries to discuss the sync issue based on
Olaf's proposal.

Comments ?

Guillaume

IANA is requested to do the following:

o  Create a new registry "IPv4 Address Space RDAP Bootstrap
Service"

in the JSON format, as shown above.

o  Create a new registry "IPv6 Address Space RDAP Bootstrap
Service"

in the JSON format, as shown above.

o  Create a new registry "Autonomous System Number Space RDAP

Bootstrap Service" in the JSON format, as shown above.

o  Create a new registry "Domain Name Space RDAP Bootstrap
Service"

in the JSON format, as shown above.

Those new registries may be maintained in IANA own format, such as
XML, in

addition to the JSON-based format described in this document.

IANA has already created registries for top-level domain names and
their

registries [DOMAINREG], Autonomous System numbers [ASREG], IPv4
network

policies of these registries are established and maintained under
other

In order to maintain coherency, the RDAP Bootstrap Service

registries should be updated if necessary whenever new or updated
data

enter [DOMAINREG], [ASREG], [IPV4REG], or [IPV6REG].

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Aug 2014 10:49:10 -0700

On Tue, Aug 12, 2014 at 8:49 AM, Guillaume Leclanche <
[email-masked]> wrote:

> technically be copies of the existing ones where whois server info can be
> found: this document does not have the same entries nor structure as the
> existing registries, so it can not just be converted.
>

A number of concerns here:

If we really can't copy this (I'm not sure I understand your justification,
but I'll go back and look at it again), then we can probably at least
populate some of the data from the old registry to the new one, no?

I'm worried about the burden of creating a second set of registries with
almost the same purpose as the first, or at least the appearance of a lot
of overlap.  If there's really no way around that, we need to spend some
time explaining in this document why that's the case.

In addition to creating the registries, we'll need to do things like select
and describe the policy for updating the registry, and anything else
required by RFC 5226.  This runs headlong into the concerns expressed by
John Klensin and others that we're treading on ICANN's terrain.  I don't
think we want to go there.

This seems like a change in direction from what we'd agreed on in Toronto
and prior.  I'm getting very nervous.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 12 Aug 2014 22:51:25 -0000

>time explaining in this document why that's the case.

There's already supposed to be a port 43 whois server and a web whois
server, which usually are at the same host name but aren't always.
IANA currently has one slot for both of them. Verisign's thin
registries have separate ones for registrars, which they call WHOIS
Server and Referral URL.  We're basically adding a third, with the
extra complexity that it's a set of URL prefixes, not just a host
name.

I wish I could see a way to make it easier, but given the constraints
about what we can say about URLs, I don't.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Aug 2014 23:00:58 -0700

Wouldn't it be simpler to add the RDAP field to the existing registry,
rather than making a new one?

---

From: "John R Levine" <[email-masked]>
Date: 13 Aug 2014 08:44:36 -0400

> rather than making a new one?

It's been a long time, if ever, since the IETF asked IANA to do something 
to the TLD registry, so I don't know what the options are.  We want them 
to add a bunch of RDAP prefixes to each TLD, however that's easiest for 
them, with an ill-specified process for letting TLD operators add the 
info.

R's,
John

>> about what we can say about URLs, I don't.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Kim Davies <[email-masked]>
Date: Wed, 13 Aug 2014 16:54:55 +0000

Hi folks,

>> rather than making a new one?

I admit I have not been tracking this discussion, so my apologies for leaping in now, I hope it is helpful nonetheless.

Operationally, if IANA were asked to maintain new data elements for TLDs, I think the starting proposition would be to expand the existing "root zone database" (i.e. registry) with an additional field or fields to support it. This registry is backed by a system that supports the change request workflow with the TLD managers and provides them with a web-based interface to manage their data. If RDAP ultimately requires additional new file formats we'd then add a new publication process to export the additional formats to publish it in accordance with the specification's requirements.

> It's been a long time, if ever, since the IETF asked IANA to do something to the TLD registry, so I don't know what the options are.  We want them to add a bunch of RDAP prefixes to each TLD, however that's easiest for them, with an ill-specified process for letting TLD operators add the info.

Operationally, IANA would take the requirements and absent specific instruction, would devise an operational approach that we think would match with our customers' expectations and roughly aligns with how similar data is processed. To both reduce surprise and to accord with our commitment to consult with all interested and affected parties, we would want to socialise the exact mechanisms with the TLD manager communities just as we have for other facets of root zone management such as determining the minimum technical conformance requirements.

>>> IANA currently has one slot for both of them.

As a point of clarification, the Root Zone Database only lists WHOIS servers that support the WHOIS protocol. We do not list URLs, only hostnames that respond on port 43. While for some gTLDs there is some additional contractual requirement that they operate a web-based WHOIS gateway, that is outside of IANA's scope and we don't check for that nor list it at this time.

kim