Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-ietf-...

From: Edward Lewis <[email-masked]>
Date: Mon, 3 Dec 2012 10:44:23 -0500

On Nov 30, 2012, at 18:48, John Levine wrote:

> Agreed.  Given the limited interest shown by the names community here
> (just Ed and Scott as far as I can tell), it makes sense to go ahead
> with the numbers stuff.

I'm puzzled by this statement.  What is meant by "go ahead with the numbers stuff" in the sense that "names" is holding it back or wants something different?  Why I'm puzzled:

There isn't a distinct "names community" that is separate from a "numbers community."  There are about a dozen organizations that do both (i.e., the NIRs and IANA, hence ICANN).

There seems to be an assumption that "just because the IETF is working on it, people are paying attention and posting."  In some cases, observers choose not to be active in the IETF and just see where the chips fall.  For them, it's hard to see the signal above the noise while there are other issues to watch.  That makes gauging interest (as limited) hard to agree with.

What is significant, in the architectural sense, about the protocol under development that is specific to "names" or to "numbers?"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2012 18:34:43 -0000

> What is significant, in the architectural sense, about the protocol
> under development that is specific to "names" or to "numbers?"

Andy and Scott's draft has a small fixed set of query terms.  They
look to me to be adequate for RIR queries, but I would be pretty
amazed if people thought that set were also adequate for DNR queries
if WEIRDS is supposed to be a replacement for the current WHOIS.

I think it'd be fine just to note that finishing the query terms for
names is TBD, and do it later, but I want everyone to be clear that's
what we're doing.  Back when we were chartering this group, a bunch of
people popped up and said it was very very very important to do the
names and numbers at the same time, but now we're back to doing
numbers first, which was the plan in the first place.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 3 Dec 2012 18:38:10 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Levine
> Sent: Monday, December 03, 2012 1:35 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [weirds] requirements/success was - Re: I-D Action: draft-
> ietf-...
> 
> Andy and Scott's draft has a small fixed set of query terms.  They look
> to me to be adequate for RIR queries, but I would be pretty amazed if
> people thought that set were also adequate for DNR queries if WEIRDS is
> supposed to be a replacement for the current WHOIS.

Could you please provide some sample queries for which the documented set of path segments is inadequate?

Scott

---

From: SM <[email-masked]>
Date: Mon, 03 Dec 2012 10:13:40 -0800

At 07:44 03-12-2012, Edward Lewis wrote:
>There isn't a distinct "names community" that is separate from a 
>"numbers community."  There are about a dozen organizations that do 
>both (i.e., the NIRs and IANA, hence ICANN).

How many individuals affiliated with IANA have reviewed the drafts?

How many individuals affiliated with ICANN have reviewed the drafts?

How many individuals affiliated with NIRs have reviewed the drafts?

>There seems to be an assumption that "just because the IETF is 
>working on it, people are

The IETF is not working on it.  The editors of the drafts are working 
on it.  People who have posted reviews to this mailing list are working on it.

Regards,
-sm

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2012 19:25:46 -0000

>Could you please provide some sample queries for which the documented set of path segments is inadequate?

The GTLD whois servers are all supposed do lookup by registrar name.
(In a surprising number of cases, they don't work, but that's a
separate issue.)

Many GTLD servers offer limited wildcard matches, e.g. this lookup in
.info.  It's in the registry agreement, and in this case actually
works:

$ whois -h whois.afilias.info abc_
[ boilerplate snipped ]

Domain ID:D47075535-LRMS
Domain Name:ABC1.INFO

Domain ID:D16905835-LRMS
Domain Name:ABC2.INFO

Domain ID:D32985814-LRMS
Domain Name:ABC3.INFO

Domain ID:D44983756-LRMS
Domain Name:ABC5.INFO

Domain ID:D44962928-LRMS
Domain Name:ABC6.INFO

Domain ID:D45421294-LRMS
Domain Name:ABC7.INFO

Domain ID:D46542896-LRMS
Domain Name:ABC8.INFO

Domain ID:D33995697-LRMS
Domain Name:ABC9.INFO

Domain ID:D2559623-LRMS
Domain Name:ABCA.INFO

Domain ID:D2453377-LRMS
Domain Name:ABCB.INFO

Domain ID:D46782033-LRMS
Domain Name:ABCC.INFO

Domain ID:D6407606-LRMS
Domain Name:ABCD.INFO

Domain ID:D43597920-LRMS
Domain Name:ABCE.INFO

Domain ID:D45826247-LRMS
Domain Name:ABCF.INFO

Domain ID:D35280565-LRMS
Domain Name:ABCG.INFO

Domain ID:D48050819-LRMS
Domain Name:ABCH.INFO

Domain ID:D34010045-LRMS
Domain Name:ABCI.INFO

Domain ID:D13490035-LRMS
Domain Name:ABCL.INFO

