Subject: [weirds] a charter offering compromise

From: Andy Newton <[email-masked]>
Date: Tue, 20 Mar 2012 17:55:58 +0000

All,

As we go into our second BoF and likely final venue to convince the IETF to form a working group, I wish to propose a compromise with regard to the charter and the charter discussion about numbers before names and the various other threads in hopes to bring finality to some issues. Attached you will find a charter proposal based on the proposal originally written by Andrew Sullivan. This charter proposal removes the numbers before names restriction that resulted from our first BoF in exchange for using the number registry input documents as a pattern going forward and explicitly noting the need for IDN data model support in the name registry specification.

Going into the BoF with a charter proposal that reflects our ability to compromise would likely do us good in convincing the IETF to form a working group on this topic, and it would be beneficial as a common starting point.

-andy

---

From: Steve Sheng <[email-masked]>
Date: Tue, 20 Mar 2012 11:13:27 -0700

Thank you Andy, I read through this charter and am comfortable with it. So
I support this charter.

Steve

-----Original Message-----
From: Andy Newton <[email-masked]>
Date: Tue, 20 Mar 2012 10:55:58 -0700
To: "[email-masked]" <[email-masked]>
Subject: [weirds] a charter offering compromise

>All,
>
>As we go into our second BoF and likely final venue to convince the IETF
>to form a working group, I wish to propose a compromise with regard to
>the charter and the charter discussion about numbers before names and the
>various other threads in hopes to bring finality to some issues. Attached
>you will find a charter proposal based on the proposal originally written
>by Andrew Sullivan. This charter proposal removes the numbers before
>names restriction that resulted from our first BoF in exchange for using
>the number registry input documents as a pattern going forward and
>explicitly noting the need for IDN data model support in the name
>registry specification.
>
>Going into the BoF with a charter proposal that reflects our ability to
>compromise would likely do us good in convincing the IETF to form a
>working group on this topic, and it would be beneficial as a common
>starting point.
>
>-andy
>
>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Mar 2012 15:01:05 -0400

Again, coming late to the game, the last paragraph doesn't make sense to me.

#    As the number registries have more experience with these services
#    and have found common ground with their dissimilarities resulting in
#    more complete working group input documents, the goals of the working
#    group are to work on specifications for both number and name registries
#    using the fashion and pattern of the name registry input documents as
#    a basis going forward.

