Subject: [weirds] Another BoF in Paris?

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Feb 2012 14:21:44 -0500

Dear colleagues,

Given the lack of complete agreement on what a charter would be for a
WG, we still have some work to do.

I was planning to request another BoF slot in Paris.  At the BoF, we
would try to hammer out the final details of a charter and see whether
there is enough agreement for certain to move ahead.  If, however, we
were able to come to agreement prior to that date, then we could use
the time to discuss document issues, optimistically hoping that we
would indeed be chartered by the IESG.

When I suggested this to some people off-list, however, they expressed
concern, because of the difficulty of recovering if a second BoF does
not produce results.  In particular, it would be very unusual to hold
a 3d BoF, and probably if we are not chartered after a 2d BoF then we
never will be.  The people I spoke to therefore suggested caution and,
in particular, suggested we'd be better off just continuing to work on
this list.

I haven't made the BoF request yet.  Does anyone have a feeling about
the above?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 11:37:57 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Wednesday, February 08, 2012 11:22 AM
> To: [email-masked]
> Subject: [weirds] Another BoF in Paris?
> 

Well, I guess this means I need to read recent traffic again.  It seemed to me that the surprising-but-pleasing expression of interest from name registries suggested that the "leave hooks for names" approach we'd been espousing all along was an indication that we'd be able to satisfy all parties here, meaning the current charter or a slight variant of it would be good to go.

I'll try to do that this evening.

-MSK

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 08 Feb 2012 14:45:17 -0500

I read it in the same way, I thought we were more or less ready to roll...

On 2/8/12 2:37 PM, Murray S. Kucherawy wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Andy Newton <[email-masked]>
Date: Wed, 8 Feb 2012 15:00:27 -0500

Same here. Seems like rough consensus to me.

-andy

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Feb 2012 17:15:44 -0500

Dear colleagues,

With so many people telling me I was being an Eeyore (this is not,
_mirabile dictu_, the first time I have heard that), I thought I'd
better try again with some charter text. 

I therefore offer the attached text as a proposed charter for WEIRDS.
I have incorporated what I understand to be the thrust of various
positions people have taken.  I believe I incorporated actual proposed
text when it was offered, except in the case where the prior consensus
rejected that approach (here, I'm thinking particularly of the
suggestions to make name registries and number registries both part of
the initial work list; this was strongly rejected in Taipei, and we
don't have additional drafts or additional experiments to point to
that would undercut that consensus).

I also included some changes sent to me off-list, including some by
Pete Resnick.  

Thanks to all those who sent suggestions.  If nobody has any
objections, I'd like to offer this to the IESG as evidence that we
have a group of people willing to work on a well-scoped problem.

It still isn't clear to me whether I ought to request a BoF slot or
whether we should just press ahead on the basis of what looks like a
group of people already having agreed.  Are there things we think
would benefit from a face to face meeting?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Michael Young" <[email-masked]>
Date: Wed, 8 Feb 2012 17:25:02 -0500

Thank you Andrew for all the hard work, it's a tough job bringing this
together and you do it well.

>From monitoring the list, I don't see why another BOF is needed - of course
others may differ,......

Michael Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Sullivan
Sent: February-08-12 5:16 PM
To: [email-masked]
Subject: [weirds] New proposed charter text (was: Another BoF in Paris?)

Dear colleagues,

With so many people telling me I was being an Eeyore (this is not, _mirabile
dictu_, the first time I have heard that), I thought I'd better try again
with some charter text. 

I therefore offer the attached text as a proposed charter for WEIRDS.
I have incorporated what I understand to be the thrust of various positions
people have taken.  I believe I incorporated actual proposed text when it
was offered, except in the case where the prior consensus rejected that
approach (here, I'm thinking particularly of the suggestions to make name
registries and number registries both part of the initial work list; this
was strongly rejected in Taipei, and we don't have additional drafts or
additional experiments to point to that would undercut that consensus).

I also included some changes sent to me off-list, including some by Pete
Resnick.  

Thanks to all those who sent suggestions.  If nobody has any objections, I'd
like to offer this to the IESG as evidence that we have a group of people
willing to work on a well-scoped problem.

It still isn't clear to me whether I ought to request a BoF slot or whether
we should just press ahead on the basis of what looks like a group of people
already having agreed.  Are there things we think would benefit from a face
to face meeting?

Best regards,

A

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 14:28:03 -0800

> Sent: Wednesday, February 08, 2012 2:16 PM
> To: [email-masked]
> objections, I'd like to offer this to the IESG as evidence that we have
> a group of people willing to work on a well-scoped problem.

I propose that we request a slot, maybe 1.5 hours.  If we fail to charter, or get close to it, by Paris, then it can be a BoF to talk about how to improve the proposal one last time.  If we do charter, we use it as our first meeting.

-MSK

---

From: Dave Piscitello <[email-masked]>
Date: Wed, 8 Feb 2012 14:47:06 -0800

+1

Name registry operators have expressed interest. 

ICANN has. 

Consumers of name registration data have.

Folks like Andy with principally number registry interests have supported inclusion of name registries.

I'm not sure what more those of us who are participating for the purpose of name registry registration data are expected to do.

Please illuminate.

---

From: SM <[email-masked]>
Date: Wed, 08 Feb 2012 15:33:51 -0800

>never will be.  The people I spoke to therefore suggested caution and,

Three BOFs are not permitted.

There are individuals who happen to be have an affiliation with 
number and name registries who volunteered to actively participate in 
a future working group.  If I am not mistaken, the latest round of 
discussions about the proposed charter has been about refining the 
scope of the work.

I suggest a last round of discussions about the proposed charter 
(BTW, it was not sent to the list) before moving forward.

Regards,
-sm

---

From: Jim Galvin <[email-masked]>
Date: Wed, 08 Feb 2012 17:23:34 -0800

There was no attached text.  Or are you going back to what you had 
before?  If so, I object.

I'm only slightly sympathetic to your request for an internet-draft 
from the name registries as you have from the number registries. 
You've had some pretty significant support from name registries 
indicated.  That seems pretty conclusive to me.  Nonetheless, I'm 
working on a draft.

I'll further point out that although you may have had strong objection 
at the BOF in Taipei, I submit that in the true IETF way that is also 
not conclusive.  Those who are speaking up now from the name registries 
were not present in Taipei.  It's not fair to judge us based solely on 
presence at that BOF.  If you're going to do that then you need to have 
another BOF in Paris so we can be present and speak for ourselves.

Jim

-- On February 8, 2012 5:15:44 PM -0500 Andrew Sullivan 
<[email-masked]> wrote regarding [weirds] New proposed charter 
text (was:  Another BoF in Paris?) --

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Feb 2012 20:42:18 -0500

> I therefore offer the attached text as a proposed charter for WEIRDS.

Yes, well, I guess I oughta have attached, eh?  Jeez, what a maroon.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Feb 2012 20:57:05 -0500

> There was no attached text.  Or are you going back to what you had

No, just sent.  I suck.  I suspect you'll still object, but I'm
willing to wait for it.

For what it's worth, my view is roughly the aphorism that starts, "A
bird in the hand. . ."  

Moreover, to play devil's advocate, if I were on the IESG I would
object today to including name registries in scope: the last time I
worked for a domain name registry and the subject of Whois
replacements came up, I couldn't get anybody in the company to
authorize any serious protocol development time or experimental
development efforts on the topic (even though everyone told me it was
super important, and even though I wasted hours on some ICANN
committee conference calls about it).  Why should anyone believe it'd
be different this time?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2012 01:56:44 -0000

>Yes, well, I guess I oughta have attached, eh?  Jeez, what a maroon.

That's a relief, I thought it was my new glasses.

It looks fine to me.  First we do numbers, then we do names.

Niggle:  In this section, I don't understand what "including number
registries" is supposed to mean.  For "other" do you mean "various
kinds of" ?

>    The base specification shall include an extension mechanism to
>    permit future development in other registries, including number
>    registries and, in so far as it can be accommodated, name
>    registries.

R's,
John

---

From: Dave Piscitello <[email-masked]>
Date: Wed, 8 Feb 2012 18:42:03 -0800

Respectfully this is not your decision to make to the exclusion of the expressions of interest from so many from the name registry  community

Sent from my iPhone

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2012 03:21:19 -0000

>Respectfully this is not your decision to make to the exclusion of the
>expressions of interest from so many from the name registry  community

Sheesh.  What is so hard to understand about doing numbers first, then
names?  Numbers are a more tractable problem, and make it more likely
that we can work out issues of transport, character sets, query
structure, and such without getting totally sidetracked by all of the
extra issues that a thousand name registries add.  Assuming we get
that to work, then we can try to build another data and query model
for names.  We're not totally dim, we can keep in mind while thinking
about the number stuff that we want to avoid approaches that will be
unworkable with names.

If I were on the IESG (which lucky for everyone, I'm not), in view of
the history here I would be extremely sceptical of a WG that claimed
it was going to do the scaffolding, number queries, and drain the
swamp of name registry WHOIS all at the same time, so I think Andrew's
prediction of pushback is likely correct.

As an alternative, if there's that much interest and it needs to be
done really fast, the name registry crowd could spin up their own WG.

R's,
John

---

From: "Tran, Trung" <[email-masked]>
Date: Wed, 8 Feb 2012 23:15:46 -0500

>We're not totally dim, we can keep in mind while thinking about the number stuff that we want to avoid >approaches that will be unworkable with names.

I appreciate your consideration to avoid unworkable approaches with name registries, but IMHO that's one of the issues.  It should not be just to avoid unworkable approaches but it should be to find an approach that works relatively well for both number and name registries.  If name registry concerns are not to be considered, then there will be perception (real or not) that the solution is optimal for number registries and not as optimal for name registries.

>As an alternative, if there's that much interest and it needs to be done really fast, the name registry >crowd could spin up their own WG.

One whois solution for number and a different one for name?

Trung

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 Feb 2012 20:40:09 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Piscitello
> Sent: Wednesday, February 08, 2012 6:42 PM
> To: Andrew Sullivan
> Cc: [email-masked]
> Subject: Re: [weirds] New proposed charter text (was: Another BoF in
> Paris?)
> 

Andrew didn't make a decision.  (He doesn't get to make it anyway.)  He was being hypothetical, applying his own experiences.  In my view what he has to say is quite relevant, especially considering the temperature in the room at the BoF in Taipei.

The path his charter has us on seems to reflect what came out of Taipei plus recent list comments from name registries that are interested in participating.  Feels like we're on target to me.

I believe we're not trying to exclude name registries; indeed, we're surprised and pleased to see the interest.   But they don't form the entire community of opinion that the IESG considers when approving a charter.

-MSK

---

From: Don Blumenthal <[email-masked]>
Date: Thu, 9 Feb 2012 00:05:02 -0500

Long time lurker, firstŠ.

I don't follow using a one-off experience as a justification for opposing
inclusion of name registries. Why would it be different? Maybe because
different
Registries would be involved, or technical, financial, and political
equations have changed.

I can't speak to what resources might be available but, from ICANN
sessions, other meetings, and side conversations, I have no doubt that
interest exists in the name community for exploring the possibility of
protocol alternatives.

Don

=========================
DON M. BLUMENTHAL
Senior Policy Advisor
.ORG, The Public Interest Registry
Direct: +1 734 418-8242  | Mobile: +1 202 431-0874 | Skype: donblumenthal
|

---

From: Don Blumenthal <[email-masked]>
Date: Thu, 9 Feb 2012 00:07:17 -0500

A certain Internet governing body has made an art form out of duplicating
effort in the Whois arena. I would hope to avoid duplicating that
experience.

Don

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2012 05:11:14 -0000

> If name registry concerns are not to be considered, then there will
> be perception (real or not) that the solution is optimal for number
> registries and not as optimal for name registries.

Hmmn.  Could you identify the people who you believe will have that
perception, and how many of them you expect to be involved in the
WEIRDS WG?  It seems likely to me that the WG will be more or less the
same people who are on this list now, and I don't see this group has a
problem understanding that using the same technology for names and
numbers is a good idea insofar as we can.

>One whois solution for number and a different one for name?

I think that would be a lousy idea, but if people are desperate to
start on a son-of-WHOIS for names, that's an option.  Another entirely
legitimate approach is to build prototype software and write drafts on
your own, and bring them to the IETF who, experience shows, is happy
to work on stuff that actually exists.  That's what the dmarc.org
group is doing, for example.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 9 Feb 2012 00:31:01 -0500

> effort in the Whois arena. I would hope to avoid duplicating that

Indeed.  Remember, the IETF is all volunteers.  If you think it's 
important, don't tell other people what to do, do the work.

I don't think that a separate WHOIS for names would be a good idea either, 
but doing names first, or even at the same time, ain't gonna happen unless 
the people who claim it's important do the work.

R's,
John

---

From: SM <[email-masked]>
Date: Thu, 09 Feb 2012 05:28:47 -0800

>Yes, well, I guess I oughta have attached, eh?  Jeez, what a maroon.

One of the milestones is:

    "An Internet-Draft listing the specific data objects
     that make up the set of things the WG shall map, possibly
     describing a common factor that is large enough for the needs of
     the WG's initial object specification.  This I-D shall be subject
     to WG LC but shall not actually proceed to the IESG unless the
     object specification (below) subsequently fails, in which case
     this shall be sent to the IESG for publication as Informational
     RFC."

I assume that the object specification is "Draft WEIRDS object 
specifications for number resource registries" (last milestone).  I 
suggest removing this milestone.  That leaves two deliverables:

  (i)  Draft WEIRDS base specification

  (ii) Draft WEIRDS object specifications for number resource registries

If the future working group cannot get work done, it's better to 
accept that than trying to change course towards some alternative 
not-well-defined destination.

