Subject: [weirds] AD Evaluation of draft-ietf-weirds-bootstrap-07

From: Pete Resnick <[email-masked]>
Date: Tue, 7 Oct 2014 00:01:45 -0500

Summary: Not ready for Last Call.

I've got some real concerns with this document that need to be addressed 
before I'm willing to Last Call it.

Overall, I have no problem with the idea that this document is putting 
forward in order to have a bootstrap. However:

3 -

    The RDAP Bootstrap Service Registries are made available as JSON
    [RFC7159] objects.  The JSON registry output...

First of all, I don't know what you mean by "the JSON registry output", 
though I have a suspicion you're talking about the registry when it is 
retrieved as a JSON object. But you're making a mish-mash of what is the 
registry itself, how it's defined, and how it's retrieved. Here's my 
attempt at a replacement for the entire first paragraph that I think is 
*marginally* clearer:

    This document defines four RDAP Bootstrap Service Registries,
    specified in Sections 4 and 5. Each of these registries will have
    some metadata information about the registry itself, and the contents
    each registry will be a list of services. This document describes
    each of the registries as a JSON object. Information regarding how
    the information in this registry is made available by IANA is noted
    in Section 12.

    All four registries follow the same general structure. Described as a
    JSON object, each registry starts with a series of members that
    contain metadata about the registry such as a version identifier, a
    timestamp of the publication date of the registry and a description.
    Following that is  in a "services" member which contains the registry
    items themselves, as an array. Each item of the array contains a
    second level array, with two elements, each of them being an array
    (third-level arrays).  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: 'Entry array' first followed by 'Service URL array'.
    An example structure of the JSON output of a RDAP Bootstrap Service
    Registry is illustrated:

But I've got to say that I don't really like that at either. It's one of 
the most convoluted ways I've ever seen to describe an IANA registry. I 
am not convinced that this will pass an IETF Last Call, let alone an 
IESG review. I really think you should have defined the registry in 
terms of a simple table with two columns, the first being the "Entries" 
column, and the second being the "Base URLs" column, and for each row in 
the table, there would be the entries for that particular service and 
the base URLs for that particular set of entries. Then, later in the 
document, you could describe the retrievable JSON format. The way you 
have it, you've tried to jam together the definition of the registry 
with the retrievable format of the registry. I am prepared to be 
convinced that this is ready to move forward, but at this point I am not 
inclined to Last Call this document.

On the JSON itself: I presume that services is an array of an array of 
arrays to somehow shrink the size of the entries, but given that you're 
depending on the ordering of the second-level array, it sure would have 
been easier to track what the heck is in this thing if services were an 
array of objects containing arrays instead:

    {
        ...
        "services": [
          {
            entries : ["entry1", "entry2", "entry3"],
            baseurls : [
              "https://registry.example.com/myrdap/",
              "http://registry.example.com/myrdap/"
            ]
          },
          {
            entries : ["entry4"],
            baseurls : [
              "http://example.org/"
            ]
          }
        ]
    }

Is the "array of arrays of arrays" idea a done deal?

Other more minor comments:

Throughout - Update RFC 4627 to RFC 7159

3 -

    Internationalized Domain Names labels used as entries or base RDAP
    URLs in the registries defined in this document MUST be only
    represented using their A-Label form as defined in [RFC5890].

Doesn't this contradict what appears in rdap-query?

7 - s/the client SHOULD provide/the client provides

8 -

    o  If the client knows the existence of an RDAP aggregator or
       redirector and trusts that service, then it could send the query
       to the redirector, which would redirect the client if it knows the
       authoritative server that client has not found.

I think you need to mention the base URL here:

    o  If the client has previously discovered an RDAP aggregator or
       redirector and its associated base URL, and the client trusts that
       service, then it could send the query to the redirector, which
       would redirect the client if it knows the authoritative server
       that client has not found.

12 -

    IANA is requested to implement the following registries in JSON
    format conformant to the syntax defined in Section 10.

