Subject: Re: [weirds] New proposed charter

From: Peter Koch <[email-masked]>
Date: Thu, 2 Feb 2012 20:40:18 +0100

On Thu, Jan 12, 2012 at 03:26:58PM -0500, Andrew Sullivan wrote:

> I don't see what the waste is, then.  The central questions, to my
> mind, are these:
> 
>     1.  Do we need to charter a WG?

Not sure, but there seems enough momentum to do so.  The RIR case
could, however, be dealt with without the WG infrastructure setup
and teardown.
 
>     2.  Does that WG cover number resources?

Obviously, yes.

>     3.  Does that WG cover domain name resources?

The WG charter should be clear about this.  With the latest version
(and the previous was no more or less specific) it is unclear to me
how strongly particluar name registry requirements could drive the
discussion or ought to be cut because of less of relevance for the
number resource case.  My general concern is that despite the
laudable commitments voiced on this list this effort will have difficulties
reflecting or collecting the full set of requirements (or non-~)
rather than being driven by a certain elephant-in-the-room-program.

Nit: the charter talks about registries 'containing' data, which is
generally okay, but the usual colloquialism describes the entity
running the database as the 'registry', not the db itself.

FWIW, start + two months for the requirements document is extremely
ambitious and might not even span a face to face meeting under the
assumption that the WG was to be instantiated after Paris.
The references to RFC 3707 go into the right direction, biut I'm
missing a predetermined breaking point should the requirements
be too close to RFC 3707 or turn out to be "IRIS over REST".

-Peter

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Feb 2012 11:56:46 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Koch
> Sent: Thursday, February 02, 2012 11:40 AM
> To: Andrew Sullivan
> Cc: [email-masked]
> Subject: Re: [weirds] New proposed charter

Ah Peter, we meet again.  :-)  Hope you had a good holiday.

> could, however, be dealt with without the WG infrastructure setup and
> teardown.

Doesn't that presume there's an AD willing to sponsor the work, or that APPSAWG would be willing to pick it up?  It seems to me to be too big a task for one-off sorts of things for which those two venues are more appropriate.  However, you do have a few more grey hairs in your IETF beard than I do...

> (and the previous was no more or less specific) it is unclear to me how
> strongly particluar name registry requirements could drive the
> number resource case.  My general concern is that despite the laudable
> commitments voiced on this list this effort will have difficulties
> reflecting or collecting the full set of requirements (or non-~) rather
> than being driven by a certain elephant-in-the-room-program.

The consensus I remember from Taipei is that we don't want to focus on name registries at all, but we shouldn't deliberately try to preclude enabling them either.  It seems to me the current text does that, especially "without the requirement that name registries be accommodated", while still creating a non-specific extension mechanism.

I think given that we have a few "beta" implementations of this already among network registries, we won't have any difficulty nailing down requirements for that case (as well as stuff that's identifiable as out-of-scope); those respective projects will have that sort of information to contribute already, even if informally.

For the name registry question it is a little more theoretical, but I imagine the above will be good input to that part of the project when we get to it.

> running the database as the 'registry', not the db itself.

Agreed.

> missing a predetermined breaking point should the requirements be too
> close to RFC 3707 or turn out to be "IRIS over REST".

I agree here too; we probably need a little more time than that.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Feb 2012 15:03:24 -0500

Hi,

On Thu, Feb 02, 2012 at 08:40:18PM +0100, Peter Koch wrote:

> number resource case.

This text in the charter was supposed to address that:

     and development of the
    number registry support will not be constrained by needs peculiar
    to name registries.  However, when choosing between two
    otherwise-equivalent options, the working group shall prefer the
    one that is most amenable to re-use by name registries, and
    potential re-use by name registries will be a guiding principle of
    the work.  

Can you suggest an alternative?

> rather than being driven by a certain elephant-in-the-room-program.

Well, the charter sort of assumes we more or less have the
requirements: CRISP plus the three named principles and "RESTful".
Isn't that how it reads?

> running the database as the 'registry', not the db itself.

I've actually heard this both ways, but if you're happier with
"registry databases" I'm not opposed.

> assumption that the WG was to be instantiated after Paris.

What do you think to be more realistic?

> be too close to RFC 3707 or turn out to be "IRIS over REST".

Do you have a suggestion for how to capture that?

Best,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Francisco Arias <[email-masked]>
Date: Thu, 2 Feb 2012 21:13:29 -0800

On 2/2/12 11:56 AM, "Murray S. Kucherawy" <[email-masked]> wrote:

>The consensus I remember from Taipei is that we don't want to focus on
>name registries at all, but we shouldn't deliberately try to preclude
>enabling them either.  It seems to me the current text does that,
>especially "without the requirement that name registries be
>accommodated", while still creating a non-specific extension mechanism.