As name registry support can be taken into consideration (re last 
paragraph of proposed charter), the current text might satisfy the 
various interests expressed on this mailing list while having a clear 
set of deliverables.  I am not sure what the two objections [1][2] 
posted recently are about.  Is anyone asking for a deliverable such as:

  (iii) Draft WEIRDS object specifications for name registries

Once (i) and (ii) are done, it should not be that difficult to do (iii).

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/weirds/current/msg00418.html
2. http://www.ietf.org/mail-archive/web/weirds/current/msg00422.html

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Feb 2012 08:41:25 -0500

> registries" is supposed to mean.  For "other" do you mean "various

Good catch.  The attached (for real this time!) modifies that passage.

Colleagues, the attached is a proposal -- not, note, a “decision” --
for a WG charter.  Those who do not like this proposal are welcome
(indeed, I urge you) to make an alternative proposal, or send
replacement text.

In this proposal, just as in the last one I sent, I did reject some
proposed replacement text from Jim Galvin.  The reason for that is
very much as others have already suggested: the last BoF seemed to say
very strongly that number resource registries ought to come first;
number resource registries are in fact making progress on this list
rather than just promising to do work in the future; and given both
that history, and the population of number resource registries as
opposed to the population of name registries, the number issues seem
tractable in short order.

To those who are arguing that the name registry issues all ought to be
milestones from the beginning, I would like you to consider something.
Number resource registries have worked on this bottom-up: they have
proposals and fielded test systems that demonstrate that progress can
be made; all that is really needed is the sort of community review to
make things consistent across systems.  This is the kind of thing at
which the IETF excels.

We have exactly one name registry that has proposed anything, and in
Internet terms it is tiny (important, but tiny).  It is also unusual:
it does not so far use the registration protocols that other
registries do, it has a massively more heavyweight (not to mention
expensive) registration qualification procedure, and at least to date
the data-consumer needs that are so important for TLDs are not that
pressing in the root zone.  Despite the claimed advantages of REST for
rapid prototyping -- one of the very reasons why this effort is
supposed to be better than IRIS -- we have not seen such prototypes
from participants in the name registry community.  (For what it's
worth, I am working on something in Dyn Labs, but I don't have access
to real databases yet.  Dyn is an ICANN-accredited registrar.)  Jim
said he's working on a draft, but nobody else has promised even that
much.

The proposed charter I offer gives a space for the name registry
issues to be hashed out while other progress is made.  Those who have
spoken from name registries have mostly merely said, "We want you to
charter our work," but have mostly not stated what that work entails.
That sounds like a top-down plan to me: create the management space
and mandate the result, and then set people to work.  But we already
did that; if you want the result, go implement IRIS.  Or, for that
matter, whois++ or RWhois.  If that's your plan, what reason do you
have to suppose the result would be different this time than the last
times -- _times_, note -- the IETF did it that way?

In any case, I believe that the attached is our best hope for getting
a WG chartered on this general topic, and getting enough momentum so
that name registry problems can be tackled in future.  If you think
I'm wrong, please make a concrete proposal.  What name registry
milestones would you add, when?  Remember that you'll need to be able
to justify them to the IESG, so you better have your arguments ready.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Thu, 9 Feb 2012 14:03:45 +0000

> (indeed, I urge you) to make an alternative proposal, or send

I hate to do this, but…

> 3.  Support for differential service levels, including bulk
>     access, according to different classes of user.

When did bulk whois come into scope?

>     December 2012 An Internet-Draft listing the specific data objects
>     RFC.  
>     April 2013 Draft WEIRDS base specification to IESG for
>     publication on the standards track.
> 
>     July 2013 Draft WEIRDS object specifications for number
>     resource registries to IESG for publication on the standards
>     track.

There have been two drafts submitted by representatives of the RIRs.
One is about the query format and the other about JSON responses to those queries.

How do those map into this set of milestones? Which one is a base specification?

And do we really need a separate draft describing the objects being mapped vs one that does the mapping?

-andy

---

From: SM <[email-masked]>
Date: Thu, 09 Feb 2012 06:40:55 -0800

>When did bulk whois come into scope?

The "including bulk access" could be dropped from the proposed 
charter as it is unrelated to the protocol a future working group 
might work on.

BTW, I read the first priority as internationalization being optional 
if the working group does not have the expertise to do so.  Is my 
assumption correct?

Regards,
-sm

---

From: Peter Koch <[email-masked]>
Date: Thu, 9 Feb 2012 15:48:33 +0100

Andrew,

> (indeed, I urge you) to make an alternative proposal, or send

i think this is on the right track. Especially the treatment of name
registries reflects not only the discussion in Taipei, but also
the status on this list.  Therefore it is also appropriate to not
have a name registry document on the deliverables list.

> make things consistent across systems.  This is the kind of thing at

Also, this is not only about running code, but also about real deployment
and deployment of optional parts.  Otherwise I'd have to disagree
with the observation that IRIS was a failure given that I know of
a registry that has a successfully deployed DCHK implementation.

> issues to be hashed out while other progress is made.  Those who have

I believe this is absolutely sufficient.

>     WHOIS also has no data model: replies are basically just free-form
>     text.  This means that processing of WHOIS output amounts to
>     "screen-scraping", with specialized handlers for every service.
>     Many of the domain name registries do share a basic common output
>     format, although the addition of data elements changes the output
>     and may cause problems for parsers of the data.

It has been observed that the absence of easy-to-parse output is
considered a feature by some in the name registry business and
obfuscation is deliberate.

>     without the requirement that name registries be accommodated.  In
>     addition, the following three priorities take precedence over
>     others from RFC 3707:

observing ;-) that the three priorities are numbered 1 .. 4 ...

>     1.  Complete support for internationalization of queries and
>     responses, including a standard representation for non-ASCII text
>     in queries and responses, and ways to indicate language or
>     character set preferences for responses.  The Working Group will
>     need to determine whether language or character set (or both) is
>     an appropriate selector.  Without significant participation from
>     internationalization experts, this requirement will be all but
>     impossible to meet.
> 
>     2.  A rigorous machine-friendly data model, both for the overall
>     protocol and for any data profiles the Working Group delivers.
> 

... i share Andy's confusion re: bulk access.

>     4.  A grammar for queries, so that all servers that support a
>     given kind of query accept the same syntax for the query.

... i'm not sure i understand why this is spelled out explicitly. Whois
    has seen lots of proprietary extensions, but isn't (4) already
    covered by (2)?

>     The working group may, but need not, develop a data profile (or
>     object format) to provide the support for name registries to use
>     the protocol.  The initial work list for the working group shall
>     not include work on name registry support, 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.  Discussion of issues, within the Working Group,
>     relating to name registry support is explicitly permitted; but
>     actual work on that topic is declared out of scope at the
>     beginning of work.  It is expected that the Working Group would
>     change this provision in its charter when and if the Working Group
>     were prepared to adopt any document related to name registry
>     support.

I support this.

> Milestones
> 
>     November 2012 Draft WEIRDS requirements to IESG for
>     publication as Informational RFC.
> 

Makes sense to me.

-Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Feb 2012 09:54:10 -0500

> When did bulk whois come into scope?

That exact sentence has been there since the first version of any
proposed charter.  See
http://www.ietf.org/mail-archive/web/weirds/current/msg00220.html.  I
guess people wanted it.

> How do those map into this set of milestones? Which one is a base specification?

It seems to me they both are: one is the query side and the other the
response side.  I don't think they need to be one document, but it
seems they would have to go up together.

> And do we really need a separate draft describing the objects being mapped vs one that does the mapping?

I don't think so, but we had a strong argument in favour of it (see
http://www.ietf.org/mail-archive/web/weirds/current/msg00380.html).
The basic idea of the way the first of those is written is to solve
that problem: basically, if the WG fails to come to agreement on the
actual protocol, then we can publish something else that describes the
objects.  The "describe the objects" is a necessary part of the
mapping anyway, it seemed to me, so I figured there was no risk in
accepting this.  I'm not wedded to it, but I guess Alessandro is.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Thu, 9 Feb 2012 10:18:53 -0500

> http://www.ietf.org/mail-archive/web/weirds/current/msg00220.html.  I

Then I take the blame for not noticing this before. However, I think it is out of scope. Not that I mind working on a standard for such a thing, but the needs for bulk whois are a much different critter than for regular whois.

> seems they would have to go up together.

That works for me.

> accepting this.  I'm not wedded to it, but I guess Alessandro is.

Can I ask that those who think this is a necessary step look at the RIR JSON response draft and explain how we are concretely benefited by a textual abstraction of that information? And if the benefit is the analysis of the different data elements, would a working group report by a designee or design team be good enough to drive the technical specifications forward?

-andy

---

From: "Smith, Bill" <[email-masked]>
Date: Thu, 9 Feb 2012 15:19:13 +0000

> to justify them to the IESG, so you better have your arguments ready.

As requested, see attached.

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2012 15:39:27 -0000

>    has seen lots of proprietary extensions, but isn't (4) already

That's my clause.  I read #2 as describing the data model of the underlying
server and the response, and likely the kinds of questions you can ask, but
not the concrete grammar.  My goal is simple: if I can ask a question at all,
I ask it in exactly the same way to everyone who can understand it.

The sort of thing I want to avoid is the current situation where, if I
ask an RIR about an IP address, some of them tell me about the
smallest surrounding allocation, some of them tell me about all of the
enclosing allocations, and one of them tells me what questions I could
ask to find out about each of the enclosing allocations.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2012 15:47:06 -0000

>As requested, see attached.

If I may ask a pointed question, how much of the extra name-related
work are you offering to do, and which name registries do you expect
to do prototypes to test the design?

For the bazillionth time, everyone knows that it would be nice to have
something better than the current WHOIS mess, but nobody's offered
any reason to believe that this would be any different from the last
three failed attempts.

R's,
John

---

From: "Smith, Bill" <[email-masked]>
Date: Thu, 9 Feb 2012 16:30:48 +0000

> to do prototypes to test the design?

Without any attempt to coerce or speak for anyone else, I expect we could see implementations from Neustar, PIR, Afilias, and ICANN. All have spoken up on the list in favor of a combined approach.

> any reason to believe that this would be any different from the last

Respectfully, Internet history is full of "failed attempts"; thankfully. When something fails, yet a need exists, people step in and try again. I've listed four list "name" participants that I believe are likely to participate in prototype development. That number exceeds the current number of "number" prototypes and is a strong argument that development interest exists. Additionally, as a consumer of WHOIS and potential consumer of WEIRDS, PayPal has a strong interest in names. 

Will this effort be any different then prior "failed attempts"? If we, this WG,  don't make the effort, the answer is guaranteed. If we make the effort, the Internet community will decide. I'm for the letting the community make the decision.

---

From: Gavin Brown <[email-masked]>
Date: Thu, 09 Feb 2012 16:39:13 +0000

> Without any attempt to coerce or speak for anyone else, I expect we could see implementations from Neustar, PIR, Afilias, and ICANN. All have spoken up on the list in favor of a combined approach.

CentralNic will certainly develop a prototype implementation. I am
certain that many of my colleagues at other registries will also do so.
Unfortunately the timing is inconvenient (we all have our heads down
working on new gTLDs) so many of us don't have the time needed to
monitor the discussion, but after April 12, I think you'll see a lot
more interest from the naming side.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Peter Koch <[email-masked]>
Date: Thu, 9 Feb 2012 17:50:47 +0100

> I ask it in exactly the same way to everyone who can understand it.

yes, but isn't that one of the basic reasons to start this effort?

> ask to find out about each of the enclosing allocations.

While that touches upon the semantics of the query and thus the shape of
the response a bit more than the syntax and while i also agree that this
sounds straightforward and useful, even under WEIRDS some servers
might, for policy reasons, give more or different responses than others.

In any case, #4 could be merged into #2 at least, given that it addresses
the same or a similar issue: a query syntax and defined semantics
("for the overall protocol").

-Peter

---

From: Dave Piscitello <[email-masked]>
Date: Thu, 9 Feb 2012 08:56:31 -0800

John,

No one interested in the name registry world can deny that the path to a successful supplanting of the current protocol is short or guaranteed, and we are all familiar with the failed attempts. There are folks who probably won't concede defeat and while we can accept the skepticism, throwing us occasional support would be welcome.

To offer you reasons to do so, I'd point you to the external WHOIS review team report and recommendations, page 92:

"• ICANN Community should task a working group within 6 months of publication to finalize (i) encoding, (ii) modifications to data model, and (iii) internationalized services, to give global access to gather, store and make available internationalized registration data. Such working group should report no later than one year from formation, using existing IDN encoding. The working group should aim for consistency of approach across the gTLD and – on a voluntary basis – the ccTLD space."

Part of this recommendation is currently being considered by ICANN's SSAC, where we have ongoing work enacting from our publication SAC051, www.icann.org/en/committees/security/sac051.pdf which recommends that:

"• Recommendation 2: The ICANN community should evaluate and adopt a replacement domain name registration data access protocol that supports the query and display of Internationalized DNRD as well as addressing the relevant recommendations in SAC 003, SAC 027 and SAC 033.

Recommendation 3: The ICANN community should develop a uniform and standard framework for accessing DNRD that would provide mechanisms to define and implement a range of verification methods, credential services, and access control capabilities."

Specifically, SSAC is studying a data profile. We have been considering the EPP data, escrow data, data registrars are obliged to collect as per the registrar accreditation agreement. While entirely speculative on my part, I can easily envision having a data profile available for IETF consideration in the next 6-9 months, especially if WEIRDS and SSAC can work cooperatively and in parallel.

If there are other specific activities that we need to proffer to earn more positive consideration, please ask.

We all know the name resource community is larger and different from the RIR and we know that there is nothing agile about its process. It's also true that early negatives are very hard to overcome. I'm not asking for a leap of faith but I think we'd have more success if WEIRDs could be more supportive.

---