That's incorrect, and it seems it was an uncorrection from -06 to -07. 
IANA doesn't "implement" registries. The registry is created by IANA. 
Independently, we are asking IANA to provide a JSON representation of 
the registry to be retrieved.

Furthermore, nowhere in this section does it ever tell IANA that it is 
expected to populate these registries from its own data.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 7 Oct 2014 07:32:09 -0400

Le 2014-10-07 à 01:01, Pete Resnick <[email-masked]> a écrit :

thanks for your review.

> I've got some real concerns with this document that need to be addressed before I'm willing to Last Call it.
> 
> Overall, I have no problem with the idea that this document is putting forward in order to have a bootstrap. However:
> 
> 3 -
> 

this text was actually a suggestion from someone. We just put it. I'm happy to change it.

> though I have a suspicion you're talking about the registry when it is retrieved as a JSON object. But you're making a mish-mash of what is the registry itself, how it's defined, and how it's retrieved. Here's my attempt at a replacement for the entire first paragraph that I think is *marginally* clearer:
> 
> But I've got to say that I don't really like that at either. It's one of the most convoluted ways I've ever seen to describe an IANA registry. I am not convinced that this will pass an IETF Last Call, let alone an IESG review. I really think you should have defined the registry in terms of a simple table with two columns, the first being the "Entries" column, and the second being the "Base URLs" column, and for each row in the table, there would be the entries for that particular service and the base URLs for that particular set of entries. Then, later in the document, you could describe the retrievable JSON format. The way you have it, you've tried to jam together the definition of the registry with the retrievable format of the registry. I am prepared to be convinced that this is ready to move forward, but at this point I am not inclined to Last Call this document.

- fine. I have to say again that IANA looked at it (both the technical people and the registration people) and they were fine with the text.
- the json format evolved into multiple level arrays, as requested by implementors.  A two columns table won't really show this structure.  So in some ways, we are just not used to define registries in complex JSON formats. I guess I'm the guiney pig...

> 
> On the JSON itself: I presume that services is an array of an array of arrays to somehow shrink the size of the entries, but given that you're depending on the ordering of the second-level array, it sure would have been easier to track what the heck is in this thing if services were an array of objects containing arrays instead:
> 
>   {
>       ...
>       "services": [
>         {

I let implementors to comment on this one.

> Doesn't this contradict what appears in rdap-query?

humm. good point. This addition was from a review comment. I guess we should think about this one.

> That's incorrect, and it seems it was an uncorrection from -06 to -07. IANA doesn't "implement" registries. The registry is created by IANA. Independently, we are asking IANA to provide a JSON representation of the registry to be retrieved.

ok.

> 
> Furthermore, nowhere in this section does it ever tell IANA that it is expected to populate these registries from its own data.

yes. it is. In fact, we don't want, since the entries will be submitted by the "owners" of the data, which will submit it through the policy defined by IANA. The relevant text is:
"
   It is envisioned that these new registries will have similar entries
   than the corresponding IANA allocation registries, such as [ipv4reg],
   [ipv6reg], [asreg], [domainreg], and possibly similar registration
   policies.  Given that the data required by RDAP clients is limited
   compared to the content of the existing corresponding registries, and
   given that this data has to be made available in a JSON format using
   a specific key/value structure, this document is not defining an
   extension of the existing IANA allocation registries.  The
   registration policies for the new registries of this document are
   left to IANA.
"

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

---

From: Andy Newton <[email-masked]>
Date: Tue, 7 Oct 2014 13:55:03 +0000

>I let implementors to comment on this one.

Speaking as an implementor, using objects would make the JSON more
self-descriptive and is probably how I would have done this. That being
said, the current array of array of arrays didn¹t really confuse me after
reading the draft. I¹d prefer this not change unless we have good reason.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Oct 2014 09:55:05 -0700

> this text was actually a suggestion from someone. We just put it. I'm

It's possible that this was my suggestion, or at least derived from one.

More generally, I tried during WGLC to nudge this in a different direction
anticipating IESG friction, but I wasn't successful.  The issue, with which
Pete now appears to agree, is that we should make clear distinctions
between creation and description of the registry, and then our expectations
for how the registry's content will be made available.  Since the way IANA
stores these things is completely opaque to us, describing the registry in
general terms is a lot more useful to them than describing them in terms of
the output we ultimately want.  By analogy, one would normally provide a
database schema before describing how to put things into the database and
what a dump of the database would be expected to contain (and in what
format).

I know Marc and others have had repeated conversations with IANA at the
meetings to ensure they get what it is we need here, but still the form of
our IANA Considerations in this document is an issue.  Suppose, for
example, that IANA has a complete staff change before this document gets to
them.  All of the context of those hallway track conversations is lost and
would need to be repeated.  I think that, instead, we should do this in a
more conventional way.

I look at IANA Considerations as a work order.  An IETF action for IANA
needs them to do these specific things when making new registries:

1) Create a registry, to include the name of the registry and the names,
descriptions, and syntaxes of the fields within it.  (schema)
2) Describe the policy by which the registry will be updated.  (We're a
special case here, I know.)
3) Provide initial registry entries (if any; for us, they should just
mirror what the other IANA registries contain).
4) Specify how the registry's contents should be made available (uncommon,
but we need it for RDAP).

