Subject: [weirds] Barry Leiba's Discuss on draft-ietf-weirds-bootstrap-10: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 28 Oct 2014 23:33:22 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-weirds-bootstrap-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DISCUSS point 1, on the clarity of the text about matching:

-- Section 4 --
The matching is of labels from right to left... You and I know that, but
will every reader understand that?  With gTLDs upon us, will it always be
clear to everyone that a registry entry of "nyc" matches "coffee.nyc",
but does not match "nyc.com"?  Will everyone understand that a registry
entry of "example.com" matches "good.example.com", but does not match
"goodexample.com"?

There's also nothing said about what happens if there are multiple
matches at the same specificity.  What if there are two Entry Arrays that
both contain "example.com"?  More likely, what if someone makes an error
in specifying AS numbers, we get one entry for 10000-12000 and another
for 12000-14000... and then we query for 12000?

It might be good to be clearer about exactly what matching is intended,
and what doesn't match.  Feel free to use my examples above, if that
helps.

-----

DISCUSS point 2: the scope of what we're asking IANA to do, and the
question of whether it's really clear both to us and to them what it is,
what it will entail, and what it will cost:

-- Section 8 --

   Clients SHOULD cache the
   registry, but use underlying protocol signalling, such as the HTTP
   Expires header field [RFC7234], to identify when it is time to
   refresh the cached registry.

Now you're putting another requirement on IANA, which I'm not sure has
been part of the discussion: they have to present the registries in the
right format AND manage the TTL of the queries with the Expires header. 
Please, please make sure that IANA is very clear about the entire scope
of what we're asking, and signs off on it.

-- Section 12 --

   IANA is expected to generate the RDAP Bootstrap
   Services Registries data from these above mentioned registries,
   according to their own registration policies.

I presume "their" refers to the registries, not to IANA, but that's
ambiguous, and should be fixed.  The above-mentioned registries do not
have RDAP URLs, do they?  Whence is IANA meant to get that information,
in order to generate these new registries?

If IANA generates these by periodically re-processing the source
registries to pick up changes, how current are the RDAP registries
expected to be? Is it OK for them to be updated once a week?  Once a
month?  Are we setting up any SLAs for the timeliness and reliability of
these registries?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 1 --

   This document requests IANA to make an augmented version of
   the existing registries available for the specific purpose of
   RDAP use

I presume that IANA has agreed to do that.  Where will the URIs for those
augmented registries be published.  That is, how will a bootstrapping
application know where to find them for the bootstrapping?

-- Section 3 --

   The JSON object for each
   registry will start with a series of members that contain metadata

"Start with" implies ordering, but members within JSON objects are
explicitly unordered.  Do you actually care about the ordering, or should
you just change "start with" to "contain" (and similarly change the
subsequent "Following that")?

   Each item of the array contains a second-level array,
   with two elements, each of them being a third-level array.

   The first third-level array, named 'Entry array', contains all
   entries that have the same set of base RDAP URLs.  The second third-
   level array, named 'Service URL array', contains the list of base
   RDAP URLs usable for the entries found in the 'Entry array'.  There
   is no assumption of sorting except that the two arrays found in each
   second-level array MUST appear in the correct order: The entries
   array are followed by the service URL array.

This is just an editorial comment, but this description seems
unnecessarily complicated, and the "no sorting, but certain things have
to be in the right order" is just odd.

May I make a suggestion that gets rid of the "third-level array"
awkwardness (and also corrects some wording errors)?:

NEW
   Each element of the Services array is a second-level array with
   two elements: in order, an Entry Array and a Service URL Array.

   The Entry Array contains all entries that have the same set of
   base RDAP URLs.  The Service URL Array contains the list of base
   RDAP URLs usable for the entries found in the Entry Array. Elements
   within these two arrays are not sorted in any way.
END

   Any unknown or unspecified JSON object
   properties or values should be ignored by implementers.

1. Implementers don't ignore the unrecognized things; implementations
do.

2. What does it mean to ignore an unspecified thing?  It's not there to
be ignored.

3. The "should be" makes people wonder whether it's supposed to be a 2119
key word, and why it's not.  I suggest just using "are" -- that's simply
the way it is.

So, maybe:
   Any unrecognized JSON object properties or values are
   ignored by implementations.