From: SM <[email-masked]>
Date: Thu, 09 Feb 2012 09:00:53 -0800

Hi Bill,
At 08:30 AM 2/9/2012, Smith, Bill wrote:
>Respectfully, Internet history is full of "failed attempts"; 
>thankfully. When something fails, yet a need exists, people step in 
>and try again. I've listed four list "name" participants that I 
>believe are likely to participate in prototype development. That 
>number exceeds the current number of "number" prototypes and is a 
>strong argument that development interest exists. Additionally, as a 
>consumer of WHOIS and potential consumer of WEIRDS, PayPal has a 
>strong interest in names.

There are five number resource registries.  All of them have 
expressed interest in the work.  I don't think that comparing the 
numbers from numbers and names provides an accurate picture.

There is strong interest on the consumer side in the data from name 
registries.  We could call it a need.  The lack of fulfillment of 
that need could be explained by the data production side not having 
the same interests as those with the need.

>  Will this effort be any different then prior "failed attempts"? If 
> we, this WG,  don't make the effort, the answer is guaranteed. If 
> we make the effort, the Internet community will decide. I'm for the 
> letting the community make the decision.

I am not disagreeing with you.  The current scope is more about work 
that can be done easily.  By putting name and numbers together, the 
attempt comes out as solving the "whois" problem.  It takes more than 
an IETF working group to solve such a problem.  If the problem is 
tackled in two steps, it is easier to focus the work if there are distractions.

Regards,
-sm

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2012 17:06:13 -0000

>("for the overall protocol").

I don't feel all that strongly, but I don't see any harm in leaving it
explicit.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Feb 2012 12:19:53 -0500

> more interest from the naming side.

Look, I want the names stuff as much as anybody.  But the above is
actually just another argument in favour of the current proposed text,
which is designed precisely to make it easy to add names to the
milestones when there is evidence of people having time and energy for
that problem.  I don't get why that's not the right way to approach
things.

The bitter irony, to me, is that in ICANN circles one hears this
argument _all the time_: "I shouldn't have to wait to implement the
thing I'm ready to do just because someone else isn't ready."
(Indeed, the ALAC made exactly this argument recently on a different
topic.)  Why is this case any different?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 09:26:01 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andy Newton
> Sent: Thursday, February 09, 2012 6:04 AM
> To: Andrew Sullivan
> Cc: <[email-masked]>
> Subject: Re: [weirds] New new proposed charter text
> 

I think it's always been in scope (at least, I hope whatever we produce will enable it), but I would also agree that it doesn't need to be explicit in the charter.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 09:34:23 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Thursday, February 09, 2012 9:01 AM
> To: Smith, Bill
> Cc: [email-masked]
> There are five number resource registries.  All of them have expressed
> interest in the work.  I don't think that comparing the numbers from
> numbers and names provides an accurate picture.

I have to agree.  In terms of "guaranteed" implementation percentages, we appear to have almost complete coverage in number space, but for names the actual count is encouraging but the percentage is substantially smaller.

But it is also worth considering the size of some of the names.  If we think about it in terms of what percentage of overall name queries would be answered by the volunteers that have stepped forward here from the name registry space, it's a lot more encouraging.

And in any case, I want both sets of work to go forward.  If getting there via tackling the numbers problem first is the path the IETF will let it happen, then fine... let's get started.

> registries.  We could call it a need.  The lack of fulfillment of that
> need could be explained by the data production side not having the same
> interests as those with the need.

+1.

-MSK

---

From: "Michael Young" <[email-masked]>
Date: Thu, 9 Feb 2012 12:50:05 -0500

It's probably important to note that if a truly useable protocol (I make
this distinction due IRIS) comes out of this work for name registries, ICANN
will likely add required compliance to those RFCs to its next iteration of
registry operator agreements (contracts).  While that is a speculative
claim, I think there's enough history to indicate its quite likely. Dave P.
may want to comment on that,.........

I prefer Bill's version of the charter, but I see Andrew's points on
participation and believe they are well founded in fact.  Given that, I
think getting the work rolling is the priority. 

BTW I will do an independent name registry implementation as well.

Michael Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Murray S. Kucherawy
Sent: February-09-12 12:34 PM
To: [email-masked]
Subject: Re: [weirds] New new proposed charter text

> numbers and names provides an accurate picture.

I have to agree.  In terms of "guaranteed" implementation percentages, we
appear to have almost complete coverage in number space, but for names the
actual count is encouraging but the percentage is substantially smaller.

But it is also worth considering the size of some of the names.  If we think
about it in terms of what percentage of overall name queries would be
answered by the volunteers that have stepped forward here from the name
registry space, it's a lot more encouraging.

And in any case, I want both sets of work to go forward.  If getting there
via tackling the numbers problem first is the path the IETF will let it
happen, then fine... let's get started.

> need could be explained by the data production side not having the 
> same interests as those with the need.

+1.

-MSK

---

From: Dave Piscitello <[email-masked]>
Date: Thu, 9 Feb 2012 10:08:27 -0800

In the interest of finding a way forward, and trying to consider as much of what's been discussed in several threads (to my best ability), please consider these changes to most recent draft. My objective here is to 

(i) acknowledge that number registry data profile work takes precedence over name because 
RIRs merit this consideration for the work they have contributed

(ii) reflect that a single data framework is desired and that name resource stakeholder 
interests ought to be taken into consideration during the definition of the "standard
single data framework".

(iii) reflect name resource interest but also put the burden of developing the data
profile for name resources. To this effect, I've added a milestone that I believe the
ICANN community can achieve given that the SSAC is already engaged in 
studying and providing a prototype domain lifecycle registration data model
for consideration of the ICANN community.

Thanks for your time and consideration,

1) TO 

"An important difference is
   that number resource registries do not have the sort of
   competitive retail market that is common to many domain name
   registries."

ADD

"Number resource registries are also fewer in number than name registries. This may influence the time to achieve consensus on name registry database considerations."

2) CHANGE

"Providing a
   standards-base solution that scales well could minimize further
   proliferation of ad hoc solutions."

TO

"Providing a standards-base solution (common convention) for internationalization for number and name registries  that scales well could minimize further
   proliferation of ad hoc solutions."

3) TO

"WHOIS also has no data model: replies are basically just free-form
   text."

ADD

"Response (and error) composition is left to the discretion of the service provider." 

4) CHANGE

"The
   existing experience with number resource registries, and their
   differences with name registries, suggests that starting work with
   number resource registries may yield quick results.  "

TO

"The
   existing experience with number resource registries, and their
   differences with name registries, suggests that starting work with
   framework and protocol considerations that are common to 
   both number and name resource registries (so that, to the extent
   possible, commonality is achieved) and attending quickly thereafter
   to number specific considerations may yield quick results.
   Experimentation by (or on behalf of) name registries will dictate
   how quickly name specific considerations are incorporated into
   the WG's program of work."

5)  CHANGE

"The Working Group will
   need to determine whether language or character set (or both) is
   an appropriate selector. "

TO

"The Working Group will
   need to determine what selector or selectors ( e.g., character set, language-script, language-country)
   are necessary."

6) CHANGE

"2.  A rigorous machine-friendly data model, both for the overall
   protocol and for any data profiles the Working Group delivers."

TO

" 2.  A rigorous machine-friendly data model, both for the overall
   protocol and for any number or name resource data profiles the Working Group delivers."

7) CHANGE

" 3.  Support for differential service levels, including bulk
   access, according to different classes of user."

TO

" 3.  Support for differential service levels according to different classes of user."

8) CHANGE

"The working group shall also develop a data profile (or object
   format) using the above framework.  The data profile shall provide
   the necessary support for operation of number registries."

TO

"The working group shall initially develop a data profile (or object
   format) using the above framework.  The initial data profile shall provide
   the necessary support for operation of number registries. A separate
   data profile shall be developed by (or on behalf of) name registries in parallel
   with or subsequent to the number resource profile. 

9) DELETE

"The working group may, but need not, develop a data profile (or
   object format) to provide the support for name registries to use
   the protocol.  "

10) CHANGE

"The initial work list for the working group shall
   the work.  "

TO

"The initial work list for the working group shall
   not preclude work on name registry support. 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."

11) CHANGE

"Discussion of issues, within the Working Group,
   relating to name registry support is explicitly permitted; but
   actual work on that topic is declared out of scope at the
   beginning of work."

TO

"Discussion of issues, within the Working Group,
   relating to name registry support is explicitly permitted and encouraged."

12) DELETE

"It is expected that the Working Group would
   change this provision in its charter when and if the Working Group
   were prepared to adopt any document related to name registry
   support."

13) ADD

September 2013 Draft WEIRDS object specifications for name
   resource registries to IESG for publication on the standards
   track.

---

From: SM <[email-masked]>
Date: Thu, 09 Feb 2012 15:18:55 -0800

Hi Dave,
At 10:08 AM 2/9/2012, Dave Piscitello wrote:
>"Number resource registries are also fewer in number than name 
>registries. This may influence the time to achieve consensus on name 
>registry database considerations."

I don't see what this has to do with the work.  We could look at this 
differently, i.e. by adding name registries, it will take longer for 
a future working group to achieve consensus.  This would be a 
disingenuous argument if we look at it from an IETF perspective.

>    resource registries to IESG for publication on the standards

Why is it important that a future working group takes on this work 
item in the initial charter?

Regards,
-sm

---

From: Dave Piscitello <[email-masked]>
Date: Thu, 9 Feb 2012 16:16:50 -0800

Hi:-)

> disingenuous argument if we look at it from an IETF perspective.

I was uncertain about adding this, but the original sentence stood out as characterizing number resource registries from name resource registries in a particular way, and I perhaps mistook this to be intended to justify first working on number resources. I added another distinguishing characteristic. I wouldn't' feel strongly against deleting both sentences.

I really don't think in terms of an "IETF perspective". The only perspective thats relevant to me 's whether is that the work benefits the Internet community and IMO having a single common successor to Whois for name and number resources is beneficial in a number of ways.

> item in the initial charter?

My understanding is that the WG would work on a single common protocol and that data profiles for name and number resources would be developed, thus three deliverables.

---

From: SM <[email-masked]>
Date: Thu, 09 Feb 2012 18:28:12 -0800

Hi Dave,
At 04:16 PM 2/9/2012, Dave Piscitello wrote:
>I was uncertain about adding this, but the original sentence stood 
>out as characterizing number resource registries from name resource 
>registries in a particular way, and I perhaps mistook this to be 
>intended to justify first working on number resources. I added 
>another distinguishing characteristic. I wouldn't' feel strongly 
>against deleting both sentences.

I read the wierds-charter-20120209a text again.  As a note to Andrew 
Sullivan, the three ADs mentioned are from the Applications Area and 
not Internet Area Directors.

I suggest striking out the following paragraph:

    "While name and number resource registry databases contain some
     kinds of data in common, there are significant differences between
     them, both in respect what data they contain, and in the operating
     models of the respective communities.  An important difference is
     that number resource registries do not have the sort of
     competitive retail market that is common to many domain name
     registries."

That avoids any characterization.  And making this minor change:

     Some number resource registries have deployed experimental services
     that provide registration information services using a RESTful
     approach to data delivery over the web.  The existing experience
     with number resource registries, and their differences with name
     registries, suggests that starting work with number resource
     registries may yield quick results.

I don't think it is important to stress the differences between the 
two types of registries.  Basically, the above says that the work on 
number resource registries can be completed somewhat quickly.  There 
is some text in the last paragraph to support name registries if it 
does not affect the initial work.

>I really don't think in terms of an "IETF perspective". The only 
>perspective thats relevant to me 's whether is that the work 
>benefits the Internet community and IMO having a single common 
>successor to Whois for name and number resources is beneficial in a 
>number of ways.

A charter is sometimes written from an "IETF perspective" to get the 
work done.  The perspective mentioned above is laudable but it lacks 
the inducements for a working group to be productive.

>My understanding is that the WG would work on a single common 
>protocol and that data profiles for name and number resources would 
>be developed, thus three deliverables.

With the RESTful approach you end up with a protocol which can be 
used for name and number resources.  There are some number resource 
registry specifics which could go in as extensions.  There are 
actually three deliverables at the moment.  With the change you 
suggested, that takes it to four.  Depending on what goes in the 
requirements document, additional deliverables might be needed.

Regards,
-sm

---

From: Arturo Servin <[email-masked]>
Date: Fri, 10 Feb 2012 00:42:45 -0200

Although I would prefer to only include number registries work compatible with name registries in the initial charter, in order to reach agreement I am not ok if we include name registries work in the initial charter.

	I am happy with the last charter version sent by Andy but I concede that some of Dave's changes would make the charter to have more possibilities to reach consensus and to break the deadlock in which I think we are. I have some comments and I do not fully agree with all the suggestions.

	My comments are trying to address my concern that name registry work could slow the work on numbers (which it is a concern but not a big one), but more important my concern that the IESG may think that we are very ambitious and destined to fail (altogether with the work that we have already done in number registries).

> "Number resource registries are also fewer in number than name registries. This may influence the time to achieve consensus on name registry database considerations."
agree

>   proliferation of ad hoc solutions."
Agree

> "Response (and error) composition is left to the discretion of the service provider." 
Agree

>   the WG's program of work."
Not very convinced.

"The existing experience with number resource registries, and their
  differences with name registries, suggests that starting work with
  framework and protocol considerations that are common to 
  both number and name resource registries but based in the practical experience of the former
 may yield quick results.
  Experimentation by (or on behalf of) name registries will dictate
  how quickly name specific considerations are incorporated into
  the WG's program of work."

Or just leave the original paragraph with the addition regarding the experimentation on name-registries

>   need to determine what selector or selectors ( e.g., character set, language-script, language-country)
either option is ok to me.

>   protocol and for any number or name resource data profiles the Working Group delivers."
Honestly I like the original one more, I do not see the need to add number and name.