In -07, the authors added a JSON description which I think satisfies (4)
above.  I don't have any particular feelings about the chosen format
(array-of-arrays-of-arrays), as long as the syntax we want is clearly
specified.  I think we have prose that covers (2) and (3).  However, I
think (1) is basically mixed into the current prose and example, and should
instead be made explicit before the example.

> the most convoluted ways I've ever seen to describe an IANA registry. I am
> not convinced that this will pass an IETF Last Call, let alone an IESG
> review. I really think you should have defined the registry in terms of a
> simple table with two columns, the first being the "Entries" column, and
> the second being the "Base URLs" column, and for each row in the table,
> there would be the entries for that particular service and the base URLs
> for that particular set of entries. Then, later in the document, you could
> describe the retrievable JSON format. The way you have it, you've tried to
> jam together the definition of the registry with the retrievable format of
> the registry. I am prepared to be convinced that this is ready to move
> forward, but at this point I am not inclined to Last Call this document.
>

Does my suggestion help at all?

> - fine. I have to say again that IANA looked at it (both the technical
> people and the registration people) and they were fine with the text.
>

See above.

> - the json format evolved into multiple level arrays, as requested by
> implementors.  A two columns table won't really show this structure.  So in
> some ways, we are just not used to define registries in complex JSON
> formats. I guess I'm the guiney pig...
>

I don't care so much about the format (especially since I'm not
implementing this) so I'm happy to yield to implementers.  I do think it
needs to be clearly specified though, and I think what you added in -07 is
a big help.

Pete, maybe Barry could also take an early look at least at that part?

> should think about this one.

WG (especially implementers and those with I18N fu), please speak up!

> yes. it is. In fact, we don't want, since the entries will be submitted by
> the "owners" of the data, which will submit it through the policy defined
> by IANA. The relevant text is:
> "

Pete, I think that's right, modulo a bit of wordsmithing.  Would it be
better placed elsewhere in the document?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2014 21:02:18 -0000

>> Doesn't this contradict what appears in rdap-query?

Yeah, but the contexts are different.  Personally, I don't think it's
likely that you can write a very useful IDN RDAP client that doesn't
understand how to convert between A-labels and U-labels, but people
who wrote the servers argued that it was no big deal to convert at
their end, so be it.  For the bootstrap, it seems to me that allowing
mixed representations in the bootstrap file would make something
that's already somewhat confusing hopelessly moreso.

I suppose the mixed formats could be useful for names like exámple.com.

R's,
John

---