However, after Taipei a number of entities, e.g., Afilias, AusRegistry,
CNNIC, ICANN, ISC, Nominet, .MX, Verisign, etc. have expressed their
interest in developing the name registries part. I believe we have a good
case for, at least, not excluding the name registries.

__

Francisco.

---

From: Peter Koch <[email-masked]>
Date: Fri, 3 Feb 2012 09:47:57 +0100

Hi Murray,

happy new year to you, too ;-)

> Doesn't that presume there's an AD willing to sponsor the work, or that APPSAWG would be willing to pick it up?

usually, yes.

> It seems to me to be too big a task for one-off sorts of things for
> which those two venues are more appropriate.

Well, for the two, three (or five) RIRs (plus ICANN) to get together, coordinate
and document their effort(s) there's still probably no need for a WG. On the other
hand it doesn't appear as a blatant waste of resources to me, either.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Fri, 3 Feb 2012 10:21:58 +0100

> Can you suggest an alternative?

I wish I could, but let me retry: due top the structured nature of the
number resources and the character set they are represented in, many of
the issues for domain names seen as input or query strings do not
apply to number resources (script/"language" tagging, fuzzy matching).
Is the WG still going to address these and when?

> requirements: CRISP plus the three named principles and "RESTful".

For one, I have just sent some comments on Murray's requirements draft.
Admitted that it's still an individual contribution it doesn't look
like ``CRISP plus the three named principles and "RESTful"''. You
could rightfully say I should stick to the charter rather than a
"random" proposal, but I'm receiving mixed signals here.

> What do you think to be more realistic?

Depends very much on how we separate policy and protocol.
Again, ``CRISP plus the three named principles and "RESTful"'' looks
promising on one hand, but makes me wonder what the deployment
incentive is.  I am just not convinced that REST makes this all
so much more appealing than BEEP did (or did not, for that matter).

With an anticipated start after Paris, having post WGLC discussion
by Atlanta (Nov) looks realistic to me.

> Do you have a suggestion for how to capture that?

Well, not completely inside the toolbox of the IETF.  Running code
is great, deployed code trumps even more.  Would enough registries
outside the new gTLD program see a benefit in this rather than
a vanilla IRIS implementation or whatever whois service they provide
today?

-Peter

---

From: Andy Newton <[email-masked]>
Date: Fri, 3 Feb 2012 10:10:55 -0500

On Feb 3, 2012, at 4:21 AM, Peter Koch wrote:

> I am just not convinced that REST makes this all

From the standpoint of an implementer with experience with both, the RESTful web method is much, much more appealing.

-andy

---

From: Peter Koch <[email-masked]>
Date: Fri, 3 Feb 2012 19:11:27 +0100

> From the standpoint of an implementer with experience with both, the RESTful web method is much, much more appealing.

I am happy to trust you with that.  Next question is are we reasonably
sure that this implementation advantage is likely to turn into a
deployment significantly better compared to IRIS? For number resource registries?
For name registries?

-Peter

---

From: Andy Newton <[email-masked]>
Date: Fri, 3 Feb 2012 13:20:14 -0500

> deployment significantly better compared to IRIS? For number resource registries?

Given ARIN's experience, yes.

> For name registries?

Well, there have been a group of people on this mailing list from the network abuse community who have suggested they could use the information. So is there an advantage for domain registries to serve this information to end users? If not, that begs the question of why they even bother with port 43.

-andy

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 03 Feb 2012 10:49:32 -0800

+1

Regardless of its virtues almost no-one in the real world has ever heard 
of BEEP.

REST/HTTP can be used just by anyone with a browser (human consumption) 
or by any script with an HTTP lib (urllib2, 
your-preferred-poison-http-lib).  JSON output makes it  trivial to 
integrate WHOIS output with rich web apps by means of jQuery/Ajax.

Try that with BEEP (*1) :-)

Implementation of REST/HTTP is almost trivial using Django (Python), 
Java or again using your preferred prescription drug. As far as I know 
there are only a handful of BEEP libraries. The key effort resides in an 
adequate design of the API rather than on implementation.

regards

Carlos

(*1) Googling javascript / jquery + beep returns results along the lines 
of 'how do I make my browser beep?' :-))))

On 2/3/12 7:10 AM, Andy Newton wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Arturo Servin <[email-masked]>
Date: Fri, 3 Feb 2012 17:15:25 -0200

Peter,

> deployment significantly better compared to IRIS? For number resource registries?

	Yes, at least to query registration data. We prototyped a server in a few weeks and a client API in one weekend.

	There is some road to have a production server and API but it was not very hard. We even have a couple of beta testers and a couple of our internal apps are using it to retrieve registration data.

> -Peter

Regards,
as

---

From: Dave Piscitello <[email-masked]>
Date: Sat, 4 Feb 2012 10:47:08 -0800

> 	Yes, at least to query registration data. We prototyped a server in a few weeks and a client API in one weekend.

We had a similar experience with our RESTful experiments.