> " 3.  Support for differential service levels according to different classes of user."
Agree

>   with or subsequent to the number resource profile. 
I do not know if we need to enforce a second data profile for name registries now. I would be happier with a "may".

"… number registries. If required, a separate
  data profile may be developed by (or on behalf of) name registries in parallel
  with or subsequent to the number resource profile. "

>   object format) to provide the support for name registries to use
Well, I think 8 takes care of this for me.

>   potential re-use by name registries will be a guiding principle of
I prefer the original one under the assumption that there will be specific needs for name registries that may add complexity to number registries implementations. But I think that including name registries work explicitly is important for reach consensus:

In either case I would propose:

  the work. However development of the
  to name registries. "

>   relating to name registry support is explicitly permitted and encouraged."
I would remove both. I think that we changes already proposed above is not need to explicitly permit or forbid work.

>   resource registries to IESG for publication on the standards
I think it is ambitious and I would prefer to add it after some prototyping by some name registries but I am ok if it is really important for name registry people.

Regards,
/as

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2012 04:49:32 -0000

>charter as it is unrelated to the protocol a future working group 

I'd like to keep it in mind even if it's not a deliverable.  It might
well turn out that the schema for bulk access is that same as or close
to the schema for individual queries.  For that matter, since web
servers are quite capable of delivering large gzipped responses, I
wouldn't want to rule out the possibility of making bulk access a kind
of query that returns a big compressed JSON or XML answer.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2012 04:51:56 -0000

>And in any case, I want both sets of work to go forward.  If getting
>there via tackling the numbers problem first is the path the IETF will
>let it happen, then fine... let's get started.

It might also be useful to have a show of virtual hands for who
expects to do what work in what timeframe.

I'm happy to work on the number spec now, and the name spec after the
number stuff has been shaken out.  I would be extremely eager to do
client implementations of number lookups so abuse.net can start providing
useful answers for questions about IP addresses.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 20:57:22 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Arturo Servin
> Sent: Thursday, February 09, 2012 6:43 PM
> To: Dave Piscitello; Andrew Sullivan
> Cc: [email-masked]
> 	Although I would prefer to only include number registries work
> compatible with name registries in the initial charter, in order to
> reach agreement I am not ok if we include name registries work in the
> initial charter.

Given what happened in Taipei, I have to agree that the names-after-numbers approach is the right path for us.

I don't understand what the objection is here.  What is this insistence that names absolutely have to be done in the first charter?  Since we have number registry prototypes already, it should be relatively short work to document them, and then we can move on to the more challenging topic of names.  Even if names were in the charter, it seems like that's the course we would follow anyway.

It also seems to me by making the first charter a smashing success, we'll have the support and momentum to tackle the second one.

-MSK

---

From: Dave Piscitello <[email-masked]>
Date: Thu, 9 Feb 2012 21:36:25 -0800

> Given what happened in Taipei, I have to agree that the names-after-numbers approach is the right path for us.

And I don't think my changes say otherwise. For the most part, I would like the charter to encourage and incline name resource participants to engage early in the process. I also think that if we want something that works for all, we are better off with more parties than fewer. Lastly, and I did not think to mention this before, there are some individuals who have worked with internationalized registration data as well as IDN in the ICANN community who would be valuable additions to this working group. So if, as the charter says, we need folks who have expertise in languages, scripts, and charsets, it would be "nice" to give those folks some indication that they could work to meet both name and number resource needs.

> I don't understand what the objection is here.  What is this insistence that names absolutely have to be done in the first charter?  Since we have number registry prototypes already, it should be r…

What is the purpose of two charters that divide work arbitrarily when at least one of the stated objectives is to have a common framework? I really find the insistence that what happened in Taipei must define what happens subsequent strange. Many of us weren't in Taipei. And since Taipei we've had more opportunities to socialize the work. In 3 months, we'd had had more. 

> It also seems to me by making the first charter a smashing success, we'll have the support and momentum to tackle the second one.

I don't foliow the logic that concludes that adding name resources to the charter puts the working group in jeopardy of abject failure. And while I'm tired and may sound contrary, I'm trying to understand why a Bof and mailing list that was initiated by number *and* name resource participants - surely an indication of interest from both communities - is focused on which goes first rather than how do we best solve the common problem.

I'm off to bed. I appreciate everyone's patience and hope things look brighter tomorrow.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 22:00:40 -0800

> From: Dave Piscitello [mailto:[email-masked]]
> Sent: Thursday, February 09, 2012 9:36 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> What is the purpose of two charters that divide work arbitrarily when
> at least one of the stated objectives is to have a common framework? I
> really find the insistence that what happened in Taipei must define
> what happens subsequent strange. Many of us weren't in Taipei. And
> since Taipei we've had more opportunities to socialize the work. In 3
> months, we'd had had more.

What happened in Taipei was resounding resistance to doing both names and numbers work, and some resistance to doing this work at all.  I think what we have in the proposed charter Andrew did is a compromise between that fairly firm position and the feelings of the community to which you're referring.

A question that often comes up in IETF standards work is "If we build this, who will come?"  The feeling in the room was answered obviously for the number registries since a few of them showed up and presented their prototypes.  The feeling in the room was that name registries would be a far harder sell, for both technical and political reasons.  The expression "hot potato" may only begin to capture the sentiment.

I am certainly encouraged by the volunteering of name resource people to participate in the work.  I don't mean to suggest that isn't a valuable show of support.  But they, and we, are not the only ones with a say in this matter.

If numbers-first-names-second is a workable compromise against the resistance I just described, I suggest we take it.

> I don't foliow the logic that concludes that adding name resources to
> the charter puts the working group in jeopardy of abject failure.

CRISP is the evidence.  We tried exactly what you're pushing for before, and it flopped.  We would really, really, like not to do that again.  If that does happen again, it will be a long time, if ever, before the IETF ever touches WHOIS again.  Some risk management is highly appropriate here.

> And while I'm tired and may sound contrary, I'm trying to understand why a
> Bof and mailing list that was initiated by number *and* name resource
> participants - surely an indication of interest from both communities -
> is focused on which goes first rather than how do we best solve the
> common problem.

I don't agree with that premise.  The BoF and list were both initiated by people who were either number resource participants or neutral parties.  (I sent the list request myself.)  I don't recall any name resource people in the room for the informal BoF in Quebec City, or among the pre-list people that were co-operating on the initial set of drafts.  I'm thrilled that they're here now, but that's not where we started.

-MSK

---

From: Arturo Servin <[email-masked]>
Date: Fri, 10 Feb 2012 09:15:50 -0200

Murray,

	I am with you, do not get me wrong. 

	But I want this to move forward, if including name-regitries as some have advocated is  a requirement to break the loop and move forward I am ok with that.

Regards,
.as

---

From: Andy Newton <[email-masked]>
Date: Fri, 10 Feb 2012 13:51:52 +0000

> of query that returns a big compressed JSON or XML answer.

That sounds reasonable to me.

I don't have a problem looking at bulk access, but we shouldn't entangle query-access with the corner cases of bulk access. If the charter were to say that possible future work would be about bulk access once the main goals of the group are achieved, that would be fine by me.

-andy

---

From: Dave Piscitello <[email-masked]>
Date: Fri, 10 Feb 2012 06:37:12 -0800

Silly me. My brain locked onto a different bulk paradigm. Now illuminated I agree this seems reasonable.

Sent from my iPhone

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 Feb 2012 18:29:50 +0100

On 09/Feb/12 16:18, Andy Newton wrote:
>>> And do we really need a separate draft describing the objects
>>> being mapped vs one that does the mapping?
>> 
>> accepting this.

Thank you, Andrew, for taking it into consideration.

> Can I ask that those who think this is a necessary step look at the
> RIR JSON response draft and explain how we are concretely benefited
> by a textual abstraction of that information? And if the benefit is
> the analysis of the different data elements, would a working group
> report by a designee or design team be good enough to drive the
> technical specifications forward?

That kind of analysis is indeed the benefit.  I note that the rir-json
draft often says "The following is an elided example of a JSON
response object [...]".  Often, specifications say instead something
like, say, "JSON responses SHALL be structured according to the
following production rules [...]".  I'm not suggesting the draft
should use the second kind of wording, as that would probably result
in less readable text.

The draft also briefly describes most object members.  Those
descriptions don't really help understanding JSON formats.  If they
were in a separate paper, a sort of glossary, it would be easier to
explain each term in more detail --where needed-- without hampering
the description of protocol responses.  The glossary can then be
referenced by rir-json, as well as by any RIR's document willing to
explain in even greater detail the checks and controls that they apply
to a datum.  In essence, this is what I suggest.  Do you think your
draft would improve by splitting those descriptions off?

A separate glossary can be reused for many different protocols,
including bulk transfer or an explanation of the existing WHOIS.

---

From: Andy Newton <[email-masked]>
Date: Fri, 10 Feb 2012 18:42:49 +0000

> draft would improve by splitting those descriptions off?

No, not to any great benefit. Or to put in another way, I do not think it will do much to enhance the understanding of the data being conveyed. I think most implementers will ignore a separate glossary style document. If there are any data elements in the draft that need further explanation as to what they mean, then we should enhance the text around them. Many of the elements can be linked to other RFCs.

> including bulk transfer or an explanation of the existing WHOIS.

Of they can simply refer to this draft or RFCs this draft references.

-andy

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2012 20:36:56 -0000

> But I want this to move forward, if including name-regitries as some have
> have advocated is a requirement to break the loop and move forward I
> am ok with that.

I still haven't seen any reason to change Andrew's draft charter,
which says that we work on son-of-WHOIS for numbers now, keeping in
mind that the more of the design that can be resused for names, the
better.  This does not in any way preclude chartering a future WG to
work on names, or for people to work on, say, a data model for names
in parallel, perhaps checking in from time to time to let us know if
there are design issues that might affect reusability.

Most of the objections can be summarized as "Names are very important!
You have to work on names right now!"  The first sentence may well be
true, but that is, shall we say, not actionable.

With only one exception (thanks, Centralnic!) I haven't seen anyone
who's said that they're prepared to do any of the name work in the
timeframe we're talking about, and I also haven't seen any reason to
doubt our belief that we're more likely to succeed if we address the
numbers first.

So it's time to declare that we're done with the charter and get to work.

R's,
John

---

From: Dave Piscitello <[email-masked]>
Date: Fri, 10 Feb 2012 13:27:49 -0800

> I still haven't seen any reason to change Andrew's draft charter,

since some of us feel we have offered reasons and these apparently are not the sorts of reasons - expressions of interest (several), willingness to work on charter, drafts (Afilias) commitment to continue experimentation (ICANN) or begin (CentralNIC) - and you steadfastly claim these are not compelling, perhaps you can give us the toll and we can try to meet it.

> true, but that is, shall we say, not actionable.

I do not believe this is the case at all. I've  made an erstwhile effort to make clear that it's in the best interest of all to work together on the protocol. I think working with some parallelism rather than single-threading (number then name)  would be beneficial, especially with regard to coming to common terms with internationalized registration data issues. It's disappointing that you characterize my and other efforts this way. 

If the majority of others on the list feel John's is a correct characterization then I'll fold my hand and spend time working on the data model since I, too, want to get to work.
 
> doubt our belief that we're more likely to succeed if we address the

Also not true. ICANN the company is continuing its work and will do so as part of its obligations to the ICANN community. Afilias has indicated they'd work on drafts. I've mentioned several times that ICANN's SSAC is working on the domain data profile. 

I fully understand you and I represent opposing views here. I've made an effort to find a way forward. Please tell me what else you expect, whether you have no intention of conceding ground on this matter, and whether yours is the prevailing sentiment. 

> So it's time to declare that we're done with the charter and get to work.

We agree.

---

From: "Smith, Bill" <[email-masked]>
Date: Fri, 10 Feb 2012 21:42:02 +0000

On Feb 10, 2012, at 12:36 PM, John Levine wrote:

Reason to change Andrew's draft: It does not adequately address the issues of
interested parties (see RFC 2148). There is a demonstrated interest in a specification
that supports both numbers and names, as is current practice with RFC 3912.

PayPal has not expressed an implementation interest (others have) but we
have expressed a consumer interest (see RFC 2148) and we believe that many
other consumers desire a unified approach to numbers and names.

With respect, that's not what I'm hearing. I proposed modifications to Andrew's
charter that reflect the first part of your statement; "names are important". I believe
they should be considered as first-class citizens. My draft also makes it clear that
names can (and will) be worked on later, not "right now". Numbers are "right
now".

I believe several have expressed interest in number work and that they are
prepared to contribute according to reasonable timeframes, certainly
within those as mentioned in my draft.

Let me express doubt that a WG chartered as per Andrew's draft will
succeed in developing a specification that can accommodate requirements
of names. From the charter "The initial work list for the working group shall
 not include work on name registry support, and development of the
 number registry support will not be constrained by needs peculiar
 to name registries."

While there is other language in the proposed charter that indicates names may
be considered, the above statement clearly and directly gives WG members,
the chair, and Area Directors the ability to shut down debate related to
names.

---

From: Dave Piscitello <[email-masked]>
Date: Fri, 10 Feb 2012 14:35:14 -0800

Thanks for the thoughtful response, see below.

On Feb 10, 2012, at 1:00 AM, Murray S. Kucherawy wrote:

>> at least one of the stated objectives is to have a common framework?

Can you comment on this question?

>> What happened in Taipei was resounding resistance to doing both names and numbers work, 
> A question that often comes up in IETF standards work is "If we build this, who will come?"  

I appreciate the recap. Children live with the shame of their fathers' sins, I get it. I live it daily.

> If numbers-first-names-second is a workable compromise against the resistance I just described, I suggest we take it.

Let me ask whether you think the charter as written accommodates the following or whether these specific requests could be accommodated:

1) Consideration for selectors appropriate for internationalized registration data will accommodate both number and name resource needs. Specifically, the charter will assure that we won't have to re-visit this issue and that we won't have two.

2) Should a data profile for name resources be prepared and submitted in the same time frame as a number resource data profile, it won't be set aside while/until the number data profile is considered.

3) Should a data profile be prepared, the WG would add it to the set of deliverables.

What I honestly fear from all the pushback is that the name resources efforts will meet persistent resistance, perhaps not from you or others who are interested in the broader end game, but from others. I'd rather you tell me now that I'm tilting windmills than go through again what I experienced with IPng...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Feb 2012 15:42:26 -0800

> Sent: Friday, February 10, 2012 2:35 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

I did, in the message to which you just replied.  I said:

"What happened in Taipei was resounding resistance to doing both names and numbers work, and some resistance to doing this work at all.  I think what we have in the proposed charter Andrew did is a compromise between that fairly firm position and the feelings of the community to which you're referring."

That's the purpose of the division.  I do not agree that it is arbitrary; I believe it is an appropriate choice.

> Let me ask whether you think the charter as written accommodates the
> following or whether these specific requests could be accommodated:
> 
> 1) Consideration for selectors appropriate for internationalized
> registration data will accommodate both number and name resource needs.
> Specifically, the charter will assure that we won't have to re-visit
> this issue and that we won't have two.

In my view, the 20120209a charter does all of that except for "assure".

If indeed all of the name proponents do come to the table early on in this working group and stay there, the assurance comes from their presence and persistence, and not from the charter.  I think that's as good, or possibly even better.

> 2) Should a data profile for name resources be prepared and submitted
> in the same time frame as a number resource data profile, it won't be
> set aside while/until the number data profile is considered.

The charter does not require it to be set aside, nor do I think the 20120209a charter text could be effectively wielded as a tool to force that work to slow down or stop unless one could demonstrate that it is interfering with the numbers work.  So again, if cautious but deliberate momentum from name proponents is there, I suspect the work will stick.

> 3) Should a data profile be prepared, the WG would add it to the set of

That would require a re-chartering.  I'm told that's typically a lightweight process.  I don't know that it would be so lightweight in this case given the history, but if the working group very clearly has the momentum to add it without detriment to its existing deliverables, I can't imagine there would be any legitimate resistance.

It might be good if our sponsoring AD commented at this point.

> What I honestly fear from all the pushback is that the name resources
> efforts will meet persistent resistance, perhaps not from you or others
> who are interested in the broader end game, but from others. I'd rather
> you tell me now that I'm tilting windmills than go through again what I
> experienced with IPng...

I can only give you my own assurances based on my intent and experience.  I can't predict what others will do.

-MSK

---

From: Dave Piscitello <[email-masked]>
Date: Fri, 10 Feb 2012 18:14:42 -0800

Again, thanks for your clarifications, personal assurances, and candor.

I'll wait to hear from the AD regarding re-chartering.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 11 Feb 2012 11:22:10 +0100

On 10/Feb/12 19:42, Andy Newton wrote:
>> If [semantic descriptions] were in a separate paper, a sort of
>> glossary, it would be easier to explain each term in more detail
>> --where needed-- without hampering the description of protocol
>> responses.  [...] Do you think your draft would improve by
>> splitting those descriptions off?
> 
> No, not to any great benefit.

Well, neutral may still be acceptable, hopefully.  If writing your
spec got negatively affected by the need to produce a separate data
dictionary, then the latter would have to be dropped.

> Or to put in another way, I do not think it will do much to enhance
> the understanding of the data being conveyed. I think most
> implementers will ignore a separate glossary style document.

If I may paraphrase John Levine, from rir-json I don't get whether
[startAddress, endAddress] is the smallest surrounding allocation,
rather than all of the enclosing allocations.  In addition, I suspect
that the meaning of those registries' data is so obvious to you that
you almost consider those terms part of everyday English.  I think the
glossary will mostly be useful to implementers of non-weirds specs
that need to use weirds clients for their own purposes.

> If there are any data elements in the draft that need further 
> explanation as to what they mean, then we should enhance the text 
> around them.

If they get too large, you'd have to relegate them in their own
sections, so that non-interested readers can skip them easily.

> Of they can simply refer to this draft or RFCs this draft references.

Hm...  Why doesn't rir-json refer to the data described in RFC 4698?

---

From: Peter Koch <[email-masked]>
Date: Sat, 11 Feb 2012 15:02:34 +0100

On Fri, Feb 10, 2012 at 01:51:52PM +0000, Andy Newton wrote:

> If the charter were to say that possible future work would be about bulk access once the main goals of the group are achieved, that would be fine by me.

+1;

"bulk" is a significantly different beast under technical/operational and policy aspects and
that would apply independently to names and numbers.

-Peter

---

From: Jim Galvin <[email-masked]>
Date: Sun, 12 Feb 2012 17:46:21 -0500

Thank you Andrew, for this revised charter.  I have three suggestions 
to offer.

First, let me say "+1" to everything Dave Piscitello is saying.  I 
could send one for every message but I think that would unnecessarily 
clutter this list.

Second, I tend not to be long-winded on IETF lists, neither in length 
nor number of messages.  I can only hope that won't be especially 
problematic.

Finally, my suggestions are below.

-- On February 9, 2012 8:41:25 AM -0500 Andrew Sullivan 
<[email-masked]> wrote regarding [weirds] New new proposed 
charter text --

> Colleagues, the attached is a proposal -- not, note, a “decision”
> -- for a WG charter.  Those who do not like this proposal are welcome

In the spirit of getting to the point, here are my suggestions.

1.  In the following sentence:

    The
    overall effort will be broadly aligned with the Cross Registry
    Internet Service Protocol (CRISP) Requirements (RFC 3707), but
    with the explicit additional goal of producing a simple,
    easy-to-implement protocol that is to be deployed via REST, and
    without the requirement that name registries be accommodated.

Can the final phrase "without the requirement that name registries be 
accommodated" be dropped?

I believe there is plenty of text to give priority to number 
registries, and I completely agree to that principle, e.g., see my 
third suggestion below.  However, this final phrase seems unnecessarily 
pejorative to me.

In various ways the comment has been made that we should not repeat 
history.  I believe it is safe to say that we are all now on notice not 
to do so.  The set of people in this effort are not the same set of 
people who were in the historical effort.  I think it's at least an 
overstatement to hold us all accountable for the events of history, 
although I agree it is absolutely necessary to remind us of history 
lest we repeat it.  Can we move on now?

2. In the following two sentences:

    The initial work list for the working group shall
    the work.

In the spirit of at least leaving the door ajar for us to work 
together, could this be "softened" just a bit by removing the following 
phrase in the first sentence:

    not include work on name registry support, and the development
    of the number registry support will

The result would be that the first sentence reads as follows:

    The initial work list for the working group shall not be
    constrained by needs peculiar to name registries.

I submit that this achieves the desired goal and, as above, eliminates 
a duplicative phrase that is unnecessarily pejorative.

3. In the following sentence:

    Discussion of issues, within the Working Group,
    relating to name registry support is explicitly permitted; but
    actual work on that topic is declared out of scope at the
    beginning of work.

Could the final phrase "at the beginning of work" be changed to the 
following:

    if it unreasonably constrains or delays the progress of work
    in support of the number registries.

I submit that this phrase is more forceful than the current one and 
ensures a consistent operating principle throughout the life of the 
working group as opposed to just at the beginning.

Thanks,

Jim

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 13 Feb 2012 16:21:54 +1000

> Hm...  Why doesn't rir-json refer to the data described in RFC 4698?

I'm not sure how useful the areg addressRangeType is …

<complexType name="addressRangeType">
  <sequence>
    <element name="start" type="token" />
    <element name="end" type="token" minOccurs="0" maxOccurs="1" />
  </sequence>
</complexType>

… given it doesn't specify the start or end in any greater detail than the rir-json-00 draft :-)

I prefer to get feedback on what is not clear in the rir-json draft and clarify it there, and create a separate document if there becomes an obvious need for it.  For most data types, I would expect to be referring to other RFCs for syntax, such as for email address, FQDN, or textual representation of an IP address.

For what it's worth, start address is the first address in a block, and end address is the last address in a block.

  Byron

---

From: Andy Newton <[email-masked]>
Date: Mon, 13 Feb 2012 14:06:04 -0500

> I prefer to get feedback on what is not clear in the rir-json draft and clarify it there, and create a separate document if there becomes an obvious need for it.  For most data types, I would expec…

I agree with Byron. 4698 doesn't do a better job with these elements... 
and that's coming from a person who has their name on 4698.

-andy

---

From: Avri Doria <[email-masked]>
Date: Tue, 14 Feb 2012 07:33:09 +0100

But if the work is declared out of scope or not included in milestones, then whatever is done will be done separately from the WG and would probably end up with a different solution.  And given the whois service needs for name registries, I think the work will be done. So we end up with yet another bad solution - a solution that requires multiple applications

It strikes me reading this whole debate that doing something only for, or even primarily for numbers as opposed to both numbers and names is likely to result in yet another useless effort in the long run. 

I still read the proposed charter, even with James's softeners, as telling the names registry people to go away.  Which I expect will result in the self fulfilling prophesy some people may be shooting for.

I certainly hope that a charter that does not put the work of the two requirements on a par is rejected by the IESG.

If there is a BOF in Paris, I will try to attend remotely.  I will also contribute to an effort intended for names registries, wherever it might be done.

avri

On 9 Feb 2012, at 06:31, John R. Levine wrote:

> Indeed.  Remember, the IETF is all volunteers.  If you think it's important, don't tell other people what to do, do the work.
> 
> I don't think that a separate WHOIS for names would be a good idea either, but doing names first, or even at the same time, ain't gonna happen unless the people who claim it's important do the work.
> 
> R's,
> John

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2012 06:53:35 -0000

>on a par is rejected by the IESG.

The IETF is an entirely volunteer organization.  Which parts of the
extra work for names that you propose are you planning to work on?

Also, as I presume you're aware, a group called CRISP tried to do a
complete name and numbers WHOIS replacement like you're suggesting,
and it completely failed.  Do you think that doing the same thing
again would have a different result?  If so, why?

R's,
John

PS: This question is directed at everyone who wants to do the whole
thing at once, not just at Avri.

---

From: Avri Doria <[email-masked]>
Date: Tue, 14 Feb 2012 08:32:27 +0100

Dear John,

I understand the nature of the pure 'volunteer' nature of the IETF work very well.  It comes in at least 2 flavors, the pure volunteer work that is funded by corporate interests and the pure volunteer work that is self funded by the volunteers.