From: Naoki Kambe <[email-masked]>
Date: Wed, 08 Oct 2014 11:27:53 +0900 (JST)

Hello,

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Oct 2014 09:55:05 -0700
...
> WG (especially implementers and those with I18N fu), please speak up!

I also think the above comment is good point.

As for the entry part of the domain bootstrap file, I certainly
suggested it should support A-label. Because the draft didn't mention
about IDN formats, and I thought the format should be fixed in either
one and it might not be so hard for the bootstrap parser to check the
entries in the A-label format.

But considering consistency with the rdap-query draft, I think the IDN
entry in the domain bootstrap file should support both formats
(A-label and U-label).  However I think the corresponding base URLs
should be same. Because such entries are not independent domain names.

So an example of an IDN entry supporting both formats is:

  ...
  [
    ["xn--zckzah", "テスト"],
    [
      "https://example.net/rdap/",
      "http://example.net/rdap/"
    ]
  ]
  ...

As for the base URL part having IDN, I didn't have much strong
opinion. However I think an A-label format is still preferred. Because
the using-http draft seems for me to say IRI should be transformed to
URI before querying in Section 9.1:

  9.1. URIs and IRIs

  Clients can use IRIs [RFC3987] for internal use as they see fit, but
  MUST transform them to URIs [RFC3986] for interaction with RDAP
  servers.  RDAP servers MUST use URIs in all responses, and again
  clients can transform these URIs to IRIs for internal use as they see
  fit.

Any comments or any questions are welcome.

Regards,
Naoki Kambe

---

From: Pete Resnick <[email-masked]>
Date: Sun, 12 Oct 2014 22:49:03 -0500

On 10/7/14 6:32 AM, Marc Blanchet wrote:
> Le 2014-10-07 à 01:01, Pete Resnick<[email-masked]>  a écrit :
>
> thanks for your review.
>
>    

OK, Murray sent me some sample text that he thought might satisfy, and I 
think it does, so I'm going to steal pieces of it and suggest we use it. 
Here are my current thoughts:

1- I think making the following change to the introduction will go a 
long way in clarifying for me:

OLD
    The proposed mechanism is based on the fact that allocation data for
    domain names and IP addresses are maintained by IANA, are publicly
    available and are in a structured format.  The mechanism assumes some
    data structure within these registries.  This document requests IANA
    to create these registries for the specific purpose of RDAP use,
    herein named RDAP Bootstrap Service registries.  An RDAP client
    fetches the RDAP Bootstrap Service registries, extracts the data and
    then does a match with the query data to find the authoritative
    registration data server and appropriate query base URL.
NEW
    TLDs, AS numbers, and network blocks are delegated by IANA to
    registrars that then issue further delegations and maintain
    information about them.  Thus, obviously the bootstrap information
    needed by RDAP clients is best generated from data and processes
    already maintained by IANA, whose registries already exist at
    [ipv4reg], [ipv6reg], [asreg], and [domainreg].

    The required new functionality in support of RDAP could be
    accomplished by augmenting these registries to contain new fields, or
    creating second parallel registries containing the extra fields whose
    entries mirror the existing ones.  Either approach will satisfy the
    needs of this document. This document requests IANA to make these
    registries available for the specific purpose of RDAP use, herein
    named RDAP Bootstrap Service Registries.  An RDAP client fetches the
    RDAP Bootstrap Service Registries, extracts the data and then does a
    match with the query data to find the authoritative registration data
    server and appropriate query base URL.
END

That makes it clear up front what we're asking IANA, and clients, to do. 
And then I think I'm fine with most of section 3, though I would like to 
put in some of the clarifications I had in my original comments:

3 -

OLD
    The RDAP Bootstrap Service Registries are made available as JSON
    [RFC7159] objects.  The JSON registry output starts with metadata
    such as a version identifier, a timestamp of the publication date of
    the registry and a description.  There exists a "services" element,
    which is an array of arrays.  Each second level array contains two
    elements, each of them being an array (third-level arrays).