Is this needed?  (I ask, again, noting I'm late to the game.)

I don't think it is a "goal" to "work on specifications" in any 
particular manner, the goal is to get a final result.

And I'm confused by "the number registries have more experience" 
leading to "using the ... the name registry input documents".  I 
would think the "name" in there should be "number."  There seems to 
be a non-sequitur in there somewhere.

Until that point the charter seemed clean.  I re-read the last 
paragraph 4 times because I couldn't make sense of it.  Perhaps 
there's background discussions that are driving this, but they aren't 
apparent.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Mar 2012 19:09:35 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Lewis
> Sent: Tuesday, March 20, 2012 12:01 PM
> To: Andy Newton
> Cc: [email-masked]
> Subject: Re: [weirds] a charter offering compromise
> 

Yes, it should be something like "to produce standards-track specifications", although one could argue that event that is redundant.

> leading to "using the ... the name registry input documents".  I would
> think the "name" in there should be "number."  There seems to be a non-
> sequitur in there somewhere.

+1.

> paragraph 4 times because I couldn't make sense of it.  Perhaps there's
> background discussions that are driving this, but they aren't apparent.

Background discussions, if they're happening, don't advance things as well as talking about them on the list.  Among other things, off-list chatter looks to observers either like attrition or cabal work, both of which are things a fledgling working group doesn't need.

-MSK

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Mar 2012 15:20:06 -0400

At 19:09 +0000 3/20/12, Murray S. Kucherawy wrote:

>Background discussions, if they're happening, don't advance things 
>as well as talking about them on the list.  Among other things, 
>off-list chatter looks to observers either like attrition or cabal 
>work, both of which are things a fledgling working group doesn't 
>need.

I didn't mean to insinuate cabal-like gossip.  I meant that not 
having been part of the WEIRDS discussions until a few weeks ago and 
not being present at BoF1, if there was any reason to include a 
paragraph dividing this into "names" and "numbers" - the charter 
doesn't describe the reason(s).  The last paragraph seems to "come 
out of the blue."

---

From: Andy Newton <[email-masked]>
Date: Tue, 20 Mar 2012 19:20:12 +0000

On Mar 20, 2012, at 3:01 PM, Edward Lewis wrote:

> And I'm confused by "the number registries have more experience" leading to "using the ... the name registry input documents".  I would think the "name" in there should be "number."  There seems to be a non-sequitur in there somewhere.

That's a mistake. Thanks for pointing it out. It should be the number registry input documents.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 20 Mar 2012 15:32:13 -0400

On Mar 20, 2012, at 3:20 PM, Edward Lewis wrote:

> I meant that not having been part of the WEIRDS discussions until a few weeks ago and not being present at BoF1, if there was any reason to include a paragraph dividing this into "names" and "numbers" - the charter doesn't describe the reason(s).

Yes, that probably doesn't make sense without context. The result of BoF1 was that there was consensus for numbers work but not names work. As a result a charter was drafted that reflected working on numbers first then names which resulted in a long thread and no obvious conclusion. At least that's how I remember it. Others may recall differently.

-and

---

From: Avri Doria <[email-masked]>
Date: Tue, 20 Mar 2012 14:32:36 -0500

Hi,

I think the compromise document it's pretty good am would like to offer one relatively small, I think/hope, change.

Modify

    As the number registries have more experience with these services
    and have found common ground with their dissimilarities resulting in
    more complete working group input documents, the goals of the working
    group are to work on specifications for both number and name registries
    using the fashion and pattern of the name registry input documents as
    a basis going forward.

To

    As the number registries have more experience with these services
    and have found common ground with their dissimilarities resulting in
    more complete working group input documents, the goals of the working
    group are to work on specifications for both number and name registries
    using the fashion and pattern of the name registry input documents as
    an initial basis.

I.e.

substitue "as a basis going forward" with "as an initial basis"

Avri

Andy Newton <[email-masked]> wrote:

>All,
>
>As we go into our second BoF and likely final venue to convince the
>IETF to form a working group, I wish to propose a compromise with
>regard to the charter and the charter discussion about numbers before
>names and the various other threads in hopes to bring finality to some
>issues. Attached you will find a charter proposal based on the proposal
>originally written by Andrew Sullivan. This charter proposal removes
>the numbers before names restriction that resulted from our first BoF
>in exchange for using the number registry input documents as a pattern
>going forward and explicitly noting the need for IDN data model support
>in the name registry specification.
>
>_______________________________________________
>weirds mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/weirds

---

From: Andy Newton <[email-masked]>
Date: Tue, 20 Mar 2012 19:34:51 +0000

> substitue "as a basis going forward" with "as an initial basis"

Thanks. I think that reads better.

-andy

---

From: SM <[email-masked]>
Date: Tue, 20 Mar 2012 12:50:00 -0700

>     using the fashion and pattern of the name registry input documents as

Which draft(s) are to be used as input documents?

Regards,
-sm

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 20 Mar 2012 19:59:18 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andy Newton
> Sent: Tuesday, March 20, 2012 1:56 PM
> To: [email-masked]

Modulo the changes already suggested I like the approach.

Scott

---

From: Andy Newton <[email-masked]>
Date: Tue, 20 Mar 2012 19:59:39 +0000

> Which draft(s) are to be used as input documents?

Again, sorry for the confusion.

https://datatracker.ietf.org/doc/draft-newton-et-al-weirds-rir-query/
https://datatracker.ietf.org/doc/draft-newton-et-al-weirds-rir-json-response/

Also, there was no intent to exclude Murray's requirements draft as an input document, which is here:
https://datatracker.ietf.org/doc/draft-kucherawy-weirds-requirements/

Or the DNRD draft as the query portion is similar.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 20 Mar 2012 16:24:50 -0400

Sorry for the confusion. Here's a revision based on the feedback so far.

-andy

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 20 Mar 2012 17:34:44 -0300

Andy,

I like and support this proposed charter,

Fred

> Web Extensible Internet Registration Data Service (weirds)
> ----------------------------------------------------------
> 
> DRAFT Charter v 2012-03-20aln.2
> 
> Chairs:
>     TBD
> 
> Applications Area Directors:
>     Pete Resnick, Peter Saint-Andre, and Barry Leiba
> 
> Description of Working Group:
> 
>     Internet registries for both number resources and names have
>     historically maintained a lookup service to permit public access
>     to some portion of the registry database.  Most registries offer
>     the service via WHOIS (RFC 3912), with additional services being
>     offered via world wide web pages, bulk downloads, and other
>     services like RPSL (RFC 2622).
> 
>     WHOIS has never been internationalized.  In the absence of formal
>     specification, ad hoc solutions to signal internationalized
>     registration data have been adopted and deployed.  Providing a
>     standards-base solution that scales well could minimize further
>     proliferation of ad hoc solutions.
> 
>     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.
> 
>     The WHOIS protocol does not offer any differential service; it
>     cannot differentiate among clients to offer different subsets of
>     information or to allow different access rates to it.
> 
>     Various attempts to solve the limitations of WHOIS have met with
>     mixed success.  The most recent of these was IRIS (RFC 3891).
>     IRIS has not been a successful replacement for WHOIS.  The primary
>     technical reason for this appears to be the complexity of IRIS, the fact
>     that it builds upon many available technologies that in the aggregate
>     form a complex system. There may also exist non-technical reasons,
>     but they lie in areas upon which the IETF does not pass judgement.
> 
>     In recent years, ARIN and RIPE NCC have fielded production RESTful
>     web services to serve WHOIS data, and each has met with success.
>     It is widely believed that this simpler re-use of Web technologies
>     familiar to modern web developers has enabled this success. The
>     purpose of this working group is to broaden the use of RESTful web
>     services by achieving simple and common URI patterns and responses
>     amenable to all number resource and domain name registries.
> 
>     This Working Group shall determine the general needs of such a
>     service, and standardize a single data framework.  That framework
>     shall be used to encapsulate objects that could form part of an
>     answer.  The framework shall be for data to be delivered via a
>     RESTful data service using HTTP (optionally using TLS). The data
>     shall have one mandatory format, though the working group may consider
>     other optional formats.  The overall effort will be broadly aligned with 
>     a subset of the Cross Registry Internet Service Protocol (CRISP) 
>     Requirements (RFC 3707), but with the explicit additional goals of 
>     producing a simple, easy-to-implement protocol, supporting 
>     internationalized registration data and, specifically for
>     name registries, a data model capturing the needs of internationalized
>     domain names.
> 
>     group are to produce standards-track specifications for both number 
>     and name registries using the fashion and pattern of the number registry 
>     input documents, draft-newton-et-al-weirds-rir-query and
>     draft-newton-et-al-weirds-rir-json-response, as an initial basis.
> 
> Milestones
> 
>     November 2012 Draft WEIRDS requirements to IESG for
>     publication as Informational RFC.
> 
>     April 2013 Draft WEIRDS specification for number resources to IESG for
>     publication on the standards track.
> 
>     July 2013 Draft WEIRDS specifications for name
>     registries to IESG for publication on the standards
>     track.

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Tue, 20 Mar 2012 17:38:45 -0300

+1 Support from me

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 20 Mar 2012 13:45:20 -0700

I would like to see:

draft-sheng-weirds-icann-rws-dnrd

as part of:

On Mar 20, 2012, at 1:24 PM, Andy Newton wrote:

> <weirds_charter.txt>_______________________________________________
> weirds mailing list
> [email-masked]

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Arturo Servin <[email-masked]>
Date: Tue, 20 Mar 2012 17:46:24 -0300

I think this chapter version reflects a balance among the many opinions done in this list, hence I support.

Regards,
.as

---

From: Alan Maitland <[email-masked]>
Date: Tue, 20 Mar 2012 15:38:25 -0600

> substitue "as a basis going forward" with "as an initial basis"

Agree, though I would use the word "foundation" to replace "basis".

Alan

---

From: "John Levine" <[email-masked]>
Date: 20 Mar 2012 23:11:55 -0000

>    draft-newton-et-al-weirds-rir-json-response, as an initial basis.

Sorry to interrupt the love-in, but I have to say this looks to me to
be a recipe for failure.

If history is a guide, the name work will get bogged down in whatever
it is that they always get bogged down in.  They will demand that the
number work wait for them to work it out, which they never will.

For there to be any hope of success, we need to specifically agree
that the number work will *NOT* wait for names work.  If I'm wrong and
the name work can move fast enough to provide useful input to make the
two similar without delaying the number work, that's great. If they
can't, well, so be it.

R's,
John

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 20 Mar 2012 20:25:25 -0300

John,

> number work wait for them to work it out, which they never will.

With all due respect, if it's to take history in any account, the fact
that we toke numbers and names together during the CRISP time, btw
numbers got on the bandwagon way after names, has nothing to do with
the failure of IRIS.

We had a base spec defining lookup, search etc... and specific
documents for the mappings of domain names and Blocks/ASs.

I see no reason that we can't agree on a base URI schema and specific
encodings for the different registries. We've already a proposed draft
that leverages the numbers schema and adapts it to the names as a
proof of the feasibility of this approach.

Regards,
Fred

---

From: "John R. Levine" <[email-masked]>
Date: 21 Mar 2012 09:12:07 +0100

> encodings for the different registries.

If so, that's great.  But if we can't, the names people can't make the 
numbers work wait.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: ALAIN AINA <[email-masked]>
Date: Wed, 21 Mar 2012 13:33:55 +0400

+1

--Alain

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Mar 2012 06:36:00 -0400

On Wed, Mar 21, 2012 at 09:12:07AM +0100, John R. Levine wrote:
> If so, that's great.  But if we can't, the names people can't make
> the numbers work wait.

Ok, but why is that something that needs to be stated in the charter
rather than just a matter of good WG management by a competent chair?

I'm more than a little concerned that everyone seems to want a charter
that will guarantee their preferred outcome.  Charters are just a way
of guiding a WG's actions, mostly by limitation; I don't think they're
like a Statement of Work that make any sort of promises about what
will happen for sure.  (If they are, the IETF has lousy management: I
can't remember the last WG I was involved with that consistently met
its milestones.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 21 Mar 2012 10:53:53 +0000

> Behalf Of John R. Levine
> Sent: Wednesday, March 21, 2012 4:12 AM
> To: Frederico A C Neves
> Cc: [email-masked]
> Subject: Re: [weirds] REVISED Re: a charter offering compromise
> 

I don't see any dependencies in the proposed charter that would make that possible.

Scott

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Mar 2012 12:59:16 +0000

> Agree, though I would use the word "foundation" to replace "basis".

I'm fine with either. Avri?

-andy

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Mar 2012 13:17:09 +0000

> Sorry to interrupt the love-in, but I have to say this looks to me to

And I thought this drum circle would never end?  :)

> number work wait for them to work it out, which they never will.

While I understand the first part of that, I don't understand the second part. Yes, there is a potential for the names work to get bogged down in some issues, such as IDNs. But what is their motivation for stopping the numbers work?

As far as codifying that in the charter, I'm not sure how you would prevent it anyway. What's to stop them from bringing up one legitimate looking nit after another?

Additionally, if the system does look likes its being gamed in that manner I'll be the first to start filling appeals.

-andy

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 21 Mar 2012 09:39:17 -0400

> rather than just a matter of good WG management by a competent chair?

well, some prudence is reasonable in view of the history of attempts
to fix or kill the thing on :43.

personally i think it reasonable to notice the historic intractables
that yet another failure is possible, leaving them with the thing on
:43, and that repetition of inability to find rough consensus for a
specification which can be implemented has limited scope.

-e

---

From: Edward Lewis <[email-masked]>
Date: Wed, 21 Mar 2012 10:56:16 -0400

>Sorry for the confusion. Here's a revision based on the feedback so far.

This is clearer, certainly.

This is the way I'd suggest wording the last paragraph:

The goal of the WG is to produce standards-track specifications for 
both number and name registries.  However, the number registries have 
more experience with these services and have found common ground with 
their dissimilarities resulting in more complete working group input 
documents.  Hence the intended approach of the WG is to begin with 
the number registry input documents, 
draft-newton-et-al-weirds-rir-query and 
draft-newton-et-al-weirds-rir-json-response [*].  The same fashion 
and pattern will be applied to the name registry documents.

[*] - and open to the suggestion of the third document.

I did a lot of cut'n'paste to retain as much of the "fashion and 
pattern" of the proposed charter text.  My re-wording attempt is to 
remove the notion of the proposed approach as a goal.  I.e., the goal 
is the set of final documents, not following the proscribed approach.

---

From: "John R. Levine" <[email-masked]>
Date: 21 Mar 2012 19:32:57 +0100

> While I understand the first part of that, I don't understand the second 
> part. Yes, there is a potential for the names work to get bogged down in 
> some issues, such as IDNs. But what is their motivation for stopping the 
> numbers work?

>> the goals of the working group are to produce standards-track specifications for both number
>> input documents,

I don't think that anyone's conscious goal is to stop the numbers work. 
But I forsee that we're looking at something like, say, what the fields 
are for a contact person, which it would be nice if it were the same for 
name and number contact people.  The names people get into a long wrangle 
about some aspect of it.  The numbers people say, we're going to pick 
something that works for us.  The names people say, no, you have to wait 
for us so that it can be the same.  Now what?

Maybe I'm being unduly pessimistic but the history is not encouraging and 
I see a very poor understanding of what goes into a successful standard, 
e.g., the frequent suggestions to allow multiple response formats,

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 21 Mar 2012 20:28:44 +0100

The last snippet of the last but one paragraph is not clear to me.

On 20/Mar/12 21:24, Andy Newton wrote:
>
> but with the explicit additional goals of producing a simple,
> easy-to-implement protocol, supporting internationalized
> registration data and, specifically for name registries, a data
> model capturing the needs of internationalized domain names.

Overall, the text makes it clear that the framework and the mandatory
format are unique.  For data models, only that phrase is given.

Possibly, it should be said that there will be two data models, one
for names and one for numbers.  I don't think i18n features are only
needed by names, as we'd better accommodate RFC 653x contacts anyway.

Can the charter mention what kind of extensibility we aim for?  I know
that this has to be discussed further, but unifying frameworks could
support a variety of model variations, which is different than
designing for simple clients that need to access whichever server
transparently.  Perhaps, the charter could speak about working out
what are the elements that are actually part of all known object
templates --capturing such work in its own milestone remains a
valuable task, IMHO.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Mar 2012 15:42:05 -0400

On Wed, Mar 21, 2012 at 07:32:57PM +0100, John R. Levine wrote:
> say, we're going to pick something that works for us.  The names
> people say, no, you have to wait for us so that it can be the same.
> Now what?

Now the chairs and AD do their job?

Seriously, yes, I see what you are worried about; but this worry is
true for every single WG in the IETF.  We can always end up with a
$your_favourite_nutbar participating.  WG failure is always possible
in the presence of enough ill will.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Mar 2012 20:04:25 +0000

> in the presence of enough ill will.

The threat John speaks of isn't a scalar but a vector.

Yes, WG failure is always a possibility. That is something the IETF tries very hard to avoid, first by not chartering ones that look like they will fail.

-andy

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Mar 2012 16:10:27 -0400

On Mar 21, 2012, at 10:56 AM, Edward Lewis wrote:

> The goal of the WG is to produce standards-track specifications for both number and name registries.  However, the number registries have more experience with these services and have found common ground with their dissimilarities resulting in more complete working group input documents.  Hence the intended approach of the WG is to begin with the number registry input documents, draft-newton-et-al-weirds-rir-query and draft-newton-et-al-weirds-rir-json-response [*].  The same fashion and pattern will be applied to the name registry documents.
> 
> I did a lot of cut'n'paste to retain as much of the "fashion and pattern" of the proposed charter text.  My re-wording attempt is to remove the notion of the proposed approach as a goal.  I.e., the goal is the set of final documents, not following the proscribed approach.

Works for me.

-andy

---

From: Dave Piscitello <[email-masked]>
Date: Wed, 21 Mar 2012 13:12:54 -0700

+1

Adding complexity or variables to the minimalist  and reasonably simplified charter under discussion should thus be avoided.

Sent from my iPhone

---

From: Andy Newton <[email-masked]>
Date: Wed, 21 Mar 2012 16:21:56 -0400

> format are unique.  For data models, only that phrase is given.

I do not understand the clarification being requested here. Can you elaborate?

> needed by names, as we'd better accommodate RFC 653x contacts anyway.

Though there will likely be two, there is the possibility of there only being one. But you are right that internationalization issues apply to both. But I thought that was being said.

> templates --capturing such work in its own milestone remains a

Just thinking here, but maybe that could go in the requirements document.

-andy

---

From: Patrick Vande Walle <[email-masked]>
Date: Wed, 21 Mar 2012 21:55:07 +0100

Andy,

On 20/03/12 21:24, Andy Newton wrote:
> [snip]
>    The
Your draft charter rightfully refers to  the inability of WHOIS to
serve  different outputs targetting different audiences, which is a
major deficiency of the current situation. 
However, the part about  the purpose of the WG  does not seem to address
the need to provide those differential services.   

I suggest to add language to that effect. Another draft charter used the
following sentence:  "Support for differential service levels according
to different classes of user" . 

With such an addition, I would support your draft.

Patrick Vande Walle

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Mar 2012 04:11:00 -0400

> to different classes of user" . 

Patrick,

We make specific mention of using HTTP and HTTPS, which provides many authentication mechanisms upon which authorization schemes can be used to provide differentiated services. Therefore, I do not think there is a need to explicitly state support of differential service levels as that just comes with using HTTP.

Does that satisfy your concern?

-andy

---

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2012 10:17:16 +0000

On 22 Mar 2012, at 08:11, Andy Newton wrote:

+1, and it's a point I made at the mic in Taipei.

IMHO we should be defining _nothing_ in the WEIRDS specifications about:

- authentication
- access control
- rate limiting

other than to note that all these MAY be provided at the HTTP layer.

Ray

---

From: Arturo Servin <[email-masked]>
Date: Thu, 22 Mar 2012 07:32:54 -0300

Possibly in the future someone would like to document (and perhaps standardise) how they are doing authentication, access control, rate limiting; I think that would be ok. But I do not think that we need to add it in the charter now.

Regards,
/as

---

From: Steve Sheng <[email-masked]>
Date: Thu, 22 Mar 2012 04:46:52 -0700

+1 to Andy and Ray on this point.

At the protocol level, it maybe helpful to define error messages such as "resource not permitted".

Steve

On Mar 22, 2012, at 10:17 AM, "Ray Bellis" <[email-masked]<mailto:[email-masked]>> wrote:

- authentication
- access control
- rate limiting

Ray

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

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Mar 2012 12:27:42 +0000

> At the protocol level, it maybe helpful to define error messages such as "resource not permitted".

The 401 or 403 error codes should be sufficient for this purpose.

-andy

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 22 Mar 2012 08:39:24 -0400

> other than to note that all these MAY be provided at the HTTP layer.

if, and only if, the mechanisms to support these are present in
transport, then the specification of such is redundant, in theory.

but a commitment to offer not even bcp advise to implementers is
indifferent to policy.

whois has been the means to get around the bulk access provision for
ages, and several studies show that email addresses that exist in no
other original machine readable form other than in regist(ry|rar)
published data are acquired in a timely fashion by economically
motivated third-parties and subsequently trafficked in "mailing lists".

we are offering to author yet another publish-upon-create mechanism,
in an environment in which the (shades of gray) industry standard
"client" is a bot set.

now suppose this is correct, and weirds is mum on authentication.

we've assumed that that any non-global semantic, e.g., the
authentication requirements for access to personal information held by
a registry in some jurisdiction, are already met by http. having been
involved in some of the http work (state management mechanism and
personal information in particular, in the w3c's p3p spec, and also in
several of the http working groups), i don't think support for
jurisdictionally scoped authentication ever was ever in scope*.

whether labeled as "privacy" or "data protection", whether arising
from private contract or public law, some requirement(s) exist which
are (a) specific to personally identifying information, and (b) not
the default for connections over http.

so i think a "note" that these "may" be provided by transport is not
quite sufficient.

-e

* the original jaye cookie spec contained metadata related to data
collection, and a digital signature. we intended to the digital
signature to provide jurisdictionally scoped authentication. as the
dsig xml spec was immature, we dropped this half of the cookie
metadata, while switching from key-value pairs to xml for the
remaining metadata, in those xml-was-fashionable times.

---

From: Patrick Vande Walle <[email-masked]>
Date: Thu, 22 Mar 2012 14:08:07 +0100

On 22/03/12 11:17, Ray Bellis wrote:
>> We make specific mention of using HTTP and HTTPS, which provides many
>> authentication mechanisms upon which authorization schemes can be
>> used to provide differentiated services. Therefore, I do not think
>> there is a need to explicitly state support of differential service
>> levels as that just comes with using HTTP.
>

As Andy notes, there are several ways to authenticate to a HTTP server. 
If there are no guidelines for implementation, there is a risk that
different registries will implement  this in a different manner.  This
would require the client side  to know in advance which authentication
method should be used for each registry. If it was only for 5 RIR
registries, it would be  manageable. For several hundreds of TLDs, this
is quite a different context. 

Patrick Vande Walle

---

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2012 13:13:39 +0000

> is quite a different context. 

Yes, that's fair.  I have no problem with "profiling" HTTP(s) to make recommendations on which authentication methods should be used, and which response codes are appropriate.

I'm strongly opposed to any of this stuff ending up in the layers above HTTP.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Mar 2012 09:21:19 -0400

On Thu, Mar 22, 2012 at 04:11:00AM -0400, Andy Newton wrote:
> We make specific mention of using HTTP and HTTPS, which provides
> many authentication mechanisms upon which authorization schemes can
> be used to provide differentiated services. Therefore, I do not
> think there is a need to explicitly state support of differential
> service levels as that just comes with using HTTP.

I disagree with this, although it's not a hill I'll die on.  

A significant motivator of this work for me is differential service
for different clients.  By my reckoning, at least half of the current
ICANN-source complaints about "problems with WHOIS" (by which is meant
bad data) could be solved by reducing the incentives to populate name
registration data with falsehoods.  The reason for those falsehoods
is, at least in part, the fact that WHOIS is an anonymous-access
protocol where everyone can get all the data.  If we had
credential-based differentiation of responses, then registering a
domain name would not necessarily be a way to publish your street
address to 2 billion people.  Something that was specified but that
didn't satisfy this need would not, IMO, be much of an advance.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Mar 2012 13:27:31 +0000

> is quite a different context. 

But the method in which to authenticate to the server would depend on the needs of the policy dictating the differentiated service. Iterating over every possible authentication scheme is simply too broad in scope for any working group.

If, however, third parties wish to bring Informational RFCs before the IETF regarding authentication schemes for review, the working group could set out the guidelines for how such reviews are performed. And the working group could request the establishment of an IANA registry of such authentication schemes. But I don't think the working group should actually work on any authentication schemes. Additionally, it is not clear to me that guidelines for review or an IANA registry are necessary until we know such authentication schemes are being created. Are any in the works?

-andy

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Mar 2012 13:37:07 +0000

> but a commitment to offer not even bcp advise to implementers is

[..snip..]

> so i think a "note" that these "may" be provided by transport is not

Eric, forgive me as I am not properly caffeinated and I've been misreading things all morning.

Are you suggesting that if an authentication scheme requires the capture of personally identifying information there are privacy implications, and therefore some advice should be offered on the handling of that information?

-andy

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 22 Mar 2012 09:42:40 -0400

+1.

a restatement of the general desire for differential service is the
hoary old phrase that "<insert acronym of choice> shall not mandate a
single <insert "business" or "process" according to taste> model".

as i've mentioned earlier, there is no (statistically significant
within the data set) bad data in several registries (.aero, .coop,
.museum, .cat), so factors other than legitimate user concerns are
sources of bad data.

