Subject: [Crisp] Working Group Last Call on AREG docs

From: April Marine <[email-masked]>
Date: Tue, 15 Feb 2005 12:16:07 -0800 (PST)

This is the official Working Group Last Call for the following two docs. 
The first has been discussed extensively; the second was a spinoff created 
after the last meeting.

Please send comments to the mailing list. This two week last call will end 
on March 1 with the hope that, if needed, the docs can be spun and sent to 
the IESG shortly after the March meeting (where feedback can be 
discussed).

thanks!
April and George

IRIS - An Address Registry (areg) Type for the Internet Registry
Information Service
draft-ietf-crisp-iris-areg-09.txt

IRIS - URI Resolution for AREG Type for the Internet Registry
Information Service
draft-ietf-crisp-iris-areg-urires-00.txt

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Feb 2005 17:41:07 -0800

I am a bit confused here.  The urires doc does not seem to have
been updated since the working group meeting in which (I thought)
we agreed not to include  iris.nro.net as a default top.  Can I have
pointers to the working group discussion where that was changed?
			thanks,
				Ted

At 12:16 PM -0800 2/15/05, April Marine wrote:
>This is the official Working Group Last Call for the following two 
>docs. The first has been discussed extensively; the second was a 
>spinoff created after the last meeting.
>
>Please send comments to the mailing list. This two week last call 
>will end on March 1 with the hope that, if needed, the docs can be 
>spun and sent to the IESG shortly after the March meeting (where 
>feedback can be discussed).
>
>thanks!
>April and George
>
>

---

From: Shane Kerr <[email-masked]>
Date: Wed, 16 Feb 2005 12:54:19 +0100

Ted,

IIRC, we agreed not to include iris.nro.net in the areg document, and rather 
to put it into a separate document, the urires document.

The idea was to separate the schema & protocol definition from the service 
resolution (I think it was your idea, Ted).

Ted Hardie wrote:
>> Please send comments to the mailing list. This two week last call will 
>> end on March 1 with the hope that, if needed, the docs can be spun and 
>> sent to the IESG shortly after the March meeting (where feedback can 
>> be discussed).
>>
>> thanks!
>> April and George
>>
>>

-- 
Shane Kerr
RIPE NCC

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Feb 2005 08:18:54 -0800

At 12:54 PM +0100 2/16/05, Shane Kerr wrote:
>Ted,
>
>IIRC, we agreed not to include iris.nro.net in the areg document, 
>and rather to put it into a separate document, the urires document.
>
>The idea was to separate the schema & protocol definition from the 
>service resolution (I think it was your idea, Ted).

I do think I suggested that. I thought I also suggested that we
leave the top as "subject to client configuration", so that the document
did not enshrine a particular domain name.  My reasoning for this
was that it would be better to build clients capable of configuration
on this point rather than having a hard-coded the address; during a DDoS attack
on iris.nro.net, to give a small example, the ability to re-point at
an active mirror or different system is valuable.  I also remember
vividly how long the SRI machines got whois queries after things
functionally changed.  That name is enshrined in RFC 954, which
didn't get updated to remove that kind of detail until Leslie took
it on RFC 3912, and that was probably part of the reason the
stream ran on so long.  I suspect April remembers this even better
than I do.

Moving the top level name to a different document *does* make it
much easier to rev, but I do wonder if that is enough.

Speaking only as a young geezer,
				Ted

---

From: April Marine <[email-masked]>
Date: Wed, 16 Feb 2005 09:34:52 -0800 (PST)

I looked at the minutes (which, thanks to Kim Davies, were quite clear on 
what we said). My memory was we were going to do the doc as done, but
it could be open for interpretation:

------------
from minutes:

There is a concern that the IESG will not be happy with having a
specific host hardcoded in the specification.

George Michaelson stated he felt uncomfortable with having a host in the
specification, and would be tempted not to specify the server selection
process as a defacto one will likely naturally emerge anyway.

Scott Hollenbeck echoed this feeling that it didn't seem right to
include a hostname.

Ted Hardie said you could always submit the draft with the reference in,
but the IESG may remove it. He said he saw the advantage of having a
single root to manage the referral process, but some people may want to
set up other services outside this one. He noted that an effort had
recently concluded on pulling operational things out of the WHOIS
specification, making it a purely technical. He believed it could be
appropriate to publish a second document that documented NRO's role in
bootstrapping searches, as it doesn't build a dependency into the
protocol on a single root.