NEW
    The RDAP Bootstrap Service Registries will be made available as JSON
    [RFC7159] objects, to be retrieved via HTTP from a location as
    specified by IANA in section 12.  The JSON object for each registry
    will start with a series of members that contain metadata about the
    registry such as a version identifier, a timestamp of the publication
    date of the registry and a description. Following that is a
    "services" member which contains the registry items themselves, as an
    array. Each item of the array contains a second-level array, with two
    elements, each of them being a third-level array.
END

> - I have to say again that IANA looked at it (both the technical people and the registration people) and they were fine with the text.
>    

I'm not worried about IANA. I'm sure between the text and what you've 
explained, they can handle it. I'm shooting for making it clear to the 
IETF folks who are reading it. With the above suggested, and what I've 
got down for section 12 below, I think it will be much clearer for them.

> - the json format evolved into multiple level arrays, as requested by implementors.  A two columns table won't really show this structure.  So in some ways, we are just not used to define registrie…

I think, given Andy's comment, best to leave it be at this point.

>> Throughout - Update RFC 4627 to RFC 7159

Don't forget that one.

> humm. good point. This addition was from a review comment. I guess we should think about this one.

I think between Naoki and John L's comment, I'm OK with leaving this, as 
the context is different.

>>       that client has not found.

Cool. Looking forward to the update.

>     registration policies for the new registries of this document are

Given what I suggest for the introduction, and stealing some of Murray's 
text, and moving the 12.5 info up to the beginning of section 12, here's 
what I suggest in order to make it clearer:

OLD
    IANA is requested to implement the following registries in JSON
    format conformant to the syntax defined in Section 10.
NEW
    IANA is requested to make the RDAP Bootstrap Services Registries
    described below available as JSON objects, the syntax of which are
    described by section 10. The process for adding or updating entries
    into these registries does not correspond to the registration
    policies described in [RFC5226]; as stated earlier, these registries
    are generated from the data, processes, and policies maintained by
    IANA in their allocation registries ([ipv4reg], [ipv6reg], [asreg],
    and [domainreg]). IANA is expected to generate the RDAP Bootstrap
    Services Registries data from these above mentioned registries,
    according to their own registration policies. This document does not
    extend or otherwise change those policies.

    Each of the RDAP Bootstrap Services Registries needs to be made
    available for general public on-demand download in the JSON format at
    a location determined by IANA.

    IANA is also advised that the download demand for the RDAP Bootstrap
    Services Registries may be unusually high compared to other
    registries that exist already. The technical infrastructure by which
    registries are published may need to be reviewed.

END

And then strike section 12.5. (Leave 12.1 through 12.4 as they are.)

pr

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 12 Oct 2014 21:08:17 -0700

All of this looks great.  A nit:

>    elements, each of them being a third-level array.

"as specified by IANA in section 12" doesn't read right to me; IANA isn't
specifying their download location in Section 12.

Replace the first sentence with:

The RDAP Bootstrap Service Registries will be made available as JSON
[RFC7159] objects, as described in Section 12, to be retrieved via HTTP
from a location to be specified by IANA.

> explained, they can handle it. I'm shooting for making it clear to the IETF
> folks who are reading it. With the above suggested, and what I've got down
> for section 12 below, I think it will be much clearer for them.
>

Right, or anyone from IANA or ICANN that might read this, now or later,
having not been a party to our private discussions with IANA.

The rest of Pete's suggestions look good to me.

-MSK

---

From: Andy Newton <[email-masked]>
Date: Mon, 13 Oct 2014 14:30:46 +0000

All looks good to me as well, fwiw.

-andy

On Oct 13, 2014, at 12:08 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Oct 12, 2014 at 8:49 PM, Pete Resnick <[email-masked]<mailto:[email-masked]>> wrote:
NEW

"as specified by IANA in section 12" doesn't read right to me; IANA isn't specifying their download location in Section 12.