Domain ID:D48037921-LRMS
Domain Name:ABCM.INFO

Domain ID:D48031914-LRMS
Domain Name:ABCN.INFO

Domain ID:D48492420-LRMS
Domain Name:ABCO.INFO

Domain ID:D11452138-LRMS
Domain Name:ABCP.INFO

Domain ID:D45954821-LRMS
Domain Name:ABCQ.INFO

Domain ID:D37889783-LRMS
Domain Name:ABCS.INFO

Domain ID:D1331443-LRMS
Domain Name:ABCT.INFO

Domain ID:D8012479-LRMS
Domain Name:ABCU.INFO

Domain ID:D44864187-LRMS
Domain Name:ABCV.INFO

Domain ID:D11989005-LRMS
Domain Name:ABCW.INFO

Domain ID:D46495772-LRMS
Domain Name:ABCX.INFO

Domain ID:D47434319-LRMS
Domain Name:ABCY.INFO

---

From: Edward Lewis <[email-masked]>
Date: Mon, 3 Dec 2012 14:26:44 -0500

> How many individuals affiliated with NIRs have reviewed the drafts?

I have tried to get input from NIRs, but my attempt to contact one particular person hasn't been successful.

There is a rat hole discussion that could happen here.  First, the IETF shies away from recognizing people having affiliations.  The IETF doesn't have members, no voting mechanism before approving a document.  The IETF relies on consensus being volunteered from participants.  That leaves open the possibility that the result can be highly biased "the wrong way" - in the sense that the entirety of the problem was underestimated or represented just a fraction of the operator communitys' concerns.  The best the IETF can do is try to beat the bushes to get as much input as it can, not sit back and expect volunteers to come calling.

A lesson from the PROVREG WG and EPP.  EPP was first published around 2003 and eventually elevated to full standard by 2009.  The elevation followed the full IETF process.  However, the operator community, which pretty much came of age around 2004-2005 (estimates vary) was unaware of the IETF's mailing list for EPP.  So in 2009 there was a lot of skepticism in the operator community over the elevation of EPP to full standard when it seemed that the protocol had so many flaws.

Between October 2009 and May 2010 a few things happened (the bookend dates here correspond to CENTR Tech meetings).  The operator community and the PROVREG mail list were introduced to each other.  It seems that while those on the PROVREG list were aware of the state of the art of registration, those who came on later never heard of the list (because there was no IETF WG to gateway them in).  After this happened, the angst over the protocol subsided and issues were worked out ceasing the desire to replace EPP with something different.  I'm keeping this short - the point is that there really needs to be an effort from the IETF outwards to make sure that what gets into IETF documents is relevant, and not rely on reviews trickling in on time.

And, returning to where my comments began, the operator community in this case is not so neatly divided between names and numbers.  Perhaps in some sense is seems that way because the number of numbers people on the list is disproportionately higher than names people (if you are to count the number of RIRs as 5 registries and the domain names as having around 300).  NIRs though...they expand the RIR's 5 number registries by about double that.

I dunno, this is a rat hole.  I expect as much though as we are talking about splitting input into "names" and "numbers" - attaching affiliations when the process does not recognize that.

>> There seems to be an assumption that "just because the IETF is working on it, people are
> 
> The IETF is not working on it.  The editors of the drafts are working on it.  People who have posted reviews to this mailing list are working on it.

In the sense that the IETF is anyone participating on a mail list or document or face to face meeting, yes, the "IETF is working on it."  I've seen other organizations refer to things the "IETF is working on" in that vein.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 3 Dec 2012 19:41:47 +0000

> From: John Levine [mailto:[email-masked]]
> Sent: Monday, December 03, 2012 2:26 PM
> To: [email-masked]
> Cc: Hollenbeck, Scott

Hmm, yes, that's a legacy use case. It may be one we can accommodate in the context of searches (see below) and string pattern matching.

> $ whois -h whois.afilias.info abc_

That's a search designed to return a multi-element response. We made a conscious decision as a group to defer search processing, but in an interesting twist of fate Andy and I have been talking about it off-list today. I agree that we have to find a way to specify search functionality for the protocol to be fully useful - and not just for names. I don't yet know if it makes sense to add search syntax and semantics to the existing query and response drafts or if they belong in their own document(s).

Scott

---

From: Edward Lewis <[email-masked]>
Date: Mon, 3 Dec 2012 15:24:32 -0500

> That's a search designed to return a multi-element response. We made a conscious decision as a group to defer search processing, but in an interesting twist of fate Andy and I have been talking abo…

In trying to decide for myself, I figured that the problem needs better definition.

E.g., where do we draw the line between searching and bulk retrieval.  For example ...  "/ip/*"