As a volunteer of the second flavor, I intend to work on the model for names (or the common model if there is such) and will at least comment on grammars.  I have been working toward the requirements for  a names model in the ICANN (or is this an organization "not to be named' in polite IETF company?) context and was happy to see that there was a possibility that the model work which is starting up now, though I am not yet involved, was moving to the IETF, a context I am comfortable with after many years - though I admit not in the applications area.

As for why the future won't end up like the past.  Can't say.  I guess it has a lot to do with how people work together and whether there is animus between groups of participants.  I think the current charter, in most of its versions initiates the process in a negative way and thus should be avoided.  As I was not part of Crisp and have not gone back to study its archives, I really cant give more of an analysis that that.

avri

---

From: Andy Newton <[email-masked]>
Date: Tue, 14 Feb 2012 11:07:43 +0000

> again would have a different result?  If so, why?

As an observation from having been through CRISP and now this, it does seem an apples to oranges comparison. CRISP spent a good amount of time working on a requirements document. After they were done with that, they spent a good amount of time deciding between an LDAP approach and a BEEP/XML approach (only later to jettison BEEP). And, as I recall, it did names first then numbers. The set of participants were also entirely made up of registry operators and no active end users.

Draw your own conclusions.

-andy

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Tue, 14 Feb 2012 09:40:51 -0200

I don't think we are telling anyone to go away. I see this as breaking 
down a problem into more tractable parts.

It has repeatedly been pointed out in this list that the 
"go-for-it-all-at-once" approach has been tried before and that it 
failed miserably, so wisdom would appear to dictate that maybe breaking 
down the problem into smaller chunks can be (nothing is for sure in this 
world) a better way forward.

Although I work for a number registry, I would be extremely happy to 
work with the name registries, and I encourage them to follow the work 
of the group and create and document their own RESTful WHOIS reference 
implementations. In other words, we need more "running code" as much as 
we need more consensus. No one is a second-class citizen here, but the 
fact here is that we have two related problems we want to solve, and one 
of them is harder than the other.

This is not an unheard-of approach. Some working groups get a charter, 
work on a problem, then re-charter and move on.

regards

Carlos

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Feb 2012 07:46:56 -0500

Dear colleagues,

On Tue, Feb 14, 2012 at 07:33:09AM +0100, Avri Doria wrote:

> be done. So we end up with yet another bad solution - a solution
> that requires multiple applications

One of the things I'm finding troubling about this discussion is the
repeated claim that it is obviously better to have one protocol for
accessing the registration data for number resources and for names,
that we need one application for this, and so on.  As nearly as I can
tell, the only premise in support of that conclusion is that it's the
way things are now: we have whois, therefore we need to "replace
whois", and that means a new system that does everything whois does,
only without all the crummy bits.

One of the things that has come up in response to this effort, however
(both in Québec at the APPSAWG meeting and in the BoF in Taipei) was
the observation that the premise could be wrong.  Maybe the reason
whois sucks, and maybe one reason RWhois and Whois++ and IRIS have all
met with limited success, is that they're trying to be one tool to
access two very different kinds of data, or data used for different
purposes, or both.

While it is true that some of the data in these different types of
repositories are quite similar, even when the data are similar the use
model is quite different.  For instance, while RIRs have contact data,
the operational model is highly centralized; name registries often
have the contact data stored in different repositories, and in any
case it's often obfuscated on purpose.

Given the above, it is entirely possible that there would be so little
in common in a "single protocol" between these two types of repository
that all the real work would be done in the mappings.  In that case,
the protocol would be much more complicated than it would need to be
just for the sake of saying we have one protocol.  This is another
reason to consider working on only half the problem at once: if it
turns out that the number resoure registry support effectively demands
things incompatible with name registries -- even while we are thinking
about the needs of those name registries, and doing so in good faith
-- then that means we do in fact need different systems.  That might
be frustrating, but I often find that the world is not arranged in the
way I wish it were (for instance, I'm none of rich, beautiful, nor
young).  I happen to believe that there's probably more in common
there than this worst-case suggestion implies, but I don't think we
should prejudge this matter.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Michael Young" <[email-masked]>
Date: Tue, 14 Feb 2012 08:07:31 -0500

Hi John,

 I'm confused, maybe I'm missing something but it doesn't seem right to call
out one person's intended effort unless we plan to ask everyone to make
equal declarations - then it's fair game. That said, I think we should do
just that just so we have a clear idea of what work resources are available
to the effort.  This can be provided to the IESG at the same time as the
charter to prop up the declared workflow.

CRISP went sideways IMHO  because it became too academic an exercise and did
not concentrate enough on solving operational pain points.  It costs real
money to transition to new protocols - lots of money - and the return on
investment for IRIS was clearly not high enough to make the entire industry
voluntarily jump to it.  Well that and it wasn't mandated by any type of
authority - another type of pain point. 

The timing is much better now to work on this problem, IDNs alone have
created a significant additional pain point, more TLDs with the NGTLD
program and new numbers with IPv6 increases existing pain points.  If we
write something that considers not just the run-rate operational and
development issues, but ALSO migration issues, I suspect there's enough
overall pain and subsequent return on investment, to get folks to transition
this time.

That said, there are no guarantees,.......

-Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Avri Doria
Sent: February-14-12 2:32 AM
To: [email-masked]
Subject: Re: [weirds] New proposed charter text (was: Another BoF in Paris?)

Dear John,

I understand the nature of the pure 'volunteer' nature of the IETF work very
well.  It comes in at least 2 flavors, the pure volunteer work that is
funded by corporate interests and the pure volunteer work that is self
funded by the volunteers.

As a volunteer of the second flavor, I intend to work on the model for names
(or the common model if there is such) and will at least comment on
grammars.  I have been working toward the requirements for  a names model in
the ICANN (or is this an organization "not to be named' in polite IETF
company?) context and was happy to see that there was a possibility that the
model work which is starting up now, though I am not yet involved, was
moving to the IETF, a context I am comfortable with after many years -
though I admit not in the applications area.

As for why the future won't end up like the past.  Can't say.  I guess it
has a lot to do with how people work together and whether there is animus
between groups of participants.  I think the current charter, in most of its
versions initiates the process in a negative way and thus should be avoided.
As I was not part of Crisp and have not gone back to study its archives, I
really cant give more of an analysis that that.

avri

On 14 Feb 2012, at 07:53, John Levine wrote:

>> I certainly hope that a charter that does not put the work of the two 
>> requirements on a par is rejected by the IESG.
>

---

From: "Michael Young" <[email-masked]>
Date: Tue, 14 Feb 2012 08:13:24 -0500

I was trying to get at this earlier, (but nowhere near as eloquently), to decide this though, I think, would require some analysis of the two use cases to see just how different things are,......

-M

"Given the above, it is entirely possible that there would be so little in common in a "single protocol" between these two types of repository that all the real work would be done in the mappings.  In that case, the protocol would be much more complicated than it would need to be just for the sake of saying we have one protocol.  This is another reason to consider working on only half the problem at once: if it turns out that the number resoure registry support effectively demands things incompatible with name registries -- even while we are thinking about the needs of those name registries, and doing so in good faith
-- then that means we do in fact need different systems.  That might be frustrating, but I often find that the world is not arranged in the way I wish it were (for instance, I'm none of rich, beautiful, nor young).  I happen to believe that there's probably more in common there than this worst-case suggestion implies, but I don't think we should prejudge this matter.

Best regards,

A

--
Andrew Sullivan
[email-masked]"

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 14 Feb 2012 06:53:59 -0800

> extra work for names that you propose are you planning to work on?

You have asked this several times, to several people. I've seen individual commitments but that you ask repeatedly tells me that no one is keeping count or that the count does not meet some criteria.

Perhaps we need a head count? Will that suffice?

Here's a set of check boxes that could shed light on commitments? (My commitments are "X"'d)

[ ] 	I will assist with developing experimental software for RESTful, name resources

[ ] 	I will assist with developing experimental software for RESTful, number resources

[ X]	I will assist with defining data profiles for RESTful, name resources

[ ]	I will assist with defining data profiles for RESTful, number resources

[X ] 	I will participate in mailing list and review of experimental software for RESTful, name resources

[ ] 	I will participate in mailing list and review of experimental software for RESTful, number resources

Do we need "X" for data framework?

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Feb 2012 15:56:52 +0100

>>      <element name="end" type="token" minOccurs="0" maxOccurs="1" />

I'd have quoted:

   The <ipv4Network> and <ipv6Network> share a common definition of
   'ipNetworkType'.  It has the following child elements:

   o  <networkHandle> contains the registry-unique assigned handle for
      this network.

   o  <name> contains a human-friendly name for the network.

   o  <startAddress> contains the first IP address of the network.

   o  <endAddress> contains the last IP address of the network.

to be compared with:

   The following is a description of the members of this object:

   handle  -- a string representing an RIR unique identifier of the
      network registration

   startAddress  -- the starting IP address of the network

   endAddress  -- the ending IP address of the network

>> I prefer to get feedback on what is not clear in the rir-json draft
>> and clarify it there, and create a separate document if there
>> becomes an obvious need for it.  For most data types, I would expect
>> to be referring to other RFCs for syntax, such as for email address,
>> FQDN, or textual representation of an IP address.
> 
> I agree with Byron. 4698 doesn't do a better job with these
> elements... and that's coming from a person who has their name on 4698.

It was rhetorical to ask you to reuse RFC 4698.  However, I wish that
the Nth time you rewrite those definition they /will/ be reusable
ones.  It is fine to clarify them in the rir-json draft and wait until
the need for a separate document becomes obvious.  (Anyway, I neither
have the desire nor the authority to impose anything :-)

I see APNIC publish object templates, which make for a
language-neutral, easy description of the data model.  ARIN's API
reference, by contrast, expands more on the keys, and gives xml
examples of the responses, suggesting they can be expressed equally
well in json or text.  In addition, semantics are extensively expanded
in each RIR's policy manuals.  Anonymity, mandatoriness of attributes,
checks, data origin and maintainer, all deserve being mentioned, don't
they?

IMHO, we should choose the representation that can be compared to each
of the five data models with the minimal effort.  If we succeed, we
can re-propose the same method for name registries.

---

From: "Michael Young" <[email-masked]>
Date: Tue, 14 Feb 2012 10:06:32 -0500

Dave I suggest the following more general, but useful additions, since I am
leery we invent something that is not useable due not understanding the real
world issues around adoption and use.

I will assist by reviewing drafts submitted to the mailing list and offering
corrections on errors or suggestions for improvement.

I will assist by reviewing drafts submitted to the mailing list and offer
comments based on knowledge of use cases and existing (or in development)
policy that affect the use and/or adoption of this protocol.

I will assist by reviewing drafts submitted to the mailing list and offer
comments based on operational experience and expertise.

I will assist by offering a test server and client implementation based on
related IDs  for others to access and experiment with.

Best Regards,

Michael Young
M:+1-647-289-1220

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dave Piscitello
Sent: February-14-12 9:54 AM
To: John Levine
Cc: [email-masked]
Subject: [weirds] Who's committing to what?

> extra work for names that you propose are you planning to work on?

You have asked this several times, to several people. I've seen individual
commitments but that you ask repeatedly tells me that no one is keeping
count or that the count does not meet some criteria.

Here's a set of check boxes that could shed light on commitments? (My
commitments are "X"'d)

[ ] 	I will assist with developing experimental software for RESTful,
name resources

[ ] 	I will assist with developing experimental software for RESTful,
number resources

[ X]	I will assist with defining data profiles for RESTful, name
resources

[ ]	I will assist with defining data profiles for RESTful, number
resources

[X ] 	I will participate in mailing list and review of experimental
software for RESTful, name resources

[ ] 	I will participate in mailing list and review of experimental
software for RESTful, number resources

---

From: Andy Newton <[email-masked]>
Date: Tue, 14 Feb 2012 10:50:58 -0500

On Feb 14, 2012, at 9:56 AM, Alessandro Vesely wrote:

> ones.  

Yes, I suck at trying to explain things *I think* are obvious. I am not disputing that point. :)

> It is fine to clarify them in the rir-json draft and wait until

But you do have the power to provide text you feel makes the specification more readable and understandable. That is likely a greater power.

You offer a reasonable compromise: put it in to rir-json until their is a need for a separate document. That works for me. Thank you.

-andy

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2012 16:26:57 -0000

>equal declarations - then it's fair game.

Yes, of course.  If Avri is offering to do work, that's OK.

I still think it would be an extremely bad idea to try to do a full
WHOIS replacement at once, and I have heard no arguments beyond
"something bad might happen" why it wouldn't be a better idea to
address the more tractable number problem first.

It can't be that it makes any difference whether we look at names now
or a year from now.  If there were an actual hurry, the people who
have been telling us how urgent it is to do a replacement for name
whois would be working on it already.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Feb 2012 11:27:37 -0500

> You offer a reasonable compromise: put it in to rir-json until their is a need for a separate document. That works for me. Thank you.

Warning!  Process wonkery ahead.

Does this mean that the separate milestone in some versions of the
proposed charter could go away?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Feb 2012 09:09:43 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Young
> Sent: Tuesday, February 14, 2012 7:07 AM
> To: 'Dave Piscitello'; 'John Levine'
> Cc: [email-masked]
> Subject: Re: [weirds] Who's committing to what?
> 
> Dave I suggest the following more general, but useful additions, since
> I am leery we invent something that is not useable due not
> understanding the real world issues around adoption and use.

I prefer this set if we're going to actually track commitments.  Dave's set, while a good idea, captures exactly the kind of partitioning of work that the name proponents are trying to prevent.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 14 Feb 2012 18:18:38 +0100

On 14/Feb/12 17:27, Andrew Sullivan wrote:
>> You offer a reasonable compromise: put it in to rir-json until
>> their is a need for a separate document. That works for me. Thank
>> you.
> 

I don't think so.  An I-D is an I-D, whether separated or not.  If the
need to separate it will not have arisen by WGLC time, a mutilated
de-jsonized copy of it can be built trivially, and kept among the WG's
documents as a mascot...  I'll volunteer for that editing, in case.

---

From: Francisco Arias <[email-masked]>
Date: Tue, 14 Feb 2012 09:47:13 -0800

>only without all the crummy bits.

The way I imagine things and it seems is the way the charter is depicting
them is we would have a general base protocol, seemingly agnostic of the
data that is traversing over it. Complemented by data profiles for each
type of registry interested on using the protocol (e.g., number and names).

However, the base protocol may need to define operations/commands (e.g.,
search, lookup) and other general features (e.g., internationalization,
standard errors, referrals) that if designed without taking into
consideration the two type of registries that had expressed interest in
the protocol, we may end up with such a protocol that is unsuitable for
some specific need of one of these type of registries.

That's why I believe it is important to keep in scope the discussion of
both number and name registries while designing the base protocol.

If people believe it would be more difficult the definition of the data
profile for name registries (given there is only a handful or RIRs/NIRs vs
hundreds of name registries) and want to have the numbers data profile
come first I could live with that. But the discussion about the base
protocol has to include both name and number registries.

Regards,

__

Francisco.

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Tue, 14 Feb 2012 16:03:35 -0200

I agree with you Francisco, and again I don't believe anyone here wants 
to kick name registries out. However, it's a fact that the name registry 
problem is more complex both technically and policy-wise, and thus it 
makes sense to focus in the easy problem first (which doesn't mean 
forgetting or kicking out the other crowd)

I think we can produce a good generic API for accessing registries, an 
API which maybe will even find uses outside the WHOIS problem domain. 
The key will be to introduce extensibility everywhere, from the data 
model to the error condition signaling and everything in between.

Looking forward to work with you all,

Carlos

On 2/14/12 3:47 PM, Francisco Arias wrote:
> On 2/14/12 4:46 AM, "Andrew Sullivan"<[email-masked]>  wrote:
>
>

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 14 Feb 2012 10:03:53 -0800

I agree with this statement, 

The de-coupling of the discussion from the base protocol from data representation, should allow us to move quickly into proposals for the latter.

Francisco

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Tue, 14 Feb 2012 16:05:54 -0200

+1

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 14 Feb 2012 10:11:25 -0800

With the Launch of new GTLDs, and the creation of potentially several hundreds of new registries, each one of them will try to implement their own interface, this is due to the fact, that ICANN will award you with an extra point if you provide a searchable interface.

Having a proposed format, in place in 2012 is critical to avoid this situation during launch in 2013. 

On the other hand, RIRs, are only 5 and _should_ be easier to sit down on a table on a working session and get things done.

I would encourage to have both working groups in parallel, I believe there is enough people already interested to be able to do that.

Francisco

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Feb 2012 12:19:18 -0600

Greetings,

I am Eeyore, your fearless^h^h^h^hful AD. Every time I think I've 
finally caught up on all of the email, some more messages appear. 
However, I think I've gotten ahead of the curve and I thought it high 
time to explain my thoughts.