something related to competition policy is the tail end of
differential service thing, as well as the privacy/data protection
issue noted by others.

-e

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 22 Mar 2012 09:53:16 -0400

> Eric, forgive me as I am not properly caffeinated and I've been misreading things all morning.

ditto on the elackocaffine.

> Are you suggesting that if an authentication scheme requires the capture of personally identifying information there are privacy implications, and therefore some advice should be offered on the han…

i wrote about the data the registry possesses and will publish, which
at least for some endpoint identifiers issued by some allocators
(number or name registries), contains personally identifying information.

any pii captured during authentication (generally) of access to random
(generally) records within the registry's data set is distinct from
the pii already present in the data set.

there may be jurisdictionally scoped rules for both that are similar,
but an authentication/access/rate rule could produce no pii, e.g., if
the query is made on a thursday at a minute past midnight, GMT, then
there is a response, else not. no pii generated, some a/a/r-l rule
implemented, to some policy end, e.g., scrape-reduction.

-e

---

From: Don Blumenthal <[email-masked]>
Date: Thu, 22 Mar 2012 11:36:00 -0400

From: [email-masked] [[email-masked]] On Behalf Of Eric Brunner-Williams [[email-masked]]
Sent: Thursday, March 22, 2012 9:42 AM
To: [email-masked]
Subject: Re: [weirds] REVISED Re:  a charter offering compromise