-- Section 4 --

   The domain names authoritative registration data service is found by
   doing the label-wise longest match of the target domain name with the
   domain values in the arrays in the IANA Domain Name RDAP Bootstrap
   Service Registry.  The values contained in the second element of the
   array are the valid base RDAP URLs as described in
   [I-D.ietf-weirds-rdap-query].

You have names for these arrays in Section 3; why don't you use them?

NEW
   The domain names authoritative registration data service is found by
   doing the label-wise longest match of the target domain name with the
   domain values in the Entry Arrays in the IANA Domain Name RDAP
   Bootstrap Service Registry.  The values contained in the Service URL
   Array of the matching second-level array are the valid base RDAP URLs
   as described in [I-D.ietf-weirds-rdap-query].
END

And similarly for other times when you say "first element" or "second
element".

I'm also thinking more and more that "longest match" should instead be
"most specific match", especially for the IP address numbers.

-- Section 5.1 --
Doesn't "CIDR format" need a reference?

-- Section 7 --

   The registries may not contain the requested value or the base RDAP
   URL value may be empty.

Nothing up in Section 3 said that a Service URL Array could be empty.  If
that's legal, that fact should be specified up there.

-- Section 10.2 --
In the definition of "rdap-bootstrap-registry" you should note that the
"description" member is optional, probably by saying, "and an optional
MEMBER description and...".

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 29 Oct 2014 09:24:58 -0400

> Le 2014-10-29 à 02:33, Barry Leiba <[email-masked]> a écrit :

thanks for your review.

this has been a recurring comment. I’ll add more text and examples. 

> of what we're asking, and signs off on it.

IANA, both regular staff and technical staff,  has reviewed the whole text, and were fine.

> have RDAP URLs, do they?

no.

>  Whence is IANA meant to get that information,

currently, for names, the registration process includes a « whois server domain name » entry. IANA will add a new entry for « rdap server url » to the process, so that registrie can send their rdap server url entry through the normal process. 

> month?  Are we setting up any SLAs for the timeliness and reliability of

they would not be regenerated from the source. The rdap registries will be updated whenever there is a change submitted by the registries for an rdap entry.  For example, say «.ontario » has a whois server but no rdap server. .ontario will not be in the rdap registry. When .ontario has his rdap server and running, they will request IANA (through the updated process described above) to add their entry (.ontario)  in the rdap registry for their rdap server. Then when IANA process the request, the rdap registry will be updated.  No synching or else.

There have been multiple comments and iterations of this section. Usually, I added those as is in the document, but maybe it became more convoluted than necessary and hence bring questions. I’ll reread it with a more fresh start and see if it could be clearer. 

> augmented registries be published.

as typical, the URI of these registries will not be in the RFC. Moreover, IANA specifically requested to not have the URI in the RFC, because of the requirements for « high volume » which may require some specific URL.

>  That is, how will a bootstrapping

the developer will have to look at IANA site once to find the url of the bootstrap registries.

Not sure what is my action item here.

> subsequent "Following that »)

ok.

> ?

>   within these two arrays are not sorted in any way.

ok. 

>   ignored by implementations.

ok.

>   as described in [I-D.ietf-weirds-rdap-query].

ok.

> "most specific match", especially for the IP address numbers.

in network operations environment, longest match for IP addresses is pretty common use. But I’m fine if people prefer most specific match. 

> Doesn't "CIDR format" need a reference?

will look into it.

> that's legal, that fact should be specified up there.

ok

> MEMBER description and… »

ok.

> .

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Oct 2014 12:23:28 -0400

Thanks for the quick response, Marc.  We're ok on almost everything... Just
the IANA bit to iron out, but that should be easy.

> this has been a recurring comment. I'll add more text and examples.

Great; thanks.

> > what it will entail, and what it will cost

...

> currently, for names, the registration process includes a << whois server
> domain name >> entry. IANA will add a new entry for << rdap server url >> to
> the process, so that registrie can send their rdap server url entry through
> the normal process.

I don't see that the document tells IANA they need to do that.  Each of the
four registries needs to have a new field, and that has to be made clear in
the IANA Considerations.