Is the intent that I can ask for 5 specific objects in one URL and get back the 5 responses?
Is the intent that I can ask for all the objects in a lexical range (abc*.se or 127.0.*)?
Is the intent that I can ask for all object matching a regular expression (127.[0-9].6.[^.]+)?
Is the intent that I can ask for all the objects that have a certain attribute - like AS numbers registered to Chile?

I ask these questions because "for the protocol to be fully useful" is open-ended.  I.e., "useful to whom" and in what way.

---

From: SM <[email-masked]>
Date: Mon, 03 Dec 2012 12:29:46 -0800

Hi Ed,
At 11:26 03-12-2012, Edward Lewis wrote:
>There is a rat hole discussion that could happen here.  First, the 
>IETF shies away from recognizing people having affiliations.  The 
>IETF doesn't have members, no voting

And I am ok with that. :-)

>mechanism before approving a document.  The IETF relies on consensus 
>being volunteered from participants.  That leaves open the 
>possibility that the result can be highly biased "the wrong way" - 
>in the sense that the entirety of the problem was underestimated or
>represented just a fraction of the operator communitys' 
>concerns.  The best the IETF can do is try to beat the bushes to get 
>as much input as it can, not sit back and expect volunteers to come calling.

The work on the drafts is still in its infancy.  In my humble opinion 
it is better to give the work sufficient time to take shape.

I would avoid using "the IETF" as it means nothing.  There were a lot 
of people in the room at the two WG sessions.  I gather that they are 
aware of the work being done and they volunteered to do some work.

>A lesson from the PROVREG WG and EPP.  EPP was first published 
>around 2003 and eventually elevated to full standard by 2009.  The 
>elevation followed the full IETF process.  However, the operator 
>community, which pretty much came of age around 2004-2005 (estimates 
>vary) was unaware of the IETF's mailing list for EPP.  So in 2009 
>there was a lot of skepticism in the operator community over the 
>elevation of EPP to full standard when it seemed that the protocol 
>had so many flaws.

Full Standard does not mean anything. :-)  However, I think that 
there is a lesson to be learned from what you wrote above.  There may 
be flaws in the documents published by this working group.  It can 
happen to any (IETF) document.  If some people think that it would be 
better to reduce or fix flaws there is a WGLC and a Last Call for 
people to read the documents and point out what is wrong.

>Between October 2009 and May 2010 a few things happened (the bookend 
>dates here correspond to CENTR Tech meetings).  The operator 
>community and the PROVREG mail list were introduced to each 
>other.  It seems that while those on the PROVREG list were aware of 
>the state of the art of registration, those who came on later never 
>heard of the list (because there was no IETF WG to gateway them 
>in).  After this happened, the angst over the protocol subsided and 
>issues were worked out ceasing the desire to replace EPP with 
>something different.  I'm keeping this short - the point is that 
>there really needs to be an effort from the IETF outwards to make 
>sure that what gets into IETF documents is relevant, and not rely on 
>reviews trickling in on time.

Yes, but someone has to go and do that work.

>And, returning to where my comments began, the operator community in 
>this case is not so neatly divided between names and 
>numbers.  Perhaps in some sense is seems that way because the number 
>of numbers people on the list is disproportionately higher than 
>names people (if you are to count the number of RIRs as 5 registries 
>and the domain names as having around 300).  NIRs though...they 
>expand the RIR's 5 number registries by about double that.

In my opinion the number of X does not matter.  If you replace X with 
vendors you end up with the same type of discussions in other working 
groups.  It can be quite discouraging to do any work.

Regards,
-sm

---

From: Andy Newton <[email-masked]>
Date: Mon, 3 Dec 2012 22:09:19 +0000

>if WEIRDS is supposed to be a replacement for the current WHOIS.

If anybody thinks the internationalization topic at the last meeting was
hard, just wait until you throw searches into the mix.

Concentrating first on lookups gets us forward progress on the things
which constitute 99% of the query volume. Holding all work to get that
last 1%, work which will be an order of magnitude more difficult to
specify, is not a good trade off.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 3 Dec 2012 17:18:13 -0500

> specify, is not a good trade off.

That's a perfectly reasonable approach, but again I want to be explict 
that's we say that's what we're doing if indeed it is.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2012 22:18:44 -0000

Assuming we try to handle searching (see previous message), ...

>E.g., where do we draw the line between searching and bulk retrieval.  For example ...  "/ip/*"

We don't.  The client asks the question, the server decides whether
it's willing to answer it.

My inclination would be to add a query prefix like /multi to indicate that
the client is asking for multiple results, and the results of a /multi
query is a JSON array, even if it only has one entry.  

The array might start with a status value to say whether these are all
the matching results, or just a subset, and it'd probably be useful to
provide some way, either an HTTP return code or additional status
values for nothing matched and too many things matched.  Servers are
not required to be strictly truthful, e.g., if the list is truncated
they don't have to say so.