as i've mentioned earlier, there is no (statistically significant
within the data set) bad data in several registries (.aero, .coop,
.museum, .cat), so factors other than legitimate user concerns are
sources of bad data.
===================================================

True, unless one thinks that criminals and other fraudsters have legitimate user concerns.  While my background may produce 
skewed numbers, the overwhelming majority of cases of false data that I have seen involved registrants who wouldn't 
want anybody to figure out who they were.

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

Find us on Facebook  |  .ORG Blog | Flickr | YouTube | Twitter |

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Mar 2012 15:55:01 +0000

> I disagree with this, although it's not a hill I'll die on.  

Same here… I'm not falling on my sword over this.

> didn't satisfy this need would not, IMO, be much of an advance.

I'm not questioning the need for differentiated access, simply questioning what it is the IETF is to do beyond providing multiple authentication mechanisms.

-andy

---

From: Jim Galvin <[email-masked]>
Date: Thu, 22 Mar 2012 16:09:21 +0000

Thanks for doing this Andy.

I support this revised charter.

Jim

-- On March 20, 2012 4:24:50 PM -0400 Andy Newton <[email-masked]> wrote 
regarding [weirds] REVISED Re:  a charter offering compromise --

---

From: Don Blumenthal <[email-masked]>
Date: Thu, 22 Mar 2012 12:20:15 -0400