> they would not be regenerated from the source. The rdap registries will be
> updated whenever there is a change submitted by the registries for an rdap
> entry.  For example, say <<.ontario >> has a whois server but no rdap server.
> .ontario will not be in the rdap registry. When .ontario has his rdap
> server and running, they will request IANA (through the updated process
> described above) to add their entry (.ontario)  in the rdap registry for
> their rdap server. Then when IANA process the request, the rdap registry
> will be updated.  No synching or else.

Again, that's not mentioned. The document says that these RDAP registries
aren't updated as usual with registries, but are generated from the source
registries.  If that's just how they get started, and IANA is expected to
keep them current in real time to coincide with all updates to the source
registries, the document has to say that in the IANA Considerations.

> There have been multiple comments and iterations of this section. Usually,
> I added those as is in the document, but maybe it became more convoluted
> than necessary and hence bring questions. I'll reread it with a more fresh
> start and see if it could be clearer.

...

> as typical, the URI of these registries will not be in the RFC. Moreover,
> IANA specifically requested to not have the URI in the RFC, because of the
> requirements for << high volume >> which may require some specific URL.
>

How will the developer know where to look?  If developers are expected to
look someplace, and then hard-code the URL(s) into their products, then (1)
they have to be told that, and told where to look to find the URL(s) and
(2) IANA has to be told that the URLs have to be published in the place we
tell the developers to look, and they have to be told that those URL MUST
be persistent (because they will be hard-coded in software).  That stuff
has to be in the IANA Considerations.

In general, the point here is that *everything* that IANA has to know and
do must be in one place, in the IANA Considerations.  We can't make them
look through and analyze the whole document, and we can't make them guess
about anything.

I will be happy when we have an IANA Considerations section that lays it
all out, and we have a review from IANA that shows they understand it and
are OK with it.

> in network operations environment, longest match for IP addresses is
> pretty common use. But I'm fine if people prefer most specific match.

No... "Most specific" sounds nicer to me, but if "longest" is a recognised
term of art, don't change it for me.

> Doesn't "CIDR format" need a reference?

One of the other docs (rdap-query, maybe) has one.

Barry

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 29 Oct 2014 12:31:04 -0400

> Le 2014-10-29 à 12:23, Barry Leiba <[email-masked]> a écrit :
> 
> Thanks for the quick response, Marc.  We're ok on almost everything... Just the IANA bit to iron out, but that should be easy.
> 
> I don't see that the document tells IANA they need to do that.  Each of the four registries needs to have a new field, and that has to be made clear in the IANA Considerations.

well, I’ve been told _many_ times to let IANA do their own stuff on their side and we should not intervene/require/write text on this. I’m all fine in saying those things (it was actually in the very first versions of the draft and in some presentations). 

> Again, that's not mentioned.

same reasoning as above.

> The document says that these RDAP registries aren't updated as usual with registries, but are generated from the source registries.  If that's just how they get started, and IANA is expected to keep them current in real time to coincide with all updates to the source registries, the document has to say that in the IANA Considerations.

Again, I’ll make another pass to it to see if I can find some common ground.

> How will the developer know where to look?  If developers are expected to look someplace, and then hard-code the URL(s) into their products, then (1) they have to be told that, and told where to look to find the URL(s) and (2) IANA has to be told that the URLs have to be published in the place we tell the developers to look, and they have to be told that those URL MUST be persistent (because they will be hard-coded in software).  That stuff has to be in the IANA Considerations.

again, I’m full agreement with your point. I’ll raised it with IANA to see if we can do something. 

> 
> In general, the point here is that *everything* that IANA has to know and do must be in one place, in the IANA Considerations.  We can't make them look through and analyze the whole document, and we can't make them guess about anything.
> 
> I will be happy when we have an IANA Considerations section that lays it all out, and we have a review from IANA that shows they understand it and are OK with it.
> 
> No... "Most specific" sounds nicer to me, but if "longest" is a recognised term of art, don't change it for me.
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Oct 2014 12:50:13 -0400

>
> well, I've been told _many_ times to let IANA do their own stuff on their
> side and we should not intervene/require/write text on this. I'm all fine
> in saying those things (it was actually in the very first versions of the
> draft and in some presentations).
>

Understood.  We need to make sure we make the *requirements* clear, without
trying to dictate *how*.

> Again, I'll make another pass to it to see if I can find some common
> ground.
>