-------------

The minutes also say that I said we should take this to the list, which 
unfortunately, I don't think I ever really did. So I guess we are having 
that conversation now. :)

April

On Wed, 16 Feb 2005, Ted Hardie wrote:

>> IIRC, we agreed not to include iris.nro.net in the areg document, and 
>> rather to put it into a separate document, the urires document.
>> 
>>>> The first has been discussed extensively; the second was a spinoff 
>>>> created after the last meeting.
>>>> 
>>>> sent to the IESG shortly after the March meeting (where feedback can be 
>>>> discussed).
>>>> 
>>>> thanks!
>>>> April and George
>>>> 
>>>>

---

From: Shane Kerr <[email-masked]>
Date: Thu, 17 Feb 2005 11:44:37 +0100

> much easier to rev, but I do wonder if that is enough.

I guess my question is:

- How does someone attempting to write a client know where to start looking?

A more general question is:

- In IRIS, where do I start my resolution process?

In IRIS, the answer is: at the top.

For DREG, this is at the top of the DNS.

For EREG, I am guessing this is also at the top of the DNS.

For AREG, there is no direct mapping (or indirect in some cases) between the 
data being searched for and a domain name. Rather than force the AREG to use 
DNS, an alternate top needs to be defined. The easiest way seemed to be... 
IRIS.NRO.NET.

I think the requirements are a directory service that has a natural mapping 
from number ranges. Neither DNS nor LDAP really has that, but I feel that 
IRIS *does*, once you have gotten around the tricky problem of where to 
*start* the lookup process.

-- 
Shane Kerr
RIPE NCC

p.s. I haven't looked at RREG, so I don't know where it starts.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 17 Feb 2005 10:53:59 -0500

On Feb 17, 2005, at 5:44 AM, Shane Kerr wrote:

> where do I start my resolution process?

start at 0.0.0.0 until you get to 255.255.255.255.  :)

> For AREG, there is no direct mapping (or indirect in some cases) 
> between the data being searched for and a domain name. Rather than 
> force the AREG to use DNS, an alternate top needs to be defined. The 
> easiest way seemed to be... IRIS.NRO.NET.

I think it is a good idea to have the draft suggest to implementors to 
make the AREG top a configuration option... and to also suggest the 
default should be IRIS.NRO.NET.  Indeed, there will be people 10 or 15 
years from now who will query that name long after it has changed to 
IRIS.SUPER-NRO.NET just like there are people who never update their 
DNS hints file.  Unless we plan on having this updated everytime MS 
Windows Update executes, I see no way around it.

-andy

---

From: Rick Wesson <[email-masked]>
Date: Thu, 17 Feb 2005 14:34:35 -0800

just a clarification question....

Why must contacts have their address associated with an organization, 
there appears no capability to have a contact with any address 
information of their own. The slippry slope is that only number 
deligations can be made to organizations.

is my logic flawed? any education would be much appreciated.

-rick

---

From: Andrew Newton <[email-masked]>
Date: Thu, 17 Feb 2005 17:42:36 -0500

> is my logic flawed? any education would be much appreciated.

I think it is simply that none of the RIRs have their databases modeled 
that way.  The addresses are with the organization, not the contact.

-andy

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Feb 2005 16:14:35 -0800

>- How does someone attempting to write a client know where to start looking?

And I guess this is the disconnect.  Why is this done at client write time,
rather than at client configuration time?

>In IRIS, the answer is: at the top.

I guess that this is also a question for me.  Given the referral
mechanism, does it have to be "the top", or can it be anyone
willing to give you a referral?  For data which relates to
a hierarchy, starting at the top of the hierarchy ensures
that the person you're talking to knows at least how to
give the referral to the next level.  For data which is not
inherently hierarchical, is this still true?  Right now,
if I understand it correctly, if I ask ARIN about something
that is undelegated, it sends me to IANA; if I ask about
something delegated to RIPE, it sends me to RIPE.
If we don't enshrine iris.nro.net in the document, could
the RIRs not operationally decide whether they would
refer to each other directly or via iris.nro.net?

Again, just another bozo thinking about the problem,
			regards,
				Ted

---

From: Engin Gunduz <[email-masked]>
Date: Fri, 18 Feb 2005 10:25:51 +0100