The RDAP Bootstrap Service Registries will be made available as JSON [RFC7159] objects, as described in Section 12, to be retrieved via HTTP from a location to be specified by IANA.

I'm not worried about IANA. I'm sure between the text and what you've explained, they can handle it. I'm shooting for making it clear to the IETF folks who are reading it. With the above suggested, and what I've got down for section 12 below, I think it will be much clearer for them.

Right, or anyone from IANA or ICANN that might read this, now or later, having not been a party to our private discussions with IANA.

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

---

From: Pete Resnick <[email-masked]>
Date: Mon, 13 Oct 2014 09:41:02 -0500

On 10/12/14 11:08 PM, Murray S. Kucherawy wrote:
> On Sun, Oct 12, 2014 at 8:49 PM, Pete Resnick 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     NEW
> "as specified by IANA in section 12" doesn't read right to me; IANA 
> isn't specifying their download location in Section 12.

Oh? Where is it going to be specified?

I thought that when IANA updates all of the "requested to do X" to "has 
done X", they'd add in the locations.

But if not:

> [RFC7159] objects, as described in Section 12, to be retrieved via 
> HTTP from a location to be specified by IANA.

Not quite right, since the JSON stuff is not really specified in Section 
12. How about:

The RDAP Bootstrap Service Registries, as specified in Section 12, will 
be made available as JSON [RFC7159] objects, to be retrieved via HTTP 
from a location as specified by IANA.

>     I'm not worried about IANA. I'm sure between the text and what
>     you've explained, they can handle it. I'm shooting for making it
>     clear to the IETF folks who are reading it. With the above
>     suggested, and what I've got down for section 12 below, I think it
>     will be much clearer for them.
>
>
> Right, or anyone from IANA or ICANN that might read this, now or 
> later, having not been a party to our private discussions with IANA.
>

Thanks,

pr

---

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

> done X", they'd add in the locations.

Oh, I hadn't thought that they might make such a permanent commitment
inside the RFC itself.  If they do, then groovy; should we add a
placeholder in our version of the draft for it?

>
> The RDAP Bootstrap Service Registries, as specified in Section 12, will be
> made available as JSON [RFC7159] objects, to be retrieved via HTTP from a
> location as specified by IANA.
>

Also groovy.

-MSK

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 13 Oct 2014 12:22:31 -0700

Le 2014-10-13 à 11:10, Murray S. Kucherawy <[email-masked]> a écrit :

> On Mon, Oct 13, 2014 at 7:41 AM, Pete Resnick <[email-masked]> wrote:
> I thought that when IANA updates all of the "requested to do X" to "has done X", they'd add in the locations.
> 
> But if not:
> 
> Oh, I hadn't thought that they might make such a permanent commitment inside the RFC itself.  If they do, then groovy; should we add a placeholder in our version of the draft for it?

IANA normally does not.  Moreover, there was a request from IANA people to make sure we are _not_ imposing location, since they will have to be hosted on their caching infrastructure which might have an influence on the location.  So unless I'm hearing big voices, I'm not going to change the draft to put a placeholder for the location.

Marc.

>  
> 
> The RDAP Bootstrap Service Registries, as specified in Section 12, will be made available as JSON [RFC7159] objects, to be retrieved via HTTP from a location as specified by IANA.
> 
> Also groovy.
>  
> -MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 13 Oct 2014 13:20:51 -0700

On Mon, Oct 13, 2014 at 12:22 PM, Marc Blanchet <[email-masked]>
wrote:

> IANA normally does not.  Moreover, there was a request from IANA people to
> make sure we are _not_ imposing location, since they will have to be hosted
> on their caching infrastructure which might have an influence on the
> location.  So unless I'm hearing big voices, I'm not going to change the
> draft to put a placeholder for the location.
>
>
Works for me.  Worst case, we deal with it during IESG Evaluation when IANA
chimes in with their formal review comments.

-MSK