Subject: [weirds] I-D Action: draft-ietf-weirds-bootstrap-11.txt

From: [email-masked]
Date: Thu, 18 Dec 2014 11:32:48 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF.

        Title           : Finding the Authoritative Registration Data (RDAP) Service
        Author          : Marc Blanchet
	Filename        : draft-ietf-weirds-bootstrap-11.txt
	Pages           : 17
	Date            : 2014-12-18

Abstract:
   This document specifies a method to find which Registration Data
   Access Protocol (RDAP) server is authoritative to answer queries for
   a requested scope, such as domain names, IP addresses or Autonomous
   System numbers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-bootstrap/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-bootstrap-11

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/

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 18 Dec 2014 14:39:26 -0500

Hello,
 this new version shall address all comments received from IESG review. IMHO, it should clear the DISCUSS and move ahead.

Regards, Marc.

> Début du message réexpédié :
> 
> De: [email-masked]
> À: [email-masked]
> Objet: I-D Action: draft-ietf-weirds-bootstrap-11.txt
> Date: 18 décembre 2014 14:32:48 UTC−5
> Cc: [email-masked]
> Répondre à: [email-masked]
> 
> 
> _______________________________________________
> 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: Peter Koch <[email-masked]>
Date: Thu, 18 Dec 2014 21:58:50 +0100

>  this new version shall address all comments received from IESG review. IMHO, it should clear the DISCUSS and move ahead.

I've re-read the updated IANA considerations section.  This new
version still does not focus on the IETF side of things and in fact
tries to make ICANN's work with IETF tools.  In fact, what is about
to be established here is not even a registry, it is operational data
(fed from existing registries coming from different, non-IETF IANA pillars).
more like the DNS root zone than an IETF protocol parameters registry.

Therefore what the IETF should do is specify the format only and let
"the other entity" (aka ICANN) describe (in an RFC, independent submission stream)
the operational details of the initial "hook".
The end result for users would be the same with the benefit of untangling the
policy space.  Let us please use this opportunity not to further contribute to
overlaps between different IANA functions where in neighboring venues we
try to more precisely specify the separation of duties.

-Peter

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Dec 2014 16:09:25 -0500

> the operational details of the initial "hook".

I would be happy with that alternative, as long as it's a normative
reference, which this document would then have to wait for.  I think
it's important for this document (along with its normative references)
to provide the complete information necessary to create
implementations.

I'm not sure we want to delay things for that, but you're welcome to argue it.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Dec 2014 16:35:24 -0500

Further following up...

> I'm not sure we want to delay things for that, but you're welcome to argue it.

I'll add that we have already run this version by IANA (and, so,
ICANN), and they're fine with it.  Are you sure that they'd rather
publish a separate document of their own for this?

Barry

---

From: Peter Koch <[email-masked]>
Date: Thu, 18 Dec 2014 22:36:27 +0100

> reference, which this document would then have to wait for.  I think

while processing them in prallel at the RFC Editor is a good idea,
I think not only should there be no normative reference (downref to Informational,
not necessary to understand the protocol spec, not even to implement it because what's
provided in the "companion" RFC is config data) but probably none
at all, simply because the IETF might not need to take a position here _and_
the protocol work is done by specifying the format.  But I could understand
the desire to provide some guidance in an appendix _with_ a pointer to the 2nd RFC.

> I'm not sure we want to delay things for that, but you're welcome to argue it.

I'd not argue in favor of delay, but definitely for said separation.
I can't write the second document because "I'm not ICANN" ...

-Peter

---

From: Peter Koch <[email-masked]>
Date: Thu, 18 Dec 2014 22:44:34 +0100

> publish a separate document of their own for this?

it's probably worth distinguishing the IANA and the ICANN roles here.
When IANA staff says they are fine with it, I'd read that as 'the instructions
are clear' and 'we can implement this as desired' rather than 'we take
a position regarding the IETF politics'.  I.e., it is the usual
check of 'IANA considerations'.  My point is that the IETF needs to
be prepared.  Also, I'd not expect "IANA" to appear in the editor's section
of the second documrnt.

-Peter

---

From: Pete Resnick <[email-masked]>
Date: Tue, 30 Dec 2014 11:47:13 -0600

Peter,

I don't disagree in principle with any of the below, but (a) I think the 
conclusion of the WG and the IESG was that the separation was sufficient 
enough to keep things separate and, more importantly, (b) I repeatedly 
brought this document to the attention of the IAB IANA Evolution Program 
and no concerns were expressed. I don't feel like I'm in a position at 
this point (both in terms of my understanding of the issue and what I 
see as the consensus) to tell the WG to go in a different direction.

If you feel this is a blunder, I will take absolutely no offense (and I 
don't think the WG should either) if you appeal this, as I do think this 
is an important issue. Appealing will not only put the single issue on 
the IESG's agenda to review, but it also means that if we stick by our 
decision it can be reviewed by the IAB as a whole. Given the political 
implications of this issue, I don't think that would be such a bad 
outcome. I am even happy to help you walk through the appeal process so 
that it happens quickly and properly. The appeal can probably be decided 
before the document is likely to get to the top of RFC Editor queue 
anyway, so I don't think it will introduce any significant delay.

Let me know if you want to do that.

Either way, once my questions from yesterday about json-response and 
rdap-query get answered, I'll mark the entire set as approved.

pr

On 12/18/14 2:58 PM, Peter Koch wrote:
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>    

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Dec 2014 13:06:23 -0500

On Tue, Dec 30, 2014 at 11:47:13AM -0600, Pete Resnick wrote:
> brought this document to the attention of the IAB IANA Evolution Program and
> no concerns were expressed. 

I read the document more than once, both with my WG participant hat on
and as a member of the IANA evolution program, and I guess I don't see
what the problem is, given the WG's decision to go this way.

That is, I _always_ thought using an IANA registry for bootstrapping
was silly, and I always thought that we have a perfectly good
mechanism in the DNS to deliver this sort of answer.  But given how
far in the rough I was, I couldn't see what else to do.  Moreover,
staff from the current IANA operator was in the room and not objecting
when this issue was raised (and is presumably still on the list).

But it seems to me that what the document is outlining is an
admittedly-unusual update mechanism for the registry.  It surprises me
somewhat that IANA in its review did not ask, "How are we supposed to
do this?"  But if they know, then I can't see what the problem is.

A

-- 
Andrew Sullivan
[email-masked]