> refer to each other directly or via iris.nro.net?

Why not.  But when the RIRs do not send the clients to IANA
and start sending them to each other, there is likely to be data 
synchronisation problems (each RIR must have an up-to-date
allocation map, otherwise the path that client will take will
be longer than required).

For the document: I think the idea was that, we needed something simple
to start with, and when have more experience with referral mechanism,
we can come up with a refined document.
-engin

-- 
Engin Gunduz
RIPE NCC Software Engineering Department

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 18 Feb 2005 12:31:21 -0200

> that way.  The addresses are with the organization, not the contact.

Ops... if this is true (I'll check the draft) we have a problem.

The RIRs actually have a mixed contact/Address model,

RIPE+APNIC only have contacts with their respective addresses, what
they don't have is actually the organization [1]. Sometimes they use
the "descr" attribute on the inetnum obj to embed addresses [2].

ARIN+LACNIC have contacts with their respective addresses, and
organization, with address too. [3]

The protocol should support both models with the use of optional
objects.

Fred

[1]
 > whois -h whois.ripe.net 193.0.0.193
 ...
 inetnum:      193.0.0.0 - 193.0.7.255
 netname:      RIPE-NCC
 descr:        RIPE Network Coordination Centre
 descr:        Amsterdam, Netherlands
 remarks:      Used for RIPE NCC infrastructure.
 country:      NL
 admin-c:      AMR68-RIPE
 admin-c:      RDK-RIPE
 tech-c:       OPS4-RIPE
 status:       ASSIGNED PI
 mnt-by:       RIPE-NCC-MNT
 mnt-lower:    RIPE-NCC-MNT
 changed:      [email-masked] 20030522
 source:       RIPE
 ...
 person:       Andrei M. Robachevsky
 address:      RIPE Network Coordination Centre (NCC)
 address:      Singel 258
 address:      NL-1016 AB Amsterdam
 address:      Netherlands
 phone:        +31-20-535-4444
 fax-no:       +31-20-535-4445
 e-mail:       [email-masked]
 nic-hdl:      AMR68-RIPE
 mnt-by:       RIPE-NCC-MNT
 changed:      [email-masked] 20001016
 source:       RIPE
 ...  

[2]
 > whois -h whois.apnic.net 202.12.29.20
 ...
 inetnum:      202.12.28.0 - 202.12.29.255
 netname:      APNIC-AP
 descr:        Asia Pacific Network Information Center, Pty. Ltd.
 descr:        Level 1 - 33 Park Road.
 descr:        Milton QLD 4064
 descr:        Australia
 country:      AU
 admin-c:      AIC1-AP
 tech-c:       NO4-AP
 mnt-by:       APNIC-HM
 changed:      [email-masked] 19980918
 status:       ASSIGNED PORTABLE
 source:       APNIC
 ...
 person:       APNIC Network Operations
 address:      Level 1
 address:      33 Park Road
 address:      Milton QLD 4064
 country:      AU
 phone:        +61 7 3858 3100
 fax-no:       +61 7 3858 3199
 e-mail:       [email-masked]
 nic-hdl:      NO4-AP
 remarks:      Administrator for APNIC Network Operations
 notify:       [email-masked]
 mnt-by:       MAINT-APNIC-AP
 changed:      [email-masked] 19981111
 changed:      [email-masked] 20020211
 source:       APNIC

[3]
 > whois -h whois.lacnic.net 200.160.0.0
 ...
 inetnum:     200.128/9
 status:      allocated
 owner:       Comite Gestor da Internet no Brasil
 ownerid:     BR-CGIN-LACNIC
 responsible: Frederico A C Neves
 address:     Av. das Nações Unidas, 11541, 7° andar
 address:     04578-000 - São Paulo - SP
 country:     BR
 phone:       +55 11 9119-0304 []
 owner-c:     CGB
 tech-c:      CGB
 inetrev:     200.128/9
 nserver:     A.DNS.BR
 nsstat:      20050217 AA
 nslastaa:    20050217
 ...
 nic-hdl:     CGB
 person:      Comite Gestor da Internet no Brasil
 e-mail:      [email-masked]
 address:     Av. das Nações Unidas, 11541, 7° andar
 address:     04578-000 - São Paulo - SP
 country:     BR
 phone:       +55 19 9119-0304 []
 created:     20020902
 changed:     20020902
 ...

---

From: "Tim Christensen" <[email-masked]>
Date: Fri, 18 Feb 2005 10:00:18 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Frederico A C Neves
> Subject: Re: [Crisp] Working Group Last Call on AREG docs
> 
> they don't have is actually the organization [1]. Sometimes 
> they use the "descr" attribute on the inetnum obj to embed 
> addresses [2].
> 

Correct, ARIN associates addresses with both organizations and with
contacts.

> The protocol should support both models with the use of 
> optional objects.

Agreed.  As I mentioned briefly to Andy late last night I'll go check the
draft too.

Tim

---

From: Andrew Newton <[email-masked]>
Date: Fri, 18 Feb 2005 10:14:49 -0500

> The protocol should support both models with the use of optional

I think this is easily enough done in one of two ways:
1) just put the address elements in the contact result as optional 
(RIPE,APNIC will never use them, ARIN,LACNIC will never use the ones in 
the organization result-- I assume)
2) create a separate address result that each may refer to as a 
temporary reference (temporary on the assumption that there is no 
full-fledged address object in the DB).