First, let me say that I'm willing to take to the IESG anything that you 
all have convinced me is a workable plan, and I'm absolutely open to 
being convinced. Of course, there is always the possibility that if you 
don't convince me, you can go convince another AD to take the charter to 
the IESG. But if I'm not convinced that the charter has a good 
likelihood of success, I suspect other members of the IESG won't be 
convinced either. So let me lay out my concerns so that you can decide 
what "convincing" you want to do.

 From my perspective, I see some folks from (a large percentage of) 
number registries willing to work on the protocol docs *and* write some 
code while working on those docs (in fact, some code and docs have 
already been written) for what I see as a relatively constrained problem 
space. That seems like a perfect recipe for success. I also see a small 
bunch of motivated names registry folks, a couple of which are willing 
to write some code, and most of which are willing to write some docs, on 
what it seems to me is a much thornier problem space. There is no doubt 
in my mind that being able to use the same (or a similar) protocol for 
access to both kinds of data is a good thing. But what I don't want to 
do is set up a whole lot of fate sharing between what I see as two 
separable efforts. I would like to see name registry issues kept in mind 
as we develop protocol, but I don't want an attempt to get a number 
registry protocol nailed down to be derailed by difficult name registry 
issues. I want the number registry work to sink or swim by itself. If 
there are straightforward ways to keep the protocol for number 
registries useful for name registries, we should do so. Insofar as 
issues get contentious, we should put them aside and leave them for later.

And that last bit is important: I absolutely foresee this WG doing work 
on the names registry protocol. I think once the WG gets a stake in the 
ground with the number registry work, we should add charter items to get 
the names registry work done. What worries me is having charter items 
that spell out the names registry work from the get go. I would rather 
the WG stay focused on the numbers work first before starting the names 
work in earnest. And to be frank, if we can't complete the numbers work, 
I can't imagine the names work is going to complete. If we can complete 
the numbers work, that leaves us free to build on it to get the names 
work done.

What I haven't been convinced of is that doing the work as distinct 
units and sequentially will be harmful to the names work. Yes, *if* the 
group wants to reuse the same protocols and *if* a bunch of stuff 
required for the names work needed to be left out of the protocol in 
order to get the numbers work done in a reasonable timeframe, it *might* 
mean that re-jiggering the protocol to support the names work might take 
longer than it would have if we undertook to do both things together. 
But that doesn't see like it would be so terrible. And we may find that 
the names protocol should be different than the numbers protocol. Or we 
may find that, even though we concentrated on numbers first, we were 
smart enough (and took enough input from the names folks) to leave 
things extensible enough to accommodate the names work handily. Either 
way, it seems better to wait until some of the numbers work is done 
before deciding those issues. What I don't want to have happen is put 
the names and numbers work in a death grip such that if there is 
contention with one, it affects the other.

Re-chartering to add work will be easier once we have a good track 
record. Initial chartering with a larger set of work items is harder.

So, I like Andrew's current charter. If we want to go with something 
that is more dependent on the names work, I'm going to want to hear why 
the proposed work is necessary to do now and can't be done sequentially, 
and especially the risk to the names work if it is not done concurrently.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Arturo Servin <[email-masked]>
Date: Tue, 14 Feb 2012 16:23:43 -0200

Alessandro,

	We tried to precisely to that. We studied and compared the 5 different data models trying to find some common data-structures before writing the draft rir-json

	Not sure if we will succeed, I am confident that we could do a nice work. There are many differences in syntax although the semantics are very similar (not always identical, but similar).

	I guess doing the same for name-registries would be hard as well but not impossible and I think it would be the way forward.

Regards,
-as

---

From: David Conrad <[email-masked]>
Date: Tue, 14 Feb 2012 11:17:16 -0800

> With the Launch of new GTLDs, and the creation of potentially several hundreds of new registries, each one of them will try to implement their own interface, this is due to the fact, that ICANN wil…

There will be more registries, but I'm not sure it follows that each registry will implement a different interface.  I suspect one of the reasons ICANN staff have been actively involved in this discussion is to try to limit the likelihood of exactly this.  My guess is that if there were an IETF-blessed standard, contractual requirements to abide by that standard would eventually appear in gTLD/registrar contracts.

> On the other hand, RIRs, are only 5 and _should_ be easier to sit down on a table on a working session and get things done.

Um. _Currently_, there is 1 IANA, 5 RIRs, 2 NIRs in LACNIC region, 4 or 5 NIRs in the APNIC region, an unknown (to me) number of LIRs in the ARIN region running RWhois, and probably other stuff I'm forgetting.  In addition, given the way things are moving, it is likely there will be a number of "secondary market" address registries. Since it has (to date) proven impossible for the various parties involved in the post-IPv4 free pool addressing world to work together, there is no administrative framework like the gTLD registry contracts or RAA to define registration data access interfaces. It is true that _currently_ the RIRs are directing this show, but I'm unsure how long this will remain true.

Regards,
-drc

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 14 Feb 2012 19:30:08 +0000

Seems like our decision has been made.

As a proponent of a combined approach, I will have to carefully consider my participation in a group whose charter states "development of the number registry support will not be constrained by needs peculiar to name registries". Other charter statements notwithstanding, this clearly establishes names as second class citizens.

On Feb 14, 2012, at 10:19 AM, Pete Resnick wrote:

> 
> So, I like Andrew's current charter. If we want to go with something that is more dependent on the names work, I'm going to want to hear why the proposed work is necessary to do now and can't be done sequentially, and especially the risk to the names work if it is not done concurrently.
>

---

From: David Conrad <[email-masked]>
Date: Tue, 14 Feb 2012 11:41:40 -0800

Andrew,

On Feb 14, 2012, at 4:46 AM, Andrew Sullivan wrote:
> way things are now

There is also the idea that having multiple methods to do the same thing is wasteful of resources and operationally more challenging to deal with.

> model is quite different.  

I'd argue the use model is most frequently the same: "I have an object, who is the owner of that object so I can scream at them."

> that all the real work would be done in the mappings.  

To me, the similarity in data and usage suggests a need for a common data schema and representation, albeit with potentially different access methods.

Regards,
-drc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Feb 2012 11:44:02 -0800

> From: [email-masked] [mailto:[email-masked]] Of Behalf Of Smith, Bill
> Sent: Tuesday, February 14, 2012 11:30 AM
> To: Pete Resnick
> Cc: [email-masked]

It didn't seem final to me.  He specifically solicited further argument (and you cited him doing so).

> As a proponent of a combined approach, I will have to carefully
> consider my participation in a group whose charter states "development
> of the number registry support will not be constrained by needs
> peculiar to name registries". Other charter statements notwithstanding,
> this clearly establishes names as second class citizens.

I don't agree at all with "clearly".  I've yet to see a claim that names isn't an interesting or desirable problem to be solved, for example.  Solving numbers is merely low-hanging fruit and can set the stage for an easier success with names later.

I still don't understand the assertion that their concurrent solution is the One True Path here.

-MSK

---

From: Arturo Servin <[email-masked]>
Date: Tue, 14 Feb 2012 17:59:02 -0200

Bill,

	I do not agree that the charter proposed establishes name-registries as second class citizen.

	I think the quoted sentence is a bit out of context. If you read the whole text:

"

	To me:

	- it sets an initial goal to work with numbers as an easier target
	- it does not include work in names but it adds space to include it in the future (I read, if names-registries have running code and proposals based on practical experience we will add them).
	- it encourages to use solutions compatible for name-registries

	My humble recommendation is to sit down and write some code. The nice thing about using restful is that it is very easy to have some results with not much effort.

Regards,
.as

---

From: Francisco Arias <[email-masked]>
Date: Tue, 14 Feb 2012 12:02:31 -0800

Hello Pete,

>and especially the risk to the names work if it is not done concurrently.

The problem is precisely what you mentioned above, that we designed a base
protocol that only focused on number registries and later when we took on
the name registries and discovered that the protocol had to be fixed to
support name registries needs. Revising a protocol would not necessarily
be trivial and may face the dislike of those that worked on it and those
who may be already using it by then.

I'd think we can develop a base protocol that takes into account the need
of both name and number registries. Then we take the design of the number
registries data profile ("the low-hanging fruit") and later the data
profile for name registries ("the difficult work").

__

Francisco.

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 14 Feb 2012 20:08:57 +0000

> It didn't seem final to me.  He specifically solicited further argument (and you cited him doing so).

I have no plans to provide further argument.

> I don't agree at all with "clearly".  I've yet to see a claim that names isn't an interesting or desirable problem to be solved, for example.  Solving numbers is merely low-hanging fruit and can se…

Clear or not, names are second class in the charter our AD prefers. I'm OK with his preference, I'm OK with names as second class citizens, I'm just stating that given that, I'll need to consider whether participating in such a group is worth the investment of my time (and money).

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 14 Feb 2012 12:12:57 -0800

On Feb 14, 2012, at 1:19 PM, Pete Resnick wrote:

> separable efforts.

I agree with this.

> I would like to see name registry issues kept in mind
> issues. I want the number registry work to sink or swim by itself.

This is fair and a correct approach.

> on the names registry protocol.

If the charter has positive assertions such as this, I'm happy with this.

> I think once the WG gets a stake in the
> the names registry work done.

I'm also OK with this if it's clear from the original charter that name registry work is in scope and that work won't be single-threaded if parties interested in name resources do what they claim they will do.  

> What worries me is having charter items

Again, I'm conceding to the chronology as you lay it out. I'm at this point only asking that the scope affords us the maximum opportunity to study the protocol for all purposes and that the charter accommodates development of data profiles in addition to the initial number resource data profile. 

I'm also asking that we jettison all the "you pooched IRIS/CRISP so you are damned forever" and other unproductive characterizations, accusations, and detritus. 

> units and sequentially will be harmful to the names work...

> Either way, it seems better to wait until some of the numbers work is done

I would not want that outcome, either. I want a bit more open-mindedness and inclusive thinking. 

> and especially the risk to the names work if it is not done concurrently.

If sequentially doesn't mean exclusive of constructive input by folks who have an interest in name resource work, I (personally) am willing to accede. With all the bashing, offline threats, and the Taipei BoF trumps all commentary you can forgive me if I have some misgivings.

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 14 Feb 2012 20:18:11 +0000

> 	I do not agree that the charter proposed establishes name-registries as second class citizen.

We disagree then.

> 	My humble recommendation is to sit down and write some code. The nice thing about using restful is that it is very easy to have some results with not much effort.

I no longer write code (sadly). Rather, I am a consumer with an interest in this work and I have expressed that. Presumably that will be taken into account in the formation of this WG, regardless of whether I write code.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Feb 2012 15:20:34 -0500

> I'd argue the use model is most frequently the same: "I have an object, who is the owner of that object so I can scream at them."

If that were a sufficient condition for them all to be treated as "the
same thing", then we'd also have to include insurance contracts,
product-defect handling, and airplane ticketing systems in scope (just
for starters).  Of course it is true that at some level, there is a
similarity between number registrations and name registrations:
they're both "registrations"; and historically they happened to be
contained in one central registration database, which is how we got
one protocol for accessing them.  If they're really so deeply the same
that they share all this data, then there ought to be _no risk_ in
starting with numbers anyway: the name systems can just pick up all
the work that's been done by someone else.

 > To me, the similarity in data and usage suggests a need for a common
> data schema and representation, albeit with potentially different
> access methods.

Yes, me too, which is why I am sanguine about the risk that the number
resource work will just turn out to be unusable for name registries.
I can't see how _anybody_ would come up with something that is deeply
incompatible, and therefore I support starting with the work that is
well in hand because we can get it done quickly and be sure we can
continue with the other stuff afterwards.  But I could be wrong, and
so could you, because we haven't actually done this work and so we
don't know.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Tue, 14 Feb 2012 12:31:00 -0800

Andrew,

On Feb 14, 2012, at 12:20 PM, Andrew Sullivan wrote:
> for starters).  

Seriously? I was, of course, referencing the context associated with network resources.  Sorry if I didn't make that clear (didn't really think it was necessary).  Live and learn.

> Of course it is true that at some level, there is a
> one protocol for accessing them.  

Exactly. One would think it would be possible to capitalize on this.  However, as others have noted, it would seem "it's all over but for the screaming". A such, I'll go waste my time elsewhere.

Regards,
-drc

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Feb 2012 14:31:56 -0600

Hi Francisco,

My evaluation here is weighing risks. So let's talk about them:

> who may be already using it by then.

OK, so this is the risk of not doing them combined. I'm trying to figure 
out if there is some way to describe more precisely or quantify those 
risks. What are the kinds of things that you think might need to be 
fixed if we didn't combine the work? Andrew said in a recent message:

> I can't see how_anybody_  would come up with something that is deeply
> continue with the other stuff afterwards.

Now, maybe he is being too optimistic, and if you think he is, I'd like 
to hear about where those risks are. That's what I'm trying to weigh on 
the one hand.

I agree with you when you say:

> of both name and number registries.

But "taking into account the need of both" is different than "combining 
the work". As Andrew's proposed charter says (or can be clarified to 
say), the needs of names will be taken into account, but if there's a 
contentious point, the needs of names can be put aside for the moment.

It's that "contentious point" problem that's the risk on the other side. 
I see the possibility that the WG could bog down trying to address 
contentious points having to do with names. Again, that might be hard to 
quantify, but as has been said, there are many more names registries, 
many more economic and political issues that come up in discussions of 
whois replacements for names registries, and that makes me worried that 
a lot of energy might be spent on working through those issues and not 
on protocol work.

I want to give the chair of the WG the ability to say, "Yes, the 
discussion seems clear that we should address that names issue in the 
spec, because it's clear that this is non-contentious and does no harm 
to moving forward with numbers", but still be able to say, "No, this is 
a contentious point, and though we might like to solve it in this 
protocol, it's going to take too much time and we'll leave out that 
feature until later."

pr

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Feb 2012 14:55:07 -0600

Hi Dave,