Jim's post reminded me that I got lost in the discussion, a hazard of taking a couple of days away from the mailing list.

I also support the draft. You've done an excellent job of balancing the feedback.

---

From: "Michael Young" <[email-masked]>
Date: Thu, 22 Mar 2012 12:23:49 -0400

+1

Michael Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Don Blumenthal
Sent: March-22-12 12:20 PM
To: [email-masked]
Subject: Re: [weirds] REVISED Re: a charter offering compromise

Jim's post reminded me that I got lost in the discussion, a hazard of taking
a couple of days away from the mailing list.

I also support the draft. You've done an excellent job of balancing the
feedback.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 22 Mar 2012 19:05:15 +0100

> so i think a "note" that these "may" be provided by transport is not

+1, the data model could mark some fields/objects as not universally
harvestable.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 22 Mar 2012 14:10:51 -0400

On 3/22/12 11:36 AM, Don Blumenthal wrote:
> True, unless one thinks that criminals and other fraudsters have legitimate user concerns. ...

don, there is no conditional, no "unless" about the .aero, .coop,
.museum, .cat data. there's simply no statistically significant bad
data there.

so the "correctness" meta-requirement is already met.

> ... While my background may produce 

you work for, and i assume you are referring to the data available to
you, a registry with a registration policy which is price and other
costs equivalent (registration policy) to verisign's, and has the same
general correctness to non-correctness property of the sampled and
verified records in the data set.

the dollar cost alone to create an identifier is six or more times
less in any of the price capped registries than in those i've
mentioned above, in addition to the additional requirements of each on
registrants. bad actors are not price indifferent.

-e

---

From: Don Blumenthal <[email-masked]>
Date: Thu, 22 Mar 2012 14:27:09 -0400

From: [email-masked] [[email-masked]] On Behalf Of Eric Brunner-Williams [[email-masked]]
Sent: Thursday, March 22, 2012 2:10 PM
To: [email-masked]
Subject: Re: [weirds] REVISED Re:  a charter offering compromise

>.museum, .cat data. there's simply no statistically significant bad

I was being facetious with that statement. In any event, I think that we're making each other's points.
Your paragraph ended with "so factors other than legitimate user concerns are sources of bad data." 
A significant amount of bad registrations come from individuals or entities involved in illegal conduct. 
They don't use the TLDs that you mentioned.

>you work for, and i assume you are referring to the data available to
?you, a registry with a registration policy which is price and other

Don't assume. I have been with PIR for less than two years. I worked on online and Internet
investigations for the FTC for over 12.

Don

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Mar 2012 14:46:04 -0400

> .museum, .cat), so factors other than legitimate user concerns are

That simply doesn't follow.  The registries you mention are not gTLDs,
and therefore the user population is different.  Find me a gTLD that
hasn't any bad data, and I'll buy this argument.

That is not to say that all the bad data is from legitimate user
concerns.  But we can't know that until a completely unreasonable
requirement about global publication to anonymous queriers is lifted
in favour of something at least as inconvenient as looking things up
in the land registry office.  That's public data, too, but scammers in
jurisictions without any effective policing are not able to harvest my
street address from the comfort of their basement just because I have
a mortgage on my house.