#1 is slightly more work for clients, #2 is slightly more work for 
servers.  And I do mean slightly in both cases because neither is a big 
deal.

Personally, I like #2 because it seems more normalized, but I could go 
either way.

-andy

---

From: Engin Gunduz <[email-masked]>
Date: Fri, 18 Feb 2005 16:43:34 +0100

On 2005-02-17 14:34:35 -0800, Rick Wesson wrote:
> information of their own. 

This must be an oversight of mine. Contacts must have address field
indeed, like organisations.

Thanks for catching this...
-engin

> The slippry slope is that only number

---

From: "Tim Christensen" <[email-masked]>
Date: Fri, 18 Feb 2005 11:34:05 -0500

> On Behalf Of Andrew Newton

Not a safe assumption. For ARIN, addresses are mandatory elements of both
Orgs and Contacts.
ARIN would use both.  (Not that this answer affects your #1 suggestion per
se)

> full-fledged address object in the DB).

It seems more normalized, yes, but it's also somewhat more cumbersome given
that address overlap among multiple Orgs or Contacts is quite a bit less
than you might think.  There is not much address commonality, even among
contacts who work for the registered org, because things like mail stops,
suite numbers, etc. make them different.

> Personally, I like #2 because it seems more normalized, but I 

I'm rather ambivalent as to which method is used, but the ability should
exist.

Tim

---

From: Andrew Newton <[email-masked]>
Date: Fri, 18 Feb 2005 13:49:07 -0500

> suite numbers, etc. make them different.

Good point.  So #1 is probably best.

-andy

---

From: William Leibzon <[email-masked]>
Date: Fri, 18 Feb 2005 13:49:15 -0800 (PST)

On Fri, 18 Feb 2005, Tim Christensen wrote:

>> servers.  And I do mean slightly in both cases because
>> neither is a big deal.

Having one central address database table is indeed correct approach for
normalizing database schema, but its going to be a pain building interface
for it (for users to be able to refer to address object).

What we could instead is to have contact be considered to linked to
organization object. Right now they are already linked as you may notice,
but its in different way as contacts are responsible for certain roles 
within the organization or roles for netobjects, here I'm talking about 
linking for purposes of showing that contact works for organizaiton, but 
he may not necesserily be responsible for any function of that organization
and may instead be reponsible for something as contractor working for 
another company. Having this link would automaticly mean that contact 
would have address coming from organization object.

Implementation wise this means address is gone from contact and instead
optional organization id is added and those that need address will have
to have organization object created. For large organization, it should
be possible to add suborg under its main org (a division or specific
office).

Note: I'm unsure how well this complexity will work for RIPE and others
as I'm also a lot more familiar with how arin structured its database,
but I suppose it will just mean that for RIPE & APNIC, orgid for contact 
will always be NULL, which isn't too difficult.

---
William Leibzon
   mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
   http://www.elan.net/~william/emailsecurity/
Whois & DNS Network Investigation Tools:
   http://www.completewhois.com

---

From: "Tim Christensen" <[email-masked]>
Date: Fri, 18 Feb 2005 17:25:09 -0500