A great deal of agreement between us in your message. Let's see if 
there's anything big still outstanding.

> If the charter has positive assertions such as this, I'm happy with this.

As I said in my reply to Francisco, so long as there are also "out 
clauses" that allow the chair to say, "That's a name-related rat hole. 
Let's avoid it for now", I'm OK with making those positive assertions.

> I'm also OK with this if it's clear from the original charter that name registry work is in scope and that work won't be single-threaded if parties interested in name resources do what they claim t…

OK, this may be just a language issue. If I were to use the words "name 
registry work is in scope", I would mean that name registry work is part 
of the initial deliverable list. That's the part that makes me queasy. 
I'm fine with having an eye to the name registry work and making sure 
that those inputs are heard. And if parties interested in name resources 
want to start doing implementations of the protocol and come back and 
say, "Hey, if you just allow that query field to contain any sort of 
UTF-8 text instead of a binary numeric value, that would make things 
much smoother for us names types", I think that's peachy. What I don't 
want to have happen is for such a statement to become, "Even if you have 
good reasons to make that field a binary numeric value for the numbers 
work, it just won't work for the names stuff and you can't publish the 
document with it that way!" I want a reasonable answer to be, "Let's 
publish it that way for now, and leave the issue for later."

Can we split this atom?

> Again, I'm conceding to the chronology as you lay it out. I'm at this point only asking that the scope affords us the maximum opportunity to study the protocol for all purposes and that the charter…

The data profiles I'm less queasy about. I guess the only issue here is, 
can we leave the "name profile document" off of the charter for now and 
add it later once it becomes clear that (a) the protocol work is 
solidified and (b) the names folks are in the blocks ready to 
write/implement? (For the record, I'm a big believer in implementing 
while writing.)

> I'm also asking that we jettison all the "you pooched IRIS/CRISP so you are damned forever" and other unproductive characterizations, accusations, and detritus.

If you're talking about the discussion here to date, yeah, folks are 
being a bit snarky on the list. Civil tongues and thick skins would be 
greatly appreciated (and would make this whole thing go more smoothly).

If there is stuff that reads that way in the charter, let's soften it. I 
do want to be clear in the charter that we are trying to take a measured 
approach now because previous efforts haven't been successful, as that 
will explain to the rest of the IESG why we think this has more 
potential. But the charter does not need to caricature past efforts.

> I would not want that outcome, either. I want a bit more open-mindedness and inclusive thinking.

Absolutely.

> If sequentially doesn't mean exclusive of constructive input by folks who have an interest in name resource work, I (personally) am willing to accede. With all the bashing, offline threats, and the…

Bashing and offline threats have no place here, and even though this is 
not a chartered WG, this is an IETF list I will take such behavior 
seriously and will enforce the procedures that we have about such 
nonsense. Anyone may let me know (offline) if there's a need for me to 
use those enforcement tools.

Do understand that things said at the BoF caused me (and others on the 
IESG and IAB) some misgivings about the "let's all work together for the 
grand unified solution" idea. So I've been leaning toward 
incrementalism. As much as we can meet in the middle, let's do so.

pr

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Feb 2012 16:04:11 -0500

On Feb 14, 2012, at 3:12 PM, Dave Piscitello wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

[ SNIP SNIP ]

> If sequentially doesn't mean exclusive of constructive input by folks who have an interest in name resource work, I (personally) am willing to accede.

As am I.

> With all the bashing, offline threats, and the Taipei BoF trumps all commentary you can forgive me if I have some misgivings.

Yup, me too -- I'm somewhat disappointed (and surprised) by the animosity, but hopefully after the chartering things will get better...

W

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iQEcBAEBAgAGBQJPOsBNAAoJEGwWiPOSXEFNLjwIAKaescPA1t4D3pM33LzGzNxX
> GVhWvwEQVFwh0YgdH9z5QVK8WBweQHQwoY7UnaszgstbNopBI9dRDyben5uvGesd
> 711iP3CNBsn+KCeKPUFbkEIjLWesBho3VZrfRpcPyTz+Bip5D842R9lqURva3rkh
> iVJwqvLRoaa7V/EE/KDI9uyqObeabKDSyuSSa7CNS/61ybWGBRxlyk6mg1xX2lc0
> XzskV6uLgK4v0zUzrFDA3e133K26ckeMNPFcmm/8avkSmDtPOKT/dNUhnX+PbR+H
> f2NQX0xBskp9+W2G3u0sxD7e2Vm7SwuVqzqYmliT5FQ7XUrz1/85Xtb/4Og3zZE=
> =c1ut
> -----END PGP SIGNATURE-----

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Feb 2012 13:12:04 -0800

> Sent: Tuesday, February 14, 2012 12:13 PM
> To: Pete Resnick
> Cc: Murray S. Kucherawy; [email-masked]
> If sequentially doesn't mean exclusive of constructive input by folks
> who have an interest in name resource work, I (personally) am willing
> to accede. With all the bashing, offline threats, and the Taipei BoF
> trumps all commentary you can forgive me if I have some misgivings.

For my part, I never said anything like "Taipei BoF trumps all".  What I meant to convey is that there was a lot of resistance presented there, and many people that are on this list now weren't there to hear it or present contrary argument or evidence.

Strangely, though, those objectors haven't carried their views to this list.  Thus, my purpose was merely to make everyone aware of them, and point out that this list's archive is not the sole source of input to consensus on whether and how to charter this working group.

---

From: SM <[email-masked]>
Date: Tue, 14 Feb 2012 13:12:04 -0800

At 11:30 14-02-2012, Smith, Bill wrote:
>notwithstanding, this clearly establishes names as second class citizens.

If I may point out, number resources are third class citizens. :-)

At 12:12 14-02-2012, Dave Piscitello wrote:
>I'm also asking that we jettison all the "you pooched IRIS/CRISP so 
>you are damned forever" and other unproductive characterizations, 
>accusations, and detritus.

I'll +1 for the removal with a "no comment" for the rest of the sentence.

>open-mindedness and inclusive thinking.

That's a thought for Valentine's day. :-)

To summarize the long discussion:

   (i)   The number resources registries wanted to have a party for
         Valentine's day

   (ii)  The name registries wanted in on the party

   (iii) The number resources registries say ok, but let's get the party
         started first

   (iv)  The name registries insisted to be at the party at the start

   (v)   The Eeyore came by to see what all the noise was about

   (vi)  Valentine's day has to be postponed to avoid unhappiness

Is the above a correct mischaracterization of the discussion?

Regards,
-sm

---

From: Francisco Arias <[email-masked]>
Date: Tue, 14 Feb 2012 14:14:09 -0800

>>of both name and number registries.

Excellent! That means we agree in principle, let's work on the details.

>contentious point, <<<the needs of names can be put aside for the
>moment.>>>

That's where some of us see the problem. I could live with the data
profile for name registries being left at the last place in the
milestones. But leaving name registries in a lesser position to number
registries for the definition of the base protocol is hard to understand.

>a lot of energy might be spent on working through those issues and not

I'd think this would be the issue of the data profile. If we leave this to
the end, we should be fine, shouldn't we?

>protocol, it's going to take too much time and we'll leave out that

I find that possibility troublesome. In order to have a protocol that
serves both the needs of number and name registries we need to have both
in the discussion on equal footing. Having a charter that allows the
possibility of disregarding the requirements of one type of registry
doesn't seem to help in finding a solution for both types of registries.

Regards,

__

Francisco.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Feb 2012 17:31:27 -0500

> With the Launch of new GTLDs, and the creation of potentially several hundreds of new registries, each one of them will try to implement their own interface, this is due to the fact, that ICANN wil…

I *think* that that is only on the web interface, but as with many things in the DAG is is kinda vague:

1.8. Searchability. Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this section.
1.8.1. Registry Operator will offer searchability on the web-based Directory Service.

Scoring:
2 – exceeds requirements: Response meets all the attributes for a score of 1and includes: (1) A Searchable Whois service: Whois service includes web-based search capabilities by domain name, registrant name, postal address, ...

W

---

From: Pete Resnick <[email-masked]>
Date: Tue, 14 Feb 2012 16:38:59 -0600

> doesn't seem to help in finding a solution for both types of registries.

So, this is what I need explained to me:

- If things go well (whether we "do it together" or we do it as "numbers 
protocol with input from names"), all of the names issues are addressed 
when we build the protocol and it is plug-and-play usable for names. 
Everybody is happy.

- If things go poorly under "do it together" idea, there is no protocol 
for names and no protocol for numbers. Nobody is happy.

- If things go poorly under the "incremental" idea, we end up with two 
different protocols, maybe with one based on the other, but otherwise 
incompatible.

I understand the good in the first. I understand the bad in the second. 
Could someone please explain the nature of the bad in the third? I 
understand that it will take more time, and obviously more code will end 
up being written (which are not good things), but are there other harms 
that I'm not seeing?

pr

---

From: "Smith, Bill" <[email-masked]>
Date: Tue, 14 Feb 2012 23:12:58 +0000

On Feb 14, 2012, at 2:38 PM, Pete Resnick wrote:

> - If things go well (whether we "do it together" or we do it as "numbers protocol with input from names"), all of the names issues are addressed when we build the protocol and it is plug-and-play usable for names. Everybody is happy.
> 
> - If things go poorly under "do it together" idea, there is no protocol for names and no protocol for numbers. Nobody is happy.
> 
> - If things go poorly under the "incremental" idea, we end up with two different protocols, maybe with one based on the other, but otherwise incompatible.
> 
> I understand the good in the first. I understand the bad in the second. Could someone please explain the nature of the bad in the third? I understand that it will take more time, and obviously more code will end up being written (which are not good things), but are there other harms that I'm not seeing?
> 

Some may consider it a small issue, others perhaps not. For those that actually "use" the protocol(s), simplicity, consistency, and ease of use are very important. To the extent that protocol differences bleed into user experience, one is preferable to two.

Another issue with option three, is that while the discussion on this list has been of the form "names will delay numbers", a sequential approach as proposed in the "preferred" charter may preclude name work before, or parallel to, number work should the number activity be delayed for some reason, unrelated to names. This is admittedly speculative, but the same can be said for the opposite argument as well.

To be clear, I am no longer arguing *for* a combined effort. I suspect that it is doomed to a second outcome. Hopefully, we'll get a first result but third remains an option.

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 14 Feb 2012 16:59:02 -0800

If there is a lack of protocol specification, then people intending to implement a web whois option will do so using their own ideas on how this should be done. Some will through a whois->web bridge, some through some RESTful interface, and some through a plain database query.

The result… If you wanted to code a tool to lookup in several registries at once, guess what: you will need to manually parse their own format in order to make it usable.. which is no different from the current whois implementation.

And yes.. the DAG or AG (no longer Draft), is very vague about how to do things. :-S

Francisco

---

From: "John Levine" <[email-masked]>
Date: 15 Feb 2012 02:48:56 -0000

>> Could someone please explain the nature of the bad in the third?

Having written my share of WHOIS scrapers, I don't see the issue.  It
seems likely that we'll come up with something that uses RESTful HTTP
queries and sends back JSON results, with a way to redirect queries,
maybe using 302 responses, maybe something else.  That's all fine,
HTTP and JSON libraries are cheap and plentiful.

Beyond that, there really isn't all that much in common between the
questions you ask about IP addresses and the ones you ask about domain
names.  In the stuff I do, the application level stuff doing name
queries is not the same as the stuff doing number queries, and the
information I'm looking for in results isn't very similar either.  

For example, in name WHOIS, I'm often trying to figure out whether
they're using a proxy registration.  In number WHOIS, I'm trying to
map multiple IP ranges and sometimes multiple ASNs to network
operators.  Nothing common there.

I suppose that if the protocols are slightly different, it'd be
slightly harder to write generic web WHOIS clients, but I can't very
worked up about that.  It's not a big deal.

R's,
John

PS:

>To the extent that protocol differences bleed into user experience, ...

User experience? Do we complain about the user experience of BGP?

---

From: SM <[email-masked]>
Date: Tue, 14 Feb 2012 20:55:36 -0800

>The timing is much better now to work on this problem, IDNs alone have

According to a letter dated January 11, which I'll quote:

   "The current WHOIS system is hampered by an old prototype and little
    consensus on policy changes."

   "staff members have developed and recommended a solution for
    internationalized registration data.  That proposal is being
    considered for adoption as a standard by the IETF."

If it was simply a matter of timing, it should have been possible to 
reach consensus on policy changes or to adopt a solution.  Quoting RFC 4690:

   "The whois protocol itself [RFC3912] has no standard capability for
    handling non-ASCII text: one cannot search consistently for, or
    report, either a DNS name or contact information that is not in
    ASCII characters.  This may provide some additional impetus for
    a switch to IRIS"

That did not happen.

Regards,
-sm

---

From: Francisco Arias <[email-masked]>
Date: Wed, 15 Feb 2012 07:56:00 -0800

>up being written (which are not good things), but are there other harms

As others have said, the main problem would be to have two protocols that
do pretty much the same. If there were an architect of the Internet, I bet
would try to make it be one (but of course, there is none).

I believe as others that the solution for names and numbers is most likely
the same, at least in the base protocol. The difference can be left to
exist on the data profile only.

I'd think that if we see the likelihood of having the names and numbers
agree on the same base protocol we should give it a try, instead of
avoiding it.

__

Francisco.

---

From: Peter Koch <[email-masked]>
Date: Sat, 18 Feb 2012 23:46:19 +0100

> continue with the other stuff afterwards.  But I could be wrong, and

the discussion over the last few days has delivered a counter example,
maybe quicker than any of us had expected.  This does not increase
my confidence in any attempt to add "name registry" work to the
initial milestone list.  So, for the record, I still believe that
of the choices presented, the version named "weirds-charter-20120213ajs.txt"
is the by far best and most promising one.

-Peter