Anyway, that's all a policy, not a protocol question.  My main point
is that I want protocol tools to _allow_ policy here, and we don't
have that now.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Mar 2012 14:47:52 -0400

> I'm not questioning the need for differentiated access, simply questioning what it is the IETF is to do beyond providing multiple authentication mechanisms.

Nothing.  I was just saying that this requirement ought to be in the
charter.  Since we plan to use http (and presumably also https), the
requirement is satisfied from the beginning.  This has the additional
benefit of commiting to a mileston we have met by design :)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 22 Mar 2012 20:01:42 +0100

> I do not understand the clarification being requested here. Can you

That quoted snippet is the only reference to the data model in the
revised charter, besides mentioning that WHOIS doesn't have one.

It seems to me that not only names and numbers have different data
models --which is quite obvious-- but also that the corresponding
communities have their minds on different /kinds/ of data models.

The choice of XML, and the various namespaces present in the RWS-DNRD
draft seem to consider extensibility as a registry-specific choice of
the representation of domain, contact, host, and registrar objects.
The cross product of local requirements and time evolution yields a
complicated framework, where apps have to be targeted at specific
classes of registries.  Will we end up with just numbers and names, or
rather numbers, names-com, names-thick, ..., names-etc?

Time evolution is implied.  If a new field, contact-lang, say, were
introduced anew, I'd expect it gets into some IANA table along with
its accompanying RFC, so that programmers can learn about fields and
upgrade their software accordingly.  Will the WG plan for such kind of
maintenance?

> Just thinking here, but maybe that could go in the requirements document.

Yes, but if we pin this particular numbers-vs-names difference, it
might help making yet another small step forward.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 22 Mar 2012 15:01:43 -0400

On 3/22/12 2:27 PM, Don Blumenthal wrote:
> ...

i've observed else where (sundry whois, fastflux, other policy/spec
working groups, that dollar cost (actual, not presented, so with
credit card fraud factored in), and time cost, appears to be
sufficient to meaningfully correlate rational economic actors and
their choice of namespaces for identifiers.

the significant exception to this was the apparent use of ~100
namespaces for rendezvous points for the .C variant of conficker. in
fact, far fewer namespaces were actually exercised by the .C authors,
as many had sufficient registration complexity to present a barrier to
its automated registration system.

subsequent authors of systems for which rendezvous points will be
necessary may elect to create inventories from existing registrations.

> investigations for the FTC for over 12.

thanks for the clarification as to the data which has been available
to you. 12 years ago i was trying to fix or kill the thing on :43*

-e

* http://www.ietf.org/mail-archive/web/provreg/current/msg02302.html

---

From: Don Blumenthal <[email-masked]>
Date: Thu, 22 Mar 2012 15:11:56 -0400

From: [email-masked] [[email-masked]] On Behalf Of Andrew Sullivan [[email-masked]]
Sent: Thursday, March 22, 2012 2:46 PM
To: [email-masked]
Subject: Re: [weirds] REVISED Re:  a charter offering compromise

>hasn't any bad data, and I'll buy this argument.

A minor point but one that is significant for purposes of how the name space is divided.
The top level domains that Erik mentioned are gTLDs, albeit sponsored ones rather than
open. The sponsored category is one reason that the bad guys don't/can't use them.

Don

---

From: "John Levine" <[email-masked]>
Date: 22 Mar 2012 19:28:37 -0000

>other than to note that all these MAY be provided at the HTTP layer.

I agree that we probably don't want to say much about them, I'd rather
not rule them out in the charter.

It would be interesting just to ask the RIRs whether they were willing
to agree that, say, HTTPS authentication with users and passwords was
adequate, so for my improved WHOIS scraper I don't have to do a
combination of HTTP passwords, client SSL certficates, credentials
entered into HTML forms, and six other authentication approaches that
haven't occurred to me yet.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Mar 2012 19:35:59 +0000

> rather numbers, names-com, names-thick, ..., names-etc?

I think you are saying the data model should be extensible, which is a goal inherited from 3707.

As to an IANA registry of data model extensions, I think encouraging Informational RFCs is simply good enough.

-andy

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 22 Mar 2012 15:42:47 -0400

> hasn't any bad data, and I'll buy this argument.

you are in a maze of twisty little passages, all alike ...

which of the pre-icann registries are generic, and which are not?
which of the 2000 and 2004 round of icann registrars are which?

some distinguish between "g" and "cc" only, others between "g", "s"
and "cc". having written the original meta proposal that lead to the
creation of the "s" form, and written winning proposals for both price
capped "g" and nexus encumbered "cc", and having some operational
responsibilities in several, i personally think that the best way to
map policy to registry is to look to the contracts.

however, the nuance i hope you'll consider is what if, instead of a
requirement that a .museum registrant be an icom member (or
colorably), or that a .coop registrant be a cooperative (or
colorably), or ... the only registration requirement could be a price
10x that of the cnobi registries -- which is about where the price
points actually are today and have been since these registries began
operations.

i hope you'll agree that rational economic actors are not price
indifferent, and given the choice of a use-and-loose registration in
.com for $6 and a use-and-loose registration in .cat for $60, absent
any specific utility in a .cat registration, the rational economic
actors will select .com over .cat.

so the registration policy, in the generalist of "s" vs "g" forms, is
not controlling.

to check this, compare the "g" vs "cc" forms, where one can look at
the price as a variable, and the nexus as a variable. cc's with $6
price points and no nexus are ... incorrectness equivalent to the
cnobi registries. the cc's with a lower price and a higher non-price
barrier (actual paper or a nexus requirement) are incorrectness
equivalent to the aero/coop/museum/cat registries.

> concerns.  But we can't know that until ...

actually the correlation of cost (dollar and non-dollar registration
overhead, including time necessary per transaction, paper and other
forms of non-dollar time/complexity cost) is something we know now.

we may actually know more about the correlations of bad data and the
value bad data provides its authors, and the registration supply chain
actors.

so without knowing if dick and jane lie about their phone number and
email address when registering ourlittlehomeonthe.net (which in fact
we already do know from registrant studies and from email harvest time
into spam list studies), we do know there are actors which use
registration systems to acquire assets, and the universe of actors who
have a contractual, or legal basis to interpose on the resulting
registrations is vastly smaller than "global ... anonymous queriers".

i don't think any waiting period is necessary to buy this bit o security.

> ... a completely unreasonable

i don't think we can do much to solve the no law west of the pecos
problem.

> Anyway, that's all a policy, not a protocol question.  My main point

mechanism allows policy. policy without mechanism is ... igf.

> is that I want protocol tools to _allow_ policy here, and we don't

here we are agreed, as we have been for years.

-e

---

From: Andy Newton <[email-masked]>
Date: Thu, 22 Mar 2012 19:49:21 +0000

> not rule them out in the charter.