> From: William Leibzon [mailto:[email-masked]] 
> Subject: RE: [Crisp] Working Group Last Call on AREG docs
> 
> > It seems more normalized, yes, but it's also somewhat more 
> cumbersome 
> > given that address overlap among multiple Orgs or Contacts 
> is quite a 
> > bit less than you might think.  There is not much address 
> commonality, 
> > even among contacts who work for the registered org, because things 
> > like mail stops, suite numbers, etc. make them different.
> >
> neither is a 
> >> big deal.
> Having one central address database table is indeed correct 
> approach for normalizing database schema, but its going to be 
> a pain building interface for it (for users to be able to 
> refer to address object).
> 
> What we could instead is to have contact be considered to 
> linked to organization object. Right now they are already 
> linked as you may notice, but its in different way as 
> contacts are responsible for certain roles 
> he may not necesserily be responsible for any function of 
> that organization and may instead be reponsible for something 
> as contractor working for 

I am not in support of this suggestion.

If a contact is not responsible for any functions in the organization, why
would the contact's information even exist in this directory service?  I
have a hard time seeing this protocol expanding to "phone book" purposes,
both in functional terms and in scale.  There are other ways to do that
already.

> Implementation wise this means address is gone from contact 
> and instead optional organization id is added and those that 
> need address will have to have organization object created. 
> For large organization, it should be possible to add suborg 
> under its main org (a division or specific office).

This has the unfortunate side effect of forcing all
"independent-contractor-Ipjockeys" to register their organization in order
to have an address for their contact information.  There are contacts which
are not employees of the organization for which they are a contact, and
furthermore the contact's own organization (IP-management-R-us, let's say)
does not have a registered org itself (because it doesn't have any number
resources to register).

I am strongly against constraining address to only an Org and then somehow
having to kludge through orgs to establish contact addresses.

Tim

---

From: William Leibzon <[email-masked]>
Date: Fri, 18 Feb 2005 16:47:47 -0800 (PST)

On Fri, 18 Feb 2005, Tim Christensen wrote:

> would the contact's information even exist in this directory service?

<sarcasm>
Thanks for deleting CWHOIS-ARIN contact because of not being associated 
with any organization. Guess that it was there for different purpose as 
documented at http://www.sixxs.net/tools/brs/ was not of concern to ARIN...
</sarcasm>

To the point, as I noted, he maybe responsble, but work for one organization
(or himself) but at the same time have technical role as contact for different
organization (contractor relationship is an example). And same contact can 
easily have roles at more then one organization also, so link to ORG from 
contact would establish what his primarily organization is but it IS NOT 
the same as link from ORG or NETBLOCK as the contacts are currently used.

> I have a hard time seeing this protocol expanding to "phone book" 
> purposes, both in functional terms and in scale.  There are other ways 
> to do that already.

Whois is in fact a phone-book for network registration data already.
Also since address is to be optional, the contact can enter or not,
so its no different then now or with direct address in contact table.

> to have an address for their contact information.

So, what's a problem especially if address is optional? And they can have 
organization as personal name too if they want, they are quite many orgs
like that in ARIN db as is now.

> There are contacts which are not employees of the organization for which 
> they are a contact

Exactly, this way they can be contact for one organization and optionally
indicate by means of ORGID what organization they are really employed by.

> ,and furthermore the contact's own organization (IP-management-R-us, 
> let's say) does not have a registered org itself (because it doesn't 
> have any number resources to register).
>

Its not a cludge. And I can assure you that 99+% of people looking for
contact data ARE NOT looking for physical address and only want to see
email address and phone (as they get it with netblock whois currently).
In fact, I'd not be surprised if direct queries for contact in ARIN are
in the ratio of 1:1000 (or more) to queries for netblock and that
direct queries for ORG may even be more common then for contact.

---
William Leibzon

---

From: Rick Wesson <[email-masked]>
Date: Mon, 21 Feb 2005 15:11:18 -0800

William,

Having s single IrisContact which has attributes of isRole, and 
isOrganization would be simpler than seporate objects for contact and 
organizations. Simply removing organization and adding a new attribute 
to contact whould be the best normalization of this schema.

-rick

William Leibzon wrote:

> within the organization or roles for netobjects, here I'm talking 
> about linking for purposes of showing that contact works for 
> organizaiton, but he may not necesserily be responsible for any 
> function of that organization
> but I suppose it will just mean that for RIPE & APNIC, orgid for 
> contact will always be NULL, which isn't too difficult.
>
> ---
> William Leibzon
>------------------------------------------------------------------------
>