I'll happily work with you (and Michelle) off list to make sure we get
something that works.

Barry

---

From: Peter Koch <[email-masked]>
Date: Wed, 29 Oct 2014 18:22:15 +0100

> registries, the document has to say that in the IANA Considerations.

in the light of the current discussion about "IANA transition" that lets us all
look a bit closer at the IETF/IANA relations I wonder whether it is
appropriate to tell the "IETF-IANA" that a "registry" shall be a copy
of (or, essentially a processed combination of) registries maintained on
behalf of/under the auspices of other policy setting bodies.
For the _protocol_ to work, a registry (in the IETF sense) is simply
not necessary.  For the _service_ to work, a bootstrapping is nice to have,
but IMHO it's not the IETF to define that service.  Instead of describing
the seeding and maintenance (rather than the syntax/format) of this "registry"
in an IETF standards track document, it would be cleaner policy wise
for ICANN (sic) to publish, say, an independent stream RFC that states
how the "registry" (and the misnomer can be dealt with by then) is
maintained and how and where it can be accessed.

-Peter

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Oct 2014 10:29:22 -0700

On Wed, Oct 29, 2014 at 9:31 AM, Marc Blanchet <[email-masked]>
wrote:

>
> currently, for names, the registration process includes a « whois server
>> domain name » entry. IANA will add a new entry for « rdap server url » to
> I don't see that the document tells IANA they need to do that.  Each of
> the four registries needs to have a new field, and that has to be made
> clear in the IANA Considerations.
>
> well, I’ve been told _many_ times to let IANA do their own stuff on their
> side and we should not intervene/require/write text on this. I’m all fine

An example of the sort of thing we can't tell IANA is to "create a registry
in the JSON format".  The way that's worded, we'd be telling IANA that they
have to store it in JSON.  In fact, we don't care how they store it; we
care how they export it.  That's the kind of precision and observation of
boundaries that IANA Considerations needs.

On the other hand, what Barry's talking about is exactly the kind of thing
we _do_ need to include.  Now, for Barry: The first paragraph of Section 12
is our attempt to do what you're asking, namely an instruction to augment
the existing registries with the fields we need to produce the RDAP
bootstrap information. Are you just looking for something like this?

ADD TO FIRST PARAGRAPH OF SECTION 12:

Specifically, each entry in the existing IANA registries needs a new field
that contains a list of RDAP server URIs where RDAP service for the
corresponding entity/entities will be available.  This field needs to be
populated as these URIs are provided to IANA.

>> they would not be regenerated from the source. The rdap registries will
>> be updated whenever there is a change submitted by the registries for an
>> rdap entry.  For example, say «.ontario » has a whois server but no rdap
>> server. .ontario will not be in the rdap registry. When .ontario has his
>> rdap server and running, they will request IANA (through the updated
>> process described above) to add their entry (.ontario)  in the rdap
>> registry for their rdap server. Then when IANA process the request, the
>> rdap registry will be updated.  No synching or else.
>
>

I agree that this is also something we do need to document.  I do think we
tried in the second paragraph of Section 12 to say that, but we're possibly
too close to the material to say it with the right amount of detail.  Does
the above suggestion cover it?

>
> The document says that these RDAP registries aren't updated as usual with
> registries, but are generated from the source registries.  If that's just
> how they get started, and IANA is expected to keep them current in real
> time to coincide with all updates to the source registries, the document
> has to say that in the IANA Considerations.
>
>

Does the above help at all?

>> requirements for « high volume » which may require some specific URL.
>>

We have a bit of a chicken-and-egg problem here.  I guess we can just leave
a placeholder URL for IANA to fill in when it makes that decision.  I
hadn't pushed us to do so because the root cache for DNS is understood to
exist for download at some known locations, but I don't think that appears
in any RFCs; it's just something IANA does, and people figure out
out-of-band how to find it.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Oct 2014 10:29:59 -0700

On Wed, Oct 29, 2014 at 9:50 AM, Barry Leiba <[email-masked]>
wrote:

> Understood.  We need to make sure we make the *requirements* clear,
> without trying to dictate *how*.
>

Yes, that's been the basis of my guidance throughout the process.

> I'll happily work with you (and Michelle) off list to make sure we get

Count me in as well.

-MSK