So I'll ask again… what specific work is it that you seek from the IETF in this regard beyond the protocol supporting multiple authentication mechanisms? We can mention that we are using HTTP to get those mechanisms in the charter, but that seems redundant. Should we also say we wish HTTP to use TCP?

> haven't occurred to me yet.

But that starts with a policy question to each RIR. The answer cannot be found in the IETF. That's why I'm confused. Is this a request to open up the scope of possible work? If so, can more specifics be provided?

I'm not gonna stand in the way of having the language put in the charter my any means. It just seems either redundant or an indicator that the scope needs to be more clearly defined.

-andy

---

From: SM <[email-masked]>
Date: Thu, 22 Mar 2012 13:36:18 -0700

>which of the 2000 and 2004 round of icann registrars are which?

Does this even matter?

>mechanism allows policy. policy without mechanism is ... igf.

It's up to each special interest group to explain what mechanisms it 
would like to have to fulfill its policy needs.  If the goal is to 
build some mechanism in the hope that it might solve some 
hypothetical policy issue, it can end up generating useless IETF work.

Regards,
-sm

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 22 Mar 2012 17:12:12 -0400

>> which of the 2000 and 2004 round of icann registrars are which?

see andrew's note, and also don's comment.

> build some mechanism in the hope that it might solve some hypothetical
> policy issue, it can end up generating useless IETF work.

what a novel observation! you're probably the first person to think of
this.

-e

---

From: "John R. Levine" <[email-masked]>
Date: 22 Mar 2012 22:48:10 +0100

> So I'll ask again… what specific work is it that you seek from the IETF 
> in this regard beyond the protocol supporting multiple authentication 
> mechanisms?

I'd prefer if it supported one (1) authentication mechanism.  The open 
question is whether that's sufficient.

> But that starts with a policy question to each RIR. The answer cannot be 
> found in the IETF. That's why I'm confused. Is this a request to open up 
> the scope of possible work? If so, can more specifics be provided?

I specifically propose that the only authentication mechanism be HTTP 
basic authentication as described in RFC 2617, transported over HTTPS. 
If people have concrete reasons why that's inadequate, we can switch to 
any of the other usual suspects, but I don't want to say that you have to 
negotiate an authentication scheme separately with every provider unless 
there's an actual reason that's necessary.

Note that a common authentication scheme does not mean common credentials, 
nor does it mean common semantics of credentials.  Those would be nice, 
but they're probably too much to ask.  If we have a common authentication 
scheme, my client can keep all the credentials in a table, and add a new 
one by adding a line to a config file.  If not, I have to patch the code 
every time I run into an authentication scheme slightly unlike the ones I 
already handle.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Mar 2012 11:20:09 +0100

> is a goal inherited from 3707.

Does CRISP allow local extensions like EPP?

---

From: Andy Newton <[email-masked]>
Date: Fri, 23 Mar 2012 12:13:39 +0000

On Mar 22, 2012, at 5:48 PM, John R. Levine wrote:

> I specifically propose that the only authentication mechanism be HTTP basic authentication as described in RFC 2617, transported over HTTPS. If people have concrete reasons why that's inadequate, we can switch to any of the other usual suspects, but I don't want to say that you have to negotiate an authentication scheme separately with every provider unless there's an actual reason that's necessary.

And now you have me concerned. In the ARIN region, we have APIKeys used for our restful registration service, template submissions, and access to bulk whois. Extending it to restful whois would be a natural for us. I think the RIPE NCC already has an active authentication scheme on their restful whois service. Are you saying we can no longer use those schemes?

If the US gov requires us to accept client certs signed by the USDOJ, does that mean we cannot also accept client certs issued by the EU? Does it mean we cannot participate in a ticket distribution scheme using HTTP cookies initiated by ICANN?

Authentication schemes are not mutually exclusive. We do not need to mandate only one. And in the absence of policy driving one, the selection of the mechanism to use is premature.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 23 Mar 2012 12:31:03 +0000

> Does CRISP allow local extensions like EPP?

Even more so. :)

But if you want it in the charter, my suggestion for para 7 last sentence is to change this:

    The overall effort will be broadly aligned with 

to this

    The overall effort will be broadly aligned with 
    a subset of the Cross Registry Internet Service Protocol (CRISP) 
    Requirements (RFC 3707), but with the explicit additional goals of 
    producing a simple, easy-to-implement protocol, supporting 
    internationalized registration data, an extensible data model capable
    of supporting local extensions without substitution of core data
    classes, and, specifically for name registries, a data model capturing 
    the needs of internationalized domain names.

Looking at the requirements document, I was trying to find a place to put this in there but it occurred to me the requirements document talks about what clients and server should do but not about the properties and/or operational principles of the protocol itself.

-andy

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 23 Mar 2012 09:35:37 -0400

> Authentication schemes are not mutually exclusive. We do not need to mandate only one. And in the absence of policy driving one, the selection of the mechanism to use is premature.

this isn't the only implied uniqueness of mechanism that bothers me.

we've already had more fun than most pay grades allow when gost wasn't
allowed for dnssec, and this isn't something to repeat just for fun.

-e

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Mar 2012 15:07:43 +0100

On 23/Mar/12 13:31, Andy Newton wrote:
> But if you want it in the charter, [...]

Personally, I'd prefer the charter to say that there are no local
extensions.  This is the one reason I like WEIRDS: to enable objects
served by RIRs to be referenced from IETF protocol specifications,
like DNS items are.  For example, the abuse-mailbox of a given IP.
(Obviously, this is a numbers-only expectation, since protocol needs
for names, such as SPF records, go on DNS directly.)

> my suggestion for para 7 last sentence is to change [...]
> to this [...]
> 
>     an extensible data model capable

Would it be feasible to confine extensions to additional data items
that can be ignored by generic apps?

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 23 Mar 2012 10:12:58 -0400

On 3/23/12 10:07 AM, Alessandro Vesely wrote:
> like DNS items are. 

our problem space may be more complex than that of a lookup mechanism
over a loosely coupled distributed database implementing resource to
address mapping.

and, the uniqueness of that implementation has been problematic due to
the absence of local extensions. cnnic turned on their root server
constellation in november 2001, enabling support for han script as a
"local extension", among other policy goals.

-e

---

From: Andy Newton <[email-masked]>
Date: Fri, 23 Mar 2012 10:35:31 -0400

> that can be ignored by generic apps?

Yes, it is feasible. Take a look at Section 3 of 
draft-newton-et-al-weirds-rir-json-response-01.

I understand what you are trying to say... local extensions shouldn't 
inhibit the interpretation of standard values. But wordsmithing it into 
the charter may be too much. Since the charter specifically points to 
this draft and says "this is the type of thing we want" is that good enough?

-andy

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Mar 2012 15:52:58 +0100

On 23/Mar/12 15:35, Andy Newton wrote:
> inhibit the interpretation of standard values. But wordsmithing it
> into the charter may be too much. Since the charter specifically
> points to this draft and says "this is the type of thing we want" is
> that good enough?

Yes it is, thank you.  I'm unable to get if such fashion and pattern
may also cover the more complex problem space of names.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Mar 2012 11:38:35 -0400

On Fri, Mar 23, 2012 at 10:35:31AM -0400, Andy Newton wrote:
> wordsmithing it into the charter may be too much. Since the charter
> specifically points to this draft and says "this is the type of
> thing we want" is that good enough?

I say "yes".  As I've tried to argue several times, attempting to
write exactly what the result is going to do into the charter is
putting the work in the wrong place.  The charter should guide us, not
tell us what to do. 

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John R. Levine" <[email-masked]>
Date: 23 Mar 2012 18:35:04 +0100

>> I specifically propose that the only authentication mechanism be HTTP 
basic authentication as described in RFC 2617, transported over HTTPS. If 
people have concrete reasons why that's inadequate, we can switch to any 
of the other usual suspects, but I don't want to say that you have to 
negotiate an authentication scheme separately with every provider unless

there's an actual reason that's necessary.     >
> And now you have me concerned. In the ARIN region, we have APIKeys used for our restful registration service, template submissions, and access to bulk whois. Extending it to restful whois would be…

No, I'm pretty sure I said "If people have concrete reasons why that's 
inadequate, we can switch to any of the other usual suspects."

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Mar 2012 14:23:25 -0400

Again, isn't this an issue _for_ the WG, and not an issue _about_ the
WG?  That is, is there any reason at all that these decisions need to
be made as part of the charter?  I say no.

A

On Fri, Mar 23, 2012 at 06:35:04PM +0100, John R. Levine wrote:
> basic authentication as described in RFC 2617, transported over
> HTTPS. If people have concrete reasons why that's inadequate, we can
> switch to any of the other usual suspects, but I don't want to say
> that you have to negotiate an authentication scheme separately with
> every provider unless
> 
> 
> No, I'm pretty sure I said "If people have concrete reasons why
> that's inadequate, we can switch to any of the other usual
> suspects."
> 
> Regards,

-- 
Andrew Sullivan
[email-masked]

---

From: Francisco Arias <[email-masked]>
Date: Sun, 25 Mar 2012 02:02:35 -0700

Perhaps the spec should have one mandatory auth schema and parties
interested on having their own could specify theirs on informational RFCs.

__

Francisco.

On 3/23/12 5:13 AM, "Andy Newton" <[email-masked]> wrote:

>>any of the other usual suspects, but I don't want to say that you have
>>to negotiate an authentication scheme separately with every provider
>>unless there's an actual reason that's necessary.
>
>And now you have me concerned. In the ARIN region, we have APIKeys used
>for our restful registration service, template submissions, and access to
>bulk whois. Extending it to restful whois would be a natural for us. I
>think the RIPE NCC already has an active authentication scheme on their
>restful whois service. Are you saying we can no longer use those schemes?
>
>If the US gov requires us to accept client certs signed by the USDOJ,
>does that mean we cannot also accept client certs issued by the EU? Does
>it mean we cannot participate in a ticket distribution scheme using HTTP
>cookies initiated by ICANN?
>
>Authentication schemes are not mutually exclusive. We do not need to
>mandate only one. And in the absence of policy driving one, the selection
>of the mechanism to use is premature.
>
>-andy
>

---

From: "John R. Levine" <[email-masked]>
Date: 25 Mar 2012 11:47:30 +0200

> interested on having their own could specify theirs on informational RFCs.

If that's workable, that would be great.  I get the impression that the 
strength of the authentication depends on its purpose.  If you're just 
relaxing rate limits, fairly weak auth might be OK, if you're showing PII 
for law enforcement, stronger auth would be needed.

Regards,

---

From: Avri Doria <[email-masked]>
Date: Mon, 26 Mar 2012 07:23:27 -0400

Hi,

Sorry been traveling.

I think there are small differences between the two phrase, 

- as an initial foundation seems to mean we have decided to build on these documents
- as an initial basis seems to mean we have decided that these provide the starting point for the discussion

I prefer the 'as an initial basis' as I don't think the charter should pre-determine the decisions the WG will/would make.
But the difference might just be a nuance, so I could live with either, as long as we are clear about not limiting ourselves to just these two documents in terms of foundations of the work. 

thanks

avri

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 26 Mar 2012 09:47:39 -0400

Colleagues,

I'm not proposing a re-write of the charter, but there are some things
I'm pointing out:

The rational offered is a perceived, undifferentiated requirement for
consistency. As spam, trademark, and law enforcement, even .C
(conficker) interest is not name space indifferent, and may not be
address space indifferent, the rational offered is an
over-requirement, or worse, the substitution of one requirement for
one or more requirements.

The dream of a universally valid contact form has been pursued before,
with little success. A single data model for what constitutes a legal
service address (we should not flinch from identifying why a "valid
postal address" is sought by some requirement proponents) may not be a
tractable goal, and data models may be less than universally scoped.

The mechanism could be called "lookup" or ... but it is simply another
form of publication, ancillary to the form of publication we had
initially via hosttables, published over port 21, and currently via a
distributed lookup on port 53. The exhaustive (or simply large scale
sampling) acquisition of contact information (email, but also phone
and other social data relations) by third parties has been and remains
an identified problem. The original (954) publication was limited to
the DoD/DARPA requestors. The repurposing of 954, removing limits upon
publication, is not a requirement, though this has been the situation
in fact since the privitization of the public names and addresses
infrastructures.

A possible goal of WIERDS is to specify mechanisms capable of scalable
limits on publication, among other possible goals.

Proposed changes to the operative text:

>     service, and standardize a single data framework.

s/standardize a single data framework./propose one or more data
formats, appropriate to the applicable constraints./

>                                                     ... That framework
>     RESTful data service using HTTP (optionally using TLS).

No change other than to conditionally pluralize "framework" as
"framework(s)".

>                                                     ... The data
>     other optional formats.

s/one mandatory format,/specified format(s), appropriate to the
applicable constraints,/

s/though the working group may consider other optional formats./and
the working group may specify additional formats./

>                      ... The overall effort will be broadly aligned with 
>     internationalized registration data and,

I don't think constraining this working group to any prior is
inherently harmless, so out of caution I propose removing this long
clause.

>                                                  ... specifically for

s/a data model/appropriate data model(s)/.

Broadly, a single requirement means we're treating all current, and
likely, identifier allocators as having no salient differences, which
may be less useful than recognizing those differences which do "make a
difference".

Eric

---

From: Dave Piscitello <[email-masked]>
Date: Mon, 26 Mar 2012 07:36:43 -0700

This is very workable within the SSL framework.
If you wanted (or policy required), you'd support different auth methods for different user groups/communities. Accommodate for this kind of requirement and leave the issue of identifying/validating user groups to whatever policy process applies.