Subject: Re: Minutes of our Minneapolis Meetings (rough cut)
From: Jaap Akkerhuis <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Date: Thu, 29 Mar 2001 12:13:52 +0200

These are the merged minutes taken by James Seng and Olafur Gudmundsson.
    (Thanks.)
    
    Please send in your comments on this real soon before this becomes part of
    the "permanent record:"

At the end of the Transport discussion I'm quoted:
    
    Jaap: I dont mind Email template.

It looks like I wasn't really clear. What I wanted to say was that

  - There should be an email transport as well. A lot of the TLDs
    (such as ccTLDs) are already using email for registration
    (with ot without templates). An email tranport mechanism
    will also be a nice transition mechanism for registries
    who want to upgrade to a standard protocol such as the
    proposed epp.

	jaap

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked]
Date: Mon, 12 Mar 2001 14:00:02 -0800 (PST)
Cc: [email-masked] (George Belotsky), [email-masked] (William Tan), [email-masked] (Bill Manning), [email-masked]
Sender: [email-masked]

% e75ad859-83db-4225-a564-120f2fd0d5a9@RIPE 
% 
% or more generally:
% <objectid>@<administrative ID>
% 
% This is what you use in 99% of the cases in the protocol. Both
% sides are globally unique so you can be sure that if RIPE
% no longer has the thing it will still have the same name of
% e75ad859-83db-4225-a564-120f2fd0d5a9 no matter where it moved
% to. The RIPE service could even give you a referal to where it
% thinks it got moved to....
% 
% Now, if you want to build an adjunct service to find an object id without
% an administative ID then that's a slower, more exhaustive search.
% But it could be done because it would be an atypical query and thus
% one that could be done as a low priority process...
% 
% Now that I think about it I guess this was Bill's point just repackaged..
% 
% -MM

	BING-BING-BING.... 
	And Ricks point as well.  
	e75ad859-83db-4225 is just icky.... :)

-bill

From: "William Tan" <[email-masked]>
To: <[email-masked]>
Subject: Re: confidentiality and transfers
Date: Tue, 27 Mar 2001 22:27:01 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

1.  Since confidentiality is a key issue, and the provisioning registry
protocol is built upon other protocols, it would be wise to choose something
that provides confidentiality at the transport layer (TLS or another
protocol).

>>>>> However, for the e-mail transport, do we define an encryption
mechanism?  Does the transport team have anything to say about this?

If the unique "registry handle" is used as the check to make modifications
to a domain registration, the generation and transmission of that handle
must be secured from evedroppers.

>>>>> I would expect implementation to check the handle against the
authenticated peer (registrar) to see if the modification can be authorized.
Object handles should be public, but may be shielded from the end-user of
course.

It might be necessary to have an authentication of a registrar by another
registrar before any objects are transferred.  Otherwise, an attacker that
has aquired the handle for a domain registration could assume control of it
by impersonating another registrar and requesting the domain to be
transferred to the attacker.

>>>>> It is documented in the requirement draft in section 3.4.3 and 3.4.4.
The EPP draft (2.6.3.4) also specified the semantics for the transfer
process, though a full example would be helpful.

wil

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Scott Rose'" <[email-masked]>, [email-masked]
Subject: RE: confidentiality and transfers
Date: Tue, 27 Mar 2001 07:45:31 -0500
Sender: [email-masked]

-----Original Message-----
From: Scott Rose [mailto:[email-masked]]
Sent: Monday, March 26, 2001 4:24 PM
To: [email-masked]
Subject: confidentiality and transfers

[snip]

> Is this last observation valid?  Would registrars need to authenticate
> themselves before requesting an object transfer?

Yes.  Authentication and identification requirements are specified in
section 3.2.

<Scott/>

To: "Scott Rose" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: confidentiality and transfers 
Date: Mon, 26 Mar 2001 18:04:00 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

...
> I use the term "confidentiality" to mean "encryption of messages in transit",
> since "privacy" means different things to different people and it is hard to
> determine what "we need privacy" means today.

As a general practice, it would be helpful if people wrote exactly what they
mean, e.g., "encryption of messages in transit", or announcement of data
collection practices, rather than "security" or "privacy" or "apple pie".

>                              ... Would registrars need to authenticate
> themselves before requesting an object transfer?  

Only if they wanted the regisTRY to perform the requested operation.

From: "Scott Rose" <[email-masked]>
To: <[email-masked]>
Subject: confidentiality and transfers
Date: Mon, 26 Mar 2001 16:24:05 -0500
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_04F6_01C0B611.2D5F6660
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Some points I noticed when going over the requirements draft and the =
notes of the Minn meeting -

1.  Since confidentiality is a key issue, and the provisioning registry =
protocol is built upon other protocols, it would be wise to choose =
something that provides confidentiality at the transport layer (TLS or =
another protocol).  If the unique "registry handle" is used as the check =
to make modifications to a domain registration, the generation and =
transmission of that handle must be secured from evedroppers.  I use the =
term "confidentiality" to mean "encryption of messages in transit", =
since "privacy" means different things to different people and it is =
hard to determine what "we need privacy" means today.

2.  The Minn meeting also pointed out the need for authentication.  In =
the requirements doc, there is no mention of any authentication needed =
for Object Transfer between registrars  (Section 3.7).  Is this =
something that might be needed, or is the posession of the unique =
registration handle (suposedly supplied by the registrant of the domain =
name) enough?  It might be necessary to have an authentication of a =
registrar by another registrar before any objects are transferred.  =
Otherwise, an attacker that has aquired the handle for a domain =
registration could assume control of it by impersonating another =
registrar and requesting the domain to be transferred to the attacker.

Is this last observation valid?  Would registrars need to authenticate =
themselves before requesting an object transfer? =20

Scott

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
Advanced Network Technologies Division
NIST

ph: 301-975-8439                       fax: 301-590-0932
http://www.nist.gov
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------=_NextPart_000_04F6_01C0B611.2D5F6660
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#d8d0c8>
<DIV><FONT face=3DArial size=3D2>Some points I noticed when going over =
the=20
requirements draft and the notes of the Minn meeting -</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1.&nbsp; Since confidentiality is a key =
issue, and=20
the provisioning registry protocol is built upon other protocols, it =
would be=20
wise to choose something that provides confidentiality at the transport =
layer=20
(TLS or another protocol).&nbsp; If the unique "registry handle" is used =
as the=20
check to make modifications to a domain registration, the generation and =

transmission of that handle must be secured from evedroppers.&nbsp; I =
use the=20
term "confidentiality" to mean "encryption of messages in transit", =
since=20
"privacy" means different things to different people and it is hard to =
determine=20
what "we need privacy" means today.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2.&nbsp; The Minn meeting also pointed =
out the need=20
for authentication.&nbsp; In the requirements doc, there is no mention =
of any=20
authentication needed for Object Transfer between registrars&nbsp; =
(Section=20
3.7).&nbsp; Is this something that might be needed, or is the posession =
of the=20
unique registration handle (suposedly supplied by the registrant of the =
domain=20
name) enough?&nbsp; It might be necessary to have an authentication of a =

registrar by another registrar before any objects are transferred.&nbsp; =

Otherwise, an attacker that has aquired the handle for a domain =
registration=20
could assume control of it by impersonating another registrar and =
requesting the=20
domain to be transferred to the attacker.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is this last observation valid?&nbsp; =
Would=20
registrars need to authenticate themselves before requesting an object=20
transfer?&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Scott</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Scott=20
Rose<BR>Advanced Network Technologies Division<BR>NIST</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>ph:=20
301-975-8439&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
fax: 301-590-0932<BR><A=20
href=3D"http://www.nist.gov">http://www.nist.gov</A><BR>=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D</FONT></DIV></BODY></HTML>

------=_NextPart_000_04F6_01C0B611.2D5F6660--

To: "Maynard Kang" <[email-masked]>
cc: "William Tan" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: HTTP Transport? (was: Re: Security Design Team) 
Date: Mon, 26 Mar 2001 16:13:19 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>                             ... because of the huge installed base of HTTP
> implementations ...

This isn't relevant, unless you've a huge installed base of provreg-protocol
participants in mind.

>            ... it may yet turn out to produce another bulky, unnecessarily
> complex, monolithic, and above all, underutilized protocol like X.400 DAP.

Not likely.

Date: Tue, 27 Mar 2001 01:54:25 +0900 (JST)
From: Peter Chow <[email-masked]>
To: Maynard Kang <[email-masked]>
cc: William Tan <[email-masked]>, <[email-masked]>
Subject: Re: HTTP Transport? (was: Re: Security Design Team)
Sender: [email-masked]

You should take a look at
http://www.ietf.org/internet-drafts/draft-mrose-beep-design-02.txt
which talks about the design principles behind BEEP.  It talks about
HTTP so it might answer your question.

On Mon, 26 Mar 2001, Maynard Kang wrote:

> William Tan wrote:
> > I do not see any technical advantage over TCP that HTTP provides, in this
> > context anyway.
> >
> > wil.
>
> Actually I don't think you can compare TCP and HTTP just like that. They
> are transport methods at different layers (HTTP is TCP based in any case).
>
> You'll have to compare HTTP with some "undefined or new TCP-based
> application-layer transport protocol" for a fair comparison.. and I think
> that HTTP would be advantageous because of the huge installed base of HTTP
> implementations and the fairly mature state of the protocol.
>
> Although not entirely a technical merit, I believe this working group
> should strongly consider how to attain maximum reach for whatever it
> develops, else it may yet turn out to produce another bulky, unnecessarily
> complex, monolithic, and above all, underutilized protocol like X.400 DAP.
>
> maynard
>
>

--------------------------------------------------------------------
_/_/_/ Peter Chow		Chief Technical Advisor
_/_/_/ [email-masked]	interQ Inc. - System Division
_/_/_/ ICQ: 41931890		Shibuya Infoss Tower 10F
_/_/_/ (tel)+81-3-5456-2555	20-1 Sakuragaoka, Shibuya-ku
_/_/_/ (fax)+81-3-5456-2556	Tokyo, Japan
_/_/_/ http://www.interq.ad.jp/	150-0031
--------------------------------------------------------------------

Date: Mon, 26 Mar 2001 08:35:24 -0800
From: Kent Crispin <[email-masked]>
To: [email-masked]
Subject: Re: HTTP Transport? (was: Re: Security Design Team)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 26, 2001 at 05:28:43PM +0100, Maynard Kang wrote:
> William Tan wrote:
> > I do not see any technical advantage over TCP that HTTP provides, in this
> > context anyway.
> >
> > wil.
> 
> Actually I don't think you can compare TCP and HTTP just like that. They
> are transport methods at different layers (HTTP is TCP based in any case).

But http is just being used as a transport protocol -- you will have to
implement all the protocol elements on top of it, anyway.  So the
comparison with plain old tcp is probably fairly accurate.

> You'll have to compare HTTP with some "undefined or new TCP-based
> application-layer transport protocol" 

We have to do a new application-layer protocol anyway.

-- 
Kent Crispin                               "Be good, and you will be
[email-masked]                           lonesome." -- Mark Twain

From: "Maynard Kang" <[email-masked]>
To: "William Tan" <[email-masked]>, <[email-masked]>
Subject: Re: HTTP Transport? (was: Re: Security Design Team)
Date: Mon, 26 Mar 2001 17:28:43 +0100
Sender: [email-masked]

William Tan wrote:
> I do not see any technical advantage over TCP that HTTP provides, in this
> context anyway.
>
> wil.

Actually I don't think you can compare TCP and HTTP just like that. They
are transport methods at different layers (HTTP is TCP based in any case).

You'll have to compare HTTP with some "undefined or new TCP-based
application-layer transport protocol" for a fair comparison.. and I think
that HTTP would be advantageous because of the huge installed base of HTTP
implementations and the fairly mature state of the protocol.

Although not entirely a technical merit, I believe this working group
should strongly consider how to attain maximum reach for whatever it
develops, else it may yet turn out to produce another bulky, unnecessarily
complex, monolithic, and above all, underutilized protocol like X.400 DAP.

maynard

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Design teams
Date: Mon, 26 Mar 2001 10:41:42 -0500
Sender: [email-masked]

Here's the info from the protocol design team.

<Scott/>

New Requirement Issues
- Base Protocol
-- Auth IDs for all object updates
-- Pass-through element
- Common to all Objects
-- "handle" aka Registry Object Identifier (roid)
- Domain
-- Optional registration period and period units
- Host (no issues noted so far)
- Contact
-- Data purpose identification

Base Protocol Design Issues I
- Client-server vs. peer-to-peer
-- Don't preclude client-server
- <ping> Command Name
-- <check> or <is>?
- Query feature to pull notifications
- Client <hello> for connectionless transport
- Command/response pipelining
- <renew> command vs. <update> option

Base Protocol Design Issues II
- Auth ID for transfers vs. other updates
-- Non-sponsor use only for transfer request
- Object relationship queries
-- Good or bad in a provisioning protocol?

Common Object Design Issues
- Globally unique ROIDs for all objects
-- <local part>-<globally unique part>?
- Non-Unicode charset identification
-- May need to store non-Unicode identifiers

Domain Object Design Issues
- Status flags per registry policy or protocol?

Host Object Design Issues
- None identified (yet)

Contact Object Design Issues
- Add extension attribute for E.164 numbers
-- <contact:voice x="1234">+1.7035555555</contact:voice>
- Data purpose definition
-- No proposals yet
- Dual charset representation
-- Also TBD

>-----Original Message-----
>From: Edward Lewis [mailto:[email-masked]]
>Sent: Wednesday, March 21, 2001 10:27 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Design teams
>
>
>First, I would like to set a target date of March 30 for the design teams
>to submit to the mailing list a set of issues and opinions (so far) so the
>WG can provide some feedback.  This isn't intended to be a deadline for the
>design teams, but a midpoint check on progress.  (The "set of issues" can
>be similar to what was put on screen yesterday, but this time in text.)

From: "William Tan" <[email-masked]>
To: "Maynard Kang" <[email-masked]>, <[email-masked]>
Subject: Re: HTTP Transport? (was: Re: Security Design Team)
Date: Mon, 26 Mar 2001 23:39:53 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

I do not see any technical advantage over TCP that HTTP provides, in this
context anyway.

wil.

----- Original Message -----
From: "Maynard Kang" <[email-masked]>
To: "William Tan" <[email-masked]>; <[email-masked]>
Sent: Monday, March 26, 2001 11:03 PM
Subject: HTTP Transport? (was: Re: Security Design Team)

> > I know they aren't.  What I meant was that for the purpose of this
design
> > team, we are gonna focus on one of them as a representation of
> > connection-oriented transport.  It is either:
> >
> > 1. BEEP over TLS as in 3080/1; or
> > 2. TCP with TLS as in epp-tcp-00
> >
>
> Ok, I'm going to stick my head out for this, so please be gentle with the
> flames... =)
> Is there a reason why HTTP is not considered as a mode of transport?
>
> Although HTTP has many problems (authentication, state maintenance, etc),
> there are many widely available APIs for HTTP and thus would be much
easier
> for the not-so-technically-competent registrars to implement.
>
> I am not sure that every registrar will be able to understand RFC 3080
> even, much less deploy an implementation using BEEP.
>
> maynard
>
>

Date: Mon, 26 Mar 2001 10:26:31 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Minutes of our Minneapolis Meetings (rough cut)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

These are the merged minutes taken by James Seng and Olafur Gudmundsson.
(Thanks.)

Please send in your comments on this real soon before this becomes part of
the "permanent record:"

ProvReg Working Group/21st March 2001 Tuesday 3:45pm.
http://www.ietf.org/html.charters/provreg-charter.html

Agenda:
- Agenda bashing
- WG Status (Interim meeting etc.)
- WG Document Status
- Design teams presentations (Protocol, Transport, Securty)
- GRRP requirements DOC
- XRP Proposal
- AOB

WG Status - Edward Lewis
- requirements, defination doc
- hopefully to finish within a year
- 3 design team - protocol, transport, security
  - not binding, just focus
- 2 current proposal, epp and xrp. xrp is slightly different

Protocol Design Team - Scott Hollenback
- design team members intro
- new requirements issues
  - authid for all object updates
  - pass-thru element
  - common to all objects (aka handle)
  - make registration period and period unit optional
  - idenfification data purpose?
- base protocol design issues
  - client-server vs peer-to-peer (don't preclude client-server)
  - ping command?
    = Bill Manning: Ping has overloaded use
    + room consensus to change 'ping' to 'check'
  - query feature to pull notification
  - client hello for connectionless transport e.g. smtp, pipelining
  - command/response pipelining
    = James: isn't this it is a transport problem?
    = Scott: It may impact how to protocol
    = George: Large number of transaction.
    = Rick: Async transaction? Good or bad?
  - renew command vs update option
    - should recombine renew and transfer into update? no answer.
  - auth id for transfer vs other updates
    - non-sponsor use only for transfer request.
  - object relationship queries
    - good or bad in a provision protocol
- common object design issues
  - globally unique ROID for all objects
    - <local part>-<globally unique part>
    - registry part - local, iana? - globally
  - Non-Unicode charset identification
    - May need to store non-Unicode identifiers
    = Rick: Since we are dealing with XML and UTF-8 is the charset,
            would it be more appriopriate
    = James: strong suggest to use only one charset, e.g UTF-8.
             See CNRP on how it done properly.
- domain object design issues
  - Status flag per registry prolicy or protocol. No consensus
- contact object design issues
  - Add extension attribute for E164 numbers
  - Data purpose definition - no proposal
  - Dual charset representation - TDB

= Sheer: there is an original thing in EPP. There is something sending
  back TransID from server to client. is it still inside?
= Scott: No. Client can get back lost ID from servers.

Transport Design Team - Jordyn Buchanan
- Goals of the Design Team
  - identify issues relating to the movmeent of data between registr*s
  - recommend specific transport mechanisms
  - creates I-D to describe the use of the transport
- Issues
  - Transactional integrity is needed
    - How to provide it?
    - How do participants recover from loss of association
  - Need for two types of transport
    - "real-time" with high volumne of transactions
    - "email-based" with low volumne of transactions
- Options for Real-Time
  - BEEP
    - provides standardized framework
    - concern about overhead and lack of operational experience
  - TLS
  - Various "non-literal" transport
    = involves mapping base provreg to over-the-wire format
    = provide better network efficieny and reduce computation
    = Rick: can give an example of "non-literal"?
    = Bill: Fax? Can you handle this?
    = Jordyn: actually consider binary representation of XML
    = Eric: clarify about email-based?
    = Jordyn: yes, no consensus
    = Rick: request a poll on if this is what transport need to do?
    = Dave: already reach a consensus for completeness but wont proposal
    = George: consider total-paper base transport
    = Sheer: try look at volumne of XML over over-the-wire?
    = Jordyn: no operation data yet.
    = Daren: TLS and BEEP are interoperate...why two choice?
  - HTTP
  - UDP - not viable
- Ongoing Strategy
  - quantitative analysis of various options
    - ideally from ops experience, alt. computation based on known char'ics

Jaap: I dont mind Email template.

Security Design Team - Bill Manning
- ProvReg A&I, Authentication and Integrity - not security, no privacy
= Rick: Privacy over the connection is an important issues
- Security is a nebulous phrase
  - Items of real interest are: authenticity and integrity
  - Who does what where? - lots of prior (black) art
  - Provide guidance to other teams
= William: take encryption as an implication of privacy
= Bill: Privacy are really local manner. Those who decide has to make sure
  that protocol does not get into the way.
= William: Privacy needed on transport
= Edward: Just in case we run out of time, we will remeet at 2:00pm after
  the IDN WG. IDN WG may have 1 hour free for us.

XRP - Eric William-Brunner
- not a competiting proposal. It is an internal design doc of Neulevel.
- some comments received
- -01 was submit but bounced. intent to submit end of the week.
- diff from epp: BEEP is the explicit transport mechanism

Requirements Draft - Edward Lewis
- "We are really close now." so we thought
- Past month have steady stream of comments so not sure if it is ready
  for Last Call. Anyone have any other concern.
= Eric: Still concern that we have only client initiation.
= Rick: suggest protocol designer go thru requirements one by one.
= Scott: Yes for EPP. But the Protocol Design Team should do it again.
= Edward: Requirements extensibility

= Eric: Suggest next meeting to get larger block of meeting time.
= Rick: Privacy is something that seem to get cut-off
= Bill: What is about privacy that protocol need to take care.
= Rick: there are some info which only known by the registrant and registry
        and that needs to be take into consideration.
= Bill: the use of encryption to protect privacy is fine. but have not seen
        all the design team document to make any comment.
= Dave: encryption can ensure integrity violation is not perfect.
        protocol privacy and database privacy is different.
= Bill: Privacy is a sensitive word as bad as security.
= Eric: Policy for data-collection as a separate issue from privacy /
encryption
= Zhuyu: Why is UDP ruled-out for transport?
= Jordyn: provreg protocol payload is likely to exceed datagram, many services
          like traffic congestion need to be re-invented.

Resumed 22nd March 2001 2:30pm

= Edward: worried that different teams may overlap each another,
  e.g. Protocol and Security cross
= Jordyn: weekly digest be publish so they can check
= Edward: by next friday, can every design team put something up
= Edward: what if transport does not provide the same security as the
          protocol design team expect?
= Jordyn: hope to see nothing we do now will preclude what future users
          may use this protocol
= Sheer: there is no way to treat security on transport generally,
         e.g. security over email very different
= Edward: Security - what is it we trying to protect?
= Sheer: privacy refers to maintain data integrity, not privacy as data
         privacy in data
= Edward: just want to scope this out and doc it it down
= Dave: did u say privacy = data integrity?
= Sheer: yes
= James: feels we still focus too much on domain. while that is a short
         term goal, strongly support a design team or someone to lead
         the effort. also we should continue to try to get other registry
         more involved in this wg.
= Edward: unique handle issues...a lot of discussion on mailing list.
= Scott: a lot of requirements posted and will be captured in the reqs
= Sheer: has consideration been taken that unique handle may be refer
         object outside the registry?
= Edward: reqs may be ready for last call after one more revision.
          but some concern over defs. maybe we should put back defs
          into reqs and send it in.
= Scott: okay, next week or so.
= Edward: next step until London. In a week of half, hopefully status
          report. feel free to comment on the result of the design team.
          design team is not final.
= Sheer: should we post weekly digest to the mailing list?
= room: no..yes..no..yes..chuckle
= Edward: I think we have consensus. weekly is good.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

From: "Maynard Kang" <[email-masked]>
To: "William Tan" <[email-masked]>, <[email-masked]>
Subject: HTTP Transport? (was: Re: Security Design Team)
Date: Mon, 26 Mar 2001 16:03:34 +0100
Sender: [email-masked]

> I know they aren't.  What I meant was that for the purpose of this design
> team, we are gonna focus on one of them as a representation of
> connection-oriented transport.  It is either:
>
> 1. BEEP over TLS as in 3080/1; or
> 2. TCP with TLS as in epp-tcp-00
>

Ok, I'm going to stick my head out for this, so please be gentle with the
flames... =)
Is there a reason why HTTP is not considered as a mode of transport?

Although HTTP has many problems (authentication, state maintenance, etc),
there are many widely available APIs for HTTP and thus would be much easier
for the not-so-technically-competent registrars to implement.

I am not sure that every registrar will be able to understand RFC 3080
even, much less deploy an implementation using BEEP.

maynard

From: "William Tan" <[email-masked]>
To: <[email-masked]>
Subject: Re: Security Design Team
Date: Mon, 26 Mar 2001 21:32:40 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

> >Yes, in fact after talking to Jordyn we have down to these:
> >
> >1. email
> >2. BEEP or TLS
>
> Clarification, please, BEEP and TLS aren't mutually exclusive.  By "BEEP"
do
> you mean BEEP with a TLS transport security profile as described in RFCs
> 3080 and 3081 and by "TLS" do you mean streaming over TCP with TLS as
> described in my epp-tcp-00 I-D?
>
> <Scott/>

I know they aren't.  What I meant was that for the purpose of this design
team, we are gonna focus on one of them as a representation of
connection-oriented transport.  It is either:

1. BEEP over TLS as in 3080/1; or
2. TCP with TLS as in epp-tcp-00

wil.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'William Tan'" <[email-masked]>, [email-masked]
Subject: RE: Security Design Team
Date: Mon, 26 Mar 2001 08:25:28 -0500
Sender: [email-masked]

>-----Original Message-----
>From: William Tan [mailto:[email-masked]]
>Sent: Monday, March 26, 2001 8:16 AM
>To: Hollenbeck, Scott; [email-masked]
>Subject: Re: Security Design Team
>
>
>
>Yes, in fact after talking to Jordyn we have down to these:
>
>1. email
>2. BEEP or TLS

Clarification, please, BEEP and TLS aren't mutually exclusive.  By "BEEP" do
you mean BEEP with a TLS transport security profile as described in RFCs
3080 and 3081 and by "TLS" do you mean streaming over TCP with TLS as
described in my epp-tcp-00 I-D?

<Scott/>

From: "William Tan" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: Re: Security Design Team
Date: Mon, 26 Mar 2001 21:16:13 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

Yes, in fact after talking to Jordyn we have down to these:

1. email
2. BEEP or TLS

wil.

----- Original Message ----- 
From: "Hollenbeck, Scott" <[email-masked]>
To: "'William Tan'" <[email-masked]>; <[email-masked]>
Sent: Monday, March 26, 2001 8:01 PM
Subject: RE: Security Design Team

> Wil,
> 
> I would also suggest consideration of deployed systems using e-mail
> transport since the RRP over SSL model isn't the only one is use.
> 
> <Scott/>
> 
> >-----Original Message-----
> >From: William Tan [mailto:[email-masked]]
> >Sent: Sunday, March 25, 2001 10:48 PM
> >To: [email-masked]
> >Subject: Security Design Team
> >
> >
> >After the design team meeting, we have identified the 
> >following tasks (in
> >accordance to Ed's suggestion):
> >
> >1) Find a threat model based upon existing deployed systems 
> >(eg. RRP over
> >SSL)
> >2) Identify the types of threats
> >3) Solicit a choice of transport from one of the transport team members
> >
> >Suggestions?
> >
> >wil.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'William Tan'" <[email-masked]>, [email-masked]
Subject: RE: Security Design Team
Date: Mon, 26 Mar 2001 07:01:53 -0500
Sender: [email-masked]

Wil,

I would also suggest consideration of deployed systems using e-mail
transport since the RRP over SSL model isn't the only one is use.

<Scott/>

>-----Original Message-----
>From: William Tan [mailto:[email-masked]]
>Sent: Sunday, March 25, 2001 10:48 PM
>To: [email-masked]
>Subject: Security Design Team
>
>
>After the design team meeting, we have identified the 
>following tasks (in
>accordance to Ed's suggestion):
>
>1) Find a threat model based upon existing deployed systems 
>(eg. RRP over
>SSL)
>2) Identify the types of threats
>3) Solicit a choice of transport from one of the transport team members
>
>Suggestions?
>
>wil.

From: "William Tan" <[email-masked]>
To: <[email-masked]>
Subject: Security Design Team
Date: Mon, 26 Mar 2001 12:47:37 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

After the design team meeting, we have identified the following tasks (in
accordance to Ed's suggestion):

1) Find a threat model based upon existing deployed systems (eg. RRP over
SSL)
2) Identify the types of threats
3) Solicit a choice of transport from one of the transport team members

Suggestions?

wil.

From: "James Seng/Personal" <[email-masked]>
To: "Sheer El-Showk" <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: "Dave Crocker" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Design teams 
Date: Sat, 24 Mar 2001 16:02:35 +0800
Sender: [email-masked]

Eric,

Relax. No one is trying to take away your rice bowl so don't jump into
conclusion until you see my I-D, which will be something next week.

-James Seng

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "Sheer El-Showk" <[email-masked]>
Cc: "Dave Crocker" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Saturday, March 24, 2001 12:04 PM
Subject: Re: Design teams

> Sheer,
>
> You may want to look at rfc2140 if the foundations for the motivation
for
> the change in connection management in http interest you.
>
> > which is generally the case in registry-registrar.  But as a
_generic_
> > registration protocol, whose to say I might not allow hundreds of
> > different clients to connection from different locations (without
going
> > through some front end registrar).  In this case the overhead of
BEEP and
>
> You may want to discuss this with James Seng, who has previously
written to
> a similar effect (access models without interposition by a registrar).
IMO
> there are some issues to be resolved when removal of the registrar
agency
> is proposed, but your milage may vary.
>
> Cheers,
> Eric

To: Sheer El-Showk <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Design teams 
Date: Fri, 23 Mar 2001 23:04:53 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Sheer,

You may want to look at rfc2140 if the foundations for the motivation for
the change in connection management in http interest you.

> which is generally the case in registry-registrar.  But as a _generic_
> registration protocol, whose to say I might not allow hundreds of
> different clients to connection from different locations (without going
> through some front end registrar).  In this case the overhead of BEEP and

You may want to discuss this with James Seng, who has previously written to
a similar effect (access models without interposition by a registrar). IMO
there are some issues to be resolved when removal of the registrar agency
is proposed, but your milage may vary.

Cheers,
Eric

Date: Fri, 23 Mar 2001 16:36:13 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: <[email-masked]>
Subject: RE: Design teams
Sender: [email-masked]

> number of http requests is separate from the question of whether they come
> over a single tcp connection or multiple.
>
> problems with having multiple tcp connections were the reason http 1.1
> permits leaving the connection open and the basis for the multiplexing and
> asynchrony of BEEP.

Your point is well taken Dave ... my experience comes from webserver
benchmarking ... I'll have to go back and take a look at what the
benchmarks were doing exactly.

>
>
> >   Most server
> >OSes have been optimized to handle high volumes of simultaneous TCP
> >connections
>
> Simultaneous connections between different machines are fine.
>
> The problem is when the connections are between the same machine.
>

True, the fact that this is generally a registrar-regyistry connection
(rather than 10,000 clients to one registrar) means that we can handle
multiplexing over a single connection but what I'm not convinced of is
that the problem hasn't already been handled in the more generic
many-to-one case.  That is, if a server can handle 100+ simultaneous
connections from different clients then why try to rework this so the 100+
connection are now done in a single connection to a single client (we can
just have a 100+ connections to a single client).  That's just a "why
reinvent the wheel" argument; there's another that you brought up (perhaps
inadverdantly).  BEEP has some strong arguments in a one-to-one connection
environment (roughly B2B without throwing too many catch phrases around),
which is generally the case in registry-registrar.  But as a _generic_
registration protocol, whose to say I might not allow hundreds of
different clients to connection from different locations (without going
through some front end registrar).  In this case the overhead of BEEP and
the associated advantages (suddenly asynchrony is not that useful) must be
weighed very differently.  I don't think our protocol can solve all
problems and work well in every case, but, in a case like this, where we
can move some of the _optional_ functionality (asynchrony, encryption,
etc...) into other layers and propose certain minimum requirements
for those layers then I think we would be well advised to consider it.

> Leaving the connection open is helpful, yes.
>
> We should note that the term light-weight is probably misleading, since
> most of the features in BEEP are present in most connection-based Internet
> applications.  If BEEP is not used, the features will be provided in some
> other way.

True, but they are often implemented by multiple tcp connections with SSL.
The current NSI RRP setup is not asynchronous (as far as I know).
Channels can be preserved using a group of long-lived TCP connections with
login and logoff commands (ie multi-session connections to avoid SSL
handshake overhead).

I'm not trying to argue in circles ... yes I think BEEP is neat and I'm
not really that worried about its performance (though I havn't really
looked at it enough to say).  My real concern is that the protocol relies
too much on an underlying BEEP session and then becomes unimplementable
over very different transporst like SMTP.  If this concern is addressed
then BEEP vs TLS+multiple connections is really not that big a deal as far
as I'm concerned (though then it really doesn't belong in the protocol as
anything other than a recommendation because our protocol becomes unaware
of that layer and doesn't rely on it).

Regards,
Sheer

>
> d/
>
>
> ----------
> Dave Crocker   <mailto:[email-masked]>
> Brandenburg InternetWorking   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
>

Date: Fri, 23 Mar 2001 09:04:22 -0800
To: Sheer El-Showk <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: Design teams
Cc: <[email-masked]>
Sender: [email-masked]

At 06:14 PM 3/21/2001, Sheer El-Showk wrote:
> > Thank you for providing the glinching reason to use beep:  multiplexing
> > data streams over a single connection.  (Multiple TCP connections cause
> > problems.)
>
>...What I said then was that TCP (the protocol
>and the implementations) has a proven record  of handling multiple
>connection with very high volume (even a low end  server can handle a very
>high volume of http requests per second) simultaneously.

number of http requests is separate from the question of whether they come 
over a single tcp connection or multiple.

problems with having multiple tcp connections were the reason http 1.1 
permits leaving the connection open and the basis for the multiplexing and 
asynchrony of BEEP.

>   Most server
>OSes have been optimized to handle high volumes of simultaneous TCP
>connections

Simultaneous connections between different machines are fine.

The problem is when the connections are between the same machine.

>I still think BEEP can help us in many ways; in particular it can undercut
>the high cost of initiating a _secure_ connection (very slow) by allowing
>us to reuse an existing connection for multiple sessions/transactions
>(depending on the nature of the protocol we design) in a non-blocking and
>standardized way (ie not re-inventing the wheel).  If secure connections
>were not a concern I would not be convinced that relying on
>simultaneous light-weight  TCP connections with no multiplexing would not
>be the right way to go.

Leaving the connection open is helpful, yes.

We should note that the term light-weight is probably misleading, since 
most of the features in BEEP are present in most connection-based Internet 
applications.  If BEEP is not used, the features will be provided in some 
other way.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Thu, 22 Mar 2001 16:06:50 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: <[email-masked]>
Subject: UDP pro's and con's (fwd)
Sender: [email-masked]

I'm going to repost this one more time since it didn't seem to make it to
the list the last two (so if you see it two more times pleae be
forgiving).

---------- Forwarded message ----------
Date: Wed, 21 Mar 2001 17:55:44 +0000 (WET)
From: [email-masked]
To: [email-masked]
Subject: UDP pro's and con's (fwd)

I've noticed the mailing list sometimes ignores/delays my mails,
particularly when they're CCed to it so here's a repost, sorry if it shows
up again in a little while:

It strikes me as slightly incongruous to even be considering UDP in a
system where we will _definately_ have to verify transactions (ie a
registrar _must_ know if a domain registration went through or not) and
thus need to develop/adapt some intermediate transaction layer (which TCP
provides) while at the same time using XML as the protocol language and
rejecting out of hand any binary conversion.  This is not a disguised
rallying cry for a XML-binary conversion, just a call for some
perspective.  I think we've already made some implicit performance
descisions in adopting XML for the protocol and we should be consistent in
the level of performance we're demainding.

In addition I think TCP overhead is going to be very light compared to
the encryption systems we're considering (TLS, BEEP) and TCP (or the
gaurantees it provides) will be necassary for any transport-level
encryption that I know of (though of course we could take the encryption
into the protocol and ignore the transport layer).

If UDP has a place I thinks its in the "Check Domain" command that we
descided we might have to consider as a special case since its
requirements are vastly different from the rest of the protocol's.

Regards,
Sheer

On Wed, 21 Mar 2001, Brian W. Spolarich wrote:

>
> | Is there an example of a UDP-based transport protocol that might
> | be applicable?
>
>   Rx, which was part of the CMU AFS work, was a UDP-based RPC
> protocol with some of the characteristics that are required
> here.
>
>   Do folks really think the TCP overhead is that big of a
> problem?  Memory and CPU is much cheaper these days, and I haven't
> seen a requirement stated that would necessitate going down
> the UDP road.
>
>   -bws
>

Date: Wed, 21 Mar 2001 21:14:59 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: <[email-masked]>
Subject: RE: Design teams
Sender: [email-masked]

> Thank you for providing the glinching reason to use beep:  multiplexing
> data streams over a single connection.  (Multiple TCP connections cause
> problems.)

How so?  I brought this up before but I was persuaded by BEEP's other
facility, namely asynchronous messages which allows for more efficient use
of a single connection.  What I said then was that TCP (the protocol
and the implementations) has a proven record  of handling multiple
connection with very high volume (even a low end  server can handle a very
high volume of http requests per second) simultaneously.  Most server
OSes have been optimized to handle high volumes of simultaneous TCP
connections and a lot of research has gone  into this (certainly beyond
the scale we should be considering since I think web servers exist
that support much higher load than most registries can expect -- their
bottleneck will be in the server business logic, not the tranport
protocol).

I still think BEEP can help us in many ways; in particular it can undercut
the high cost of initiating a _secure_ connection (very slow) by allowing
us to reuse an existing connection for multiple sessions/transactions
(depending on the nature of the protocol we design) in a non-blocking and
standardized way (ie not re-inventing the wheel).  If secure connections
were not a concern I would not be convinced that relying on
simultaneous light-weight  TCP connections with no multiplexing would not
be the right way to go.

Sheer

>
> d/
>
>
> ----------
> Dave Crocker   <mailto:[email-masked]>
> Brandenburg InternetWorking   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
>

Date: Wed, 21 Mar 2001 17:55:44 +0000 (WET)
From: [email-masked]
To: [email-masked]
Subject: UDP pro's and con's (fwd)
Sender: [email-masked]

I've noticed the mailing list sometimes ignores/delays my mails,
particularly when they're CCed to it so here's a repost, sorry if it shows
up again in a little while: 

It strikes me as slightly incongruous to even be considering UDP in a
system where we will _definately_ have to verify transactions (ie a
registrar _must_ know if a domain registration went through or not) and
thus need to develop/adapt some intermediate transaction layer (which TCP
provides) while at the same time using XML as the protocol language and
rejecting out of hand any binary conversion.  This is not a disguised
rallying cry for a XML-binary conversion, just a call for some
perspective.  I think we've already made some implicit performance
descisions in adopting XML for the protocol and we should be consistent in
the level of performance we're demainding.

In addition I think TCP overhead is going to be very light compared to
the encryption systems we're considering (TLS, BEEP) and TCP (or the
gaurantees it provides) will be necassary for any transport-level
encryption that I know of (though of course we could take the encryption
into the protocol and ignore the transport layer).

If UDP has a place I thinks its in the "Check Domain" command that we
descided we might have to consider as a special case since its
requirements are vastly different from the rest of the protocol's.

Regards,
Sheer

On Wed, 21 Mar 2001, Brian W. Spolarich wrote:

> 
> | Is there an example of a UDP-based transport protocol that might 
> | be applicable?
> 
>   Rx, which was part of the CMU AFS work, was a UDP-based RPC
> protocol with some of the characteristics that are required
> here.
> 
>   Do folks really think the TCP overhead is that big of a 
> problem?  Memory and CPU is much cheaper these days, and I haven't
> seen a requirement stated that would necessitate going down
> the UDP road.
> 
>   -bws
> 

Date: Wed, 21 Mar 2001 15:40:07 +0000 (WET)
From: Sheer El-Showk <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>
cc: "Jordyn A. Buchanan" <[email-masked]>, Bill Manning <[email-masked]>, George Michaelson <[email-masked]>, Peter Chow <[email-masked]>, Zhu Yu <[email-masked]>, [email-masked]
Subject: UDP pro's and con's
Sender: [email-masked]

It strikes me as slightly incongruous to even be considering UDP in a
system where we will _definately_ have to verify transactions (ie a
registrar _must_ know if a domain registration went through or not) and
thus need to develop/adapt some intermediate transaction layer (which TCP
provides) while at the same time using XML as the protocol language and
rejecting out of hand any binary conversion.  This is not a disguised
rallying cry for a XML-binary conversion, just a call for some
perspective.  I think we've already made some implicit performance
descisions in adopting XML for the protocol and we should be consistent in
the level of performance we're demainding.

In addition I think TCP overhead is going to be very light compared to
the encryption systems we're considering (TLS, BEEP) and TCP (or the
gaurantees it provides) will be necassary for any transport-level
encryption that I know of (though of course we could take the encryption
into the protocol and ignore the transport layer).

If UDP has a place I thinks its in the "Check Domain" command that we
descided we might have to consider as a special case since its
requirements are vastly different from the rest of the protocol's.

Regards,
Sheer

On Wed, 21 Mar 2001, Brian W. Spolarich wrote:

> 
> | Is there an example of a UDP-based transport protocol that might 
> | be applicable?
> 
>   Rx, which was part of the CMU AFS work, was a UDP-based RPC
> protocol with some of the characteristics that are required
> here.
> 
>   Do folks really think the TCP overhead is that big of a 
> problem?  Memory and CPU is much cheaper these days, and I haven't
> seen a requirement stated that would necessitate going down
> the UDP road.
> 
>   -bws
> 

From: "James Seng/Personal" <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>, "Jordyn A. Buchanan" <[email-masked]>, "Bill Manning" <[email-masked]>, "George Michaelson" <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: "Bill Manning" <[email-masked]>, "Peter Chow" <[email-masked]>, "Zhu Yu" <[email-masked]>, <[email-masked]>
Subject: Re: Design teams
Date: Thu, 22 Mar 2001 06:40:39 +0800
Sender: [email-masked]

The answer would depends on the protocol.

-James Seng

> At 16.00 -0600 01-03-21, Brian W. Spolarich wrote:
> >   Do folks really think the TCP overhead is that big of a  problem?
>
> Or rather, because issues like congestion control, packet ordering
> and reordering, fragmentation of blocks of data, error correction etc
> have to be handled by all protocols -- what makes people belive that
> this transport mechanism will be "cheaper" than TCP, SCTP or whatever
> else (even cheaper than BEEP over TCP or SCTP)?
>
>     paf
>

From: "Bason, Chris" <[email-masked]>
To: [email-masked]
Subject: RE: Design teams
Date: Thu, 22 Mar 2001 13:53:39 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 8:58 PM
> To: Brian W. Spolarich
> Cc: Jordyn A. Buchanan; Bill Manning; George Michaelson; 
> Peter Chow; Zhu
> Yu; [email-masked]
> Subject: RE: Design teams
> 
> 
> At 07:49 PM 3/21/2001, Brian W. Spolarich wrote:
> >   A particular implementation might open several connections to a
> >given peer and use those in a similar manner to pooled database
> >connections.
> 
> Thank you for providing the glinching reason to use beep:  
> multiplexing 
> data streams over a single connection.  (Multiple TCP 
> connections cause 
> problems.)
> 

The use of multiplexing also introduces a problem in 
that when a TCP connection is dropped (for whatever reason)
you lose ALL ongoing transactions through X number of data
streams. X being the number of channels opened within the
multiplexed TCP connection.

> d/
> 
> 
> ----------
> Dave Crocker   <mailto:[email-masked]>
> Brandenburg InternetWorking   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
> 

Date: Wed, 21 Mar 2001 21:03:56 -0500
To: Dave Crocker <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Design teams
Cc: <[email-masked]>
Sender: [email-masked]

At 5:31 PM -0500 3/21/01, Dave Crocker wrote:
>the usual argument put forward by UDP devotees is that TCP connection setup
>takes too long.  However absent a standard, robust, popular transaction
>transport protocol, TCP is a better choice than UDP.  UDP simply requires
>that you re-invent too much.

Speaking a non-chair ... I agree with Dave.  I've seen similar arguments
dating way back.  My usual punch line is "do you think you can implement a
better TCP than the vendor already has?"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Wed, 21 Mar 2001 19:58:19 -0600
To: "Brian W. Spolarich" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: Design teams
Cc: "Jordyn A. Buchanan" <[email-masked]>, "Bill Manning" <[email-masked]>, "George Michaelson" <[email-masked]>, "Peter Chow" <[email-masked]>, "Zhu Yu" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 07:49 PM 3/21/2001, Brian W. Spolarich wrote:
>   A particular implementation might open several connections to a
>given peer and use those in a similar manner to pooled database
>connections.

Thank you for providing the glinching reason to use beep:  multiplexing 
data streams over a single connection.  (Multiple TCP connections cause 
problems.)

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Brian W. Spolarich" <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>, "Dave Crocker" <[email-masked]>
Cc: "Bill Manning" <[email-masked]>, "George Michaelson" <[email-masked]>, "Peter Chow" <[email-masked]>, "Zhu Yu" <[email-masked]>, <[email-masked]>
Subject: RE: Design teams
Date: Wed, 21 Mar 2001 19:49:52 -0600
Importance: Normal
Sender: [email-masked]

| Also, if done right, these connections should generally be fairly 
| long-lived (lots of transactions per connection).  Setup time becomes 
| a rather small drop in the bucket if these connections are staying up 
| for a while.

  This is what I was thinking as well.

  A particular implementation might open several connections to a
given peer and use those in a similar manner to pooled database
connections.

  -bws

Date: Wed, 21 Mar 2001 18:15:19 -0600
To: Dave Crocker <[email-masked]>, "Brian W. Spolarich" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: Design teams
Cc: "Bill Manning" <[email-masked]>, "George Michaelson" <[email-masked]>, "Peter Chow" <[email-masked]>, "Zhu Yu" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 4:31 PM -0600 3/21/01, Dave Crocker wrote:
>At 04:00 PM 3/21/2001, Brian W. Spolarich wrote:
>>   Do folks really think the TCP overhead is that big of a
>>problem?  Memory and CPU is much cheaper these days, and I haven't
>>seen a requirement stated that would necessitate going down
>>the UDP road.
>
>the usual argument put forward by UDP devotees is that TCP 
>connection setup takes too long.  However absent a standard, robust, 
>popular transaction transport protocol, TCP is a better choice than 
>UDP.  UDP simply requires that you re-invent too much.

Also, if done right, these connections should generally be fairly 
long-lived (lots of transactions per connection).  Setup time becomes 
a rather small drop in the bucket if these connections are staying up 
for a while.

Jordyn

Date: Wed, 21 Mar 2001 16:31:49 -0600
To: "Brian W. Spolarich" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: Design teams
Cc: "Jordyn A. Buchanan" <[email-masked]>, "Bill Manning" <[email-masked]>, "George Michaelson" <[email-masked]>, "Bill Manning" <[email-masked]>, "Peter Chow" <[email-masked]>, "Zhu Yu" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 04:00 PM 3/21/2001, Brian W. Spolarich wrote:
>   Do folks really think the TCP overhead is that big of a
>problem?  Memory and CPU is much cheaper these days, and I haven't
>seen a requirement stated that would necessitate going down
>the UDP road.

the usual argument put forward by UDP devotees is that TCP connection setup 
takes too long.  However absent a standard, robust, popular transaction 
transport protocol, TCP is a better choice than UDP.  UDP simply requires 
that you re-invent too much.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Brian W. Spolarich" <[email-masked]>
To: "Jörg Bauer/Denic" <[email-masked]>, "Edward Lewis" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Antwort: Pre-meeting notes
Date: Wed, 21 Mar 2001 16:17:33 -0600
Importance: Normal
Sender: [email-masked]

| > 4) One of the issues raised in the drafting of the charter is
| > extensibility.  I feel that although the requirements document mentions
| > this, extensibility isn't being addresses enough.  Are there a few folks
| > (say 2-3) that would be willing to be a "design team" to keep an eye on
| > extensibilty?  I'm looking towards the folks that most vocally supported
| > the use of the protocol for not-just-DNS registrations.
| >
| > Q: Do we need this / who wants to volunteer?
|
| I realy want that the protocol isn´t just usefull for domainnames, but i
| think we first should concentrate on domainnames because there is the
| biggest need for a protocol.
|
| It´s important that the protocol has that ability to be extended but i
| think this is something for version 2.
| Maybe it´s easier to define the requirement of this extensibility with the
| experience of a working system.

  Perhaps one way of approaching this is defining what things
the protocol is NOT intented to be extensible to do.

  That is to say, it is very difficult to predict how a given thing will
be used by users, but it is useful to define the kinds of activities
that thing should be used for, and also explicitly what it is not intended
to do.

  An important goal here is to be extensible.  Fair enough, but
I think we need to constrain the design space, otherwise we could
wind up with never-ending "feature creep".  Saying what the
protocol should not be used for might be a good way to do that.

  -bws

Date: Wed, 21 Mar 2001 16:19:21 -0600
To: "Brian W. Spolarich" <[email-masked]>, "Jordyn A. Buchanan" <[email-masked]>, "Bill Manning" <[email-masked]>, "George Michaelson" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Design teams
Cc: "Bill Manning" <[email-masked]>, "Peter Chow" <[email-masked]>, "Zhu Yu" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 16.00 -0600 01-03-21, Brian W. Spolarich wrote:
>   Do folks really think the TCP overhead is that big of a  problem?

Or rather, because issues like congestion control, packet ordering 
and reordering, fragmentation of blocks of data, error correction etc 
have to be handled by all protocols -- what makes people belive that 
this transport mechanism will be "cheaper" than TCP, SCTP or whatever 
else (even cheaper than BEEP over TCP or SCTP)?

    paf

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>, "Jordyn A. Buchanan" <[email-masked]>, "Bill Manning" <[email-masked]>, "George Michaelson" <[email-masked]>
Cc: "Bill Manning" <[email-masked]>, "Peter Chow" <[email-masked]>, "Zhu Yu" <[email-masked]>, <[email-masked]>
Subject: Re: Design teams
Date: Wed, 21 Mar 2001 14:05:31 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

>   Do folks really think the TCP overhead is that big of a 
> problem?  Memory and CPU is much cheaper these days, and I haven't
> seen a requirement stated that would necessitate going down
> the UDP road.

Agreed. My point, as well.

Christopher

From: "Brian W. Spolarich" <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>, "Bill Manning" <[email-masked]>, "George Michaelson" <[email-masked]>
Cc: "Bill Manning" <[email-masked]>, "Peter Chow" <[email-masked]>, "Zhu Yu" <[email-masked]>, <[email-masked]>
Subject: RE: Design teams
Date: Wed, 21 Mar 2001 16:00:23 -0600
Importance: Normal
Sender: [email-masked]

| Is there an example of a UDP-based transport protocol that might 
| be applicable?

  Rx, which was part of the CMU AFS work, was a UDP-based RPC
protocol with some of the characteristics that are required
here.

  Do folks really think the TCP overhead is that big of a 
problem?  Memory and CPU is much cheaper these days, and I haven't
seen a requirement stated that would necessitate going down
the UDP road.

  -bws

Date: Wed, 21 Mar 2001 15:44:02 -0600
To: Bill Manning <[email-masked]>, [email-masked] (George Michaelson)
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: Design teams
Cc: [email-masked] (Bill Manning), [email-masked] (Peter Chow), [email-masked] (Zhu Yu), [email-masked]
Sender: [email-masked]

At 1:25 PM -0800 3/21/01, Bill Manning wrote:
>	figure that most transactions will use some transport protocol
>	and the transport protocols will eventually run on either UDP or
>	TCP. Stealing an existing transport protocol is easier than
>	writing one from scratch.

Is there an example of a UDP-based transport protocol that might be applicable?

Jordyn

From: Bill Manning <[email-masked]>
Subject: Re: Design teams
To: [email-masked] (George Michaelson)
Date: Wed, 21 Mar 2001 13:25:02 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked] (Peter Chow), [email-masked] (Zhu Yu), [email-masked]
Sender: [email-masked]

% 
% 
% If you use UDP, you have to roll your own VC to try and leverage anything
% from connected state. Re-inventing the wheel is usually bad.

	Yup.  

% If you are looking for transactional completeness, I suspect UDP/TCP is
% the wrong question. However you do get a little more help to know if data
% made it without neccessarily needing an applications-layer ACK.
% 
% maybe?

	figure that most transactions will use some transport protocol
	and the transport protocols will eventually run on either UDP or
	TCP. Stealing an existing transport protocol is easier than
	writing one from scratch.

% 
% -George
% 

-- 
--bill

To: Bill Manning <[email-masked]>
cc: [email-masked] (Peter Chow), [email-masked] (Zhu Yu), [email-masked]
Subject: Re: Design teams 
Date: Thu, 22 Mar 2001 06:30:38 +1000
From: George Michaelson <[email-masked]>
Sender: [email-masked]

If you use UDP, you have to roll your own VC to try and leverage anything
from connected state. Re-inventing the wheel is usually bad.

If you are looking for transactional completeness, I suspect UDP/TCP is
the wrong question. However you do get a little more help to know if data
made it without neccessarily needing an applications-layer ACK.

maybe?

-George

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bill Manning '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: Design teams
Date: Wed, 21 Mar 2001 15:20:52 -0500
Sender: [email-masked]

UDP Con: Delivery not guaranteed, undesirable in a high volume system where
transactional integrity is important.

I may think of more as time goes on ;-)

<Scott/>

-----Original Message-----
From: Bill Manning
To: [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 3/21/01 3:03 PM
Subject: Re: Design teams

UDP-Pro:

	low-overhead/lightweight - The fastest transport protocol.
	desireable for high-volume systems.

UDP-Cons:
	
	bare-bones - needs a fair amount of application development/API
	work.
	"Small" size before fragmentation, however fallback can be to
use
	TCP (with all the TCP checks)

% 
% Zhu,
% 
% Both you and Bill expressed some concerns regarding the lack of
support
% for UDP.  Can either of you summarize the pros and cons of UDP so the
% transport team have the benefit of your input?
%  
% On Thu, 22 Mar 2001, Zhu Yu wrote:
% 
% > Yes.
% > We got many things to be clarified first
% > 
% > I think the dependancies among 3 design teams will cause confusion
and
% > conflicts.
% > (I am with protocal design team.)
% > For example, if I want a connectless transportation scheme, should
% > transportation team
% > come out with it? How about our protocal support both connection and
% > connectionless?
% > 
% > For the role of security team.
% > Since it is not clear now where (protocal level or transportation
level or
% > both?) to put the
% > secutiry scheme in, the security teams seem to have no job to do
now.
% > If we let security come out a scheme, our team and transportation
team will
% > have to wait
% > their result..
% > 
% > So I think we should clarify such basic things first. Otherwise it
seems
% > confusing and difficult
% > to go on with..
% > 
% > Hope we can have time slot this afternoon after IDN WG meeting..
% > 
% > 
% > ZY
% > ----- Original Message -----
% > From: "Edward Lewis" <[email-masked]>
% > To: <[email-masked]>
% > Cc: <[email-masked]>
% > Sent: Wednesday, March 21, 2001 11:26 PM
% > Subject: Design teams
% > 
% > 
% > > First, I would like to set a target date of March 30 for the
design teams
% > > to submit to the mailing list a set of issues and opinions (so
far) so the
% > > WG can provide some feedback.  This isn't intended to be a
deadline for
% > the
% > > design teams, but a midpoint check on progress.  (The "set of
issues" can
% > > be similar to what was put on screen yesterday, but this time in
text.)
% > >
% > > For the security team, there is one item that seems to need
addressing.
% > We
% > > need to identify the threats that the RRP will have to be defended
% > against.
% > > Traffic inspection, modification, etc. are documented means of
attack.
% > > What I have in mind are identification of ways that the RRP may be
abused
% > > (requesting unauthorized actions, leakage of contact data to
spammers,
% > > etc.).  I do think that we need a better understanding of the
'privacy'
% > > issue before declaring it of scope of the protocol.  By
identifying the
% > > threats we can determine which "security" services are needed.
% > >
% > > For the protocol and transport teams, I'd like there to be some
addressing
% > > of how the choice of transport will impact the protocol.  E.g., if
one
% > > transport layer offers a security service to the protocol and
another
% > > transport does not, how will the protocol know to adapt.
% > >
% > > [1] - Regarding my comment about authorization vs. authentication.
IMHO,
% > > Authorization is more germaine to the problem here because we want
to know
% > > if the client (whomever they are) is allowed to request an action.
Of
% > > course, to make an authoriztion determination, you do need to
perform some
% > > authenication first.
% > >
% > >
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
% > > Edward Lewis                                                NAI
Labs
% > > Phone: +1 443-259-2352                      Email:
[email-masked]
% > >
% > > Dilbert is an optimist.
% > >
% > > Opinions expressed are property of my evil twin, not my employer.
% > >
% > >
% > 
% 
% --------------------------------------------------------------------
% _/_/_/ Peter Chow		Chief Technical Advisor
% _/_/_/ [email-masked]	interQ Inc. - System Division
% _/_/_/ ICQ: 41931890		Shibuya Infoss Tower 10F
% _/_/_/ (tel)+81-3-5456-2555	20-1 Sakuragaoka, Shibuya-ku
% _/_/_/ (fax)+81-3-5456-2556	Tokyo, Japan
% _/_/_/ http://www.interq.ad.jp/	150-0031
% --------------------------------------------------------------------
% 

-- 
--bill

From: Bill Manning <[email-masked]>
Subject: Re: Design teams
To: [email-masked] (Peter Chow)
Date: Wed, 21 Mar 2001 12:03:23 -0800 (PST)
Cc: [email-masked] (Zhu Yu), [email-masked]
Sender: [email-masked]

UDP-Pro:

	low-overhead/lightweight - The fastest transport protocol.
	desireable for high-volume systems.

UDP-Cons:
	
	bare-bones - needs a fair amount of application development/API
	work.
	"Small" size before fragmentation, however fallback can be to use
	TCP (with all the TCP checks)

% 
% Zhu,
% 
% Both you and Bill expressed some concerns regarding the lack of support
% for UDP.  Can either of you summarize the pros and cons of UDP so the
% transport team have the benefit of your input?
%  
% On Thu, 22 Mar 2001, Zhu Yu wrote:
% 
% > Yes.
% > We got many things to be clarified first
% > 
% > I think the dependancies among 3 design teams will cause confusion and
% > conflicts.
% > (I am with protocal design team.)
% > For example, if I want a connectless transportation scheme, should
% > transportation team
% > come out with it? How about our protocal support both connection and
% > connectionless?
% > 
% > For the role of security team.
% > Since it is not clear now where (protocal level or transportation level or
% > both?) to put the
% > secutiry scheme in, the security teams seem to have no job to do now.
% > If we let security come out a scheme, our team and transportation team will
% > have to wait
% > their result..
% > 
% > So I think we should clarify such basic things first. Otherwise it seems
% > confusing and difficult
% > to go on with..
% > 
% > Hope we can have time slot this afternoon after IDN WG meeting..
% > 
% > 
% > ZY
% > ----- Original Message -----
% > From: "Edward Lewis" <[email-masked]>
% > To: <[email-masked]>
% > Cc: <[email-masked]>
% > Sent: Wednesday, March 21, 2001 11:26 PM
% > Subject: Design teams
% > 
% > 
% > > First, I would like to set a target date of March 30 for the design teams
% > > to submit to the mailing list a set of issues and opinions (so far) so the
% > > WG can provide some feedback.  This isn't intended to be a deadline for
% > the
% > > design teams, but a midpoint check on progress.  (The "set of issues" can
% > > be similar to what was put on screen yesterday, but this time in text.)
% > >
% > > For the security team, there is one item that seems to need addressing.
% > We
% > > need to identify the threats that the RRP will have to be defended
% > against.
% > > Traffic inspection, modification, etc. are documented means of attack.
% > > What I have in mind are identification of ways that the RRP may be abused
% > > (requesting unauthorized actions, leakage of contact data to spammers,
% > > etc.).  I do think that we need a better understanding of the 'privacy'
% > > issue before declaring it of scope of the protocol.  By identifying the
% > > threats we can determine which "security" services are needed.
% > >
% > > For the protocol and transport teams, I'd like there to be some addressing
% > > of how the choice of transport will impact the protocol.  E.g., if one
% > > transport layer offers a security service to the protocol and another
% > > transport does not, how will the protocol know to adapt.
% > >
% > > [1] - Regarding my comment about authorization vs. authentication.  IMHO,
% > > Authorization is more germaine to the problem here because we want to know
% > > if the client (whomever they are) is allowed to request an action.  Of
% > > course, to make an authoriztion determination, you do need to perform some
% > > authenication first.
% > >
% > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
% > > Edward Lewis                                                NAI Labs
% > > Phone: +1 443-259-2352                      Email: [email-masked]
% > >
% > > Dilbert is an optimist.
% > >
% > > Opinions expressed are property of my evil twin, not my employer.
% > >
% > >
% > 
% 
% --------------------------------------------------------------------
% _/_/_/ Peter Chow		Chief Technical Advisor
% _/_/_/ [email-masked]	interQ Inc. - System Division
% _/_/_/ ICQ: 41931890		Shibuya Infoss Tower 10F
% _/_/_/ (tel)+81-3-5456-2555	20-1 Sakuragaoka, Shibuya-ku
% _/_/_/ (fax)+81-3-5456-2556	Tokyo, Japan
% _/_/_/ http://www.interq.ad.jp/	150-0031
% --------------------------------------------------------------------
% 

-- 
--bill

Date: Thu, 22 Mar 2001 02:35:16 +0900 (JST)
From: Peter Chow <[email-masked]>
To: Zhu Yu <[email-masked]>
cc: [email-masked]
Subject: Re: Design teams
Sender: [email-masked]

Zhu,

Both you and Bill expressed some concerns regarding the lack of support
for UDP.  Can either of you summarize the pros and cons of UDP so the
transport team have the benefit of your input?
 
On Thu, 22 Mar 2001, Zhu Yu wrote:

> Yes.
> We got many things to be clarified first
> 
> I think the dependancies among 3 design teams will cause confusion and
> conflicts.
> (I am with protocal design team.)
> For example, if I want a connectless transportation scheme, should
> transportation team
> come out with it? How about our protocal support both connection and
> connectionless?
> 
> For the role of security team.
> Since it is not clear now where (protocal level or transportation level or
> both?) to put the
> secutiry scheme in, the security teams seem to have no job to do now.
> If we let security come out a scheme, our team and transportation team will
> have to wait
> their result..
> 
> So I think we should clarify such basic things first. Otherwise it seems
> confusing and difficult
> to go on with..
> 
> Hope we can have time slot this afternoon after IDN WG meeting..
> 
> 
> ZY
> ----- Original Message -----
> From: "Edward Lewis" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, March 21, 2001 11:26 PM
> Subject: Design teams
> 
> 
> > First, I would like to set a target date of March 30 for the design teams
> > to submit to the mailing list a set of issues and opinions (so far) so the
> > WG can provide some feedback.  This isn't intended to be a deadline for
> the
> > design teams, but a midpoint check on progress.  (The "set of issues" can
> > be similar to what was put on screen yesterday, but this time in text.)
> >
> > For the security team, there is one item that seems to need addressing.
> We
> > need to identify the threats that the RRP will have to be defended
> against.
> > Traffic inspection, modification, etc. are documented means of attack.
> > What I have in mind are identification of ways that the RRP may be abused
> > (requesting unauthorized actions, leakage of contact data to spammers,
> > etc.).  I do think that we need a better understanding of the 'privacy'
> > issue before declaring it of scope of the protocol.  By identifying the
> > threats we can determine which "security" services are needed.
> >
> > For the protocol and transport teams, I'd like there to be some addressing
> > of how the choice of transport will impact the protocol.  E.g., if one
> > transport layer offers a security service to the protocol and another
> > transport does not, how will the protocol know to adapt.
> >
> > [1] - Regarding my comment about authorization vs. authentication.  IMHO,
> > Authorization is more germaine to the problem here because we want to know
> > if the client (whomever they are) is allowed to request an action.  Of
> > course, to make an authoriztion determination, you do need to perform some
> > authenication first.
> >
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > Edward Lewis                                                NAI Labs
> > Phone: +1 443-259-2352                      Email: [email-masked]
> >
> > Dilbert is an optimist.
> >
> > Opinions expressed are property of my evil twin, not my employer.
> >
> >
> 

--------------------------------------------------------------------
_/_/_/ Peter Chow		Chief Technical Advisor
_/_/_/ [email-masked]	interQ Inc. - System Division
_/_/_/ ICQ: 41931890		Shibuya Infoss Tower 10F
_/_/_/ (tel)+81-3-5456-2555	20-1 Sakuragaoka, Shibuya-ku
_/_/_/ (fax)+81-3-5456-2556	Tokyo, Japan
_/_/_/ http://www.interq.ad.jp/	150-0031
--------------------------------------------------------------------

From: "Zhu Yu" <[email-masked]>
To: <[email-masked]>, "Edward Lewis" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Design teams
Date: Thu, 22 Mar 2001 01:20:04 +0800
Sender: [email-masked]

Yes.
We got many things to be clarified first

I think the dependancies among 3 design teams will cause confusion and
conflicts.
(I am with protocal design team.)
For example, if I want a connectless transportation scheme, should
transportation team
come out with it? How about our protocal support both connection and
connectionless?

For the role of security team.
Since it is not clear now where (protocal level or transportation level or
both?) to put the
secutiry scheme in, the security teams seem to have no job to do now.
If we let security come out a scheme, our team and transportation team will
have to wait
their result..

So I think we should clarify such basic things first. Otherwise it seems
confusing and difficult
to go on with..

Hope we can have time slot this afternoon after IDN WG meeting..

ZY
----- Original Message -----
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 21, 2001 11:26 PM
Subject: Design teams

> First, I would like to set a target date of March 30 for the design teams
> to submit to the mailing list a set of issues and opinions (so far) so the
> WG can provide some feedback.  This isn't intended to be a deadline for
the
> design teams, but a midpoint check on progress.  (The "set of issues" can
> be similar to what was put on screen yesterday, but this time in text.)
>
> For the security team, there is one item that seems to need addressing.
We
> need to identify the threats that the RRP will have to be defended
against.
> Traffic inspection, modification, etc. are documented means of attack.
> What I have in mind are identification of ways that the RRP may be abused
> (requesting unauthorized actions, leakage of contact data to spammers,
> etc.).  I do think that we need a better understanding of the 'privacy'
> issue before declaring it of scope of the protocol.  By identifying the
> threats we can determine which "security" services are needed.
>
> For the protocol and transport teams, I'd like there to be some addressing
> of how the choice of transport will impact the protocol.  E.g., if one
> transport layer offers a security service to the protocol and another
> transport does not, how will the protocol know to adapt.
>
> [1] - Regarding my comment about authorization vs. authentication.  IMHO,
> Authorization is more germaine to the problem here because we want to know
> if the client (whomever they are) is allowed to request an action.  Of
> course, to make an authoriztion determination, you do need to perform some
> authenication first.
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
>
> Dilbert is an optimist.
>
> Opinions expressed are property of my evil twin, not my employer.
>
>

Date: Wed, 21 Mar 2001 23:39:58 +0800
From: William Tan <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: Design teams
Mail-Followup-To: William Tan <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked]
Organization: i-DNS.net
Sender: [email-masked]

> For the security team, there is one item that seems to need addressing.  We
> need to identify the threats that the RRP will have to be defended against.
> Traffic inspection, modification, etc. are documented means of attack.
> What I have in mind are identification of ways that the RRP may be abused
> (requesting unauthorized actions, leakage of contact data to spammers,
> etc.).  I do think that we need a better understanding of the 'privacy'
> issue before declaring it of scope of the protocol.  By identifying the
> threats we can determine which "security" services are needed.
> 

It would be appropriate to define 'privacy' in this context to be an issue
of guarding the communication channel from eavesdropping.  Let us rest the
discussions on country laws and UK's mandatory traffic inspection, though
I agree that it is a valid point.

wil.

Date: Wed, 21 Mar 2001 10:26:54 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Design teams
Cc: [email-masked]
Sender: [email-masked]

First, I would like to set a target date of March 30 for the design teams
to submit to the mailing list a set of issues and opinions (so far) so the
WG can provide some feedback.  This isn't intended to be a deadline for the
design teams, but a midpoint check on progress.  (The "set of issues" can
be similar to what was put on screen yesterday, but this time in text.)

For the security team, there is one item that seems to need addressing.  We
need to identify the threats that the RRP will have to be defended against.
Traffic inspection, modification, etc. are documented means of attack.
What I have in mind are identification of ways that the RRP may be abused
(requesting unauthorized actions, leakage of contact data to spammers,
etc.).  I do think that we need a better understanding of the 'privacy'
issue before declaring it of scope of the protocol.  By identifying the
threats we can determine which "security" services are needed.

For the protocol and transport teams, I'd like there to be some addressing
of how the choice of transport will impact the protocol.  E.g., if one
transport layer offers a security service to the protocol and another
transport does not, how will the protocol know to adapt.

[1] - Regarding my comment about authorization vs. authentication.  IMHO,
Authorization is more germaine to the problem here because we want to know
if the client (whomever they are) is allowed to request an action.  Of
course, to make an authoriztion determination, you do need to perform some
authenication first.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 20 Mar 2001 18:15:11 +0000 (WET)
From: Sheer El-Showk <[email-masked]>
To: Bruce Campbell <[email-masked]>
cc: [email-masked]
Subject: Re: light comment on security provisions.
Sender: [email-masked]

Hi,

I think the design teams are intended to be long-term overseers of their
particular areas as we develope the protocol.  You're suggesting that the
requirements has already address the needs for certain kinds of security
and you're probably right (which is why we're trying to finalize the
requirements document).  The task of the security design team is now going
to be to address these issues and help descide at what level (protocol or
transport) these issues are going to be addressed.

As to your other point (regarding security being a local consideration),
there are some necassary clarifications here.  While data-access might be
a local consideration, data protection for the most part will not be (with
the caveats of maximum encryption strength and governement tap-in
laws).  Eric proposed considering P3P to publish local data access
preferences and I think this is an important part of the protocol.  The
subtle point here is that while data access laws might vary and different
methods might be employed to ensure security, where-ever this may vary
different entities have to have a way of publishing this so others
communicating with them can understand what restrictions are in place (eg
can't query by contact).  Some meta-protocol concept like this is also
relevant for describing what subset of provreg a site supports (this is an
unrelated concern but something that might want to be brought up in the
protocol design team).  These issues have been hashed out in the past but
I don't remember any closure anywhere and they're being brought up again
so I've mentioned them here.

Regards,
Sheer

On Wed, 21 Mar 2001, Bruce Campbell wrote:

> 
> This is in the 'am I missing something here' vein, however the drafts
> already released (as listed in the IETF WG charter page) have wording
> which covers in-transit security, which seems to be most of the security
> concerns being brought to the microphone, ie:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-00.txt
> 
>  11. Security Considerations
> 
>   [1] Security services MUST be provided to protect against the
>   following types of attack: eavesdropping, replay, message insertion,
>   deletion, modification, and man-in-the-middle.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-00.txt
> 
>  7. Security Considerations
> 
>   EPP provides only simple client authentication services.  A passive
>   attack is sufficient to recover client identifiers and passwords,
>   allowing trivial command forgery.  Protection against most common
>   attacks must be provided by other protocols.
> 
> The actual security provided is (as someone, Bill?) pointed out, dependent
> on country laws which one or both of the Registrars/Registries must
> observe, and as such, could be left as an issue between the individual
> Registrars/Registries. (ie, whatever the local laws/customers allow/want).
> 
> --==--
> Bruce.
> 

To: Bill Manning <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: security in draft-ietf-provreg-epp-0.txt
From: Sam Hartman <[email-masked]>
Date: 20 Mar 2001 12:06:03 -0500
Lines: 30
Sender: [email-masked]

>>>>> "Bill" == Bill Manning <[email-masked]> writes:

    Bill> % % Hi.  I've been looking at the security implications of
    Bill> the current EPP % draft and I am concerned that plaintext
    Bill> logins are not an appropriate % authentication mechanism for
    Bill> this protocol.  Per section 3.2 of %
    Bill> draft-ietf-provreg-grrp-req-0: % % 3.2 Identification and
    Bill> Authentication % % [1] The protocol or another layered
    Bill> protocol MUST provide services to % identify registrar
    Bill> clients and registry servers before granting access % to
    Bill> other protocol services.  % % [2] The protocol or another
    Bill> layered protocol MUST provide services to % authenticate
    Bill> registrar clients and registry servers before granting %
    Bill> access to other protocol services.  % % [3] The protocol or
    Bill> another layered protocol MUST provide services to %
    Bill> negotiate an authentication mechanism acceptable to both
    Bill> client and % server.  % % % First of all, having a login
    Bill> element that requires plaintext % passwords is not standard
    Bill> practice in new IETF protocols.

    Bill> 	Where, in the above quoted sections, is there a
    Bill> requirement for plaintext passwords?

My question was unclear because it assumed familiarity with the EPP
draft.  The current EPP draft has a login element that takes a
plaintext password; section 2.6.1.1 of the EPP draft requires a client
send a plaintext passwordbefore any other command.

The requirements are fine; the draft is not.

Date: Tue, 20 Mar 2001 18:09:57 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Possible impromptu meeting Wednesday
Cc: [email-masked]
Sender: [email-masked]

We have a chance to meet again tomorrow, at 1400 in Salon A.  This is a
time slot that *may* become available.  IDN is meeting from 1300 onwards
and there is a slight chance that they may be done early.  If they do, we
have been offered the opportunity to use the room then.

So, if you are willing to take a chance on making use of this time, please
be near the room at 1400.

Don't barge in!  IDN may not be done...let's not be impolite to our hosts!

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Wed, 21 Mar 2001 08:51:56 +1000 (EST)
From: Bruce Campbell <[email-masked]>
To: [email-masked]
Subject: light comment on security provisions.
Sender: [email-masked]

This is in the 'am I missing something here' vein, however the drafts
already released (as listed in the IETF WG charter page) have wording
which covers in-transit security, which seems to be most of the security
concerns being brought to the microphone, ie:

http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-00.txt

 11. Security Considerations

  [1] Security services MUST be provided to protect against the
  following types of attack: eavesdropping, replay, message insertion,
  deletion, modification, and man-in-the-middle.

http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-00.txt

 7. Security Considerations

  EPP provides only simple client authentication services.  A passive
  attack is sufficient to recover client identifiers and passwords,
  allowing trivial command forgery.  Protection against most common
  attacks must be provided by other protocols.

The actual security provided is (as someone, Bill?) pointed out, dependent
on country laws which one or both of the Registrars/Registries must
observe, and as such, could be left as an issue between the individual
Registrars/Registries. (ie, whatever the local laws/customers allow/want).

--==--
Bruce.

Date: Wed, 21 Mar 2001 01:50:04 +0800
From: William Tan <[email-masked]>
To: Rick H Wesson <[email-masked]>
Cc: Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Subject: Re: Pre-meeting notes
Organization: i-DNS.net
Sender: [email-masked]

Perhaps what is more important is that if we feel that the
base protocol is sufficient to support extensibility.
Applying the protocol in other types of registration other
than for domain names may require more than the currently
proposed facilities in the protocol.

wil.

On Tue, 20 Mar 2001, Rick H Wesson wrote:

> Ed,
> 
> 
> > 4) One of the issues raised in the drafting of the charter is
> > extensibility.  I feel that although the requirements document mentions
> > this, extensibility isn't being addresses enough.  Are there a few folks
> > (say 2-3) that would be willing to be a "design team" to keep an eye on
> > extensibilty?  I'm looking towards the folks that most vocally supported
> > the use of the protocol for not-just-DNS registrations.
> 
> This is inaccurate IMNSHO. Scott has addressed extensibility in several
> areas and several folks have made comments regarding various aspects of
> extensibility resulting in imrpovements in the drafts.
> 
> Unless you can be more specific about what has not been addressed in this
> area I think we are ok.
> 
> -rick
> 
> 

From: Bill Manning <[email-masked]>
Subject: Re: security in draft-ietf-provreg-epp-0.txt
To: [email-masked] (Hollenbeck, Scott)
Date: Tue, 20 Mar 2001 09:03:51 -0800 (PST)
Cc: [email-masked] ('Bill Manning '), [email-masked] ([email-masked] '), [email-masked] ([email-masked] ')
Sender: [email-masked]

 then perhaps the wording should be modified. Currently the statements
are "The protocol -OR- another layered protocol".  If there is no way
for the protocol to distinguish if the "other layered protocol" has 
done the work, then it MUST do it on its own.

% 
% I suspect that negotiation failures in lower layered protocols should be
% managed and contained in the layer(s) at which they occur.  If a fatal error
% occurs in a lower layer, the provreg base protocol layer shouldn't be
% instantiated.  Thus, if it is instantiated it can assume that all lower
% layer processing has been completed successfully.
% 
% <Scott/>
% 
% -----Original Message-----
% From: Bill Manning
% To: [email-masked]
% Cc: [email-masked]; [email-masked]
% Sent: 3/20/01 10:38 AM
% Subject: Re: security in draft-ietf-provreg-epp-0.txt
% 
% % 
% % Hi.  I've been looking at the security implications of the current EPP
% % draft and I am concerned that plaintext logins are not an appropriate
% % authentication mechanism for this protocol.  Per section 3.2 of
% % draft-ietf-provreg-grrp-req-0:
% % 
% %  3.2 Identification and Authentication
% % 
% %    [1] The protocol or another layered protocol MUST provide services
% to
% %    identify registrar clients and registry servers before granting
% access
% %    to other protocol services.
% % 
% %    [2] The protocol or another layered protocol MUST provide services
% to
% %    authenticate registrar clients and registry servers before granting
% %    access to other protocol services.
% % 
% %    [3] The protocol or another layered protocol MUST provide services
% to
% %    negotiate an authentication mechanism acceptable to both client and
% %    server.
% % 
% % 
% % First of all, having a login element that  requires plaintext
% % passwords  is not standard practice in new IETF protocols.  
% 
% 	Where, in the above quoted sections, is there a requirement
% 	for plaintext passwords?
% 
% 
% % At a minimum, EPP must provide a way to specify that authentication
% % should be imported from the layer providing security in order to meet
% % requirement 3 above.
% 
% 	if we change the wording in your question to:
% 	" ... imported from the layer providing authentication and
% integrity
% 	in order ..." then it seems to be nearly identical to #3.
% 
% 	I would like to see a refinement of how the protocol is going to
% 	determine when/how "another layered protocol" has failed to
% perform
% 	the tasks of a) identifying "authentic" clients/servers vs.
% imposters.
% 	see #1; b) authenticating client/server systems, see #2; and 
% 	c) negotiation of integrity checks for clients/servers, see #3
% 	
% 	One the protocol has determined a failure has occured, how does
% it
% 	negotiate to assume for itself these tasks, and then how does
% the
% 	protocol determine that the "other layered protocol" has
% recovered
% 	and it needs to stop performing these checks since there is now
% 	another entity performing them on its behalf.
% 
% 	Scott, any comments?
% 
% --bill
% 

-- 
--bill

Subject: Antwort: Pre-meeting notes
To: Edward Lewis <[email-masked]>
Cc: [email-masked], [email-masked]
From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" <[email-masked]>
Date: Tue, 20 Mar 2001 17:31:39 +0100
Sender: [email-masked]

On 20.03.2001 16:51 Edward Lewis <[email-masked]> wrote:
>
> The provreg meeting at the 50th IETF will be held later today (1545, in
> Salon B).  I have been reviewing recent activity and have come up with a
> few questions for the group:
>
> 1) Do the design teams feel that they have clear goals?  I have heard
some
> comment that this is not the case.  I will refrain from requesting the
> teams address this in their short presentations today because of the
short
> lead time.
>
> 2) How close are we to having a stable requirements document?  The
document
> is in good shape, but every once in a while an issue or two is raised.  I
> think that we are close to consensus on the document.

(+1)
We have to move forward, even if there is some discussion going on.
Things like "unique names" or a more open look to different objects could
go into a Version 2 of the protokoll.

>
> During the meeting, I'll ask the room if there are issues just to gauge
> what is needed.  I want to refrain from discussing the issues, refering
all
> discussion to the list.
>
> 3) The definitions document needs work, and we need to decide whether to
> tether the requirements document and the definitions document or not.  If
> not tethered, the requirements document needs to define its terms, if
> tethered, the requirements document cannot progress until the definitions
> document does.
>
> Q: To tether or not to tether...

I prefer doing some work on the definitions document. It´s a clear
seperation and it will help with new papers.

>
> 4) One of the issues raised in the drafting of the charter is
> extensibility.  I feel that although the requirements document mentions
> this, extensibility isn't being addresses enough.  Are there a few folks
> (say 2-3) that would be willing to be a "design team" to keep an eye on
> extensibilty?  I'm looking towards the folks that most vocally supported
> the use of the protocol for not-just-DNS registrations.
>
> Q: Do we need this / who wants to volunteer?

I realy want that the protocol isn´t just usefull for domainnames, but i
think we first should concentrate on domainnames because there is the
biggest need for a protocol.

It´s important that the protocol has that ability to be extended but i
think this is something for version 2.
Maybe it´s easier to define the requirement of this extensibility with the
experience of a working system.

--
----------------------------------+-------------------------------------------

Joerg Bauer                       | eMail : [email-masked]
DENIC eG                          | Fon   : +49 69 272 35 180
Wiesenhuettenplatz 26             | Fax   : +49 69 27235 235
D-60329 Frankfurt                 |
----------------------------------+-------------------------------------------

Date: Tue, 20 Mar 2001 11:23:48 -0500
To: Rick H Wesson <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Pre-meeting notes
Cc: Edward Lewis <[email-masked]>, Ietf-Provreg <[email-masked]>
Sender: [email-masked]

At 11:06 AM -0500 3/20/01, Rick H Wesson wrote:
>Unless you can be more specific about what has not been addressed in this
>area I think we are ok.

I do think the requirements document is okay with extensibility, the
definitions document is not.  What I had in mind for this design team is to
be set to analyze the protocol spec to make sure we maintain the ability to
be extensible.

I didn't mean to intone that the requirements aren't addressing
extensibility.  But I think that the words written (specificially in 7.5)
aren't strong enough to ensure that we are headed towards an extensible
protocol.  That being said, I believe the requirements document is okay as
is - because "extensibility" is not something you can measure/specify in
advance, especially in this case.

(In other words, I can't imagine a yes/no statement that, if yes, means
"it" is extensibile, no "it" is not.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 20 Mar 2001 08:06:05 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: Ietf-Provreg <[email-masked]>
Subject: Re: Pre-meeting notes
Sender: [email-masked]

Ed,

> 4) One of the issues raised in the drafting of the charter is
> extensibility.  I feel that although the requirements document mentions
> this, extensibility isn't being addresses enough.  Are there a few folks
> (say 2-3) that would be willing to be a "design team" to keep an eye on
> extensibilty?  I'm looking towards the folks that most vocally supported
> the use of the protocol for not-just-DNS registrations.

This is inaccurate IMNSHO. Scott has addressed extensibility in several
areas and several folks have made comments regarding various aspects of
extensibility resulting in imrpovements in the drafts.

Unless you can be more specific about what has not been addressed in this
area I think we are ok.

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bill Manning '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: security in draft-ietf-provreg-epp-0.txt
Date: Tue, 20 Mar 2001 10:50:52 -0500
Sender: [email-masked]

I suspect that negotiation failures in lower layered protocols should be
managed and contained in the layer(s) at which they occur.  If a fatal error
occurs in a lower layer, the provreg base protocol layer shouldn't be
instantiated.  Thus, if it is instantiated it can assume that all lower
layer processing has been completed successfully.

<Scott/>

-----Original Message-----
From: Bill Manning
To: [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 3/20/01 10:38 AM
Subject: Re: security in draft-ietf-provreg-epp-0.txt

% 
% Hi.  I've been looking at the security implications of the current EPP
% draft and I am concerned that plaintext logins are not an appropriate
% authentication mechanism for this protocol.  Per section 3.2 of
% draft-ietf-provreg-grrp-req-0:
% 
%  3.2 Identification and Authentication
% 
%    [1] The protocol or another layered protocol MUST provide services
to
%    identify registrar clients and registry servers before granting
access
%    to other protocol services.
% 
%    [2] The protocol or another layered protocol MUST provide services
to
%    authenticate registrar clients and registry servers before granting
%    access to other protocol services.
% 
%    [3] The protocol or another layered protocol MUST provide services
to
%    negotiate an authentication mechanism acceptable to both client and
%    server.
% 
% 
% First of all, having a login element that  requires plaintext
% passwords  is not standard practice in new IETF protocols.  

	Where, in the above quoted sections, is there a requirement
	for plaintext passwords?

% At a minimum, EPP must provide a way to specify that authentication
% should be imported from the layer providing security in order to meet
% requirement 3 above.

	if we change the wording in your question to:
	" ... imported from the layer providing authentication and
integrity
	in order ..." then it seems to be nearly identical to #3.

	I would like to see a refinement of how the protocol is going to
	determine when/how "another layered protocol" has failed to
perform
	the tasks of a) identifying "authentic" clients/servers vs.
imposters.
	see #1; b) authenticating client/server systems, see #2; and 
	c) negotiation of integrity checks for clients/servers, see #3
	
	One the protocol has determined a failure has occured, how does
it
	negotiate to assume for itself these tasks, and then how does
the
	protocol determine that the "other layered protocol" has
recovered
	and it needs to stop performing these checks since there is now
	another entity performing them on its behalf.

	Scott, any comments?

--bill

Date: Tue, 20 Mar 2001 10:51:50 -0500
To: Ietf-Provreg <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Pre-meeting notes
Cc: [email-masked]
Sender: [email-masked]

The provreg meeting at the 50th IETF will be held later today (1545, in
Salon B).  I have been reviewing recent activity and have come up with a
few questions for the group:

1) Do the design teams feel that they have clear goals?  I have heard some
comment that this is not the case.  I will refrain from requesting the
teams address this in their short presentations today because of the short
lead time.

2) How close are we to having a stable requirements document?  The document
is in good shape, but every once in a while an issue or two is raised.  I
think that we are close to consensus on the document.

During the meeting, I'll ask the room if there are issues just to gauge
what is needed.  I want to refrain from discussing the issues, refering all
discussion to the list.

3) The definitions document needs work, and we need to decide whether to
tether the requirements document and the definitions document or not.  If
not tethered, the requirements document needs to define its terms, if
tethered, the requirements document cannot progress until the definitions
document does.

Q: To tether or not to tether...

4) One of the issues raised in the drafting of the charter is
extensibility.  I feel that although the requirements document mentions
this, extensibility isn't being addresses enough.  Are there a few folks
(say 2-3) that would be willing to be a "design team" to keep an eye on
extensibilty?  I'm looking towards the folks that most vocally supported
the use of the protocol for not-just-DNS registrations.

Q: Do we need this / who wants to volunteer?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: Tue, 20 Mar 2001 09:32:05 -0600
To: "Hollenbeck, Scott" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: security in draft-ietf-provreg-epp-0.txt
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

At 09:19 AM 3/20/2001, Hollenbeck, Scott wrote:
>but I believe that such profiles should be specified in
>documents separate from the base protocol specification

Having it in a separate document does underscore that other mappings are 
possible and allowed, yes.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: Bill Manning <[email-masked]>
Subject: Re: security in draft-ietf-provreg-epp-0.txt
To: [email-masked] (Sam Hartman)
Date: Tue, 20 Mar 2001 07:38:07 -0800 (PST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

% 
% Hi.  I've been looking at the security implications of the current EPP
% draft and I am concerned that plaintext logins are not an appropriate
% authentication mechanism for this protocol.  Per section 3.2 of
% draft-ietf-provreg-grrp-req-0:
% 
%  3.2 Identification and Authentication
% 
%    [1] The protocol or another layered protocol MUST provide services to
%    identify registrar clients and registry servers before granting access
%    to other protocol services.
% 
%    [2] The protocol or another layered protocol MUST provide services to
%    authenticate registrar clients and registry servers before granting
%    access to other protocol services.
% 
%    [3] The protocol or another layered protocol MUST provide services to
%    negotiate an authentication mechanism acceptable to both client and
%    server.
% 
% 
% First of all, having a login element that  requires plaintext
% passwords  is not standard practice in new IETF protocols.  

	Where, in the above quoted sections, is there a requirement
	for plaintext passwords?

% At a minimum, EPP must provide a way to specify that authentication
% should be imported from the layer providing security in order to meet
% requirement 3 above.

	if we change the wording in your question to:
	" ... imported from the layer providing authentication and integrity
	in order ..." then it seems to be nearly identical to #3.

	I would like to see a refinement of how the protocol is going to
	determine when/how "another layered protocol" has failed to perform
	the tasks of a) identifying "authentic" clients/servers vs. imposters.
	see #1; b) authenticating client/server systems, see #2; and 
	c) negotiation of integrity checks for clients/servers, see #3
	
	One the protocol has determined a failure has occured, how does it
	negotiate to assume for itself these tasks, and then how does the
	protocol determine that the "other layered protocol" has recovered
	and it needs to stop performing these checks since there is now
	another entity performing them on its behalf.

	Scott, any comments?

--bill

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bill Manning '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: security in draft-ietf-provreg-epp-0.txt
Date: Tue, 20 Mar 2001 10:24:01 -0500
Sender: [email-masked]

Agreed, that's why the existing "Security Considerations" section describes
the weaknesses in the base protocol's security features, noting that
"better" services are required from other protocol layers.

<Scott/>

-----Original Message-----
From: Bill Manning
To: [email-masked]
Cc: [email-masked]
Sent: 3/20/01 10:14 AM
Subject: Re: security in draft-ietf-provreg-epp-0.txt

% We've already architected a solution that allows appropriate security
% service layers, and forcing those services into the base protocol can
% introduce redundancy -- such as when SMTP transport with S/MIME or PGP
% security is required.
% 
% <Scott/>

We should be very clear that the architected solution is an acceptable
solution not THE solution.  Determining what is appropriate is...
(outside the scope?) 
What we are required to do is document the security (authentication &
integrity checks for sure) methods that the architected solution is
using and note the strengths and weaknesses in the selected methods.

--bill

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Dave Crocker '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: security in draft-ietf-provreg-epp-0.txt
Date: Tue, 20 Mar 2001 10:19:42 -0500
Sender: [email-masked]

I don't think I'm confused this time ;-), but perhaps my response didn't
help eliminate anyone else's confusion.  I agree that we need a BEEP
operational profile (I'd go so far as to say that we really need more than
one such profile), but I believe that such profiles should be specified in
documents separate from the base protocol specification.  Sorry if I didn't
make that clear in my earlier response.

-----Original Message-----
From: Dave Crocker
To: Hollenbeck, Scott
Cc: [email-masked]
Sent: 3/20/01 8:35 AM
Subject: RE: security in draft-ietf-provreg-epp-0.txt

At 07:13 AM 3/20/2001, Hollenbeck, Scott wrote:
>Requiring BEEP contradicts other requirements for transport
independence.

I suspect there is some confusion between:

         a technical characteristic -- ability to map the application 
protocol to run over multiple transports, versus

         an operational profile -- specification of a complete set of 
features to be used for basic interoperability, including transport and 
security mechanisms.

The former is good for extensibility.  The latter is essential for
initial use.

From: Bill Manning <[email-masked]>
Subject: Re: security in draft-ietf-provreg-epp-0.txt
To: [email-masked] (Hollenbeck, Scott)
Date: Tue, 20 Mar 2001 07:14:43 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

% We've already architected a solution that allows appropriate security
% service layers, and forcing those services into the base protocol can
% introduce redundancy -- such as when SMTP transport with S/MIME or PGP
% security is required.
% 
% <Scott/>

We should be very clear that the architected solution is an acceptable
solution not THE solution.  Determining what is appropriate is...
(outside the scope?) 
What we are required to do is document the security (authentication &
integrity checks for sure) methods that the architected solution is
using and note the strengths and weaknesses in the selected methods.

--bill

Date: Tue, 20 Mar 2001 07:35:09 -0600
To: "Hollenbeck, Scott" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: security in draft-ietf-provreg-epp-0.txt
Cc: [email-masked]
Sender: [email-masked]

At 07:13 AM 3/20/2001, Hollenbeck, Scott wrote:
>Requiring BEEP contradicts other requirements for transport independence.

I suspect there is some confusion between:

         a technical characteristic -- ability to map the application 
protocol to run over multiple transports, versus

         an operational profile -- specification of a complete set of 
features to be used for basic interoperability, including transport and 
security mechanisms.

The former is good for extensibility.  The latter is essential for initial use.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: security in draft-ietf-provreg-epp-0.txt
Date: Tue, 20 Mar 2001 08:13:11 -0500
Sender: [email-masked]

>-----Original Message-----
>From: Sam Hartman [mailto:[email-masked]]
>Sent: Monday, March 19, 2001 10:54 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: security in draft-ietf-provreg-epp-0.txt
>
>

[snip]

>However, I think  that EPP would be significantly improved if it
>actually had security mechansims like SASL or TLS within the base
>protocol.  One easy way to do this would be to make EPP be a BEEP
>profile.

As architected, a BEEP profile can be written with no problem whatsoever.
Requiring BEEP contradicts other requirements for transport independence.

Needless to say, I disagree with the suggestion that SASL or TLS or anything
other than what's in there already should be required in the base protocol.
We've already architected a solution that allows appropriate security
service layers, and forcing those services into the base protocol can
introduce redundancy -- such as when SMTP transport with S/MIME or PGP
security is required.

<Scott/>

Date: Mon, 19 Mar 2001 23:54:27 -0500 (EST)
From: Sam Hartman <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: security in draft-ietf-provreg-epp-0.txt
Sender: [email-masked]

Hi.  I've been looking at the security implications of the current EPP
draft and I am concerned that plaintext logins are not an appropriate
authentication mechanism for this protocol.  Per section 3.2 of
draft-ietf-provreg-grrp-req-0:

 3.2 Identification and Authentication

   [1] The protocol or another layered protocol MUST provide services to
   identify registrar clients and registry servers before granting access
   to other protocol services.

   [2] The protocol or another layered protocol MUST provide services to
   authenticate registrar clients and registry servers before granting
   access to other protocol services.

   [3] The protocol or another layered protocol MUST provide services to
   negotiate an authentication mechanism acceptable to both client and
   server.

First of all, having a login element that  requires plaintext
passwords  is not standard practice in new IETF protocols.  The BEEP
framework relies on SASL which can use plaintext passwords or other
negotiated mechanisms.  Many protocols use TLS, but when they do they
allow TLS to provide both client and server authentication ; this is
true for HTTP, and for LDAP and IMAP using TLS with the SASL external
mechanism.   

Older protocols are even beting retrofitted to allow authentication
other than plaintext passwords.  SMTP  supports SASL; SMNP3 supports
security frameworks that allow arbitrary authentication.  

In all these cases, information is carried from the layer providing
the security services to the application layer.  It is not enough to
simply say that the EPP protocol will be layered within some protocol
that provides security negotiation.  That protocol might provide
authentication and authentication negotiation  but then the user still
has to login at the EPP layer under the current spec.  Thus, the
client cannot negotiate  a mechanism because whatever mechanism it
uses at the security layering protocol, it then has to in addition
use the EPP plaintext password.

At a minimum, EPP must provide a way to specify that authentication
should be imported from the layer providing security in order to meet
requirement 3 above.

However, I think  that EPP would be significantly improved if it
actually had security mechansims like SASL or TLS within the base
protocol.  One easy way to do this would be to make EPP be a BEEP
profile.

Date: Mon, 19 Mar 2001 16:51:23 +0000 (WET)
From: Sheer El-Showk <[email-masked]>
To: [email-masked]
Subject: Re: Minneapolis time slot 
Sender: [email-masked]

Are there any intended off-site meetings for general discussion?  If any
of the design teams are having meetings would they be willing to open
them up to non-design team members?

Regards,
Sheer

On Mon, 19 Mar 2001, Jaap Akkerhuis wrote:

> 
>     
>     | Our time slot in Minneapolis is *Tuesday* from 5pm-6pm.   (March 20.)
>     
>       What's the location?  I don't see anything on the schedule.
>     
> It is on the schedule. Tuesday, 15:45-16:45, salon B
> 
> 	jaap
> 

To: "Brian W. Spolarich" <[email-masked]>
cc: "Edward Lewis" <[email-masked]>, [email-masked]
Subject: Re: Minneapolis time slot 
Date: Mon, 19 Mar 2001 22:52:23 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    | Our time slot in Minneapolis is *Tuesday* from 5pm-6pm.   (March 20.)
    
      What's the location?  I don't see anything on the schedule.
    
It is on the schedule. Tuesday, 15:45-16:45, salon B

	jaap

From: "Brian W. Spolarich" <[email-masked]>
To: "Edward Lewis" <[email-masked]>, <[email-masked]>
Subject: RE: Minneapolis time slot
Date: Mon, 19 Mar 2001 16:23:21 -0500
Importance: Normal
Sender: [email-masked]

| Our time slot in Minneapolis is *Tuesday* from 5pm-6pm.   (March 20.)

  What's the location?  I don't see anything on the schedule.

Date: Fri, 16 Mar 2001 10:23:32 +0100
From: Klaus Malorny <[email-masked]>
To: Martin Oldfield <[email-masked]>
CC: [email-masked], George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Martin Oldfield wrote:
> 
> Splendid, thanks for your illuminating comments.
> 
> I think I'm slightly disappointed that experience suggests people
> can't maintain persistent URNs, but that's life I guess.
> 
> Cheers,
> --
> Martin Oldfield,
> AdamsNames Ltd.

Sorry to intervene: URI != URN != URL. My original idea was to use URNs, which
are, per definition, persistent. They do not follow the typical host/file
schema used e.g. by the http: and ftp: schemas. In contrast to many other
URIs, do not define a protocol, a way to access the data behind. This is its
strength and also its weakness. The problem is that currently no standard
exists to resolve a URN, i.e. to access the data described by the URN.

Another way could be to create an own URI schema, e.g. a "whois:". But one
should be careful and should not introduce new standards if it is not
necessary.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

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

     C e B I T  2001                    Visit us at our booth:
     H a n n o v e r                    
     22.3.-28.3.2001                    Hall 6, A 47 (716)

Date: Thu, 15 Mar 2001 20:44:40 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: My whereabouts
Cc: [email-masked]
Sender: [email-masked]

I've finally returned to where I can read email.  For the past 10 days I
was in ISDN-only hotels, so I have been unable to receive or send email.

I see that there are a lot of messages outstanding (for me to read, that
is), but I think we are at least set up for Minneapolis.  If there is an
immediate issue I need to attend to, please bug me if it seems I'm
responding too slowly.  (No more ISDN hotels for awhile...)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

Date: 15 Mar 2001 19:17:13 -0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: .name
Sender: [email-masked]

Hi Rick (and provreg WG),

yes, I am reading the provreg mailing list, but I have (at least up until now)
not participated actively in the Working Group (nor the mailing list). :-)

In the original application we proposed the socalled SRRP (Stateless RRP), but
the way it look now, we are not going to use SRRP from day one. To make it
easier for new Registrars to connect to our Registry, we will in the beginning
most probably use an extended version of RRP.

Later it might be more interesting to implement EPP instead of SRRP, but that
depends partly on the progress and status of the EPP when the decission needs to
be made.

Asbjorn Steira
The Global Name Registry

-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

Date: Thu, 15 Mar 2001 19:06:35 +0000 (GMT)
To: [email-masked]
Cc: Martin Oldfield <[email-masked]>, George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

Splendid, thanks for your illuminating comments.

I think I'm slightly disappointed that experience suggests people
can't maintain persistent URNs, but that's life I guess.

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Thu, 15 Mar 2001 13:19:06 -0500
From: Michael Mealling <[email-masked]>
To: Martin Oldfield <[email-masked]>
Cc: [email-masked], George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Mar 15, 2001 at 06:17:44PM +0000, Martin Oldfield wrote:
> >>>>> "Michael" == Michael Mealling <[email-masked]> writes:
>     Michael> That's a step in the right direction, yes. The other main
>     Michael> objection is that of using the 'http' scheme which
>     Michael> contains a domain-name.  A domain-name is too fragil of
>     Michael> an identifier to use for the entities that actually
>     Michael> manage those domain-names (i.e. the registries involved
>     Michael> here should last longer than the average life of their
>     Michael> default domain-names).  IMHO, you want a scheme that a)
>     Michael> has uniqueness b) has persistence and c) does not have
>     Michael> domain-names in it.
> 
> I see your point of view, but isn't it really hard to escape domain
> names somewhere ? 

Sure. You still use domain-names somewhere in the lookup. You just
don't put them in the name itself.

> Consider a scheme where the registry-handle comes from some central
> registry. Don't you then need to have some magic URN which contains a
> list of registry handles and tells the client how to handle them ? The
> alternative would appear to be giving each client a list of registry
> handles and details of how to handle them: perhaps a list is unavoidable
> because I'm sure that some clients will want to only trust certain
> registries.

Sure. But as long as you have that level of redirection you can
easily move those DNS values around. I.e. don't put the DNS values
in the name itself. Instead specify how that non-DNS value points into
DNS so you can find out where the registry-handle currently lives.

> If we do want to have a automated scheme for resolving a handle though
> , then presumably we need some central root which knows how to direct
> all the registry handles, or the handle itself has to tell us where to 
> go. 

Yep. And that's a service that the IANA would provide since it would
act as the registry handle registry itself. Sure, its another root
but root's aren't completely anathema are they? Heck, even if you
use _any_ URI you still have hte IANA as the root since its the
registry for all URI schemes...

> If that's right then isn't this a trade-off between having registry
> handles issued by a central authority who has to keep their URN alive
> forever, or having a multiplicity of URNs but letting everyone make up
> their own registry handle ?

Sure... But the key here is that as long as there is uniqueness of
the registry handles you have a persistent identifier. Its a tradeoff
but in order to make a system that's stable and persistent you'll need
some kind of limited root. IMHO, a single registry of registry handles is
sufficiently lightweight to be reasonable....

> 
>     Michael> But still, once you limit it like this you've gotten
>     Michael> yourself back to an identification scheme that is
>     Michael> specific to your system (a good thing) that happens to be
>     Michael> a URI (also a good thing).

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Thu, 15 Mar 2001 18:17:44 +0000 (GMT)
To: [email-masked]
Cc: Martin Oldfield <[email-masked]>, George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Michael" == Michael Mealling <[email-masked]> writes:

    Michael> On Thu, Mar 15, 2001 at 05:25:10PM +0000, Martin Oldfield
    Michael> wrote:
    >> >>>>> "Michael" == Michael Mealling <[email-masked]>
    >> >>>>> writes:
    Michael> Please. No. I've been involved in a lot of these XML/URI
    Michael> discusions and you really don't want to do this. Do you
    Michael> really want to have your system to have to deal with a
    Michael> registry using "mailto:[email-masked]" as its registry
    Michael> identifier? Allowing any URI means you allow _ANY_ URI
    Michael> here.  The issues surrounding the nearly 100 different
    Michael> unregistered URIs that folks are using with no
    Michael> coordination and several conflicts [1][2] make this a
    Michael> currently very badly managed space. This is the
    Michael> identifier the _entire_ provreg system is going to depend
    Michael> on at its _core_. You really don't want it based on such
    Michael> loose identification scheme...
    >>
    >> So much for that daft idea then!

    Michael> Sorry about the bluntness there. The pain that was felt

Not at all: I'm just hope you didn't need too much anti-histamine.. I
think your experience is really valuable, and short-circuits a whole
bunch of ignorant waffling.

    Michael> in many different areas created a severe alergic
    Michael> reaction. ;-)

    >> If you'll indulge my stupidity for a little longer,

    Michael> Not stupidity! Its a good idea that has merit but
    Michael> experience is in the process of teaching us where that
    Michael> idea is useful and where it causes problems... (As an
    Michael> aside, I'm involved in the W3C URI Interest Group where
    Michael> we're discussing exactly these kind of issues and
    Michael> hopefull we'll be able to issue some guidance soon).

Splendid. 

    >> would you objections persist if the URI had to be an http:
    >> thing, and the target of the URI had to deliver a particular
    >> document ?

    Michael> That's a step in the right direction, yes. The other main
    Michael> objection is that of using the 'http' scheme which
    Michael> contains a domain-name.  A domain-name is too fragil of
    Michael> an identifier to use for the entities that actually
    Michael> manage those domain-names (i.e. the registries involved
    Michael> here should last longer than the average life of their
    Michael> default domain-names).  IMHO, you want a scheme that a)
    Michael> has uniqueness b) has persistence and c) does not have
    Michael> domain-names in it.

I see your point of view, but isn't it really hard to escape domain
names somewhere ? 

Consider a scheme where the registry-handle comes from some central
registry. Don't you then need to have some magic URN which contains a
list of registry handles and tells the client how to handle them ? The
alternative would appear to be giving each client a list of registry
handles and details of how to handle them: perhaps a list is unavoidable
because I'm sure that some clients will want to only trust certain
registries.

If we do want to have a automated scheme for resolving a handle though
, then presumably we need some central root which knows how to direct
all the registry handles, or the handle itself has to tell us where to 
go. 

If that's right then isn't this a trade-off between having registry
handles issued by a central authority who has to keep their URN alive
forever, or having a multiplicity of URNs but letting everyone make up
their own registry handle ?

    Michael> But still, once you limit it like this you've gotten
    Michael> yourself back to an identification scheme that is
    Michael> specific to your system (a good thing) that happens to be
    Michael> a URI (also a good thing).

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Thu, 15 Mar 2001 18:56:28 +0100 (MET)
From: Elmar Knipp <[email-masked]>
To: Rick H Wesson <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: .name
Sender: [email-masked]

On Thu, 15 Mar 2001, Rick H Wesson wrote:

> is anyone from .name participating in this wg, I herd .name intends to
> launch Q2 of this year and they have proposed a new protocol to use with
> their registry.

Rick,

last month I spoke in Zuerich with Geir Rasmussen (CTO of
Global.Name). I got the impression that they are far away of
launching.

Best regards,
Elmar

-- 
_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        44227 Dortmund
                                        Germany
                                        Fon: +49 231 9703-0
     [email-masked]               Fax: +49 231 9703-200

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

     C e B I T  2001                    Besuchen Sie uns
     H a n n o v e r                    auf unserem Stand:
     22.3.-28.3.2001                    Halle 6, A 47 (716)

Date: Thu, 15 Mar 2001 12:35:19 -0500
From: Michael Mealling <[email-masked]>
To: Martin Oldfield <[email-masked]>
Cc: [email-masked], George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Mar 15, 2001 at 05:25:10PM +0000, Martin Oldfield wrote:
> >>>>> "Michael" == Michael Mealling <[email-masked]> writes:
>     Michael> Please. No. I've been involved in a lot of these XML/URI
>     Michael> discusions and you really don't want to do this. Do you
>     Michael> really want to have your system to have to deal with a
>     Michael> registry using "mailto:[email-masked]" as its registry
>     Michael> identifier? Allowing any URI means you allow _ANY_ URI
>     Michael> here.  The issues surrounding the nearly 100 different
>     Michael> unregistered URIs that folks are using with no
>     Michael> coordination and several conflicts [1][2] make this a
>     Michael> currently very badly managed space. This is the
>     Michael> identifier the _entire_ provreg system is going to depend
>     Michael> on at its _core_. You really don't want it based on such
>     Michael> loose identification scheme...
> 
> So much for that daft idea then!

Sorry about the bluntness there. The pain that was felt in many different
areas created a severe alergic reaction. ;-) 

> If you'll indulge my stupidity for a little longer, 

Not stupidity! Its a good idea that has merit but experience is
in the process of teaching us where that idea is useful and where it
causes problems... (As an aside, I'm involved in the W3C URI Interest
Group where we're discussing exactly these kind of issues and hopefull
we'll be able to issue some guidance soon).

> would you
> objections persist if the URI had to be an http: thing, and the target 
> of the URI had to deliver a particular document ?

That's a step in the right direction, yes. The other main objection
is that of using the 'http' scheme which contains a domain-name.
A domain-name is too fragil of an identifier to use for the entities
that actually manage those domain-names (i.e. the registries involved
here should last longer than the average life of their default domain-names).
IMHO, you want a scheme that a) has uniqueness b) has persistence and c) 
does not have domain-names in it. 

But still, once you limit it like this you've gotten yourself back to 
an identification scheme that is specific to your system (a good thing)
that happens to be a URI (also a good thing). 

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Thu, 15 Mar 2001 18:31:32 +0100
From: Patrick <[email-masked]>
To: Rick H Wesson <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: .name
Organization: Gandi
Sender: [email-masked]

--XlS4q8O07AKt4+K1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 15, 2001 at 08:51:40AM -0800, Rick H Wesson took time to write:
>=20
> is anyone from .name participating in this wg, I herd .name intends to
> launch Q2 of this year and they have proposed a new protocol to use with
> their registry.
>=20
> If anyone from .name is around would you mind droping me a note.

I think everyone here could be interested so please make it public.
=46rom their website I have downloaded some documents explaining their
protocol : SRRP for Stateless RRP but I am definitively instered by
comments.

Patrick.

--XlS4q8O07AKt4+K1
Content-Type: application/pgp-signature
Content-Disposition: inline

--XlS4q8O07AKt4+K1--

Date: Thu, 15 Mar 2001 17:25:10 +0000 (GMT)
To: [email-masked]
Cc: George Belotsky <[email-masked]>, Martin Oldfield <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Michael" == Michael Mealling <[email-masked]> writes:

    Michael> On Thu, Mar 15, 2001 at 11:55:09AM -0500, George Belotsky
    Michael> wrote:
    >> Can we automatically generate these URIs and ensure uniqueness
    >> without resorting to some central repository?
    >>
    >> If we can (I don't see why not), then this is potentially a
    >> good approach.

    Michael> Please. No. I've been involved in a lot of these XML/URI
    Michael> discusions and you really don't want to do this. Do you
    Michael> really want to have your system to have to deal with a
    Michael> registry using "mailto:[email-masked]" as its registry
    Michael> identifier? Allowing any URI means you allow _ANY_ URI
    Michael> here.  The issues surrounding the nearly 100 different
    Michael> unregistered URIs that folks are using with no
    Michael> coordination and several conflicts [1][2] make this a
    Michael> currently very badly managed space. This is the
    Michael> identifier the _entire_ provreg system is going to depend
    Michael> on at its _core_. You really don't want it based on such
    Michael> loose identification scheme...

    Michael> -MM

    Michael> [1]http://www.w3.org/Addressing/schemes
    Michael> [2]http://www.isi.edu/in-notes/iana/assignments/url-schemes

So much for that daft idea then!

If you'll indulge my stupidity for a little longer, would you
objections persist if the URI had to be an http: thing, and the target 
of the URI had to deliver a particular document ?

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Thu, 15 Mar 2001 12:00:06 -0500
From: Michael Mealling <[email-masked]>
To: George Belotsky <[email-masked]>
Cc: Martin Oldfield <[email-masked]>, [email-masked], "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Mar 15, 2001 at 11:55:09AM -0500, George Belotsky wrote:
> Can we automatically generate these URIs and ensure uniqueness
> without resorting to some central repository?
> 
> If we can (I don't see why not), then this is potentially a
> good approach.

Please. No. I've been involved in a lot of these XML/URI discusions and you
really don't want to do this. Do you really want to have your system
to have to deal with a registry using "mailto:[email-masked]" as its
registry identifier? Allowing any URI means you allow _ANY_ URI here.
The issues surrounding the nearly 100 different unregistered URIs that
folks are using with no coordination and several conflicts [1][2] make
this a currently very badly managed space. This is the identifier the
_entire_ provreg system is going to depend on at its _core_. You
really don't want it based on such loose identification scheme...

-MM

[1]http://www.w3.org/Addressing/schemes
[2]http://www.isi.edu/in-notes/iana/assignments/url-schemes

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Thu, 15 Mar 2001 11:49:56 -0500
From: Michael Mealling <[email-masked]>
To: Martin Oldfield <[email-masked]>
Cc: [email-masked], George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Mar 15, 2001 at 04:40:33PM +0000, Martin Oldfield wrote:
> >>>>> "Michael" == Michael Mealling <[email-masked]> writes:
> --> snip <--
>     Michael> My recommendation is this: use the
>     Michael> <registry-handle>-<local-handle> syntax where
>     Michael> registry-handle is registered with the IANA and
>     Michael> local-handle is a unique identifier assigned however the
> 
> Rather than having an IANA registered registry-handle, can't one
> simply use a URI ? This idea is used by XML namespaces [2], and
> similar to Rick Wesson's idea [3]. 

And suffers from the same problems that XML Namespaces has:
If you allow any URI here you end up with unstable identifiers.
_We_ all know how unstable domain-name based identifiers are. It
seems kind of silly to base our identification structure on something
that we are in the process of managing and thus changes out from underneath
us. A good example: is the Verisign registry required to still be 
known as networksolutions.com? Shouldn't it still be internic.net since
that's what the registry originally was known as?

You _could_ restrict it to a particular URI scheme (which IMHO is what
XML Namespaces wanted to do but couldn't due to some political issues).
But, IMHO, this is overkill. What would make sense is turn the tables
around and turn the handle into a URI (i.e. a URN) which would allow
you to do some interesting (but probably not core) things.

> From the handle perspective I don't think it's necessary that the URI
> actually points at anything, though of course this could happen in
> future---this actually mirrors the XML situation (see
> e.g. [4]). Following the XML example, the registry handle URI would be
> a natural place to store things like a specification of the registry,
> its policies and so forth.

Sure, but is that an argument for being able to turn a handle into a 
URI fairly easily not making handles be _any_ URI. We're not designing 
XML here, just a fairly task specific system for provisioning records 
in databases.

> Are there lessons to be learned from XML namespaces ? I've done little
> more than browse the FAQs [5] but I'm sure there are people here much
> more knowledgable.

One of the issues that XML is learning now is that you should only
allow a field to be _any_ URI when you're application is completely aware
that it could be identifying ANY sort of resource (abstract or otherwise)
and in most cases the entity that originally bound the URI to that 
Resource had no intention of it being used as an identifier in some
other system. In the case where some field is a core protocol concept (such as
in RDF or XML Schemas) its a good idea to limit the types of URIs you 
can safely use in that field. Thus, IMHO, the registry part of the
name should not be a URI but instead the whole thing should be capable
of being turned into a specific type of URI (IMHO, a URN but that's just
my opinion).

>     Michael> registry sees fit. Then, to handle equivalence between
>     Michael> registries, the base schema of all objects (if that has a
>     Michael> concept here, I haven't looked yet) allow for a way for
>     Michael> one object to say two things: "Hey, I'm also known as
>     Michael> FOO-BAR, BAZ-BAR, and HOMER-DONUTS." as well as "I was
>     Michael> also known as PREHISTORIC-CAVEMAN at sometime in the
>     Michael> past". The one thing this fixes is that equivalence may
> 
> Presumably this implies that the local-parts can't be reused ?

I think that's a rough concensus here for that idea. I'm pretty sure its 
an informal policy among most of the existing registries/registrars....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Thu, 15 Mar 2001 11:55:09 -0500
From: George Belotsky <[email-masked]>
To: Martin Oldfield <[email-masked]>
Cc: [email-masked], "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Can we automatically generate these URIs and ensure uniqueness
without resorting to some central repository?

If we can (I don't see why not), then this is potentially a
good approach.

George. 

On Thu, Mar 15, 2001 at 04:40:33PM +0000, Martin Oldfield wrote:
> >>>>> "Michael" == Michael Mealling <[email-masked]> writes:
> 
> --> snip <--
> 
>     Michael> My recommendation is this: use the
>     Michael> <registry-handle>-<local-handle> syntax where
>     Michael> registry-handle is registered with the IANA and
>     Michael> local-handle is a unique identifier assigned however the
> 
> Rather than having an IANA registered registry-handle, can't one
> simply use a URI ? This idea is used by XML namespaces [2], and
> similar to Rick Wesson's idea [3]. 
> 
> >From the handle perspective I don't think it's necessary that the URI
> actually points at anything, though of course this could happen in
> future---this actually mirrors the XML situation (see
> e.g. [4]). Following the XML example, the registry handle URI would be
> a natural place to store things like a specification of the registry,
> its policies and so forth.
> 
> Are there lessons to be learned from XML namespaces ? I've done little
> more than browse the FAQs [5] but I'm sure there are people here much
> more knowledgable.
> 
>     Michael> registry sees fit. Then, to handle equivalence between
>     Michael> registries, the base schema of all objects (if that has a
>     Michael> concept here, I haven't looked yet) allow for a way for
>     Michael> one object to say two things: "Hey, I'm also known as
>     Michael> FOO-BAR, BAZ-BAR, and HOMER-DONUTS." as well as "I was
>     Michael> also known as PREHISTORIC-CAVEMAN at sometime in the
>     Michael> past". The one thing this fixes is that equivalence may
> 
> Presumably this implies that the local-parts can't be reused ?
> 
>     Michael> be a pre-registry concept. I.e. while Bill may consider
>     Michael> WM110-ARIN and WM35-RADB the same, the registries
>     Michael> involved may have some policy where they're not allowed
>     Michael> to either know or publish that information.
> 
>     Michael> -MM
> 
>     Michael> [1]
>     Michael> http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00128.html
> 
> [2] http://www.w3.org/TR/REC-xml-names/
> [3] http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00059.html
> [4] http://www.xmlhack.com/read.php?item=974
> [5] http://www.rpbourret.com/xml/NamespacesFAQ.htm
> 
> Cheers,
> -- 
> Martin Oldfield,
> AdamsNames Ltd.
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Thu, 15 Mar 2001 08:51:40 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: .name
Sender: [email-masked]

is anyone from .name participating in this wg, I herd .name intends to
launch Q2 of this year and they have proposed a new protocol to use with
their registry.

If anyone from .name is around would you mind droping me a note.

thnaks,

-rick

Date: Thu, 15 Mar 2001 16:40:33 +0000 (GMT)
To: [email-masked]
Cc: George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Michael" == Michael Mealling <[email-masked]> writes:

--> snip <--

    Michael> My recommendation is this: use the
    Michael> <registry-handle>-<local-handle> syntax where
    Michael> registry-handle is registered with the IANA and
    Michael> local-handle is a unique identifier assigned however the

Rather than having an IANA registered registry-handle, can't one
simply use a URI ? This idea is used by XML namespaces [2], and
similar to Rick Wesson's idea [3]. 

>From the handle perspective I don't think it's necessary that the URI
actually points at anything, though of course this could happen in
future---this actually mirrors the XML situation (see
e.g. [4]). Following the XML example, the registry handle URI would be
a natural place to store things like a specification of the registry,
its policies and so forth.

Are there lessons to be learned from XML namespaces ? I've done little
more than browse the FAQs [5] but I'm sure there are people here much
more knowledgable.

    Michael> registry sees fit. Then, to handle equivalence between
    Michael> registries, the base schema of all objects (if that has a
    Michael> concept here, I haven't looked yet) allow for a way for
    Michael> one object to say two things: "Hey, I'm also known as
    Michael> FOO-BAR, BAZ-BAR, and HOMER-DONUTS." as well as "I was
    Michael> also known as PREHISTORIC-CAVEMAN at sometime in the
    Michael> past". The one thing this fixes is that equivalence may

Presumably this implies that the local-parts can't be reused ?

    Michael> be a pre-registry concept. I.e. while Bill may consider
    Michael> WM110-ARIN and WM35-RADB the same, the registries
    Michael> involved may have some policy where they're not allowed
    Michael> to either know or publish that information.

    Michael> -MM

    Michael> [1]
    Michael> http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00128.html

[2] http://www.w3.org/TR/REC-xml-names/
[3] http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00059.html
[4] http://www.xmlhack.com/read.php?item=974
[5] http://www.rpbourret.com/xml/NamespacesFAQ.htm

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Thu, 15 Mar 2001 11:40:39 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Correction
Sender: [email-masked]

I have mistakenly attributed some comments in:

http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00039.html

to Dave (see below), when they were really made by Bill.

Sorry Bill, Dave.

George.

[snip]

> The messages you quote spell out some of the issues, and Dave
> suggests the employee number analogy, which looks like an
> opaque identifier.

[snip]

From: "Hollenbeck, Scott" <[email-masked]>
To: "Mealling, Michael" <[email-masked]>, George Belotsky <[email-masked]>
Cc: [email-masked]
Subject: RE: Unique handle generation
Date: Thu, 15 Mar 2001 11:30:52 -0500
Sender: [email-masked]

>-----Original Message-----
>From: Michael Mealling [mailto:[email-masked]]
>Sent: Thursday, March 15, 2001 10:53 AM
>To: George Belotsky
>Cc: Hollenbeck, Scott; [email-masked]
>Subject: Re: Unique handle generation
>
>
>On Thu, Mar 15, 2001 at 10:30:14AM -0500, George Belotsky wrote:
>> The reason for having global identifiers for all objects is so
>> that they can move between various entities without changing.
>
>But we really haven't specified if that's a goal yet have we?
>The sticking point for me is: has this actually happened and 
>are the times it happens more easily handled by some additional
>metadata pointing to equivalent identifiers in other 
>registry/registrar.
>Let's take Bill's example of WM110, WM110-ARIN, WM110-RIPE, etc [1]
>Would it be easier to just use the current de facto usage and add
>something to the schema of objects that shows equivalence in other
>object repositories? Even in Bill's example you have WM35-RADB so
>the only way to know that's the same Bill Manning is for something
>in the database to tell you so.

Agreed, I don't think that object movement between repositories is a common
enough issue to be categorized as the "reason for having global
identifiers".  IMO, the most significant use of these identifiers will be in
whois.  They will likely be required as part of a response (such as to
identify domain contacts), and then be queried or automatically resolved to
appropriate repositories (such as to obtain a registrant's address/phone
number/etc).

<Scott/>

Date: Thu, 15 Mar 2001 10:53:15 -0500
From: Michael Mealling <[email-masked]>
To: George Belotsky <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Mar 15, 2001 at 10:30:14AM -0500, George Belotsky wrote:
> The reason for having global identifiers for all objects is so
> that they can move between various entities without changing.

But we really haven't specified if that's a goal yet have we?
The sticking point for me is: has this actually happened and 
are the times it happens more easily handled by some additional
metadata pointing to equivalent identifiers in other registry/registrar.
Let's take Bill's example of WM110, WM110-ARIN, WM110-RIPE, etc [1]
Would it be easier to just use the current de facto usage and add
something to the schema of objects that shows equivalence in other
object repositories? Even in Bill's example you have WM35-RADB so
the only way to know that's the same Bill Manning is for something
in the database to tell you so.

My recommendation is this: use the <registry-handle>-<local-handle>
syntax where registry-handle is registered with the IANA and local-handle
is a unique identifier assigned however the registry sees fit. Then, to handle
equivalence between registries, the base schema of all objects (if that
has a concept here, I haven't looked yet) allow for a way for one
object to say two things: "Hey, I'm also known as FOO-BAR, BAZ-BAR, 
and HOMER-DONUTS." as well as "I was also known as PREHISTORIC-CAVEMAN
at sometime in the past". The one thing this fixes is that equivalence
may be a pre-registry concept. I.e. while Bill may consider WM110-ARIN
and WM35-RADB the same, the registries involved may have some policy 
where they're not allowed to either know or publish that information.

-MM

[1] http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00128.html

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Thu, 15 Mar 2001 18:00:30 +0200
From: Lucio De Re <[email-masked]>
To: [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Mar 15, 2001 at 10:30:14AM -0500, George Belotsky wrote:
> 
> We may be 'deja vu' on the questions, but not on the answers.
> 
I'm not sure about the merits, but has anyone actually considered
distinguished names, as in X.500 (perish the thought) but more
plausibly in LDAP?

I should think that a flattenable hierarchy as well as the locally,
hopefully globally unique "relative distinguished names" when the
localising qualifier is dropped, would address most of the needs
raised in this forum.  Note that attempts to map the DNS onto LDAP
have been made with (to my limited knowledge) some degree of success.
And anything has been mapped to X.500, but let's not go there :-)

At the very minimum, this is understood technology, and humanly
readable DNs are also implicitly globally unique.  I find LDAP a
little English-language parochial, but so is DNS, addressing
internationalisation of both would in any event happily occur
simultaneously.  Also, I have lost track of LDAP and I'm still
stuck in the version 1 warp, I have no idea what the version 2 cat
actually brought in.

++L

Date: Thu, 15 Mar 2001 10:30:14 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

We may be 'deja vu' on the questions, but not on the answers.

The messages you quote spell out some of the issues, and Dave
suggests the employee number analogy, which looks like an
opaque identifier.

The reason for having global identifiers for all objects is so
that they can move between various entities without changing.

For a domain name, you may get away with just using the fqdn 
itself, but then the handle would never change -- even if the
name is deleted and then registered by someone else.  This may be
undesireable (although you would want the handle to remain the same in
the case of an actual transfer).

For other objects (e.g. contacts), no unique identifier exists a
priori.  Thus, you are forced to choose either between a UUID-style
composite of atomics, or maintaining a shared database of handles
(after all, we have this for domain names, which is why we can trust
the uniqueness of an fqdn in the first place).

With Variant (3), I can still use my contact identifier with as many
registries/registrars as I choose.  The opaque identifier can also be
used to grant limited access to certain information.  

For example, a whois search (using an fqdn) can return the opaque
identifier of a contact as a parameter, along with the electronic
address of the administrative entitity holding the name.  Using this
returned identifier, I can query the administrative entity for more
information.  Depending on my permissions (which are a matter of
policy), I may be able to get the email address (but not the name or
telephone number) of the contact.

As can be seen from the above, Variant (3) functionality can still
have many uses.  We already have Variant (2) functionality for some
objects (such as domain names) through other means (such as whois).

Is it really worth it to have lookup (let alone search) functionality
for every single object type -- given the fact that a database of
handles would have to be maintained for this purpose?

George.

On Thu, Mar 15, 2001 at 07:59:26AM -0500, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: George Belotsky [mailto:[email-masked]]
> >Sent: Wednesday, March 14, 2001 4:44 PM
> >To: Hollenbeck, Scott
> >Cc: 'Patrik Fältström'; [email-masked]
> >Subject: Re: Unique handle generation
> >
> 
> [snip]
> 
> >This once again gets back to what the handle is for.  To illustrate, I
> >have listed three basic variants below.
> >
> >         (1) Handles are used to search for objects.
> >         (2) Handles are used to quickly look up objects, regardless of
> >             their location.
> >         (3) Handles are used only to request operations on 
> >objects whose
> >             location is already known.
> 
> [snip]
> 
> This feels like "deja vu all over again" (my apologies to Yogi Berra):
> 
> http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00035.html
> 
> http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00038.html
> 
> http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00039.html
> 
> I think we've already determined (or at least I've suggested) that variant
> (2) is required functionality for systems like whois.  Within a registry, I
> don't believe variant (3) provides any functionality that we don't have with
> more basic identifiers -- I can refer to a domain name or host name by FQN
> and a contact name by whatever local part makes sense because these values
> are already unique within the repository.  There are deployed systems (like
> whois again) that provide variant (1) functionality, though I don't think
> this functionality is necessary in a provisioning protocol.
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Thu, 15 Mar 2001 07:59:26 -0500
Sender: [email-masked]

>-----Original Message-----
>From: George Belotsky [mailto:[email-masked]]
>Sent: Wednesday, March 14, 2001 4:44 PM
>To: Hollenbeck, Scott
>Cc: 'Patrik Fältström'; [email-masked]
>Subject: Re: Unique handle generation
>

[snip]

>This once again gets back to what the handle is for.  To illustrate, I
>have listed three basic variants below.
>
>         (1) Handles are used to search for objects.
>         (2) Handles are used to quickly look up objects, regardless of
>             their location.
>         (3) Handles are used only to request operations on 
>objects whose
>             location is already known.

[snip]

This feels like "deja vu all over again" (my apologies to Yogi Berra):

http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00035.html

http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00038.html

http://www.cafax.se/ietf-provreg/maillist/2001-03/msg00039.html

I think we've already determined (or at least I've suggested) that variant
(2) is required functionality for systems like whois.  Within a registry, I
don't believe variant (3) provides any functionality that we don't have with
more basic identifiers -- I can refer to a domain name or host name by FQN
and a contact name by whatever local part makes sense because these values
are already unique within the repository.  There are deployed systems (like
whois again) that provide variant (1) functionality, though I don't think
this functionality is necessary in a provisioning protocol.

<Scott/>

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (George Belotsky)
Date: Wed, 14 Mar 2001 14:37:37 -0800 (PST)
Cc: [email-masked] (Hollenbeck Scott), [email-masked] (=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=), [email-masked]
Sender: [email-masked]

% This once again gets back to what the handle is for.  To illustrate, I
% have listed three basic variants below.
% 
%          (1) Handles are used to search for objects.
%          (2) Handles are used to quickly look up objects, regardless of
%              their location.
%          (3) Handles are used only to request operations on objects whose
%              location is already known.
% 
% 
% Variant (1) is the most difficult to implement -- especially if wildcards
% and boolean searches are used.  These kinds of operations are
% typically done on documents -- a handle would have to be huge to
% contain enough meaningful information.  A large, centralized database
% with a complex search engine is required for this kind of operation.

But I already know my handle, so when searching for it, I
want to get composites that have used my atomic handle.

but you are correct, hashing is useful here, esp if I want to:

	grep *WM110* <all known/visable composite handles>

-- 
--bill

Date: Wed, 14 Mar 2001 16:44:00 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

On Wed, Mar 14, 2001 at 01:58:52PM -0500, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: George Belotsky [mailto:[email-masked]]
> >Sent: Wednesday, March 14, 2001 1:27 PM
> >To: Hollenbeck, Scott
> >Cc: 'Patrik Fältström'; [email-masked]
> >Subject: Re: Unique handle generation
> >
> >
> >An opaque identifier has plenty of uses (and provides some security,
> >too).
> >
> >A vehicle license plate, for example, provides identification even if
> >you know nothing about its format.  With sufficient authorization, you
> >can get answers to queries such as 'who does this vehicle belong to',
> >etc.
> >
> >Opaque identifiers have many uses, and are in fact frequently used.
> >We just have to determine if such identifiers meet our requirements.
> >If they do, then there are great advantages in using them -- most
> >prominently the elimination of the need to maintain a registry of
> >handles (or parts thereof).
> >
> >George.
> 
> OK, so what can you tell me about the object referred to by this sample UUID
> created using the uuidgen utility (23c67e00-71b6-11c9-9dfc-08002b0ecef1) vs.
> this identifier suggested by Patrik (RIPE-PAF2001)?  In the absence of
> context the UUID tells me _nothing_, including who to ask for more info.
> With Patrik's format I at least know who to ask for more info.
> 
> Considering your license plate example, in the US a vehicle license plate
> includes not only an opaque identifier, but the name of the state,
> territory, or other issuing entity that identifies the administrator of a
> license plate repository.  This administrator is the one that 1) assigned an
> identifier that's unique within the repository, and 2) holds the keys to
> obtaining additional information.  Strangely enough, this example appears to
> mirror Patrik's suggested format...
> 
> <Scott/>

This once again gets back to what the handle is for.  To illustrate, I
have listed three basic variants below.

         (1) Handles are used to search for objects.
         (2) Handles are used to quickly look up objects, regardless of
             their location.
         (3) Handles are used only to request operations on objects whose
             location is already known.

Variant (1) is the most difficult to implement -- especially if wildcards
and boolean searches are used.  These kinds of operations are
typically done on documents -- a handle would have to be huge to
contain enough meaningful information.  A large, centralized database
with a complex search engine is required for this kind of operation.

Variant (2) is easier: DNS does it.  Patrick's format would support
this level of functionality.  A distributed shared database is
sufficient, and complex search capabilities are not required.

Variant (3) is where digest-style handles would really be useful.
Searching for objects would be done by other means (e.g. via whois).
Once an object was found, operations (such as deletions, transfers,
etc.) could be requested on it.  Note that the original 'owner' of an
object would have the handle already, and would know the location.
Thus, operations such as transfers and deletions need no more than
Variant (3).

In general, Variant (3) is the simplest -- it needs no shared database
at all to ensure the uniqueness of handles.  It seems that the
decision to be made is whether the added functionality of Variant (2)
is warranted, given its significantly greater complexity and
possibility for error.  If it is, then the digest handle would not
work by itself, and a scheme like Patrick's (or DNS names) is
required.  On the other hand, if Variant (3) functionality is all that
is needed, then digest handles have several advantages, as I discussed
in previous posts.

George.

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>
Cc: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>, [email-masked]
Subject: RE: Unique handle generation
Date: Wed, 14 Mar 2001 13:58:52 -0500
Sender: [email-masked]

>-----Original Message-----
>From: George Belotsky [mailto:[email-masked]]
>Sent: Wednesday, March 14, 2001 1:27 PM
>To: Hollenbeck, Scott
>Cc: 'Patrik Fältström'; [email-masked]
>Subject: Re: Unique handle generation
>
>
>An opaque identifier has plenty of uses (and provides some security,
>too).
>
>A vehicle license plate, for example, provides identification even if
>you know nothing about its format.  With sufficient authorization, you
>can get answers to queries such as 'who does this vehicle belong to',
>etc.
>
>Opaque identifiers have many uses, and are in fact frequently used.
>We just have to determine if such identifiers meet our requirements.
>If they do, then there are great advantages in using them -- most
>prominently the elimination of the need to maintain a registry of
>handles (or parts thereof).
>
>George.

OK, so what can you tell me about the object referred to by this sample UUID
created using the uuidgen utility (23c67e00-71b6-11c9-9dfc-08002b0ecef1) vs.
this identifier suggested by Patrik (RIPE-PAF2001)?  In the absence of
context the UUID tells me _nothing_, including who to ask for more info.
With Patrik's format I at least know who to ask for more info.

Considering your license plate example, in the US a vehicle license plate
includes not only an opaque identifier, but the name of the state,
territory, or other issuing entity that identifies the administrator of a
license plate repository.  This administrator is the one that 1) assigned an
identifier that's unique within the repository, and 2) holds the keys to
obtaining additional information.  Strangely enough, this example appears to
mirror Patrik's suggested format...

<Scott/>

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (George Belotsky)
Date: Wed, 14 Mar 2001 11:03:54 -0800 (PST)
Cc: [email-masked], [email-masked] (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

 There is an unwritten agreement on handles.

 UserInitals+monotonically increasing number[+Registry]

 e.g.
 
 WM110
 WM110-ARIN
 WM110-RIPE
 WM35-RADB

all exist.

% 
% I thought there was no one set standard for handles yet ...
% 
% 
% On Wed, Mar 14, 2001 at 01:24:19PM -0500, Michael Mealling wrote:
% > On Wed, Mar 14, 2001 at 01:15:05PM -0500, George Belotsky wrote:
% > > I am puzzled why some people find this algorithm complicated.
% > > Is running a registry for handles really a simpler solution
% > > than a UUID?
% > 
% > If it means retrofitting your entire current system because all of your
% > existing handles have to change, yes.....
% > 
% > -MM
% > 
% > -- 
% > --------------------------------------------------------------------------------
% > Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
% > Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
% > Network Solutions	|          www.lp.org          |  [email-masked]
% 
% -- 
% -----------------------------
% George Belotsky
% Senior Software Architect
% Register.com, inc.
% [email-masked]
% 212-798-9127 (phone)
% 212-798-9876 (fax)
% 

-- 
--bill

Date: Wed, 14 Mar 2001 13:34:16 -0500
From: Michael Mealling <[email-masked]>
To: George Belotsky <[email-masked]>
Cc: [email-masked], =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Mar 14, 2001 at 01:39:14PM -0500, George Belotsky wrote:
> I thought there was no one set standard for handles yet ...

Nope. But existing systems already have some defined way of creating 
them internally. Its just a minor point, nevermind....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Wed, 14 Mar 2001 13:39:14 -0500
From: George Belotsky <[email-masked]>
To: [email-masked]
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

I thought there was no one set standard for handles yet ...

On Wed, Mar 14, 2001 at 01:24:19PM -0500, Michael Mealling wrote:
> On Wed, Mar 14, 2001 at 01:15:05PM -0500, George Belotsky wrote:
> > I am puzzled why some people find this algorithm complicated.
> > Is running a registry for handles really a simpler solution
> > than a UUID?
> 
> If it means retrofitting your entire current system because all of your
> existing handles have to change, yes.....
> 
> -MM
> 
> -- 
> --------------------------------------------------------------------------------
> Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
> Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
> Network Solutions	|          www.lp.org          |  [email-masked]

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 14 Mar 2001 13:24:19 -0500
From: Michael Mealling <[email-masked]>
To: George Belotsky <[email-masked]>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Mar 14, 2001 at 01:15:05PM -0500, George Belotsky wrote:
> I am puzzled why some people find this algorithm complicated.
> Is running a registry for handles really a simpler solution
> than a UUID?

If it means retrofitting your entire current system because all of your
existing handles have to change, yes.....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Wed, 14 Mar 2001 13:27:01 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

An opaque identifier has plenty of uses (and provides some security,
too).

A vehicle license plate, for example, provides identification even if
you know nothing about its format.  With sufficient authorization, you
can get answers to queries such as 'who does this vehicle belong to',
etc.

Opaque identifiers have many uses, and are in fact frequently used.
We just have to determine if such identifiers meet our requirements.
If they do, then there are great advantages in using them -- most
prominently the elimination of the need to maintain a registry of
handles (or parts thereof).

George.

On Wed, Mar 14, 2001 at 08:20:42AM -0500, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: Patrik Fältström [mailto:[email-masked]]
> >Sent: Wednesday, March 14, 2001 1:31 AM
> >To: George Belotsky; Hollenbeck, Scott
> >Cc: [email-masked]
> >Subject: Re: Unique handle generation
> >
> >
> >At 21.14 -0500 01-03-13, George Belotsky wrote:
> >>Scott:
> >>
> >>Here is an overview of the algorithm I had in mind, so that
> >>it is easier to understand the changes that I am suggesting.
> >>
> >>
> >>    (1) A human-readable object handle is created.  This
> >>        is done UUID-style, by concatenating several
> >>        atomic units.  The creating repository may be
> >>        one of these, but it does not have to be.
> >>        The end result is something like this.
> >>
> >>        Scott+Hollenbeck+verisign.com+scottshomepage.com+Mar.13.2001
> >>
> >>   
> >>    (2) A digest function is applied to the human-readable handle.
> >>        The system stores the resulting  digest, and not the readable
> >>        form itself.
> >>
> >>    (3) The readable form is returned to the user.  Now, there are
> >>        two equivalent representations: the digest (which is used
> >>        by default), and the readable form (which can be used
> >>        by the 'owner', or anyone else that the 'owner' gives it to).
> >>        This is the essence of [5] and [6] as I suggested; not
> >>        contradictory, but complimentary.
> >
> >I think you make life much too complicated.
> 
> I agree, too.  One of things that I don't like about digests used this way
> is that a registry has to maintain _three_ different identifiers for an
> object like a domain name:
> 
> 1. The name itself,
> 2. A combination of human-readable elements used as digest algorithm input,
> and
> 3. A digest (128 bits (16 octets) for MD5, or 160 bits (20 octets) for
> SHA-1, or more for newer algorithms -- fewer bits or weaker algorithms don't
> offer much collision protection)
> 
> I know that George suggested that the human-readable form doesn't need to be
> stored by a registry, but putting an opaque digest into a whois response (as
> an example) seems useless to me.  Take the digest out of the surrounding
> context and you have a meaningless string of characters.
> 
> If I'm reading this right, the real sticking point that we're continuing to
> debate is local part uniqueness, primarily if a repository ever has to join
> with all of the objects and identifiers from another repository.  I might be
> wrong, but I think this is a pretty rare corner case that we don't really
> need to optimize for.  I think a simple approach is best, and if collisions
> ever do occur they are best handled on a case-by-case basis -- which means
> that an object identifier could change if a new local part is needed to
> avoid a collision when integrating repositories.  However, if the identifier
> is going to change anyway as a result of the repository change, maybe this
> isn't a major issue.
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 14 Mar 2001 13:15:05 -0500
From: George Belotsky <[email-masked]>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

I am puzzled why some people find this algorithm complicated.
Is running a registry for handles really a simpler solution
than a UUID?

George.

On Wed, Mar 14, 2001 at 07:30:34AM +0100, Patrik Fältström wrote:
> At 21.14 -0500 01-03-13, George Belotsky wrote:
> >Scott:
> >
> >Here is an overview of the algorithm I had in mind, so that
> >it is easier to understand the changes that I am suggesting.
> >
> >
> >    (1) A human-readable object handle is created.  This
> >        is done UUID-style, by concatenating several
> >        atomic units.  The creating repository may be
> >        one of these, but it does not have to be.
> >        The end result is something like this.
> >
> >        Scott+Hollenbeck+verisign.com+scottshomepage.com+Mar.13.2001
> >
> >   
> >    (2) A digest function is applied to the human-readable handle.
> >        The system stores the resulting  digest, and not the readable
> >        form itself.
> >
> >    (3) The readable form is returned to the user.  Now, there are
> >        two equivalent representations: the digest (which is used
> >        by default), and the readable form (which can be used
> >        by the 'owner', or anyone else that the 'owner' gives it to).
> >        This is the essence of [5] and [6] as I suggested; not
> >        contradictory, but complimentary.
> 
> I think you make life much too complicated.
> 
> It is much easier if you use an algorithm which
> 
> (a) Divides the world in a number of registries. One can be a RIR, 
> another a TLD.
> (b) All registries get a unique identifier, and that is registered somewhere.
> (c) Each registry is responsible for assigning a unique local 
> identifier for each object.
> (d) The globally unique identifier is a concatenation of the two.
> (e) One might be able to create a URN scheme for this space of identifiers
> 
> This is what happens today (part from at VGRS and ARIN), and it 
> works. You don't have to come up with some rules for how a registry 
> works, and creates the identifier. That is up to them.
> 
> A registry might go away, but if that happens, I claim that all 
> records are moved together to a different organization, but the 
> registry stay atomic.
> 
> A registry might be split (something which will happen soon I think) 
> and this is the tricky part. One record might stay, and another might 
> be moved. This can be achieved by deleting records which are moved, 
> and creation of new ones in the new registry.
> 
> Note that splitting a registry is a very rare operation, and I am 
> prepared getting some trouble when that one-time-operation happens.
> 
>      paf
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>, George Belotsky <[email-masked]>
Cc: [email-masked]
Subject: RE: Unique handle generation
Date: Wed, 14 Mar 2001 08:20:42 -0500
Sender: [email-masked]

>-----Original Message-----
>From: Patrik Fältström [mailto:[email-masked]]
>Sent: Wednesday, March 14, 2001 1:31 AM
>To: George Belotsky; Hollenbeck, Scott
>Cc: [email-masked]
>Subject: Re: Unique handle generation
>
>
>At 21.14 -0500 01-03-13, George Belotsky wrote:
>>Scott:
>>
>>Here is an overview of the algorithm I had in mind, so that
>>it is easier to understand the changes that I am suggesting.
>>
>>
>>    (1) A human-readable object handle is created.  This
>>        is done UUID-style, by concatenating several
>>        atomic units.  The creating repository may be
>>        one of these, but it does not have to be.
>>        The end result is something like this.
>>
>>        Scott+Hollenbeck+verisign.com+scottshomepage.com+Mar.13.2001
>>
>>   
>>    (2) A digest function is applied to the human-readable handle.
>>        The system stores the resulting  digest, and not the readable
>>        form itself.
>>
>>    (3) The readable form is returned to the user.  Now, there are
>>        two equivalent representations: the digest (which is used
>>        by default), and the readable form (which can be used
>>        by the 'owner', or anyone else that the 'owner' gives it to).
>>        This is the essence of [5] and [6] as I suggested; not
>>        contradictory, but complimentary.
>
>I think you make life much too complicated.

I agree, too.  One of things that I don't like about digests used this way
is that a registry has to maintain _three_ different identifiers for an
object like a domain name:

1. The name itself,
2. A combination of human-readable elements used as digest algorithm input,
and
3. A digest (128 bits (16 octets) for MD5, or 160 bits (20 octets) for
SHA-1, or more for newer algorithms -- fewer bits or weaker algorithms don't
offer much collision protection)

I know that George suggested that the human-readable form doesn't need to be
stored by a registry, but putting an opaque digest into a whois response (as
an example) seems useless to me.  Take the digest out of the surrounding
context and you have a meaningless string of characters.

If I'm reading this right, the real sticking point that we're continuing to
debate is local part uniqueness, primarily if a repository ever has to join
with all of the objects and identifiers from another repository.  I might be
wrong, but I think this is a pretty rare corner case that we don't really
need to optimize for.  I think a simple approach is best, and if collisions
ever do occur they are best handled on a case-by-case basis -- which means
that an object identifier could change if a new local part is needed to
avoid a collision when integrating repositories.  However, if the identifier
is going to change anyway as a result of the repository change, maybe this
isn't a major issue.

<Scott/>

Date: Wed, 14 Mar 2001 09:03:51 +0200
From: Lucio De Re <[email-masked]>
To: [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Mar 14, 2001 at 07:30:34AM +0100, Patrik Fältström wrote:
> 
> I think you make life much too complicated.
> 
This I agree with.

> It is much easier if you use an algorithm which
> 
> (a) Divides the world in a number of registries. One can be a RIR, 
> another a TLD.
> (b) All registries get a unique identifier, and that is registered somewhere.

So far so good.

> (c) Each registry is responsible for assigning a unique local 
> identifier for each object.

Unless I'm missing the point, the middle ground between George and
Bill lies with making the "local" identifier globally unique.
Irrespective of the algorithm used to generate the ID, a digest
operation would provide a much greater degree of uniqueness.  Only
the participating parties need to know what was used to construct
the digest, the digest itself becomes the handle, guaranteed unique
by the {pre,suf}fix of the registry's unique ID.

The registrant retains the components, so she can advise the next
registry how the digest was constructed (if required, of course).

> (d) The globally unique identifier is a concatenation of the two.

Yes.

> (e) One might be able to create a URN scheme for this space of identifiers
> 
> This is what happens today (part from at VGRS and ARIN), and it 
> works. You don't have to come up with some rules for how a registry 
> works, and creates the identifier. That is up to them.
> 
But it could lead to collisions and/or incompatibilities in migrating
an object from one registry to another.  Fixing the digest algorithm
would avoid incompatibilities and, through sensible choice, minimise
collisions.  The few collisions that may still occur can be handled
manually.

> A registry might go away, but if that happens, I claim that all 
> records are moved together to a different organization, but the 
> registry stay atomic.
> 
I think this is an unnecessary restriction.  As the registrant of
a record, I may want to make a decision at the point of collapse
as to where I want my record to be migrated to.

> A registry might be split (something which will happen soon I think) 
> and this is the tricky part. One record might stay, and another might 
> be moved. This can be achieved by deleting records which are moved, 
> and creation of new ones in the new registry.
> 
Again, the registrant may want a choice.

> Note that splitting a registry is a very rare operation, and I am 
> prepared getting some trouble when that one-time-operation happens.
> 
At least in splitting a registry no collision is likely to happen.
COnsolidating registries would be a bigger problem, and the registrant
then has less say in the matter :-(

++L

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=)
Date: Tue, 13 Mar 2001 22:53:35 -0800 (PST)
Cc: [email-masked] (George Belotsky), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

% I think you make life much too complicated.
% It is much easier if you use an algorithm which
% 
% (a) Divides the world in a number of registries. One can be a RIR, 
% another a TLD.

	Is KTH a registry?
	Cisco?
	Patrick?
	.NATO

how about:
a) divide the world into a number of object classes.

% (b) All registries get a unique identifier, and that is registered somewhere.

b) each object within a class gets a unique identifier, and that is registered
   somewhere. One object class will be a registry.
	
% (c) Each registry is responsible for assigning a unique local 
% identifier for each object.
% (d) The globally unique identifier is a concatenation of the two.
% (e) One might be able to create a URN scheme for this space of identifiers
% 
% This is what happens today (part from at VGRS and ARIN), and it 
% works. You don't have to come up with some rules for how a registry 
% works, and creates the identifier. That is up to them.
% 
% A registry might go away, but if that happens, I claim that all 
% records are moved together to a different organization, but the 
% registry stay atomic.
% 
% A registry might be split (something which will happen soon I think) 
% and this is the tricky part. One record might stay, and another might 
% be moved. This can be achieved by deleting records which are moved, 
% and creation of new ones in the new registry.
% 
% Note that splitting a registry is a very rare operation, and I am 
% prepared getting some trouble when that one-time-operation happens.
% 
%      paf
% 

-- 
--bill

Date: Wed, 14 Mar 2001 07:30:34 +0100
To: George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

At 21.14 -0500 01-03-13, George Belotsky wrote:
>Scott:
>
>Here is an overview of the algorithm I had in mind, so that
>it is easier to understand the changes that I am suggesting.
>
>
>    (1) A human-readable object handle is created.  This
>        is done UUID-style, by concatenating several
>        atomic units.  The creating repository may be
>        one of these, but it does not have to be.
>        The end result is something like this.
>
>        Scott+Hollenbeck+verisign.com+scottshomepage.com+Mar.13.2001
>
>   
>    (2) A digest function is applied to the human-readable handle.
>        The system stores the resulting  digest, and not the readable
>        form itself.
>
>    (3) The readable form is returned to the user.  Now, there are
>        two equivalent representations: the digest (which is used
>        by default), and the readable form (which can be used
>        by the 'owner', or anyone else that the 'owner' gives it to).
>        This is the essence of [5] and [6] as I suggested; not
>        contradictory, but complimentary.

I think you make life much too complicated.

It is much easier if you use an algorithm which

(a) Divides the world in a number of registries. One can be a RIR, 
another a TLD.
(b) All registries get a unique identifier, and that is registered somewhere.
(c) Each registry is responsible for assigning a unique local 
identifier for each object.
(d) The globally unique identifier is a concatenation of the two.
(e) One might be able to create a URN scheme for this space of identifiers

This is what happens today (part from at VGRS and ARIN), and it 
works. You don't have to come up with some rules for how a registry 
works, and creates the identifier. That is up to them.

A registry might go away, but if that happens, I claim that all 
records are moved together to a different organization, but the 
registry stay atomic.

A registry might be split (something which will happen soon I think) 
and this is the tricky part. One record might stay, and another might 
be moved. This can be achieved by deleting records which are moved, 
and creation of new ones in the new registry.

Note that splitting a registry is a very rare operation, and I am 
prepared getting some trouble when that one-time-operation happens.

     paf

Date: Wed, 14 Mar 2001 07:23:38 +0100
To: "Hollenbeck, Scott" <[email-masked]>, "'George Belotsky'" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

At 20.50 -0500 01-03-13, Hollenbeck, Scott wrote:
>  > > [4] An object identifier MUST contain information that unambiguously
>  > > identifies both the object and the object's administrative
>>  repository at
>>  > time of creation.
>>
>>    We should probably reduce the scope of this one.  How about
>>  the version
>>    below?
>>
>>    An object identifier MUST contain information that unambiguously
>>    identifies the object.
>
>The text that's there was originally suggested by Patrik.  Patrik, are you
>OK with George's suggested change?

Sure.

     paf

Date: Tue, 13 Mar 2001 21:14:09 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Scott:

Here is an overview of the algorithm I had in mind, so that
it is easier to understand the changes that I am suggesting.

   (1) A human-readable object handle is created.  This
       is done UUID-style, by concatenating several
       atomic units.  The creating repository may be
       one of these, but it does not have to be.
       The end result is something like this.

       Scott+Hollenbeck+verisign.com+scottshomepage.com+Mar.13.2001

   (2) A digest function is applied to the human-readable handle.
       The system stores the resulting  digest, and not the readable 
       form itself.

   (3) The readable form is returned to the user.  Now, there are
       two equivalent representations: the digest (which is used
       by default), and the readable form (which can be used 
       by the 'owner', or anyone else that the 'owner' gives it to).
       This is the essence of [5] and [6] as I suggested; not 
       contradictory, but complimentary. 

George.

On Tue, Mar 13, 2001 at 08:50:29PM -0500, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: George Belotsky [mailto:[email-masked]]
> > Sent: Tuesday, March 13, 2001 3:04 PM
> > To: Hollenbeck, Scott
> > Cc: [email-masked]
> > Subject: Re: Unique handle generation
> > 
> > 
> > On Tue, Mar 13, 2001 at 02:26:18PM -0500, Hollenbeck, Scott wrote:
> 
> [snip]
> 
> > > [4] An object identifier MUST contain information that unambiguously
> > > identifies both the object and the object's administrative 
> > repository at
> > > time of creation.
> > 
> >   We should probably reduce the scope of this one.  How about 
> > the version
> >   below?
> > 
> >   An object identifier MUST contain information that unambiguously
> >   identifies the object.
> 
> The text that's there was originally suggested by Patrik.  Patrik, are you
> OK with George's suggested change?
> 
> > > 
> > > [5] Object identifier format SHOULD be easily parsed and 
> > understood by
> > > humans.
> > 
> >   Some scope reduction here, too.
> > 
> >   [5] Object identifier SHOULD have an opaque, fixed length format 
> >       (e.g. 128 bit digest).
> 
> I don't like this one.  For one I think it conflicts with what you've
> suggested for [6] (how is an opaque digest easily parsed and understood by
> humans?), and secondly it introduces a formatting suggestion when you just
> suggested that we remove a different formatting suggestion from [4].  If you
> want to reduce the scope of [4] by removing mention of one format, why
> should we introduce a different format?
> 
> >   [6] An identifier that is easily parsed and understood by 
> > humans, and 
> >       is equivalent to the identifier in [5], MUST be made 
> > available to
> >       the object's owner at the time of object creation.
> 
> I don't like the word "owner" here, though I think I understand what you're
> getting at.  How about this instead:
> 
> [x] The format of an object identifier SHOULD be easily parsed and
> understood by humans.
> 
> [y] An object's identifier MUST be generated and returned as part of the
> protocol response when an object is created.
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>, =?iso-8859-1?Q?=27Patrik_F?= =?iso-8859-1?Q?=E4ltstr=F6m=27?= <[email-masked]>
Cc: [email-masked]
Subject: RE: Unique handle generation
Date: Tue, 13 Mar 2001 20:50:29 -0500
Sender: [email-masked]

> -----Original Message-----
> From: George Belotsky [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2001 3:04 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: Unique handle generation
> 
> 
> On Tue, Mar 13, 2001 at 02:26:18PM -0500, Hollenbeck, Scott wrote:

[snip]

> > [4] An object identifier MUST contain information that unambiguously
> > identifies both the object and the object's administrative 
> repository at
> > time of creation.
> 
>   We should probably reduce the scope of this one.  How about 
> the version
>   below?
> 
>   An object identifier MUST contain information that unambiguously
>   identifies the object.

The text that's there was originally suggested by Patrik.  Patrik, are you
OK with George's suggested change?

> > 
> > [5] Object identifier format SHOULD be easily parsed and 
> understood by
> > humans.
> 
>   Some scope reduction here, too.
> 
>   [5] Object identifier SHOULD have an opaque, fixed length format 
>       (e.g. 128 bit digest).

I don't like this one.  For one I think it conflicts with what you've
suggested for [6] (how is an opaque digest easily parsed and understood by
humans?), and secondly it introduces a formatting suggestion when you just
suggested that we remove a different formatting suggestion from [4].  If you
want to reduce the scope of [4] by removing mention of one format, why
should we introduce a different format?

>   [6] An identifier that is easily parsed and understood by 
> humans, and 
>       is equivalent to the identifier in [5], MUST be made 
> available to
>       the object's owner at the time of object creation.

I don't like the word "owner" here, though I think I understand what you're
getting at.  How about this instead:

[x] The format of an object identifier SHOULD be easily parsed and
understood by humans.

[y] An object's identifier MUST be generated and returned as part of the
protocol response when an object is created.

<Scott/>

Date: Tue, 13 Mar 2001 22:25:32 +0100
To: Bill Manning <[email-masked]>, [email-masked] (Hollenbeck, Scott)
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

At 12.49 -0800 01-03-13, Bill Manning wrote:
>%
>% Back to requirements...
>%
>% Are there any objections to these, with number 4 amended as suggested by
>% Paul George:
>%
>% [1] Every object MUST have an associated object identifier.
>%
>% [2] Object identifiers MUST be globally unique.
>%
>% [3] An object's identifier MUST NOT change during the lifetime of the
>% object, even if administrative control of the object changes over time.
>%
>% [4] An object identifier MUST contain information that unambiguously
>% identifies both the object and the object's administrative repository at
>% time of creation.
>%
>% [5] Object identifier format SHOULD be easily parsed and understood by
>% humans.
>%
>% <Scott/>
>
>I am concerned w/ two things:
>
>	) what constitutes "lifetime" in #3

I would define lifetime as the actual lifetime of the object. This 
doesn't mean that at very extreme situations a record can be replaced 
by some other record, and that way a new record is created.

For example, I see "Arin go away (not only taken over by someone 
else)" is an extreme situation. I see "record for a domain handled by 
the VGRS registry moving from one registrar to another" being a 
likely situation. The identifyer only have to survive the latter (or 
Arin taken over by someone else).

>	) I am opposed to the construction of #4.
>	  George's construct of an OI is as a composite, the object and
>	  the administrative repository.  The other items refer to
>	  atomic objects that have meaning independent of any associated
>	  repository.

My take is that the identifier should be created in such a way that 
given this identifier, the record should be able to be found -- 
without having to have one database with all record identifiers in 
the world in one place.

   paf

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Hollenbeck, Scott)
Date: Tue, 13 Mar 2001 12:49:45 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

% 
% Back to requirements...
% 
% Are there any objections to these, with number 4 amended as suggested by
% Paul George:
% 
% [1] Every object MUST have an associated object identifier.
% 
% [2] Object identifiers MUST be globally unique.
% 
% [3] An object's identifier MUST NOT change during the lifetime of the
% object, even if administrative control of the object changes over time.
% 
% [4] An object identifier MUST contain information that unambiguously
% identifies both the object and the object's administrative repository at
% time of creation.
% 
% [5] Object identifier format SHOULD be easily parsed and understood by
% humans.
% 
% <Scott/>

I am concerned w/ two things:

	) what constitutes "lifetime" in #3
	) I am opposed to the construction of #4. 
	  George's construct of an OI is as a composite, the object and
	  the administrative repository.  The other items refer to 
	  atomic objects that have meaning independent of any associated
	  repository.

-- 
--bill

Date: Tue, 13 Mar 2001 15:03:57 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

On Tue, Mar 13, 2001 at 02:26:18PM -0500, Hollenbeck, Scott wrote:
> Back to requirements...
> 
> Are there any objections to these, with number 4 amended as suggested by
> Paul George:
> 
> [1] Every object MUST have an associated object identifier.
> 
> [2] Object identifiers MUST be globally unique.
> 
> [3] An object's identifier MUST NOT change during the lifetime of the
> object, even if administrative control of the object changes over time.
> 
> [4] An object identifier MUST contain information that unambiguously
> identifies both the object and the object's administrative repository at
> time of creation.

  We should probably reduce the scope of this one.  How about the version
  below?

  An object identifier MUST contain information that unambiguously
  identifies the object.

> 
> [5] Object identifier format SHOULD be easily parsed and understood by
> humans.

  Some scope reduction here, too.

  [5] Object identifier SHOULD have an opaque, fixed length format 
      (e.g. 128 bit digest).

  [6] An identifier that is easily parsed and understood by humans, and 
      is equivalent to the identifier in [5], MUST be made available to
      the object's owner at the time of object creation.

> 
> <Scott/>

George.

-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Tue, 13 Mar 2001 14:26:18 -0500
Sender: [email-masked]

Back to requirements...

Are there any objections to these, with number 4 amended as suggested by
Paul George:

[1] Every object MUST have an associated object identifier.

[2] Object identifiers MUST be globally unique.

[3] An object's identifier MUST NOT change during the lifetime of the
object, even if administrative control of the object changes over time.

[4] An object identifier MUST contain information that unambiguously
identifies both the object and the object's administrative repository at
time of creation.

[5] Object identifier format SHOULD be easily parsed and understood by
humans.

<Scott/>

Date: Mon, 12 Mar 2001 16:46:10 -0500
From: Michael Mealling <[email-masked]>
To: George Belotsky <[email-masked]>
Cc: [email-masked], William Tan <[email-masked]>, Bill Manning <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 12, 2001 at 04:31:29PM -0500, George Belotsky wrote:
> MM has brought up a valid limitation of UUID-style identifiers for
> doing lookups. Unfortunately, MM's observation also applies to any
> constant identifier -- not just UUIDs.  If the handle contains
> information on its location, and its location changes, the handle must
> also change.

There's a subtle but important point here. There are two functions
we're talking about: identifier assignment and resolution. You
can optimize the namespace for one or the other. For example, you
could design the namespace so that assignment is done by concatinating
a registry ID and a local ID but resolution is flat. This allows
each entity to have their own name creation policy and still have
uniqueness. Resolution is then flat. Conversely you can optimize
for resolution and federate the lookup process. 

> If we wanted to store handles, so that we can access the objects
> later no matter where they got moved to in the meantime, then
> MM's point becomes a serious consideration.

Its a consideration but its not impossible to solve. The audience
of this list is used to dealing with large databases of things like
this. Its just that this particular database becomes a shared 
resource that everyone depends on. That causes politics and policy
to jump into the process....

> On the other hand, if the handles were used to specify operations on
> objects where the caller already knew the location(s), then we are
> still fine.  Examples of such operations are transfers, deletions,
> changes to contact information, etc.
>
> MM, can you think of a solution to this problem?  It may be possible
> to use DNS for resolving handles, but this gets back to most of the
> drawbacks of operating a handle registry.

This is a very valid point. Just because the unique object identifier
is not easily resolvable by itself does not invalidate it. You just
have to have some other information along for the ride that lets you
know who currently has that object (or a pointer to it). Imagine
some construct similar to this

e75ad859-83db-4225-a564-120f2fd0d5a9@RIPE 

or more generally:
<objectid>@<administrative ID>

This is what you use in 99% of the cases in the protocol. Both
sides are globally unique so you can be sure that if RIPE
no longer has the thing it will still have the same name of
e75ad859-83db-4225-a564-120f2fd0d5a9 no matter where it moved
to. The RIPE service could even give you a referal to where it
thinks it got moved to....

Now, if you want to build an adjunct service to find an object id without
an administative ID then that's a slower, more exhaustive search.
But it could be done because it would be an atypical query and thus
one that could be done as a low priority process...

Now that I think about it I guess this was Bill's point just repackaged..

-MM

> On Mon, Mar 12, 2001 at 03:08:25PM -0500, Michael Mealling wrote:
> > On Tue, Mar 13, 2001 at 04:01:33AM +0800, William Tan wrote:
> > > > Yup... Thats pretty much my take as well.
> > > > #1 has not worked well
> > > > #2 is ... operationally challenging ... :)
> > > > #3 might be the most fun to work on.
> > > 
> > > I'm for the idea of uuid-like hashes.  Readability has to be sacrificed, I
> > > don't see any way out.  However, handles may be hidden from the end users,
> > > so it might not be an issue after all.
> > 
> > You not only sacrifice readability but you also sacrifice delegated resolution. 
> > A flag namespace such as UUIDs would require either a single large
> > database or a lookup would have to be sent to every potential object
> > holder to see who had it....
> > 
> > -MM
> > 
> > -- 
> > --------------------------------------------------------------------------------
> > Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
> > Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
> > Network Solutions	|          www.lp.org          |  [email-masked]
> 
> -- 
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Mon, 12 Mar 2001 16:34:18 -0500
From: George Belotsky <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: William Tan <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Readability is only partially sacrificed: the owner of an object
can still use the readable handle, as can anyone else he/she
gives the plaintext representation to.  Thus, we are actually
not too badly off as far as readability is concerned.

George.

On Mon, Mar 12, 2001 at 01:11:01PM -0800, Bill Manning wrote:
> % 
> % > Yup... Thats pretty much my take as well.
> % > #1 has not worked well
> % > #2 is ... operationally challenging ... :)
> % > #3 might be the most fun to work on.
> % 
> % I'm for the idea of uuid-like hashes.  Readability has to be sacrificed, I
> % don't see any way out.  However, handles may be hidden from the end users,
> % so it might not be an issue after all.
> % 
> % 
> % wil.
> 
> 	See Michaels comments wrt hashing.  It would be "reasonable"
> 	to consider composite handles being hashed.
> 
> -- 
> --bill

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Mon, 12 Mar 2001 16:31:29 -0500
From: George Belotsky <[email-masked]>
To: [email-masked]
Cc: William Tan <[email-masked]>, Bill Manning <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

MM has brought up a valid limitation of UUID-style identifiers for
doing lookups. Unfortunately, MM's observation also applies to any
constant identifier -- not just UUIDs.  If the handle contains
information on its location, and its location changes, the handle must
also change.

If we wanted to store handles, so that we can access the objects
later no matter where they got moved to in the meantime, then
MM's point becomes a serious consideration.

On the other hand, if the handles were used to specify operations on
objects where the caller already knew the location(s), then we are
still fine.  Examples of such operations are transfers, deletions,
changes to contact information, etc.

MM, can you think of a solution to this problem?  It may be possible
to use DNS for resolving handles, but this gets back to most of the
drawbacks of operating a handle registry.

George.

On Mon, Mar 12, 2001 at 03:08:25PM -0500, Michael Mealling wrote:
> On Tue, Mar 13, 2001 at 04:01:33AM +0800, William Tan wrote:
> > > Yup... Thats pretty much my take as well.
> > > #1 has not worked well
> > > #2 is ... operationally challenging ... :)
> > > #3 might be the most fun to work on.
> > 
> > I'm for the idea of uuid-like hashes.  Readability has to be sacrificed, I
> > don't see any way out.  However, handles may be hidden from the end users,
> > so it might not be an issue after all.
> 
> You not only sacrifice readability but you also sacrifice delegated resolution. 
> A flag namespace such as UUIDs would require either a single large
> database or a lookup would have to be sent to every potential object
> holder to see who had it....
> 
> -MM
> 
> -- 
> --------------------------------------------------------------------------------
> Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
> Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
> Network Solutions	|          www.lp.org          |  [email-masked]

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (William Tan)
Date: Mon, 12 Mar 2001 13:11:01 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked]
Sender: [email-masked]

% 
% > Yup... Thats pretty much my take as well.
% > #1 has not worked well
% > #2 is ... operationally challenging ... :)
% > #3 might be the most fun to work on.
% 
% I'm for the idea of uuid-like hashes.  Readability has to be sacrificed, I
% don't see any way out.  However, handles may be hidden from the end users,
% so it might not be an issue after all.
% 
% 
% wil.

	See Michaels comments wrt hashing.  It would be "reasonable"
	to consider composite handles being hashed.

-- 
--bill

Date: Mon, 12 Mar 2001 15:08:25 -0500
From: Michael Mealling <[email-masked]>
To: William Tan <[email-masked]>
Cc: Bill Manning <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Tue, Mar 13, 2001 at 04:01:33AM +0800, William Tan wrote:
> > Yup... Thats pretty much my take as well.
> > #1 has not worked well
> > #2 is ... operationally challenging ... :)
> > #3 might be the most fun to work on.
> 
> I'm for the idea of uuid-like hashes.  Readability has to be sacrificed, I
> don't see any way out.  However, handles may be hidden from the end users,
> so it might not be an issue after all.

You not only sacrifice readability but you also sacrifice delegated resolution. 
A flag namespace such as UUIDs would require either a single large
database or a lookup would have to be sent to every potential object
holder to see who had it....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Mon, 12 Mar 2001 15:05:57 -0500
From: Michael Mealling <[email-masked]>
To: George Belotsky <[email-masked]>
Cc: Bill Manning <[email-masked]>, [email-masked], Hollenbeck Scott <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 12, 2001 at 02:37:31PM -0500, George Belotsky wrote:
> A digest can be used as a handle.  A composite built up of atomics
> (UUID-style) can be used as input to the digest function.  The
> handle's owner still has the easy to remember representation,
> which they can share or keep from whoever they like.
> 
> As I said in a previous post, the digest solution does provide
> a measure of security.  Additional benefits are consistency of
> representation, and proper enforcement of access control.  The digest
> handle is opaque.  I cannot get any information from such a handle by
> itself.  

The main drawback from this is that it becomes a flat namespace. If you
find an identifier you either have to ask everyone who has it or
have some 'database in the sky' that contains all of the identifiers.
This may or may not be an issues. It really depends on how often
you'll be attempting to deal with 'naked' and unknown/foreign identifiers.
I'm not intimate enought with the problem space to know if its an issue...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

From: "William Tan" <[email-masked]>
To: "Bill Manning" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Unique handle generation
Date: Tue, 13 Mar 2001 04:01:33 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

> Yup... Thats pretty much my take as well.
> #1 has not worked well
> #2 is ... operationally challenging ... :)
> #3 might be the most fun to work on.

I'm for the idea of uuid-like hashes.  Readability has to be sacrificed, I
don't see any way out.  However, handles may be hidden from the end users,
so it might not be an issue after all.

wil.

Date: Mon, 12 Mar 2001 14:37:31 -0500
From: George Belotsky <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: [email-masked], Hollenbeck Scott <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

A digest can be used as a handle.  A composite built up of atomics
(UUID-style) can be used as input to the digest function.  The
handle's owner still has the easy to remember representation,
which they can share or keep from whoever they like.

As I said in a previous post, the digest solution does provide
a measure of security.  Additional benefits are consistency of
representation, and proper enforcement of access control.  The digest
handle is opaque.  I cannot get any information from such a handle by
itself.  

For example, the full names of domain owners may be privileged
information in some registries (this is a matter of policy).  The
digest handle would allow users with varying privilege levels to get
just the allowed amount of information about a specific object.

The UUID-style approach of building up a unique handle from components
is easier, far less costly, and inherently much safer than running a
handle repository.  What happens if a coding error is introduced into
the repository, and duplicate handles are handed out?  What if the
handle registry is not accessible/down?  Who will build the necessary
registry infrastructure for the entire world, maintain it, provide
24x7 support for it, and pay for it?

George.

On Mon, Mar 12, 2001 at 11:02:04AM -0800, Bill Manning wrote:
> 
> A globally unique space is required within a given object type or
> confusion reigns. Constructing composites out of atomics can assist
> in removing abiguity.
> 
> Without additional information, I can't discriminate George from George
> from George.  Adding a Surname helps. (different object type) Adding 
> a registry helps (different object type).  Still too many GEORGEB-ARIN
> handles... 
> And while ARIN may fabricate its own ideas of which GEORGEB is which,
> unless there is some atomic way of removing the ambiguity of GEORGE, as
> that object type pertains to the Internet, then we can only refer to GEORGE
> in its relationship to another object type.  We can't talk about GEORGE as
> a handle with independent meaning.
> 
> 
> 
> 
> % 
> % A globally unique handle does not necessarily require
> % coordination between organizations to ensure uniqueness.
> % 
> % George.
> % 
> % 
> % On Mon, Mar 12, 2001 at 10:04:20AM -0800, Bill Manning wrote:
> % > %>% I'm not sure I understand the point you're trying to make in the context of
> % > %>% admin repository changes over time.
> % > %>% 
> % > %>% What happens to your example handle if the admin function is one day moved
> % > %>% from ARIN to some other administrative entity (call it !ARIN for the sake of
> % > %>% argument), but the person and prefix remain constant?  Does the handle
> % > %>% remain WM110-ARIN, or must it change to WM110-!ARIN?
> % > %> 
> % > %> 	The legecy composite  WM110-ARIN remains
> % > %> 	If -I- chose to do business w/ !ARIN, then !ARIN may
> % > %> 	create the composite WM110-!ARIN.  If !ARIN wishes
> % > %> 	to create the composite anyway, they -MUST- use my
> % > %> 	handle, WM110, not create something else.. like BM14
> % > %> 	or WM73.
> % > %
> % > % So your personal handle is part of a globally unique space that all
> % > % registries have to coordinate to ensure uniqueness, right?
> % > % 
> % > % -MM
> % > 
> % > 	Unfortunately, yes.
> % > 	Just like the registry handles have be be globally unique.
> % > 	(It would be confusing to have two registries with the same
> % > 	handle... :)
> % > 	One must have globally unique space within each object type.
> % > 	
> % > 
> % > -- 
> % > --bill
> % 
> % -- 
> % -----------------------------
> % George Belotsky
> % Senior Software Architect
> % Register.com, inc.
> % [email-masked]
> % 212-798-9127 (phone)
> % 212-798-9876 (fax)
> % 
> 
> 
> -- 
> --bill

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked]
Date: Mon, 12 Mar 2001 11:05:53 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

% > % So your personal handle is part of a globally unique space that all
% > % registries have to coordinate to ensure uniqueness, right?
% > % 
% > % -MM
% > 
% > 	Unfortunately, yes.
% > 	Just like the registry handles have be be globally unique.
% > 	(It would be confusing to have two registries with the same
% > 	handle... :)
% > 	One must have globally unique space within each object type.
% 
% So, you have three methods that I'm aware of to do this:
% 
% 1) all of the registries have to cooperate to make sure they are
%    creating unique handles 
% 
% 2) some other entity has to give out unique object handles.
% 
% 3) come up with a scheme that can be self assigned but still
%    gaurantees uniqueness (some hash function, uuid being just one)

	Yup... Thats pretty much my take as well. 
	#1 has not worked well
	#2 is ... operationally challenging ... :)
	#3 might be the most fun to work on.

% I think the point that others are attempting to get to by
% suggesting that an object's name is its registry handle 
% plus its handle is to avoid these methods.  It would be nice of 
% folks said why they find these methods objectionable..

	See reply to George, already in flight.
	If a handle has independent meaning, we ought to be 
	able to talk about it w/o refering to its other associations.

% 
% -MM
% 
% -- 
% --------------------------------------------------------------------------------
% Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
% Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
% Network Solutions	|          www.lp.org          |  [email-masked]
% 

-- 
--bill

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (George Belotsky)
Date: Mon, 12 Mar 2001 11:02:04 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked], [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

A globally unique space is required within a given object type or
confusion reigns. Constructing composites out of atomics can assist
in removing abiguity.

Without additional information, I can't discriminate George from George
from George.  Adding a Surname helps. (different object type) Adding 
a registry helps (different object type).  Still too many GEORGEB-ARIN
handles... 
And while ARIN may fabricate its own ideas of which GEORGEB is which,
unless there is some atomic way of removing the ambiguity of GEORGE, as
that object type pertains to the Internet, then we can only refer to GEORGE
in its relationship to another object type.  We can't talk about GEORGE as
a handle with independent meaning.

% 
% A globally unique handle does not necessarily require
% coordination between organizations to ensure uniqueness.
% 
% George.
% 
% 
% On Mon, Mar 12, 2001 at 10:04:20AM -0800, Bill Manning wrote:
% > %>% I'm not sure I understand the point you're trying to make in the context of
% > %>% admin repository changes over time.
% > %>% 
% > %>% What happens to your example handle if the admin function is one day moved
% > %>% from ARIN to some other administrative entity (call it !ARIN for the sake of
% > %>% argument), but the person and prefix remain constant?  Does the handle
% > %>% remain WM110-ARIN, or must it change to WM110-!ARIN?
% > %> 
% > %> 	The legecy composite  WM110-ARIN remains
% > %> 	If -I- chose to do business w/ !ARIN, then !ARIN may
% > %> 	create the composite WM110-!ARIN.  If !ARIN wishes
% > %> 	to create the composite anyway, they -MUST- use my
% > %> 	handle, WM110, not create something else.. like BM14
% > %> 	or WM73.
% > %
% > % So your personal handle is part of a globally unique space that all
% > % registries have to coordinate to ensure uniqueness, right?
% > % 
% > % -MM
% > 
% > 	Unfortunately, yes.
% > 	Just like the registry handles have be be globally unique.
% > 	(It would be confusing to have two registries with the same
% > 	handle... :)
% > 	One must have globally unique space within each object type.
% > 	
% > 
% > -- 
% > --bill
% 
% -- 
% -----------------------------
% George Belotsky
% Senior Software Architect
% Register.com, inc.
% [email-masked]
% 212-798-9127 (phone)
% 212-798-9876 (fax)
% 

-- 
--bill

Date: Mon, 12 Mar 2001 13:47:05 -0500
From: Michael Mealling <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: [email-masked], Hollenbeck Scott <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 12, 2001 at 10:04:20AM -0800, Bill Manning wrote:
> %>% I'm not sure I understand the point you're trying to make in the context of
> %>% admin repository changes over time.
> %>% 
> %>% What happens to your example handle if the admin function is one day moved
> %>% from ARIN to some other administrative entity (call it !ARIN for the sake of
> %>% argument), but the person and prefix remain constant?  Does the handle
> %>% remain WM110-ARIN, or must it change to WM110-!ARIN?
> %> 
> %> 	The legecy composite  WM110-ARIN remains
> %> 	If -I- chose to do business w/ !ARIN, then !ARIN may
> %> 	create the composite WM110-!ARIN.  If !ARIN wishes
> %> 	to create the composite anyway, they -MUST- use my
> %> 	handle, WM110, not create something else.. like BM14
> %> 	or WM73.
> %
> % So your personal handle is part of a globally unique space that all
> % registries have to coordinate to ensure uniqueness, right?
> % 
> % -MM
> 
> 	Unfortunately, yes.
> 	Just like the registry handles have be be globally unique.
> 	(It would be confusing to have two registries with the same
> 	handle... :)
> 	One must have globally unique space within each object type.

So, you have three methods that I'm aware of to do this:

1) all of the registries have to cooperate to make sure they are
   creating unique handles 

2) some other entity has to give out unique object handles.

3) come up with a scheme that can be self assigned but still
   gaurantees uniqueness (some hash function, uuid being just one)

I think the point that others are attempting to get to by
suggesting that an object's name is its registry handle 
plus its handle is to avoid these methods.  It would be nice of 
folks said why they find these methods objectionable..

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (William Tan)
Date: Mon, 12 Mar 2001 10:53:16 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

 Tough call. Perhaps a new type of registry?

% 
% And who would be responsible for maintaining the globally uniqueness of your
% personal handle?  It would be reasonable for IANA to maintain registry
% handles, but it cannot be a generic object registry.
% 
% wil
% 
% ----- Original Message -----
% From: "Bill Manning" <[email-masked]>
% To: <[email-masked]>
% Cc: "Bill Manning" <[email-masked]>; "Hollenbeck Scott"
% <[email-masked]>; <[email-masked]>
% Sent: Tuesday, March 13, 2001 2:04 AM
% Subject: Re: Unique handle generation
% 
% 
% > %>% I'm not sure I understand the point you're trying to make in the
% context of
% > %>% admin repository changes over time.
% > %>%
% > %>% What happens to your example handle if the admin function is one day
% moved
% > %>% from ARIN to some other administrative entity (call it !ARIN for the
% sake of
% > %>% argument), but the person and prefix remain constant?  Does the handle
% > %>% remain WM110-ARIN, or must it change to WM110-!ARIN?
% > %>
% > %> The legecy composite  WM110-ARIN remains
% > %> If -I- chose to do business w/ !ARIN, then !ARIN may
% > %> create the composite WM110-!ARIN.  If !ARIN wishes
% > %> to create the composite anyway, they -MUST- use my
% > %> handle, WM110, not create something else.. like BM14
% > %> or WM73.
% > %
% > % So your personal handle is part of a globally unique space that all
% > % registries have to coordinate to ensure uniqueness, right?
% > %
% > % -MM
% >
% > Unfortunately, yes.
% > Just like the registry handles have be be globally unique.
% > (It would be confusing to have two registries with the same
% > handle... :)
% > One must have globally unique space within each object type.
% >
% >
% > --
% > --bill
% 

-- 
--bill

Date: Mon, 12 Mar 2001 13:43:26 -0500
From: George Belotsky <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: [email-masked], Hollenbeck Scott <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

A globally unique handle does not necessarily require
coordination between organizations to ensure uniqueness.

George.

On Mon, Mar 12, 2001 at 10:04:20AM -0800, Bill Manning wrote:
> %>% I'm not sure I understand the point you're trying to make in the context of
> %>% admin repository changes over time.
> %>% 
> %>% What happens to your example handle if the admin function is one day moved
> %>% from ARIN to some other administrative entity (call it !ARIN for the sake of
> %>% argument), but the person and prefix remain constant?  Does the handle
> %>% remain WM110-ARIN, or must it change to WM110-!ARIN?
> %> 
> %> 	The legecy composite  WM110-ARIN remains
> %> 	If -I- chose to do business w/ !ARIN, then !ARIN may
> %> 	create the composite WM110-!ARIN.  If !ARIN wishes
> %> 	to create the composite anyway, they -MUST- use my
> %> 	handle, WM110, not create something else.. like BM14
> %> 	or WM73.
> %
> % So your personal handle is part of a globally unique space that all
> % registries have to coordinate to ensure uniqueness, right?
> % 
> % -MM
> 
> 	Unfortunately, yes.
> 	Just like the registry handles have be be globally unique.
> 	(It would be confusing to have two registries with the same
> 	handle... :)
> 	One must have globally unique space within each object type.
> 	
> 
> -- 
> --bill

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "William Tan" <[email-masked]>
To: <[email-masked]>
Subject: Re: Unique handle generation
Date: Tue, 13 Mar 2001 02:28:01 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

And who would be responsible for maintaining the globally uniqueness of your
personal handle?  It would be reasonable for IANA to maintain registry
handles, but it cannot be a generic object registry.

wil

----- Original Message -----
From: "Bill Manning" <[email-masked]>
To: <[email-masked]>
Cc: "Bill Manning" <[email-masked]>; "Hollenbeck Scott"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 13, 2001 2:04 AM
Subject: Re: Unique handle generation

> %>% I'm not sure I understand the point you're trying to make in the
context of
> %>% admin repository changes over time.
> %>%
> %>% What happens to your example handle if the admin function is one day
moved
> %>% from ARIN to some other administrative entity (call it !ARIN for the
sake of
> %>% argument), but the person and prefix remain constant?  Does the handle
> %>% remain WM110-ARIN, or must it change to WM110-!ARIN?
> %>
> %> The legecy composite  WM110-ARIN remains
> %> If -I- chose to do business w/ !ARIN, then !ARIN may
> %> create the composite WM110-!ARIN.  If !ARIN wishes
> %> to create the composite anyway, they -MUST- use my
> %> handle, WM110, not create something else.. like BM14
> %> or WM73.
> %
> % So your personal handle is part of a globally unique space that all
> % registries have to coordinate to ensure uniqueness, right?
> %
> % -MM
>
> Unfortunately, yes.
> Just like the registry handles have be be globally unique.
> (It would be confusing to have two registries with the same
> handle... :)
> One must have globally unique space within each object type.
>
>
> --
> --bill

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked]
Date: Mon, 12 Mar 2001 10:04:20 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

%>% I'm not sure I understand the point you're trying to make in the context of
%>% admin repository changes over time.
%>% 
%>% What happens to your example handle if the admin function is one day moved
%>% from ARIN to some other administrative entity (call it !ARIN for the sake of
%>% argument), but the person and prefix remain constant?  Does the handle
%>% remain WM110-ARIN, or must it change to WM110-!ARIN?
%> 
%> 	The legecy composite  WM110-ARIN remains
%> 	If -I- chose to do business w/ !ARIN, then !ARIN may
%> 	create the composite WM110-!ARIN.  If !ARIN wishes
%> 	to create the composite anyway, they -MUST- use my
%> 	handle, WM110, not create something else.. like BM14
%> 	or WM73.
%
% So your personal handle is part of a globally unique space that all
% registries have to coordinate to ensure uniqueness, right?
% 
% -MM

	Unfortunately, yes.
	Just like the registry handles have be be globally unique.
	(It would be confusing to have two registries with the same
	handle... :)
	One must have globally unique space within each object type.

-- 
--bill

Date: Mon, 12 Mar 2001 12:51:49 -0500
From: Michael Mealling <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 12, 2001 at 09:48:21AM -0800, Bill Manning wrote:
> % I'm not sure I understand the point you're trying to make in the context of
> % admin repository changes over time.
> % 
> % What happens to your example handle if the admin function is one day moved
> % from ARIN to some other administrative entity (call it !ARIN for the sake of
> % argument), but the person and prefix remain constant?  Does the handle
> % remain WM110-ARIN, or must it change to WM110-!ARIN?
> 
> 	The legecy composite  WM110-ARIN remains
> 	If -I- chose to do business w/ !ARIN, then !ARIN may
> 	create the composite WM110-!ARIN.  If !ARIN wishes
> 	to create the composite anyway, they -MUST- use my
> 	handle, WM110, not create something else.. like BM14
> 	or WM73.

So your personal handle is part of a globally unique space that all
registries have to coordinate to ensure uniqueness, right?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Hollenbeck, Scott)
Date: Mon, 12 Mar 2001 09:48:21 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

% 
% Bill,
% 
% I'm not sure I understand the point you're trying to make in the context of
% admin repository changes over time.
% 
% What happens to your example handle if the admin function is one day moved
% from ARIN to some other administrative entity (call it !ARIN for the sake of
% argument), but the person and prefix remain constant?  Does the handle
% remain WM110-ARIN, or must it change to WM110-!ARIN?

	The legecy composite  WM110-ARIN remains
	If -I- chose to do business w/ !ARIN, then !ARIN may
	create the composite WM110-!ARIN.  If !ARIN wishes
	to create the composite anyway, they -MUST- use my
	handle, WM110, not create something else.. like BM14
	or WM73.

% 
% <Scott/>
% 
% >-----Original Message-----
% >From: Bill Manning [mailto:[email-masked]]
% >Sent: Monday, March 12, 2001 12:05 PM
% >To: [email-masked]
% >Cc: [email-masked]; [email-masked]
% >Subject: Re: Unique handle generation
% >
% >
% > some time back (last week) I mentioned that each object has its own
% >handle. One of those objects is the administrative repository. We have
% >documented evidence that administrative repositories have changed while
% >the objects it has chosen to imbed have not changed. 
% >
% >Please consider that some "handles" are a concatination of "atomic"
% >handles. e.g.
% >
% >Person:  WM110
% >Admin Repository: ARIN
% >	these two are concatinated to form WM110-ARIN and that composite
% >	is bound to:
% >---
% >Prefix: 192.168.0.0/16
% 

-- 
--bill

Date: Mon, 12 Mar 2001 12:28:37 -0500
From: Michael Mealling <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Unique handle generation
Reply-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 12, 2001 at 12:17:49PM -0500, Hollenbeck, Scott wrote:
> I'm not sure I understand the point you're trying to make in the context of
> admin repository changes over time.
> 
> What happens to your example handle if the admin function is one day moved
> from ARIN to some other administrative entity (call it !ARIN for the sake of
> argument), but the person and prefix remain constant?  Does the handle
> remain WM110-ARIN, or must it change to WM110-!ARIN?

And if the two elements have meaning (which making them atomic suggests)
then you end up needing to ensure that both are globally unique since
I'd bet there would be a WM110 in the new entity pointing to someone else...

-MM

> >-----Original Message-----
> >From: Bill Manning [mailto:[email-masked]]
> >Sent: Monday, March 12, 2001 12:05 PM
> >To: [email-masked]
> >Cc: [email-masked]; [email-masked]
> >Subject: Re: Unique handle generation
> >
> >
> > some time back (last week) I mentioned that each object has its own
> >handle. One of those objects is the administrative repository. We have
> >documented evidence that administrative repositories have changed while
> >the objects it has chosen to imbed have not changed. 
> >
> >Please consider that some "handles" are a concatination of "atomic"
> >handles. e.g.
> >
> >Person:  WM110
> >Admin Repository: ARIN
> >	these two are concatinated to form WM110-ARIN and that composite
> >	is bound to:
> >---
> >Prefix: 192.168.0.0/16

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Mon, 12 Mar 2001 12:17:49 -0500
Sender: [email-masked]

Bill,

I'm not sure I understand the point you're trying to make in the context of
admin repository changes over time.

What happens to your example handle if the admin function is one day moved
from ARIN to some other administrative entity (call it !ARIN for the sake of
argument), but the person and prefix remain constant?  Does the handle
remain WM110-ARIN, or must it change to WM110-!ARIN?

<Scott/>

>-----Original Message-----
>From: Bill Manning [mailto:[email-masked]]
>Sent: Monday, March 12, 2001 12:05 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: Unique handle generation
>
>
> some time back (last week) I mentioned that each object has its own
>handle. One of those objects is the administrative repository. We have
>documented evidence that administrative repositories have changed while
>the objects it has chosen to imbed have not changed. 
>
>Please consider that some "handles" are a concatination of "atomic"
>handles. e.g.
>
>Person:  WM110
>Admin Repository: ARIN
>	these two are concatinated to form WM110-ARIN and that composite
>	is bound to:
>---
>Prefix: 192.168.0.0/16

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Hollenbeck, Scott)
Date: Mon, 12 Mar 2001 09:05:15 -0800 (PST)
Cc: [email-masked] ('Paul George'), [email-masked]
Sender: [email-masked]

 some time back (last week) I mentioned that each object has its own
handle. One of those objects is the administrative repository. We have
documented evidence that administrative repositories have changed while
the objects it has chosen to imbed have not changed. 

Please consider that some "handles" are a concatination of "atomic"
handles. e.g.

Person:  WM110
Admin Repository: ARIN
	these two are concatinated to form WM110-ARIN and that composite
	is bound to:
---
Prefix: 192.168.0.0/16

% 
% Right now I'm working with the assumption that the administrative repository
% won't change, but maybe that's not a good assumption.  For example, gTLD
% registry operators may change over time.  Changing the handle upon such a
% repository change would be counter to other requirements, but not changing
% it might be confusing.
% 
% Perhaps this requirement should be reworded -- suggestions?
% 
% <Scott/>
% 
% >-----Original Message-----
% >From: Paul George [mailto:[email-masked]]
% >Sent: Monday, March 12, 2001 7:08 AM
% >To: [email-masked]
% >Subject: RE: Unique handle generation
% >
% >
% >4. An object handle MUST contain information that 
% >unambiguously identifies
% >both the object and the object's administrative repository.
% >
% >Is there a possibility that the object's administrative 
% >repository could
% >change?  If so, then that attribute should not be a part of 
% >the handle. This
% >is because that part of the handle would then only indicate 
% >the admin that
% >originated the handle, not the current administrator.
% 

-- 
--bill

Date: Mon, 12 Mar 2001 10:50:07 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

If the admin repository changes, #3 and #4 will contradict
each other.  The repository that created the object could
be part of the handle.  Then, if an object is deleted and
registered by some other repository, the handle will change
(which could be a good thing).

Transfers would not change the handle.

Also, there are advantages to converting the handles to 
digests, and then using those instead of handles.  It would
provide a measure of security (and perhaps privacy, if personal
information is part of the handle) for the user.  Also, the
handles would be stored and used in a consistent, fixed-length
format (e.g. 128 bits of opaque binary data).

While a digest would preclude search functionality (especially
across registries, registrars, etc.), this is probably too 
complex a task for a handle anyway.  Powerful search facilities
rely on a number of object attributes, can contain patterns and
have a complex boolean structure, etc.  Trying to fit all the 
needed information into a handle would make it very large,
complex, and thus difficult to remember.

In the above scenario, searches would return the digest form of the
handle as attributes of the found objects.  The opaque format would
prevent the originator of the request from potentially learning any
more information from the handle itself than their access privileges
allow.  The user on whose behalf the handle was created would still
have the readable version of the handle, and could choose who to give
(or not to give) this information to.

George.

On Sat, Mar 10, 2001 at 09:03:41AM -0500, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: Patrik Fältström [mailto:[email-masked]]
> > Sent: Saturday, March 10, 2001 2:13 AM
> > To: Hollenbeck, Scott; [email-masked]
> > Subject: RE: Unique handle generation
> > 
> > 
> > At 19.49 -0500 01-03-09, Hollenbeck, Scott wrote:
> > >The requirements draft currently states that every object 
> > must be associated
> > >with a unique identifier, but it doesn't specifically define 
> > the format of
> > >the identifier(s).  It's that "what the protocol should do" 
> > (in scope) vs.
> > >the "how the protocol should do it" (out of scope) thing again.
> > 
> > What do you mean by unique? Locally in the registrar? In the 
> > Registry? In the world? Should the handle change when an object is 
> > moved between registrars? Should the handle be able to not only 
> > identify the object but also where the object is?
> > 
> > I.e. a bit more specific requirements would help. It is the lack of 
> > answers to these questions the discussion on the syntax is so hard.
> 
> OK, I see your point.  In an earlier message you suggested some requirements
> for handles; let me try to capture those thoughts (and some mentioned by
> others) more precisely:
> 
> 1. Every object MUST have an associated handle.
> 
> 2. An object handle MUST be globally unique.
> 
> 3. An object's handle MUST NOT change during the lifetime of an object, even
> if administrative control of the object changes over time.
> 
> 4. An object handle MUST contain information that unambiguously identifies
> both the object and the object's administrative repository.
> 
> 5. Handle format SHOULD be easily parsed by humans.
> 
> Does anyone object to having these added to the requirements draft?
> 
> <Scott/>

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Paul George'" <[email-masked]>, [email-masked]
Subject: RE: Unique handle generation
Date: Mon, 12 Mar 2001 10:43:59 -0500
Sender: [email-masked]

Paul,

If we disallow identifier change, and require the identifier to reflect the
creating repository per your suggested rewording, I think we run the risk of
confusion over time.  After a repository change the unchanged identifier
will not reflect the new administrative repository; this seems counter to
some of the desires I've read over the last few days.

A basic question: do we feel that it's necessary for someone to look at an
identifier and know which repository it lives in, or would some kind of
resolver technology be OK to provide that information?

The eyeball approach leads to problems if we believe that objects can change
repositories over time, but identifiers shouldn't change over time.

The resolver approach helps manage the repository change problem, but then
identifiers may be less intuitive to someone who happens to be looking at
one.

<Scott/>

>-----Original Message-----
>From: Paul George [mailto:[email-masked]]
>Sent: Monday, March 12, 2001 7:53 AM
>To: [email-masked]
>Subject: RE: Unique handle generation
>
>
>Perhaps remove the second part of #4?  Why add auxilary info 
>to the handle?
>It would then be serving two purposes. So it would read:
>
>>4. An object handle MUST contain information that 
>unambiguously identifies
>>the object.
>
>But then is it duplicating #2.(2. An object handle MUST be 
>globally unique.)
>
>The alternative would be:
>
>4. An object handle MUST contain information that 
>unambiguously identifies
>both the object and the object's administrative repository at time of
>creation.

Date: Mon, 12 Mar 2001 13:17:33 +0000 (GMT)
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "'Paul George'" <[email-masked]>, [email-masked]
Subject: RE: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Scott" == Hollenbeck, Scott <[email-masked]> writes:

    Scott> Right now I'm working with the assumption that the
    Scott> administrative repository won't change, but maybe that's
    Scott> not a good assumption.  For example, gTLD registry
    Scott> operators may change over time.  Changing the handle upon
    Scott> such a repository change would be counter to other
    Scott> requirements, but not changing it might be confusing.

Surely the possibility of change significantly reduces the handle's
utility though ? 

If one of the reasons people want global uniqueness is to facilitate
using the handle as a foreign key, then if the handle might change
surely we'd also need to have some way to disseminate the changes ?

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Unique handle generation
Date: Mon, 12 Mar 2001 07:52:40 -0500
Importance: Normal
Sender: [email-masked]

Perhaps remove the second part of #4?  Why add auxilary info to the handle?
It would then be serving two purposes. So it would read:

>4. An object handle MUST contain information that unambiguously identifies
>the object.

But then is it duplicating #2.(2. An object handle MUST be globally unique.)

The alternative would be:

4. An object handle MUST contain information that unambiguously identifies
both the object and the object's administrative repository at time of
creation.

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Monday, March 12, 2001 7:37 AM
To: 'Paul George'; [email-masked]
Subject: RE: Unique handle generation

Right now I'm working with the assumption that the administrative repository
won't change, but maybe that's not a good assumption.  For example, gTLD
registry operators may change over time.  Changing the handle upon such a
repository change would be counter to other requirements, but not changing
it might be confusing.

Perhaps this requirement should be reworded -- suggestions?

<Scott/>

>-----Original Message-----
>From: Paul George [mailto:[email-masked]]
>Sent: Monday, March 12, 2001 7:08 AM
>To: [email-masked]
>Subject: RE: Unique handle generation
>
>
>4. An object handle MUST contain information that
>unambiguously identifies
>both the object and the object's administrative repository.
>
>Is there a possibility that the object's administrative
>repository could
>change?  If so, then that attribute should not be a part of
>the handle. This
>is because that part of the handle would then only indicate
>the admin that
>originated the handle, not the current administrator.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Paul George'" <[email-masked]>, [email-masked]
Subject: RE: Unique handle generation
Date: Mon, 12 Mar 2001 07:36:35 -0500
Sender: [email-masked]

Right now I'm working with the assumption that the administrative repository
won't change, but maybe that's not a good assumption.  For example, gTLD
registry operators may change over time.  Changing the handle upon such a
repository change would be counter to other requirements, but not changing
it might be confusing.

Perhaps this requirement should be reworded -- suggestions?

<Scott/>

>-----Original Message-----
>From: Paul George [mailto:[email-masked]]
>Sent: Monday, March 12, 2001 7:08 AM
>To: [email-masked]
>Subject: RE: Unique handle generation
>
>
>4. An object handle MUST contain information that 
>unambiguously identifies
>both the object and the object's administrative repository.
>
>Is there a possibility that the object's administrative 
>repository could
>change?  If so, then that attribute should not be a part of 
>the handle. This
>is because that part of the handle would then only indicate 
>the admin that
>originated the handle, not the current administrator.

From: "Paul George" <[email-masked]>
To: <[email-masked]>
Subject: RE: Unique handle generation
Date: Mon, 12 Mar 2001 07:07:32 -0500
Importance: Normal
Sender: [email-masked]

4. An object handle MUST contain information that unambiguously identifies
both the object and the object's administrative repository.

Is there a possibility that the object's administrative repository could
change?  If so, then that attribute should not be a part of the handle. This
is because that part of the handle would then only indicate the admin that
originated the handle, not the current administrator.

Paul George
SARAF Software Solutions
(703)538-5666 x234

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Hollenbeck, Scott
Sent: Saturday, March 10, 2001 9:04 AM
To: [email-masked]
Subject: RE: Unique handle generation

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Saturday, March 10, 2001 2:13 AM
> To: Hollenbeck, Scott; [email-masked]
> Subject: RE: Unique handle generation
>
>
> At 19.49 -0500 01-03-09, Hollenbeck, Scott wrote:
> >The requirements draft currently states that every object
> must be associated
> >with a unique identifier, but it doesn't specifically define
> the format of
> >the identifier(s).  It's that "what the protocol should do"
> (in scope) vs.
> >the "how the protocol should do it" (out of scope) thing again.
>
> What do you mean by unique? Locally in the registrar? In the
> Registry? In the world? Should the handle change when an object is
> moved between registrars? Should the handle be able to not only
> identify the object but also where the object is?
>
> I.e. a bit more specific requirements would help. It is the lack of
> answers to these questions the discussion on the syntax is so hard.

OK, I see your point.  In an earlier message you suggested some requirements
for handles; let me try to capture those thoughts (and some mentioned by
others) more precisely:

1. Every object MUST have an associated handle.

2. An object handle MUST be globally unique.

3. An object's handle MUST NOT change during the lifetime of an object, even
if administrative control of the object changes over time.

4. An object handle MUST contain information that unambiguously identifies
both the object and the object's administrative repository.

5. Handle format SHOULD be easily parsed by humans.

Does anyone object to having these added to the requirements draft?

<Scott/>

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Subject: Re: Unique handle generation
Date: Sun, 11 Mar 2001 14:45:54 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

I do agree, and perhaps should have noted my statement as a leading
question. Apologies.

Christopher

----- Original Message ----- 
From: "Patrik Fältström" <[email-masked]>
To: "Christopher Ambler" <[email-masked]>; <[email-masked]>
Sent: Sunday, March 11, 2001 1:22 AM
Subject: Re: Unique handle generation

> At 15.55 -0800 01-03-10, Christopher Ambler wrote:
> >Same with name servers, then, if you mandate that there is one object
> >per IP address?
> 
> No. With this model you are redefining the DNS.
> 
> A domain name object is refering to a nameserver object, and that 
> nameserver object have an IP-address as an attribute. If the 
> IP-address change of that nameserver (different operation from 
> nameserver for the domain changes) the reference in the domain name 
> object is not to be changed.
> 
>     paf
> 

Date: Sun, 11 Mar 2001 16:39:58 +0000 (GMT)
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Cc: Rick H Wesson <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: RE: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "paf" == paf  <Patrik> writes:

    paf> At 15.48 -0800 01-03-10, Rick H Wesson wrote:
    >> On Sat, 10 Mar 2001, Hollenbeck, Scott wrote:
    >>
    >>
    >>> OK, I see your point.  In an earlier message you suggested
    >>> some requirements for handles; let me try to capture those
    >>> thoughts (and some mentioned by others) more precisely:
    >>>
    >>> 1. Every object MUST have an associated handle.
    >>
    >> Domain Name objects DO NOT need handles, as the FQDN uniquely
    >> identifies the object.

    paf> We need handles on _every_ object, and maybe the handle on
    paf> domain name objects (which is a very small part of all
    paf> objects we talk about) have the same syntax as the FQDN. But
    paf> I see talking about some object classes not having handles is
    paf> not a good thing.

Even with domain names---which are unique at a given instant of
time---I think there's a case for a more abstract handle. 

For example suppose foo.com is registered for a while, then it goes
dormant, but is then registered again. In some circumstances it's
better that the handles on the two instances are different.

Of course this is very much an issue for individual registries: I only 
make the point because I agree with Patrick that _every_ object should 
have a handle.

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Sun, 11 Mar 2001 09:24:42 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: [idn] Thoughts on nameprep 
BCC:
Sender: [email-masked]

------- Blind-Carbon-Copy

To: "James Seng/Personal" <[email-masked]>
cc: "D. J. Bernstein" <[email-masked]>, [email-masked], brunner
Subject: Re: [idn] Thoughts on nameprep 
In-Reply-To: Your message of "Sun, 11 Mar 2001 20:37:04 +0800."
             <007201c0aa27$fc0b7670$4f3213cb@jamessonyvaio> 
Date: Sun, 11 Mar 2001 09:24:42 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>

...
> > Registrars will forbid strings that have [some particular property,
> > the specific instance omitted from the original as irrelevant to the
> > mechanism/policy issue.]
> 
> And you assumed only Registrars will put names into DNS entries? I have
> not realised that DNS has evolved to a stage where it become a property
> of Registries and Registrars only.

What other mechanism(s) do you have in mind? What scope(s) does these
independant mechanism(s) and policy (policies) have?

------- End of Blind-Carbon-Copy

Date: Sun, 11 Mar 2001 10:20:58 +0100
To: Rick H Wesson <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Cc: <[email-masked]>
Sender: [email-masked]

At 15.48 -0800 01-03-10, Rick H Wesson wrote:
>On Sat, 10 Mar 2001, Hollenbeck, Scott wrote:
>
>
>>  OK, I see your point.  In an earlier message you suggested some requirements
>>  for handles; let me try to capture those thoughts (and some mentioned by
>>  others) more precisely:
>>
>>  1. Every object MUST have an associated handle.
>
>Domain Name objects DO NOT need handles, as the FQDN uniquely identifies
>the object.

We need handles on _every_ object, and maybe the handle on domain 
name objects (which is a very small part of all objects we talk 
about) have the same syntax as the FQDN. But I see talking about some 
object classes not having handles is not a good thing.

Think about AS-numbers, IP-address blocks (for IPv4 and IPv6), E.164 
numbers (for ENUM-like services) etc. And _then_ all different kind 
of admin, acl objects that are needed for the actual databases.

   paf

Date: Sun, 11 Mar 2001 10:22:39 +0100
To: "Christopher Ambler" <[email-masked]>, <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Unique handle generation
Sender: [email-masked]

At 15.55 -0800 01-03-10, Christopher Ambler wrote:
>Same with name servers, then, if you mandate that there is one object
>per IP address?

No. With this model you are redefining the DNS.

A domain name object is refering to a nameserver object, and that 
nameserver object have an IP-address as an attribute. If the 
IP-address change of that nameserver (different operation from 
nameserver for the domain changes) the reference in the domain name 
object is not to be changed.

    paf

Date: Sat, 10 Mar 2001 18:46:28 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: <[email-masked]>
Subject: RE: Unique handle generation
Sender: [email-masked]

ok, I stand corrected. Handles would be a good thing for all objects.

-rick

On Sat, 10 Mar 2001, Hollenbeck, Scott wrote:

> > -----Original Message-----
> > From: Rick H Wesson [mailto:[email-masked]]
> > Sent: Saturday, March 10, 2001 6:48 PM
> > To: Hollenbeck, Scott
> > Cc: [email-masked]
> > Subject: RE: Unique handle generation
> >
> > Scott,
> >
> > On Sat, 10 Mar 2001, Hollenbeck, Scott wrote:
> [snip]
> > >
> > > 1. Every object MUST have an associated handle.
> >
> > Domain Name objects DO NOT need handles, as the FQDN uniquely
> > identifies
> > the object.
>
> True, but the FQDN doesn't identify the registry/repository without a layer
> of indirection (you have to know or figure out that .com is in the VeriSign
> registry, for example).  Some of the comments in this thread have suggested
> that this was one of the reasons that a handle should be required for all
> objects.
>
> <Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Sat, 10 Mar 2001 20:18:44 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Saturday, March 10, 2001 6:48 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: RE: Unique handle generation
>
> Scott,
> 
> On Sat, 10 Mar 2001, Hollenbeck, Scott wrote:
[snip]
> >
> > 1. Every object MUST have an associated handle.
> 
> Domain Name objects DO NOT need handles, as the FQDN uniquely 
> identifies
> the object.

True, but the FQDN doesn't identify the registry/repository without a layer
of indirection (you have to know or figure out that .com is in the VeriSign
registry, for example).  Some of the comments in this thread have suggested
that this was one of the reasons that a handle should be required for all
objects.

<Scott/>

Date: Sat, 10 Mar 2001 16:14:55 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Christopher Ambler <[email-masked]>
cc: <[email-masked]>
Subject: Re: Unique handle generation
Sender: [email-masked]

Chris,

I don't think we can make that decision as it is up to the registry to
implement the plicy that a 1 to 1 relation ship exists between IPv4
addresses and name servers.

-rick

On Sat, 10 Mar 2001, Christopher Ambler wrote:

> Same with name servers, then, if you mandate that there is one object
> per IP address?
>
> Christopher
>
> ----- Original Message -----
> From: "Rick H Wesson" <[email-masked]>
> To: "Hollenbeck, Scott" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, March 10, 2001 3:48 PM
> Subject: RE: Unique handle generation
>
>
> >
> > Scott,
> >
> > On Sat, 10 Mar 2001, Hollenbeck, Scott wrote:
> >
> >
> > > OK, I see your point.  In an earlier message you suggested some requirements
> > > for handles; let me try to capture those thoughts (and some mentioned by
> > > others) more precisely:
> > >
> > > 1. Every object MUST have an associated handle.
> >
> > Domain Name objects DO NOT need handles, as the FQDN uniquely identifies
> > the object.
> >
> >
> > -rick
> >
> >
> >
>

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>
Subject: Re: Unique handle generation
Date: Sat, 10 Mar 2001 15:55:52 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

Same with name servers, then, if you mandate that there is one object
per IP address?

Christopher

----- Original Message ----- 
From: "Rick H Wesson" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, March 10, 2001 3:48 PM
Subject: RE: Unique handle generation

> 
> Scott,
> 
> On Sat, 10 Mar 2001, Hollenbeck, Scott wrote:
> 
> 
> > OK, I see your point.  In an earlier message you suggested some requirements
> > for handles; let me try to capture those thoughts (and some mentioned by
> > others) more precisely:
> >
> > 1. Every object MUST have an associated handle.
> 
> Domain Name objects DO NOT need handles, as the FQDN uniquely identifies
> the object.
> 
> 
> -rick
> 
> 
> 

Date: Sat, 10 Mar 2001 15:48:07 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: <[email-masked]>
Subject: RE: Unique handle generation
Sender: [email-masked]

Scott,

On Sat, 10 Mar 2001, Hollenbeck, Scott wrote:

> OK, I see your point.  In an earlier message you suggested some requirements
> for handles; let me try to capture those thoughts (and some mentioned by
> others) more precisely:
>
> 1. Every object MUST have an associated handle.

Domain Name objects DO NOT need handles, as the FQDN uniquely identifies
the object.

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Sat, 10 Mar 2001 09:03:41 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Saturday, March 10, 2001 2:13 AM
> To: Hollenbeck, Scott; [email-masked]
> Subject: RE: Unique handle generation
> 
> 
> At 19.49 -0500 01-03-09, Hollenbeck, Scott wrote:
> >The requirements draft currently states that every object 
> must be associated
> >with a unique identifier, but it doesn't specifically define 
> the format of
> >the identifier(s).  It's that "what the protocol should do" 
> (in scope) vs.
> >the "how the protocol should do it" (out of scope) thing again.
> 
> What do you mean by unique? Locally in the registrar? In the 
> Registry? In the world? Should the handle change when an object is 
> moved between registrars? Should the handle be able to not only 
> identify the object but also where the object is?
> 
> I.e. a bit more specific requirements would help. It is the lack of 
> answers to these questions the discussion on the syntax is so hard.

OK, I see your point.  In an earlier message you suggested some requirements
for handles; let me try to capture those thoughts (and some mentioned by
others) more precisely:

1. Every object MUST have an associated handle.

2. An object handle MUST be globally unique.

3. An object's handle MUST NOT change during the lifetime of an object, even
if administrative control of the object changes over time.

4. An object handle MUST contain information that unambiguously identifies
both the object and the object's administrative repository.

5. Handle format SHOULD be easily parsed by humans.

Does anyone object to having these added to the requirements draft?

<Scott/>

Date: Sat, 10 Mar 2001 08:13:27 +0100
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Sender: [email-masked]

At 19.49 -0500 01-03-09, Hollenbeck, Scott wrote:
>The requirements draft currently states that every object must be associated
>with a unique identifier, but it doesn't specifically define the format of
>the identifier(s).  It's that "what the protocol should do" (in scope) vs.
>the "how the protocol should do it" (out of scope) thing again.

What do you mean by unique? Locally in the registrar? In the 
Registry? In the world? Should the handle change when an object is 
moved between registrars? Should the handle be able to not only 
identify the object but also where the object is?

I.e. a bit more specific requirements would help. It is the lack of 
answers to these questions the discussion on the syntax is so hard.

   paf

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Fri, 9 Mar 2001 19:49:14 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Friday, March 09, 2001 1:34 PM
> To: Hollenbeck, Scott; [email-masked]
> Subject: RE: Unique handle generation
> 
> 
> At 12.02 -0500 01-03-09, Hollenbeck, Scott wrote:
> >This might really be worth exploring.  We'd have to come up 
> with the tree,
> >but we may be further along in developing resolution tools.
> 
> A suggestion for this wg:
> 
> See that you have some basic requirements on Handles in the 
> requirements document which is I belive what you are working on now.

The requirements draft currently states that every object must be associated
with a unique identifier, but it doesn't specifically define the format of
the identifier(s).  It's that "what the protocol should do" (in scope) vs.
the "how the protocol should do it" (out of scope) thing again.

<Scott/>

Date: Wed, 7 Mar 2001 09:50:04 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: <[email-masked]>
Subject: missing posts
Sender: [email-masked]

Hi,

Sorry, this is really a test post... George Belotsky and I were cc-ing our
mailing list discussion to the provreg list but I only see his side posted
(which I'm sure makes him look weird ;->).

I just want to see if the list is ignoring my posts so I can do something
about it.

Regards,
Sheer

Date: Fri, 9 Mar 2001 19:33:44 +0100
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Sender: [email-masked]

At 12.02 -0500 01-03-09, Hollenbeck, Scott wrote:
>This might really be worth exploring.  We'd have to come up with the tree,
>but we may be further along in developing resolution tools.

A suggestion for this wg:

See that you have some basic requirements on Handles in the 
requirements document which is I belive what you are working on now.

I promise to summarize with a few proposals later on, when I have 
syncronized with the whois discussions which I have with some RIR's.

    paf

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Fri, 9 Mar 2001 12:02:45 -0500 
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Friday, March 09, 2001 8:48 AM
>To: Rick H Wesson
>Cc: Patrik Fältström; Bill Manning; Brian W. Spolarich; George 
>Belotsky;
>Hollenbeck Scott; [email-masked]
>Subject: Re: Unique handle generation

>Not quite serios (but a bit): Lets take URNs!
>
>e.g.
>     urn:provreg-guid:ripe:ct:wm:4711
>     |____________________|
>
>defining only the marked part of urn in the specs. And since 
>there are drafts
>on the way for the resolution of URNs (some from NSI also), 
>this might open
>some new opportunities.

This might really be worth exploring.  We'd have to come up with the tree,
but we may be further along in developing resolution tools.

<Scott/>

Date: Fri, 9 Mar 2001 17:53:22 +0100
To: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Sender: [email-masked]

At 11.30 -0500 01-03-09, Hollenbeck, Scott wrote:
>Patrik and Mark Kosters have/had a whois-related draft that describes
>registry identifier maintenance, but I can't seem to find it in the
>individual submission archives at the moment.

I missed the deadline...

The draft talks about "what goes on port 43", i.e. the whois protocol.

It tries to resolv the following issues:

   - Introduction of syntax for referals
   - Introduction of charset specification
   - Specification of handle format
   - Introduction of registry identifier (1/2 of the global handle for an
     object) at IANA
   - Points at RFC 2622 for proposed syntax for output, and how to
     give information to client about syntax

Nothing more, nothing less.

Some of the above might be removed.

If you are interested in talking more about this. Find me in Minneapolis!

When the I-D is out there, then we can start discussing this "what 
goes on port 43".

Note that the goal is not at all to solve all needs for a real 
directory services protocol which the last whois bof turned into. 
I.e. when I accepted the last whois bof, I thought personally that it 
would be about fixing bugs in what goes on port 43, but people seem 
to be more interested in a "Whois service for domain name databases" 
-- which is a very much different problem.

      paf

Date: Fri,  9 Mar 2001 16:52:59 +0000 (GMT)
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: RE: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Scott" == Hollenbeck, Scott <[email-masked]> writes:

    >> -----Original Message----- From: Martin Oldfield
    >> [mailto:[email-masked]] Sent: Friday, March 09, 2001 11:33 AM To:
    >> Hollenbeck, Scott Cc: [email-masked] Subject: RE: Unique
    >> handle generation

    Scott> [snip]

    >> For example, suppose you supplied the hint `Hollenbeck' to a
    >> registry which wanted local-parts to be lower-case, 12
    >> characters long and to have a certain checksum: it would be
    >> simple for the registry to return a local-part of
    >> `hollenbeck34'.

    Scott> I'd be OK with that as well.  It would be nice if the
    Scott> person whose identity is tied to the handle has some
    Scott> influence on the local part.

Presumably though this would have to be through the registrar.

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Fri, 9 Mar 2001 11:37:26 -0500 
Sender: [email-masked]

>-----Original Message-----
>From: Martin Oldfield [mailto:[email-masked]]
>Sent: Friday, March 09, 2001 11:33 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>Subject: RE: Unique handle generation

[snip]

>For example, suppose you supplied the hint `Hollenbeck' to a registry
>which wanted local-parts to be lower-case, 12 characters long and to
>have a certain checksum: it would be simple for the registry to return
>a local-part of `hollenbeck34'.

I'd be OK with that as well.  It would be nice if the person whose identity
is tied to the handle has some influence on the local part.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Fri, 9 Mar 2001 11:30:11 -0500 
Sender: [email-masked]

>-----Original Message-----
>From: Brian W. Spolarich [mailto:[email-masked]]
>Sent: Friday, March 09, 2001 11:29 AM
>To: Hollenbeck, Scott; [email-masked]
>Subject: RE: Unique handle generation
>
>
>| Handles should be returned when an object is created, and 
>they should be
>| added to the list of attributes associated with an object.  
>Handles should
>| be formed with both a registry-unique local part and a 
>globally-unique
>| registry identifier.  Local part format should be determined 
>by registry
>| policy since these local parts must be registry-unique.  Registry
>| identifiers will be assigned and maintained by IANA.  
>Handles must not be
>| reused within a registry.
>|
>| Sound reasonable?
>
>  Who defines the content in the global space?  Is this left 
>up to IANA to
>decide how to name things or will the specification provide detail?

Patrik and Mark Kosters have/had a whois-related draft that describes
registry identifier maintenance, but I can't seem to find it in the
individual submission archives at the moment.  Some text will probably be
needed in the IANA Considerations section to note that a registry must
request assignment of an identifier from IANA in accordance with some TBD
policy that needs to be documented in a draft.

<Scott/>

Date: Fri,  9 Mar 2001 16:32:49 +0000 (GMT)
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: RE: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Scott" == Hollenbeck`, Scott <[email-masked]> writes:

--> snip <--

    >>
    >> 1. Registry generates it, and sends it the registrar.
    >>
    >> 2. Registry generates it but tries to accomodate an optional
    >>    hint
    >> supplied by the registrar.
    >>
    >> 3. Registrar generates it, and submits it to the registry. If
    >>    the
    >> local-part isn't unique then the registry just refuses, and the
    >> registrar tries again.
    >>
    >> Roughly there's a progression here from registry- to registrar-
    >> generated handles: where's the optimum ?
    >>
    >> (2) is a special case of (1) because (2) places no requirement
    >>     on the
    >> registry to accomodate the hint; (3) seems slightly dangerous
    >> becuase in the general case it might be hard for the registrar
    >> to see why his handle isn't valid and so pick one which did
    >> work.
    >>
    >> Comments ?

    Scott> Personally I like (3).  We already have a "does it exist"
    Scott> query mechanism defined in the <ping> command, so a
    Scott> registrar can check multiple values before trying to create
    Scott> anything.  If they try to create one that already exists,
    Scott> an error code will identify the "not unique" problem quite
    Scott> definitively.  This will allow a person to have some
    Scott> control over the local part, which may help facilitate use.

I quite agree that it's good for the registrar to be able to influence 
the local-part, which was the idea behind (2).

I'm not sure that just being able to see if a handle is taken is
enough though. Suppose the registry requires that the handles have
some sort of internal consistency checksum, then it's not enough to
know that a local-part is free: rather one needs to know if the
local-part is free and valid. Blind guessing might take a while to hit
on a suitable value, and it seems messy for every registrar to have to
embed the algorithm in their code.

By contrast the registry is well-placed to generate a local-part which
both conforms to its own criteria of validity, and which pertains to
the registrar supplied hint.

For example, suppose you supplied the hint `Hollenbeck' to a registry
which wanted local-parts to be lower-case, 12 characters long and to
have a certain checksum: it would be simple for the registry to return
a local-part of `hollenbeck34'. 

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

From: "Brian W. Spolarich" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: RE: Unique handle generation
Date: Fri, 9 Mar 2001 11:28:56 -0500
Importance: Normal
Sender: [email-masked]

| Handles should be returned when an object is created, and they should be
| added to the list of attributes associated with an object.  Handles should
| be formed with both a registry-unique local part and a globally-unique
| registry identifier.  Local part format should be determined by registry
| policy since these local parts must be registry-unique.  Registry
| identifiers will be assigned and maintained by IANA.  Handles must not be
| reused within a registry.
|
| Sound reasonable?

  Who defines the content in the global space?  Is this left up to IANA to
decide how to name things or will the specification provide detail?

  -bws

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Unique handle generation
Date: Fri, 9 Mar 2001 11:22:20 -0500 
Sender: [email-masked]

>-----Original Message-----
>From: George Belotsky [mailto:[email-masked]]
>Sent: Friday, March 09, 2001 11:07 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>Subject: Re: Unique handle generation
>
>
>A UUID-style approach is less burdensome than having IANA assign and
>maintain handles.

I didn't suggest that IANA maintain handles.  I echoed what Patrik first
suggested WRT IANA maintenance of registry identifiers.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Fri, 9 Mar 2001 11:03:35 -0500 
Sender: [email-masked]

>-----Original Message-----
>From: Martin Oldfield [mailto:[email-masked]]
>Sent: Friday, March 09, 2001 11:02 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>Subject: RE: Unique handle generation
>
>
>>>>>> "Scott" == Hollenbeck, Scott <[email-masked]> writes:
>
>--> snip <--
>
>    Scott> Here's an idea for how handles can be used in the protocol:
>
[snip]
>
>Sounds good to me. That leaves the question of who generates the local 
>part: I can see three models, but I'm sure there are more:
>
>1. Registry generates it, and sends it the registrar.
>
>2. Registry generates it but tries to accomodate an optional hint
>   supplied by the registrar.
>
>3. Registrar generates it, and submits it to the registry. If the
>   local-part isn't unique then the registry just refuses, and the
>   registrar tries again.
>
>Roughly there's a progression here from registry- to registrar-
>generated handles: where's the optimum ?
>
>(2) is a special case of (1) because (2) places no requirement on the
>registry to accomodate the hint; (3) seems slightly dangerous becuase
>in the general case it might be hard for the registrar to see why his
>handle isn't valid and so pick one which did work.
>
>Comments ?

Personally I like (3).  We already have a "does it exist" query mechanism
defined in the <ping> command, so a registrar can check multiple values
before trying to create anything.  If they try to create one that already
exists, an error code will identify the "not unique" problem quite
definitively.  This will allow a person to have some control over the local
part, which may help facilitate use.

Date: Fri, 9 Mar 2001 11:06:38 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

A UUID-style approach is less burdensome than having IANA assign and
maintain handles.

If some sort of centralized repository is required, maybe we should
consider having registries operate authoritative DNS servers for the
handle space.

George.

On Fri, Mar 09, 2001 at 07:47:33AM -0500, Hollenbeck, Scott wrote:
> I think so -- there's certainly no method in place at this time for
> inter-registry data sharing, but that doesn't mean that there might not be
> one in the future.
> 
> This does get back to the question of just what the handle should look like
> and how it should be used in the protocol.  Given the alternatives I think
> Patrik's proposal is simple, effective, and usable.
> 
> Here's an idea for how handles can be used in the protocol:
> 
> Handles should be returned when an object is created, and they should be
> added to the list of attributes associated with an object.  Handles should
> be formed with both a registry-unique local part and a globally-unique
> registry identifier.  Local part format should be determined by registry
> policy since these local parts must be registry-unique.  Registry
> identifiers will be assigned and maintained by IANA.  Handles must not be
> reused within a registry.
> 
> Sound reasonable?
> 
> <Scott/>
> 
> -----Original Message-----
> From: Martin Oldfield [mailto:[email-masked]]
> 
> [snip]
> 
> Is it right to say that on a technical level we can merely facilitate
> things by giving every object in every registry a globally unique
> handle ?

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Fri,  9 Mar 2001 16:01:38 +0000 (GMT)
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: RE: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Scott" == Hollenbeck, Scott <[email-masked]> writes:

--> snip <--

    Scott> Here's an idea for how handles can be used in the protocol:

    Scott> Handles should be returned when an object is created, and
    Scott> they should be added to the list of attributes associated
    Scott> with an object.  Handles should be formed with both a
    Scott> registry-unique local part and a globally-unique registry
    Scott> identifier.  Local part format should be determined by
    Scott> registry policy since these local parts must be
    Scott> registry-unique.  Registry identifiers will be assigned and
    Scott> maintained by IANA.  Handles must not be reused within a
    Scott> registry.

    Scott> Sound reasonable?

Sounds good to me. That leaves the question of who generates the local 
part: I can see three models, but I'm sure there are more:

1. Registry generates it, and sends it the registrar.

2. Registry generates it but tries to accomodate an optional hint
   supplied by the registrar.

3. Registrar generates it, and submits it to the registry. If the
   local-part isn't unique then the registry just refuses, and the
   registrar tries again.

Roughly there's a progression here from registry- to registrar-
generated handles: where's the optimum ?

(2) is a special case of (1) because (2) places no requirement on the
registry to accomodate the hint; (3) seems slightly dangerous becuase
in the general case it might be hard for the registrar to see why his
handle isn't valid and so pick one which did work.

Comments ?

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Fri, 09 Mar 2001 14:48:03 +0100
From: Klaus Malorny <[email-masked]>
To: Rick H Wesson <[email-masked]>
CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, Bill Manning  <[email-masked]>, "Brian W. Spolarich" <[email-masked]>, George  Belotsky <[email-masked]>, Hollenbeck Scott  <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Rick H Wesson wrote:
> 
> all:
> 
> On Thu, 8 Mar 2001, Patrik Fältström wrote:
> 
> > At 11.00 -0800 01-03-08, Bill Manning wrote:
> > >     How will "handles" support non-ASCII character representations?
> >
> > Rathole!
> >
> > >     Endgame... I think I should be able to select the "seed" be which
> > >     my Internet-wide, unique handle is created. My seed is used to
> > >     generate a unique handle that has at least two other, non-Internet
> > >     related "salts".  So my handle might be:
> > >
> > >             WM-9387-19790922:09:27:33
> >
> > Ok, that solves the uniqueness.
> >
> 
> let me say one thing, the handle WM-9387-19790922:09:27:33  SUCKS!
> The uniqueness SHOULD NOT be obtained by appending a date/timestamp.
> Furthermore the handle MAY contain a Registry Identifer and the handle
> SHOULD contain information that describes what kind of object it points
> to.
> 
> For instance WM9387-CT:RIPE
>   WM - bills initials
>   9387 incrementor
>   CT differientiates this hadle as a contact object
>   RIPE The optional suffex (pick your seporator [%#@:]) of the Registry of
>        Record for the Object.
> 
> -rick

Not quite serios (but a bit): Lets take URNs!

e.g.
     urn:provreg-guid:ripe:ct:wm:4711
     |____________________|

defining only the marked part of urn in the specs. And since there are drafts
on the way for the resolution of URNs (some from NSI also), this might open
some new opportunities.

regards
Klaus Malorny

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Unique handle generation
Date: Fri, 9 Mar 2001 07:47:33 -0500 
Sender: [email-masked]

I think so -- there's certainly no method in place at this time for
inter-registry data sharing, but that doesn't mean that there might not be
one in the future.

This does get back to the question of just what the handle should look like
and how it should be used in the protocol.  Given the alternatives I think
Patrik's proposal is simple, effective, and usable.

Here's an idea for how handles can be used in the protocol:

Handles should be returned when an object is created, and they should be
added to the list of attributes associated with an object.  Handles should
be formed with both a registry-unique local part and a globally-unique
registry identifier.  Local part format should be determined by registry
policy since these local parts must be registry-unique.  Registry
identifiers will be assigned and maintained by IANA.  Handles must not be
reused within a registry.

Sound reasonable?

<Scott/>

-----Original Message-----
From: Martin Oldfield [mailto:[email-masked]]

[snip]

Is it right to say that on a technical level we can merely facilitate
things by giving every object in every registry a globally unique
handle ?

Date: Fri,  9 Mar 2001 12:24:25 +0000 (GMT)
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Cc: Bill Manning <[email-masked]>, [email-masked] (Brian W. Spolarich), [email-masked] (George Belotsky), [email-masked] (Hollenbeck Scott), [email-masked]
Subject: Re: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "paf" == paf  <Patrik> writes:

--> snip <--

    paf> Let's say that this record is stored in whois server at the
    paf> RIR "A" when you get your first IP-addresses. Now, you go to
    paf> registrar "B" of TLD-registry "C" and register a domain,
    paf> should you not be able to have your handle at "A" as pointer
    paf> to the technical contact for your domain? I rather see that
    paf> than having one person object for you at A, and one at C (or
    paf> even, one at A, one at B and one at D which might be a
    paf> different registry -- paralell with B -- of C).

Are there concerns here about the integrity of the information stored
in a foreign registry ?

For example, suppose registry C charges the registrant, and the
registrant has told registry C that his contact details are record
foobar69 in registry A. Should registry B be obliged to trust registry
A's data ?

I suppose this isn't really a technical issue at all: different
registries might very well adopt different policies towards trusting
foreign data, and the choice of policy is most likely to be based on
legal or commercial argument.

Is it right to say that on a technical level we can merely facilitate
things by giving every object in every registry a globally unique
handle ? 

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Rick H Wesson)
Date: Thu, 8 Mar 2001 16:45:17 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked] (Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=), [email-masked] (Brian W. Spolarich), [email-masked] (George Belotsky), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

% > 	How are Registry Identifiers different from the handles
% > 	we have been tossing about?  I expect that handle concatination
% > 	between objects may be useful to narrow scope in -limited-
% > 	circumstances, the general rule should be to only expose the
% > 	handle.  None of <MY> handles is going to have, as part of
% > 	<MY> handle, a conncationation that describes some association.
% > 	Their handles might... :)
% 
% Bill,
% 
% the utility come from the ability to locate the object through a yet to be
% detemined protocol.
% 
% -rick

	I didn't say they were not useful. I am saying that my handle is
	useful in and of itself w/o being tied to another handle that
	describes a registry. (Noting that at the time I receive a
	delegation, I become my own registry... :)

-- 
--bill

Date: Thu, 8 Mar 2001 16:15:09 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Bill Manning <[email-masked]>
cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, "Brian W. Spolarich" <[email-masked]>, George Belotsky <[email-masked]>, Hollenbeck Scott <[email-masked]>, <[email-masked]>
Subject: Re: Unique handle generation
Sender: [email-masked]

> 	How are Registry Identifiers different from the handles
> 	we have been tossing about?  I expect that handle concatination
> 	between objects may be useful to narrow scope in -limited-
> 	circumstances, the general rule should be to only expose the
> 	handle.  None of <MY> handles is going to have, as part of
> 	<MY> handle, a conncationation that describes some association.
> 	Their handles might... :)

Bill,

the utility come from the ability to locate the object through a yet to be
detemined protocol.

-rick

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Rick H Wesson)
Date: Thu, 8 Mar 2001 16:07:03 -0800 (PST)
Cc: [email-masked] (Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=), [email-masked] (Bill Manning), [email-masked] (Brian W. Spolarich), [email-masked] (George Belotsky), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

% let me say one thing, the handle WM-9387-19790922:09:27:33  SUCKS!

	Tell me how you really feel... :)
	It was an example. 

% The uniqueness SHOULD NOT be obtained by appending a date/timestamp.

	Perhaps. Thats one way to increment.  I think there should be
	two distinct salts for each seed. You have selected an abstract
	thing called Object Identifier e.g. CT... again YMMV.

% Furthermore the handle MAY contain a Registry Identifer and the handle
% SHOULD contain information that describes what kind of object it points
% to.
% 
% For instance WM9387-CT:RIPE
%   WM - bills initials
%   9387 incrementor
%   CT differientiates this hadle as a contact object
%   RIPE The optional suffex (pick your seporator [%#@:]) of the Registry of
%        Record for the Object.
% 
% -rick

	How are Registry Identifiers different from the handles 
	we have been tossing about?  I expect that handle concatination
	between objects may be useful to narrow scope in -limited-
	circumstances, the general rule should be to only expose the
	handle.  None of <MY> handles is going to have, as part of
	<MY> handle, a conncationation that describes some association.
	Their handles might... :)

-- 
--bill

Date: Thu, 8 Mar 2001 15:42:41 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
cc: Bill Manning <[email-masked]>, "Brian W. Spolarich" <[email-masked]>, George Belotsky <[email-masked]>, Hollenbeck Scott <[email-masked]>, <[email-masked]>
Subject: Re: Unique handle generation
Sender: [email-masked]

all:

On Thu, 8 Mar 2001, Patrik Fältström wrote:

> At 11.00 -0800 01-03-08, Bill Manning wrote:
> >	How will "handles" support non-ASCII character representations?
>
> Rathole!
>
> >	Endgame... I think I should be able to select the "seed" be which
> >	my Internet-wide, unique handle is created. My seed is used to
> >	generate a unique handle that has at least two other, non-Internet
> >	related "salts".  So my handle might be:
> >
> >		WM-9387-19790922:09:27:33
>
> Ok, that solves the uniqueness.
>

let me say one thing, the handle WM-9387-19790922:09:27:33  SUCKS!
The uniqueness SHOULD NOT be obtained by appending a date/timestamp.
Furthermore the handle MAY contain a Registry Identifer and the handle
SHOULD contain information that describes what kind of object it points
to.

For instance WM9387-CT:RIPE
  WM - bills initials
  9387 incrementor
  CT differientiates this hadle as a contact object
  RIPE The optional suffex (pick your seporator [%#@:]) of the Registry of
       Record for the Object.

-rick

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (George Belotsky)
Date: Thu, 8 Mar 2001 12:18:05 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked] (Brian W. Spolarich), [email-masked] (Patrik Faltstrom), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

% 
% With something like 'WM-9387-19790922:09:27:33' we are back
% to handles that are hard to remember.

	Well, hard for whom?  Only I have to remember it.

--bill

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=)
Date: Thu, 8 Mar 2001 12:16:37 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked] (Brian W. Spolarich), [email-masked] (George Belotsky), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

% 
% At 11.00 -0800 01-03-08, Bill Manning wrote:
% >	How will "handles" support non-ASCII character representations?
% 
% Rathole!

	Tah. Told you it was a curve ball... :)

% >	Endgame... I think I should be able to select the "seed" be which
% >	my Internet-wide, unique handle is created. My seed is used to
% >	generate a unique handle that has at least two other, non-Internet
% >	related "salts".  So my handle might be:
% >
% >		WM-9387-19790922:09:27:33
% 
% Ok, that solves the uniqueness.
% 
% A related question:
% 
% Let's say that this record is stored in whois server at the RIR "A" 
% when you get your first IP-addresses. Now, you go to registrar "B" of 
% TLD-registry "C" and register a domain, should you not be able to 
% have your handle at "A" as pointer to the technical contact for your 
% domain? I rather see that than having one person object for you at A, 
% and one at C (or even, one at A, one at B and one at D which might be 
% a different registry -- paralell with B -- of C).
% 
%     paf

	Again, going to the corporation analogy, I get an 
	employee number. As I am assigned to various operating
	groups and divisions, the "composite" identifer is 
	built as the group+eid, e.g.  my eid is #9387 and
	I am assigned to two operating groups, div7 and
	group33. Inside the group, I am 33-9387 and in the
	division, I am 7-9387.  All it really takes to find
	me is the eid.

	So, the record stored in RIR'A' will be the composite
	of my eid and the RIRid.  When I go to 'B' or 'C',
	I would -NOT- use the composite built from 'A', I'd 
	use the "core" eid.

-- 
--bill

Date: Thu, 8 Mar 2001 20:59:13 +0100
To: George Belotsky <[email-masked]>, Bill Manning <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Unique handle generation
Cc: "Brian W. Spolarich" <[email-masked]>, Hollenbeck Scott <[email-masked]>, [email-masked]
Sender: [email-masked]

At 14.44 -0500 01-03-08, George Belotsky wrote:
>           (i)   Handles should be easy to remember/readable;
>           (ii)  Handles should identify objects uniquely;
>           (iii) It's probably a bad idea for the handles to change.
>
>Does everyone agree with the above list?

I would add (iv) It's not bad if the Handle can be used for finding 
the record. This so one can have only one person record somewhere, 
and reference that from all other objects I "own", instead of being 
forced to create one person record per registry (or even registrar).

    paf

Date: Thu, 8 Mar 2001 14:44:33 -0500
From: George Belotsky <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: "Brian W. Spolarich" <[email-masked]>, Patrik Faltstrom <[email-masked]>, Hollenbeck Scott <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

With something like 'WM-9387-19790922:09:27:33' we are back
to handles that are hard to remember.

In previous posts, complaints were raised about this issue.

If readability is not a problem, existing UUID algorithms will ensure
uniqueness.

>From previous discussion, I have identified three properties of handles
that people seemed to find desireable (listed again below).

          (i)   Handles should be easy to remember/readable;
          (ii)  Handles should identify objects uniquely;
          (iii) It's probably a bad idea for the handles to change.

Does everyone agree with the above list?

George.

On Thu, Mar 08, 2001 at 11:00:13AM -0800, Bill Manning wrote:
> % 
> % > 	I like the idea of a timestamp, but I don't want to remember it
> % > 	as part of my handle.
> % 
> %   Hi.  I'm "Brian W. Spolarich-RIPE-984076683".
> % 
> %   Ick. :-)
> % 
> %   -bws
> 
> 
> 	Well...  the American Registry for Internet Numbers got ARIN.
> 	Does that mean the Argentian Registry for Internet Numbers gets ARIN2 ?
> 
> 	Under the new RIR structure, I am assigned WM110-<rir-handle>
> 	Under the old, single IR structure, I was assigned WM110.
> 	Under the earlier IR structure, I was assigned WMAN
> 
> 	A couple of problems. 
> 	There is a problem with internal vs external tagging. e.g.
> 	the registrar should not expose their internal tagging of client
> 	handles.
> 	Then there is the debate on dealing w/ duplicates. The approch
> 	currently in use is to assign a monotonically increasing number
> 	to initals.  Patrik has refined this to using a timestamp.
> 	(warning... curveball ahead...:)
> 	And then there is the use of initals.  Not everyone uses ASCII.
> 	How will "handles" support non-ASCII character representations?
> 
> 	Endgame... I think I should be able to select the "seed" be which
> 	my Internet-wide, unique handle is created. My seed is used to
> 	generate a unique handle that has at least two other, non-Internet
> 	related "salts".  So my handle might be:
> 
> 		WM-9387-19790922:09:27:33
> 
> 		My initals, the last four characters of my national
> 	registration card, and the date/time stamp I first logged ito
> 	an IP-supporting node.
> 
> 	ARINs could be:
> 
> 		ARIN-8866-19970110
> 
> 		Their initals, the last four characters of their TaxID,
> 	and the date of first operation.
> 
> YMMV... 
> 
> 	
> -- 
> --bill

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Thu, 8 Mar 2001 14:32:25 -0500
From: George Belotsky <[email-masked]>
To: Bill Manning <[email-masked]>
Cc: "Brian W. Spolarich" <[email-masked]>, Patrik Fdltstrvm <[email-masked]>, Hollenbeck Scott <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

An FQDN is just what you are trying to register (e.g. 'myname.ca').

The other items are there to ensure uniqueness.  It is irrelevant
if a registrar goes out of business -- unless someone takes their
exact identifier.

The timestamp could be supplied in the whois information, so
you would not have to remember it.

George.

On Thu, Mar 08, 2001 at 10:27:31AM -0800, Bill Manning wrote:
> % 
> % Brian:
> % 
> % For entities, it would be possible to take a similar approach.
> % 
> % For example, a domain name might be: <fqdn>+<creating registrar>+<timestamp>
> 
> 	self-referal.  where/how is an FQDN created?... :)
> 	for that matter, the "creating registrar" itself has a "handle"
> 	and, as folks have pointed out, registrars themselves are ephemeral.
> 	We've had three die in the last ~20 years....  Postel, SRI, NSI...
> 	(ok, NIS actually morphed into something else)  who is to say
> 	that RIPE/APNIC/ARIN or any of the other registries will be existant?
> 	
> 	I like the idea of a timestamp, but I don't want to remember it
> 	as part of my handle.
> 
> --bill

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Thu, 8 Mar 2001 20:32:05 +0100
To: Bill Manning <[email-masked]>, [email-masked] (Brian W. Spolarich)
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Unique handle generation
Cc: [email-masked] (Bill Manning), [email-masked] (George Belotsky), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

At 11.00 -0800 01-03-08, Bill Manning wrote:
>	How will "handles" support non-ASCII character representations?

Rathole!

>	Endgame... I think I should be able to select the "seed" be which
>	my Internet-wide, unique handle is created. My seed is used to
>	generate a unique handle that has at least two other, non-Internet
>	related "salts".  So my handle might be:
>
>		WM-9387-19790922:09:27:33

Ok, that solves the uniqueness.

A related question:

Let's say that this record is stored in whois server at the RIR "A" 
when you get your first IP-addresses. Now, you go to registrar "B" of 
TLD-registry "C" and register a domain, should you not be able to 
have your handle at "A" as pointer to the technical contact for your 
domain? I rather see that than having one person object for you at A, 
and one at C (or even, one at A, one at B and one at D which might be 
a different registry -- paralell with B -- of C).

    paf

Date: Mon, 5 Mar 2001 12:34:11 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: George Belotsky <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Transport Team Mailing List.
Sender: [email-masked]

I've gone ahead and created a transport list:

list:           transport-provreg-list
post:           [email-masked]
admin:          [email-masked]
subscribe:      [email-masked]

I'm currently subscribed but I'll unsubscribe once I see everything up and
running.  I'll moderate subscriptions (_not_ posts) until I hear otherwise
from Edward, Joap, or the transport design team in general (basically
I'll allow _only_ members of the design team to subscibe).

I propose sending a weekly digest to the general provreg list, but I'll
wait on a more general response before doing so.

I'm willing to do the same thing for the security and the protocol list,
but am worried that further unilateral action will get me in trouble.

George, Chris, Peter please send subscription emails and I'll push them
through.

If anyone is interested these lists feature archive retreival and some
other neat features ... consult http://www.ezmlm.org/ezman-0.32/index.html
for more information.

Regards,
Sheer

On Mon, 5 Mar 2001, George Belotsky wrote:

> O.K.  Let's wait until tomorrow to hear any objections from
> the Transport team, and then set the list up.  It would really
> be a useful tool.
>
> George.
>
>
> On Sat, Mar 03, 2001 at 01:03:44PM -0500, Sheer El-Showk wrote:
> > I can set up the list right away but I think subscription
> > (not posting, just subscription) should be moderated.  I have
> > no problem moderating it myself (I can just check against the
> > email address Joap posted) but it would probably be more
> > appropriate for Joap and Edward to moderate the subscriptions.
> >
> > I await a response from one of them, or a general consensus
> > from any design team (since they are supposed to be
> > self-administering) as to how to set up the lists subscriptions.
> >
> > Regards,
> > Sheer
> >
> >
> > On Fri, 2 Mar 2001, George Belotsky wrote:
> >
> > > I would really appreciate that.  Does everyone else on the Transport
> > > Team mind if Sheer sets up our list?
> > >
> > > George.
> > >
> > >
> > > On Fri, Mar 02, 2001 at 07:06:10PM -0500, Sheer El-Showk wrote:
> > > > I'll gladly host mailing lists for any of the groups that need it.  What
> > > > are we looking for in terms of a list -- digests, archiving, all that I
> > > > have, but a web interface would require some setting up (not that I mind,
> > > > but it might just take a little while).  I could set up any regular
> > > > mailing lists as soon there is a consensus.
> > > >
> > > > Please let me know (Joap and Edward could moderate subscription via email
> > > > if they want to, and we could send out a weekly digest to the regular
> > > > list).
> > > >
> > > > Regards,
> > > > Sheer
> > > >
> > > > On Fri, 2 Mar 2001, George Belotsky wrote:
> > > >
> > > > >
> > > > > Is any member of the transport team willing to set up a mailing
> > > > > list for us?  If not, I can see about setting something up here.
> > > > >
> > > > > George.
> > > > >
> > > > >
> > > > > -----------------------------
> > > > > George Belotsky
> > > > > Senior Software Architect
> > > > > Register.com, inc.
> > > > > [email-masked]
> > > > > 212-798-9127 (phone)
> > > > > 212-798-9876 (fax)
> > > > >
> > > >
> > > >
> > >
> > > --
> > > -----------------------------
> > > George Belotsky
> > > Senior Software Architect
> > > Register.com, inc.
> > > [email-masked]
> > > 212-798-9127 (phone)
> > > 212-798-9876 (fax)
> > >
> >
>
> --
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)
>

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Brian W. Spolarich)
Date: Thu, 8 Mar 2001 11:00:13 -0800 (PST)
Cc: [email-masked] (Bill Manning), [email-masked] (George Belotsky), [email-masked] (Patrik Faltstrom), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

% 
% > 	I like the idea of a timestamp, but I don't want to remember it
% > 	as part of my handle.
% 
%   Hi.  I'm "Brian W. Spolarich-RIPE-984076683".
% 
%   Ick. :-)
% 
%   -bws

	Well...  the American Registry for Internet Numbers got ARIN.
	Does that mean the Argentian Registry for Internet Numbers gets ARIN2 ?

	Under the new RIR structure, I am assigned WM110-<rir-handle>
	Under the old, single IR structure, I was assigned WM110.
	Under the earlier IR structure, I was assigned WMAN

	A couple of problems. 
	There is a problem with internal vs external tagging. e.g.
	the registrar should not expose their internal tagging of client
	handles.
	Then there is the debate on dealing w/ duplicates. The approch
	currently in use is to assign a monotonically increasing number
	to initals.  Patrik has refined this to using a timestamp.
	(warning... curveball ahead...:)
	And then there is the use of initals.  Not everyone uses ASCII.
	How will "handles" support non-ASCII character representations?

	Endgame... I think I should be able to select the "seed" be which
	my Internet-wide, unique handle is created. My seed is used to
	generate a unique handle that has at least two other, non-Internet
	related "salts".  So my handle might be:

		WM-9387-19790922:09:27:33

		My initals, the last four characters of my national
	registration card, and the date/time stamp I first logged ito
	an IP-supporting node.

	ARINs could be:

		ARIN-8866-19970110

		Their initals, the last four characters of their TaxID,
	and the date of first operation.

YMMV... 

-- 
--bill

From: "Brian W. Spolarich" <[email-masked]>
To: "Bill Manning" <[email-masked]>, "George Belotsky" <[email-masked]>
Cc: "Patrik Faltstrom" <[email-masked]>, "Hollenbeck Scott" <[email-masked]>, <[email-masked]>
Subject: RE: Unique handle generation
Date: Thu, 8 Mar 2001 13:40:00 -0500
Importance: Normal
Sender: [email-masked]

> 	I like the idea of a timestamp, but I don't want to remember it
> 	as part of my handle.

  Hi.  I'm "Brian W. Spolarich-RIPE-984076683".

  Ick. :-)

  -bws

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (George Belotsky)
Date: Thu, 8 Mar 2001 10:27:31 -0800 (PST)
Cc: [email-masked] (Brian W. Spolarich), [email-masked] (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=), [email-masked] (Hollenbeck Scott), [email-masked]
Sender: [email-masked]

% 
% Brian:
% 
% For entities, it would be possible to take a similar approach.
% 
% For example, a domain name might be: <fqdn>+<creating registrar>+<timestamp>

	self-referal.  where/how is an FQDN created?... :)
	for that matter, the "creating registrar" itself has a "handle"
	and, as folks have pointed out, registrars themselves are ephemeral.
	We've had three die in the last ~20 years....  Postel, SRI, NSI...
	(ok, NIS actually morphed into something else)  who is to say
	that RIPE/APNIC/ARIN or any of the other registries will be existant?
	
	I like the idea of a timestamp, but I don't want to remember it
	as part of my handle.

--bill

Date: Thu, 8 Mar 2001 13:13:27 -0500
From: George Belotsky <[email-masked]>
To: "Brian W. Spolarich" <[email-masked]>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Brian:

For entities, it would be possible to take a similar approach.

For example, a domain name might be: <fqdn>+<creating registrar>+<timestamp>

If a name is transferred, the handle stays the same.  If a name is deleted,
and later someone else registers it, the handle will change (which is
probably a good thing in this case).

George.

On Thu, Mar 08, 2001 at 12:42:40PM -0500, Brian W. Spolarich wrote:
> > One record will point out a person (as an example). A person have a 
> > lifetime of say 120 years. We need to find a handle which can have 
> > the unique identifier for at least 120 years.
> 
>   This is a great discussion, but I find myself asking the question:
> is this our problem to solve at the moment?  Creating globally-unique
> identifiers which will live a very, very long time is a pretty tall
> order.
> 
>   Perhaps we're trying to "boil the ocean" with this?
> 
>   Have any other identifiers (other than government-issued things like
> Social Security Numbers, driver's license numbers, and the like) met
> this requirement?
> 
>   I kind of like the digest-based approach (although perhaps SHA-1
> would be a better choice than MD5).  The user can identify themselves
> via some relatively static information such as complete name, 
> city and country of birth, date of birth, etc. and this results in
> a digest that should be guaranteed to be unique.  The user can
> easily reconstitute this identifier by supplying the source information,
> which they should know fairly well.
> 
>   Its not clear to me however how this scheme would facilitate easy
> referencing of entities, so perhaps that's where this concept falls down.
> 
>   -brian

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Thu, 8 Mar 2001 19:04:59 +0100
To: "Brian W. Spolarich" <[email-masked]>, "George Belotsky" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Cc: <[email-masked]>
Sender: [email-masked]

At 12.42 -0500 01-03-08, Brian W. Spolarich wrote:
>  > One record will point out a person (as an example). A person have a
>>  lifetime of say 120 years. We need to find a handle which can have
>>  the unique identifier for at least 120 years.
>
>   This is a great discussion, but I find myself asking the question:
>is this our problem to solve at the moment?  Creating globally-unique
>identifiers which will live a very, very long time is a pretty tall
>order.
>
>   Perhaps we're trying to "boil the ocean" with this?

Yes and no.

We do have some problems with handles in todays internet:

  + They are not changed after an object is changed
  - They are not globally unique
  - One can not find an object only knowing the handle

The second issue is especially problematic because objects have been 
mirrored between the registries, so the same handle _might_ be the 
same record (but different copies), but can also be refering to two 
different objects in two different registries.

>   I kind of like the digest-based approach (although perhaps SHA-1
>would be a better choice than MD5).  The user can identify themselves
>via some relatively static information such as complete name,
>city and country of birth, date of birth, etc. and this results in
>a digest that should be guaranteed to be unique.  The user can
>easily reconstitute this identifier by supplying the source information,
>which they should know fairly well.
>
>   Its not clear to me however how this scheme would facilitate easy
>referencing of entities, so perhaps that's where this concept falls down.

I think this an interesting approach, but I like many others would 
like to have an agreement on what requirements we have on the 
handles. That is something which I claim is not boiling the ocean... 
(hit me if I am wrong).

My suggestion for requirements on objects:

  - The handle should not change during the lifetime of an object
  - It must be possible to move an object from one registrar to another
    without deleting one object and then creating a new one
  - One must be able to have one "person" object somewhere, which then
    can be referenced from several places (this means that a handle, or
    what I proposed: serverid + localid, identify a record, and one
    can then use the handle to find a record (what registry).

If we do it this way, separating serverid and localid, and call them 
concatenated "the handle", that means that we don't have to say 
anything at all about how the localid is created -- AND, it is also 
the format which for example RIPE already is using. "RIPE" is the 
serverid, and then it's up to RIPE to allocate the localid.

But, back to requirements.

      paf

From: "Brian W. Spolarich" <[email-masked]>
To: "Patrik Fältström" <[email-masked]>, "George Belotsky" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Unique handle generation
Date: Thu, 8 Mar 2001 12:42:40 -0500
Importance: Normal
Sender: [email-masked]

> One record will point out a person (as an example). A person have a 
> lifetime of say 120 years. We need to find a handle which can have 
> the unique identifier for at least 120 years.

  This is a great discussion, but I find myself asking the question:
is this our problem to solve at the moment?  Creating globally-unique
identifiers which will live a very, very long time is a pretty tall
order.

  Perhaps we're trying to "boil the ocean" with this?

  Have any other identifiers (other than government-issued things like
Social Security Numbers, driver's license numbers, and the like) met
this requirement?

  I kind of like the digest-based approach (although perhaps SHA-1
would be a better choice than MD5).  The user can identify themselves
via some relatively static information such as complete name, 
city and country of birth, date of birth, etc. and this results in
a digest that should be guaranteed to be unique.  The user can
easily reconstitute this identifier by supplying the source information,
which they should know fairly well.

  Its not clear to me however how this scheme would facilitate easy
referencing of entities, so perhaps that's where this concept falls down.

  -brian

From: Bill Manning <[email-masked]>
Subject: Re: Unique handle generation
To: [email-masked] (Dave Crocker)
Date: Thu, 8 Mar 2001 08:12:37 -0800 (PST)
Cc: [email-masked]
Sender: [email-masked]

% What is/are the specific use(s) for the proposed handle?
% 
% d/
% 
% 
% >----- Original Message -----
% >From: "George Belotsky" <[email-masked]>
% >To: <[email-masked]>
% >Subject: Unique handle generation
% >
% > > Since unique handle creation is still an open issue, could we not
% > > borrow/adapt a UUID generating algorithm for making such handles?
% 
% ----------
% Dave Crocker   <mailto:[email-masked]>

	To my mind, a handle has a single, specific use.
	It is a globally unique identifier, in Internet space,
	that marks the entit(ies) that are mapped to the
	intangibles that form the "assets" of the Internet, e.g.
	address blocks, ASNs, code points, DNS delegation points.. etc.
	
	In this manner, it functions alot like an employee number
	in a corporation. 

-- 
--bill

Date: Thu, 8 Mar 2001 10:54:47 -0500
From: George Belotsky <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: Christopher Ambler <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Excellent point, Dave.

Let's try to come up with some answers to what a handle is for.  A
number of people (e.g. Martin, Patrick) have made very useful suggestions
regarding handles.  From the overall discussion, it seems that:

          (i)   Handles should be easy to remember/readable;
          (ii)  Handles should identify objects uniquely;
          (iii) It's probably a bad idea for the handles to change.

It appears that a handle is really useful for lookups, rather than
searches.  Making the information contained in the handle itself
meaningful for some operation (other than memorization by the user)
is probably too ambitious a goal.  The likely use for handles is
automated exchanges between systems (e.g. transfer of registrar), and
some user-initiated operations, where the handle would be supplied
directly by a human (e.g. transfer of registrar, again).

Searches for objects would return handles as just another object
attribute, as would other lookup mechanisms (e.g. whois).

A common UUID calculation algorithm would satisfy both requirements
(ii) and (iii), above, but not requirement (i).  Therefore, it is
appropriate to generate the handle as a concatenation of several
(readable) attributes, such as email address, name, timestamp,
identifier of the generating server, etc (both myself and others
have suggested this).

** It does not really matter if some of the attributes placed into
** a handle change later -- as long as the handle remains unique, and
** is easy to remember.

After the handle is generated, it may be a good idea to store it as a
digest (e.g. MD5 hash) on the server.  The handle' owner can still
use the human-readable form, while automated exchanges between systems
will use the digest only.

George. 

On Thu, Mar 08, 2001 at 10:44:26PM +1100, Dave Crocker wrote:
> At 05:43 AM 3/8/2001, Christopher Ambler wrote:
> >That depends on what you want the handle for.
> 
> This is a key question and I do not believe it has been answered.
> 
> What is/are the specific use(s) for the proposed handle?
> 
> d/
> 
> 
> >----- Original Message -----
> >From: "George Belotsky" <[email-masked]>
> >To: <[email-masked]>
> >Subject: Unique handle generation
> >
> > > Since unique handle creation is still an open issue, could we not
> > > borrow/adapt a UUID generating algorithm for making such handles?
> 
> ----------
> Dave Crocker   <mailto:[email-masked]>
> Brandenburg InternetWorking   <http://www.brandenburg.com>
> tel: +1.408.246.8253;   fax: +1.408.273.6464
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Thu, 8 Mar 2001 16:34:10 +0100
To: Takeshi Saigoh <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

At 23.54 +0900 01-03-08, Takeshi Saigoh wrote:
>Patrik,
>
>The contact may associate any number of previosly allocated handles
>into "one" universal handle, the point of authoratitive refernece is
>identified and where a transfer is effected the new handle can associate
>with old handle...

Who is responsible for this old handle? Is a new handle created in 
the new registrar? How long such chains do you force registrars to 
keep track of?

I strongly oppose using any short-lived information (i.e. reuse of an 
attribute value) in the handle itself.

   paf

>
>Ken
>
>-----Original Message-----
>Date: Thu, 8 Mar 2001 07:41:27 +0100
>To: Takeshi Saigoh <[email-masked]>
>From: Patrik F"ptstr°@  <[email-masked]>
>Subject: RE: Unique handle generation
>Cc: [email-masked]
>Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>Status:  
>
>At 15.35 +0900 01-03-08, Takeshi Saigoh wrote:
>>Our IOJ system assigns a contact handle by a similar way. ie:
>>
>>    "NIC-<REGISTRAR ID>-<LOCAL USER ID>"
>
>Is this the record which specifies who is the contact for a specific
>registrar?
>
>Or a contact for a object which is created at that registrar, i.e.
>points to a customer of that registrar?
>
>If the latter, what do you do if that object is transferred to a
>different registrar? Do the handle change?
>
>     paf

Date: Thu, 08 Mar 2001 23:54:22 +0900
To: Patrik F=?ISO-2022-JP?B?GyRCZ00bKEI=?=tstr =?ISO-2022-JP?B?GyRCi04bKEI=?=  <[email-masked]>
From: Takeshi Saigoh <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

Patrik,

The contact may associate any number of previosly allocated handles
into "one" universal handle, the point of authoratitive refernece is
identified and where a transfer is effected the new handle can associate
with old handle...

Ken

-----Original Message-----
Date: Thu, 8 Mar 2001 07:41:27 +0100
To: Takeshi Saigoh <[email-masked]>
From: Patrik F$BgM(Btstr$B‹N(B  <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Status:   

At 15.35 +0900 01-03-08, Takeshi Saigoh wrote:
>Our IOJ system assigns a contact handle by a similar way. ie:
>
>   "NIC-<REGISTRAR ID>-<LOCAL USER ID>"

Is this the record which specifies who is the contact for a specific 
registrar?

Or a contact for a object which is created at that registrar, i.e. 
points to a customer of that registrar?

If the latter, what do you do if that object is transferred to a 
different registrar? Do the handle change?

    paf

Date: Thu, 08 Mar 2001 22:44:26 +1100
To: "Christopher Ambler" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Unique handle generation
Cc: <[email-masked]>
Sender: [email-masked]

At 05:43 AM 3/8/2001, Christopher Ambler wrote:
>That depends on what you want the handle for.

This is a key question and I do not believe it has been answered.

What is/are the specific use(s) for the proposed handle?

d/

>----- Original Message -----
>From: "George Belotsky" <[email-masked]>
>To: <[email-masked]>
>Subject: Unique handle generation
>
> > Since unique handle creation is still an open issue, could we not
> > borrow/adapt a UUID generating algorithm for making such handles?

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

Date: Thu, 08 Mar 2001 12:24:54 +0100
From: Klaus Malorny <[email-masked]>
To: [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Patrick wrote:
> 
> On Wed, Mar 07, 2001 at 06:22:02PM -0500, George Belotsky took time to write:
> > Someone on this list talked about the possibility of people changing
> > email addresses, and their old address being claimed by someone else.
> >
> > At first glance, an email address appears unique, but the above
> > arguments do raise a legitimate concern.
> 
> Then, just add a timestamp (of handle creation time) to the email
> address and then it is (quite) unique.
> 
> If you loose your email address, you can still use your handle, since
> if someone else creates a new handle with the same email address it
> will have another timestamp.
> 
> You can also add a registrar/registry id.
> 
> Patrick.

Although I don't know the origins of this discussion (provreg meeting?), the
big question is whether humans should use these handles directly (as I assume
from the ongoing discussion) or not. In the first case, I think handles 

  - should be syntactically simple (e.g. limited possible characters, case
    independed)
  - should be similar among each object type
  - should -- on the other hand -- identify the object type
  - should not _directly_ refer to data it describes, but may contain some
    hints

Of course a compromise is possible. For example, CORE handles contain (beside
a type id) only a number, and we got some complaints about the handles not
having a mnemonic feature. Nevertheless, having a complete e-mail address
contained in the handle is too specific, too complicated (do we have to refer
to RFC822 or similar?) and too unhandy.

regards
Klaus Malorny

Date: Thu, 8 Mar 2001 11:40:21 +0100
From: Patrick <[email-masked]>
To: George Belotsky <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Organization: Gandi
Sender: [email-masked]

On Wed, Mar 07, 2001 at 06:22:02PM -0500, George Belotsky took time to write:
> Someone on this list talked about the possibility of people changing
> email addresses, and their old address being claimed by someone else.
> 
> At first glance, an email address appears unique, but the above
> arguments do raise a legitimate concern.

Then, just add a timestamp (of handle creation time) to the email
address and then it is (quite) unique.

If you loose your email address, you can still use your handle, since
if someone else creates a new handle with the same email address it
will have another timestamp.

You can also add a registrar/registry id.

Patrick.

Date: Thu,  8 Mar 2001 10:35:50 +0000 (GMT)
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, "'George Belotsky'" <[email-masked]>, [email-masked]
Subject: RE: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "paf" == paf  <Patrik> writes:

--> snip <--

    paf> So, my proposal is simply that the local handle is allocated
    paf> / generated by the registry for each object, the server
    paf> handle is registered somewhere (I have a draft which is on
    paf> it's way out...but I missed the deadline) and unique for the
    paf> registry -- and the handle for any object is a combination of
    paf> the two.

This strikes me as eminently sensible.

Presumably the registrar could offer a hint to the registry for the
local part of the handle, which the registry could simply ignore if it 
didn't fit its handle policy or if it had been taken. 

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Thu,  8 Mar 2001 10:29:25 +0000 (GMT)
To: George Belotsky <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "George" == George Belotsky <[email-masked]> writes:

    George> Someone on this list talked about the possibility of
    George> people changing email addresses, and their old address
    George> being claimed by someone else.

    George> At first glance, an email address appears unique, but the
    George> above arguments do raise a legitimate concern.

Even if the old address isn't claimed I think that people changing
email addresses makes the concept flawed.

If someone changes their email address then either the handle changes
which is a pain, or it doesn't and the email address == handle
relation no longer holds. The latter case seems fraught with loads of
address qua handle and address qua address confusions.

Surely it's better to have a handle which really is immutable and tags
the object without any regard to the object's internal state ? To me
such a notion seems a thoroughly sensible concept for almost any
database. By contrast if the handle starts to relate to the object's
state then you probably end up reinventing an immutable tag for the
object too.

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Thu,  8 Mar 2001 09:52:55 +0000 (GMT)
To: Sheer El-Showk <[email-masked]>
Cc: George Belotsky <[email-masked]>, <[email-masked]>
Subject: Re: Transport Team Mailing List.
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Sheer" == Sheer El-Showk <[email-masked]> writes:

--> snip <--

    Sheer> Please let me know (Joap and Edward could moderate
    Sheer> subscription via email if they want to, and we could send
    Sheer> out a weekly digest to the regular list).

I for one would appreciate a weekly digest.

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

Date: Sat, 3 Mar 2001 13:03:44 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: George Belotsky <[email-masked]>
cc: <[email-masked]>
Subject: Re: Transport Team Mailing List.
Sender: [email-masked]

I can set up the list right away but I think subscription
(not posting, just subscription) should be moderated.  I have
no problem moderating it myself (I can just check against the
email address Joap posted) but it would probably be more
appropriate for Joap and Edward to moderate the subscriptions.

I await a response from one of them, or a general consensus
from any design team (since they are supposed to be
self-administering) as to how to set up the lists subscriptions.

Regards,
Sheer

On Fri, 2 Mar 2001, George Belotsky wrote:

> I would really appreciate that.  Does everyone else on the Transport
> Team mind if Sheer sets up our list?
>
> George.
>
>
> On Fri, Mar 02, 2001 at 07:06:10PM -0500, Sheer El-Showk wrote:
> > I'll gladly host mailing lists for any of the groups that need it.  What
> > are we looking for in terms of a list -- digests, archiving, all that I
> > have, but a web interface would require some setting up (not that I mind,
> > but it might just take a little while).  I could set up any regular
> > mailing lists as soon there is a consensus.
> >
> > Please let me know (Joap and Edward could moderate subscription via email
> > if they want to, and we could send out a weekly digest to the regular
> > list).
> >
> > Regards,
> > Sheer
> >
> > On Fri, 2 Mar 2001, George Belotsky wrote:
> >
> > >
> > > Is any member of the transport team willing to set up a mailing
> > > list for us?  If not, I can see about setting something up here.
> > >
> > > George.
> > >
> > >
> > > -----------------------------
> > > George Belotsky
> > > Senior Software Architect
> > > Register.com, inc.
> > > [email-masked]
> > > 212-798-9127 (phone)
> > > 212-798-9876 (fax)
> > >
> >
> >
>
> --
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)
>

Date: Fri, 2 Mar 2001 19:06:10 -0500 (EST)
From: Sheer El-Showk <[email-masked]>
To: George Belotsky <[email-masked]>
cc: <[email-masked]>
Subject: Re: Transport Team Mailing List.
Sender: [email-masked]

I'll gladly host mailing lists for any of the groups that need it.  What
are we looking for in terms of a list -- digests, archiving, all that I
have, but a web interface would require some setting up (not that I mind,
but it might just take a little while).  I could set up any regular
mailing lists as soon there is a consensus.

Please let me know (Joap and Edward could moderate subscription via email
if they want to, and we could send out a weekly digest to the regular
list).

Regards,
Sheer

On Fri, 2 Mar 2001, George Belotsky wrote:

>
> Is any member of the transport team willing to set up a mailing
> list for us?  If not, I can see about setting something up here.
>
> George.
>
>
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)
>

Date: Thu, 8 Mar 2001 07:41:27 +0100
To: Takeshi Saigoh <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

At 15.35 +0900 01-03-08, Takeshi Saigoh wrote:
>Our IOJ system assigns a contact handle by a similar way. ie:
>
>   "NIC-<REGISTRAR ID>-<LOCAL USER ID>"

Is this the record which specifies who is the contact for a specific registrar?

Or a contact for a object which is created at that registrar, i.e. 
points to a customer of that registrar?

If the latter, what do you do if that object is transferred to a 
different registrar? Do the handle change?

    paf

Date: Thu, 08 Mar 2001 15:35:16 +0900
To: Patrik F=?ISO-2022-JP?B?GyRCZ00bKEI=?=tstr =?ISO-2022-JP?B?GyRCi04bKEI=?=  <[email-masked]>
From: Takeshi Saigoh <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

Patrik,

Our IOJ system assigns a contact handle by a similar way. ie:

  "NIC-<REGISTRAR ID>-<LOCAL USER ID>"

This way functions well in a usual case. However, when a registrar
stops service, this way brings a user confusion. If it adopts this
way, the database which manages all handles is required (UWhois??).
Of course, it needs to follow correspondence of an old handle and
a new handle...

Ken

-----Original Message-----
To: "Hollenbeck, Scott" <[email-masked]>,"'George Belotsky'" <[email-masked]>
From: Patrik F$BgM(Btstr$B‹N(B  <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
Status:   

At 15.38 -0500 01-03-07, Hollenbeck, Scott wrote:
>George,
>
>Maybe I'm missing something, but what's not unique about an e-mail address?

A handle is a globally unique identifier of a record in a database. 
The handle can normally be used for two things:

  - Uniqueness
  - Locality

In some cases when one design a handle, one have to choose one of 
these functions before the other, i.e. prioritize.

Each record need a handle.

A person change email address, but the handle of the record which 
contain the email address should stay the same -- and have as long 
life as possible.

The routing registries today use handles which are of the form

  <LOCAL HANDLE>-<SERVER HANDLE>

Example: PAFA1-RIPE

The local handle have to be unique within the server, and the server 
handles unique by itself. The combination of local handle and server 
handle will because of this be globally unique.

A record can if these kind of handles are used refer to objects in a 
different registry -- which I claim is a good thing.

If we have a registry of all server handles, we can even locate the 
record given the server handle -- which I claim is a good thing.

A record can though NOT with this design move from one registry to 
another, and I claim that is not needed.

With registry I mean for example the three RIR we have today, or one 
TLD registry (including registrars).

This means that all registrars for the same TLD have to use the same 
server handle, and unique local handles between themselves for this 
scheme to work.

If not, if one transfer a domain (for example) from one registrar to 
another, the handle will change. This is a bad thing.

So, my proposal is simply that the local handle is allocated / 
generated by the registry for each object, the server handle is 
registered somewhere (I have a draft which is on it's way out...but I 
missed the deadline) and unique for the registry -- and the handle 
for any object is a combination of the two.

       paf

Date: Thu, 8 Mar 2001 07:15:39 +0100
To: George Belotsky <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

At 18.22 -0500 01-03-07, George Belotsky wrote:
>Someone on this list talked about the possibility of people changing
>email addresses, and their old address being claimed by someone else.

Exactly!

One record will point out a person (as an example). A person have a 
lifetime of say 120 years. We need to find a handle which can have 
the unique identifier for at least 120 years.

That is not the case with email addresses.

Email address might be one of the attributes in that person object.

Se the RPSL specification. You have to be conformant with that 
regarding lots of semantics. Don't reinvent too much.

    paf

>
>At first glance, an email address appears unique, but the above
>arguments do raise a legitimate concern.
>
>George.
>
>
>On Wed, Mar 07, 2001 at 03:38:56PM -0500, Hollenbeck, Scott wrote:
>>  George,
>>
>>  Maybe I'm missing something, but what's not unique about an e-mail address?
>>
>>  <Scott/>
>>
>>  -----Original Message-----
>>  From: George Belotsky [mailto:[email-masked]]
>>  Sent: Wednesday, March 07, 2001 3:25 PM
>>  To: Christopher Ambler
>>  Cc: Hollenbeck, Scott; [email-masked]
>>  Subject: Re: Unique handle generation
>>
>>
>>  Maybe we can attach some other information along with the email
>>  address to ensure uniqueness.  A digest of the whole handle can then
>>  be generated.  At this point, you basically have a UUID.  People can
>>  use the plain text version of their handle (easy to remember), while
>>  automated information exchanges can work with the digests directly.
>>
>>  .. and I hope this is not beef liver, or you may not even remember
>>      your email in a few years :) ...
>>
>>  George.
>>
>>
>>  On Wed, Mar 07, 2001 at 10:48:36AM -0800, Christopher Ambler wrote:
>>  > I have been, and remain convinced that email address, with the
>>  > ability to change it as necessary, is the way to go.
>>  >
>>  > Then again, I'm also fond of liver and onions.
>>  >
>>  > Christopher
>>  >
>>  > ----- Original Message -----
>>  > From: "Hollenbeck, Scott" <[email-masked]>
>>  > To: "'George Belotsky'" <[email-masked]>; <[email-masked]>
>>  > Sent: Wednesday, March 07, 2001 10:36 AM
>>  > Subject: RE: Unique handle generation
>>  >
>>  >
>>  > > George,
>>  > >
>>  > > In terms of placing interoperability in the hands of the user, I prefer
>>  the
>>  > > idea of either letting them choose their own identifier (it it happens
>>  to be
>>  > > unused by anyone else), or using an e-mail address.  InterNIC-generated
>>  > > handles (which sounds similar to what you've suggested below) haven't
>>  proven
>>  > > to be very memorable or useful in other contexts.
>>  > >
>>  > > <Scott/>
>>  > >
>>  > > -----Original Message-----
>>  > > From: George Belotsky [mailto:[email-masked]]
>>  > > Sent: Wednesday, March 07, 2001 11:54 AM
>>  > > To: [email-masked]
>>  > > Subject: Unique handle generation
>>  > >
>>  > >
>>  > > Since unique handle creation is still an open issue, could we not
>>  > > borrow/adapt a UUID generating algorithm for making such handles?
>>  > >
>>  > > This eliminates the need to keep a centralized database of these
>>  > > things.  Anyone can have as many handles as they want, and use them as
>>  > > they see fit.  This places interoperability in the hands of the user;
>>  > > if someone wants their information shared between systems, they will
>>  > > continue to use the same handle.
>>  > >
>>  > > George.
>
>--
>-----------------------------
>George Belotsky
>Senior Software Architect
>Register.com, inc.
>[email-masked]
>212-798-9127 (phone)
>212-798-9876 (fax)

-- 
Patrik Fältström <[email-masked]>                         Cisco Systems
Consulting Engineer                                  Office of the CSO
Phone: (Stockholm) +46-8-6859131            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

Date: Thu, 8 Mar 2001 07:13:36 +0100
To: "Hollenbeck, Scott" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

At 17.30 -0500 01-03-07, Hollenbeck, Scott wrote:
>Are you suggesting that a handle as you described be assigned to every
>registry object,

Yes. Domain name registry aswell as IP-address registry and other 
registries that might be interested in using this protocol when 
communicating with the registrars of theirs.

I might be far off, but this was my intent.

>and that this handle should be used as the one and only
>searchable identifier for the object?

No.

Searchable is something completely different.

Personally, I differ between search and lookup, and when doing a 
lookup, you know exactly the identifier of the object you want to 
get, and issue a query which have exactly that identifier.

DNS is a lookup.

>Or are you suggesting a combination
>of searchable identifiers, such as domain name, host name, contact e-mail
>address, and such a handle (with the local part of the handle being the
>domain name, host name, e-mail address, etc)?

email address etc can _not_ be part of a handle because the email 
address is not long lived enough.

A Handle MUST have a lifetime which is longer than the object itself.

I have changed email address 4 times since my record in the RIPE 
database was created...

     paf

>Sorry to be dense, I'm trying to capture this precisely so it can be
>accurately described for our Minneapolis "issues" discussion.
>
><Scott/>
>
>-----Original Message-----
>From: Patrik Fältström [mailto:[email-masked]]
>Sent: Wednesday, March 07, 2001 4:12 PM
>To: Hollenbeck, Scott; 'George Belotsky'
>Cc: [email-masked]
>Subject: RE: Unique handle generation
>
>
>At 15.38 -0500 01-03-07, Hollenbeck, Scott wrote:
>>George,
>>
>>Maybe I'm missing something, but what's not unique about an e-mail address?
>
>A handle is a globally unique identifier of a record in a database.
>The handle can normally be used for two things:
>
>   - Uniqueness
>   - Locality
>
>In some cases when one design a handle, one have to choose one of
>these functions before the other, i.e. prioritize.
>
>Each record need a handle.
>
>A person change email address, but the handle of the record which
>contain the email address should stay the same -- and have as long
>life as possible.
>
>The routing registries today use handles which are of the form
>
>   <LOCAL HANDLE>-<SERVER HANDLE>
>
>Example: PAFA1-RIPE
>
>The local handle have to be unique within the server, and the server
>handles unique by itself. The combination of local handle and server
>handle will because of this be globally unique.
>
>A record can if these kind of handles are used refer to objects in a
>different registry -- which I claim is a good thing.
>
>If we have a registry of all server handles, we can even locate the
>record given the server handle -- which I claim is a good thing.
>
>A record can though NOT with this design move from one registry to
>another, and I claim that is not needed.
>
>With registry I mean for example the three RIR we have today, or one
>TLD registry (including registrars).
>
>This means that all registrars for the same TLD have to use the same
>server handle, and unique local handles between themselves for this
>scheme to work.
>
>If not, if one transfer a domain (for example) from one registrar to
>another, the handle will change. This is a bad thing.
>
>So, my proposal is simply that the local handle is allocated /
>generated by the registry for each object, the server handle is
>registered somewhere (I have a draft which is on it's way out...but I
>missed the deadline) and unique for the registry -- and the handle
>for any object is a combination of the two.
>
>        paf
>
>
>
>>
>><Scott/>
>>
>>-----Original Message-----
>>From: George Belotsky [mailto:[email-masked]]
>>Sent: Wednesday, March 07, 2001 3:25 PM
>>To: Christopher Ambler
>>Cc: Hollenbeck, Scott; [email-masked]
>>Subject: Re: Unique handle generation
>>
>>
>>Maybe we can attach some other information along with the email
>>address to ensure uniqueness.  A digest of the whole handle can then
>  >be generated.  At this point, you basically have a UUID.  People can
>>use the plain text version of their handle (easy to remember), while
>>automated information exchanges can work with the digests directly.
>>
>>.. and I hope this is not beef liver, or you may not even remember
>>      your email in a few years :) ...
>>
>>George.
>>
>>
>>On Wed, Mar 07, 2001 at 10:48:36AM -0800, Christopher Ambler wrote:
>>>   I have been, and remain convinced that email address, with the
>>>   ability to change it as necessary, is the way to go.
>>>
>>>   Then again, I'm also fond of liver and onions.
>>>
>>>   Christopher
>>>
>>>   ----- Original Message -----
>>>   From: "Hollenbeck, Scott" <[email-masked]>
>>>   To: "'George Belotsky'" <[email-masked]>; <[email-masked]>
>>>   Sent: Wednesday, March 07, 2001 10:36 AM
>>>   Subject: RE: Unique handle generation
>>>
>>>
>>>   > George,
>>>   >
>>>   > In terms of placing interoperability in the hands of the user, I
>prefer
>>the
>>>   > idea of either letting them choose their own identifier (it it happens
>>to be
>>>   > unused by anyone else), or using an e-mail address.
>InterNIC-generated
>>>   > handles (which sounds similar to what you've suggested below) haven't
>>proven
>>>   > to be very memorable or useful in other contexts.
>>>   >
>>>   > <Scott/>
>>>   >
>>>   > -----Original Message-----
>>>   > From: George Belotsky [mailto:[email-masked]]
>>>   > Sent: Wednesday, March 07, 2001 11:54 AM
>>>   > To: [email-masked]
>>>   > Subject: Unique handle generation
>>>   >
>>>   >
>>>   > Since unique handle creation is still an open issue, could we not
>>>   > borrow/adapt a UUID generating algorithm for making such handles?
>>   > >
>>>   > This eliminates the need to keep a centralized database of these
>>>   > things.  Anyone can have as many handles as they want, and use them as
>>>   > they see fit.  This places interoperability in the hands of the user;
>>>   > if someone wants their information shared between systems, they will
>>>   > continue to use the same handle.
>>>   >
>>>   > George.

-- 
Patrik Fältström <[email-masked]>                         Cisco Systems
Consulting Engineer                                  Office of the CSO
Phone: (Stockholm) +46-8-6859131            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

Date: Wed, 7 Mar 2001 18:22:02 -0500
From: George Belotsky <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Someone on this list talked about the possibility of people changing
email addresses, and their old address being claimed by someone else.

At first glance, an email address appears unique, but the above
arguments do raise a legitimate concern.

George.

On Wed, Mar 07, 2001 at 03:38:56PM -0500, Hollenbeck, Scott wrote:
> George,
> 
> Maybe I'm missing something, but what's not unique about an e-mail address?
> 
> <Scott/>
> 
> -----Original Message-----
> From: George Belotsky [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 3:25 PM
> To: Christopher Ambler
> Cc: Hollenbeck, Scott; [email-masked]
> Subject: Re: Unique handle generation
> 
> 
> Maybe we can attach some other information along with the email
> address to ensure uniqueness.  A digest of the whole handle can then
> be generated.  At this point, you basically have a UUID.  People can
> use the plain text version of their handle (easy to remember), while
> automated information exchanges can work with the digests directly.
> 
> .. and I hope this is not beef liver, or you may not even remember
>     your email in a few years :) ...
> 
> George. 
> 
> 
> On Wed, Mar 07, 2001 at 10:48:36AM -0800, Christopher Ambler wrote:
> > I have been, and remain convinced that email address, with the
> > ability to change it as necessary, is the way to go.
> > 
> > Then again, I'm also fond of liver and onions.
> > 
> > Christopher
> > 
> > ----- Original Message ----- 
> > From: "Hollenbeck, Scott" <[email-masked]>
> > To: "'George Belotsky'" <[email-masked]>; <[email-masked]>
> > Sent: Wednesday, March 07, 2001 10:36 AM
> > Subject: RE: Unique handle generation
> > 
> > 
> > > George,
> > > 
> > > In terms of placing interoperability in the hands of the user, I prefer
> the
> > > idea of either letting them choose their own identifier (it it happens
> to be
> > > unused by anyone else), or using an e-mail address.  InterNIC-generated
> > > handles (which sounds similar to what you've suggested below) haven't
> proven
> > > to be very memorable or useful in other contexts.
> > > 
> > > <Scott/>
> > > 
> > > -----Original Message-----
> > > From: George Belotsky [mailto:[email-masked]]
> > > Sent: Wednesday, March 07, 2001 11:54 AM
> > > To: [email-masked]
> > > Subject: Unique handle generation
> > > 
> > > 
> > > Since unique handle creation is still an open issue, could we not
> > > borrow/adapt a UUID generating algorithm for making such handles?
> > > 
> > > This eliminates the need to keep a centralized database of these
> > > things.  Anyone can have as many handles as they want, and use them as
> > > they see fit.  This places interoperability in the hands of the user;
> > > if someone wants their information shared between systems, they will
> > > continue to use the same handle.
> > > 
> > > George.

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>
Cc: [email-masked]
Subject: RE: Unique handle generation
Date: Wed, 7 Mar 2001 17:30:33 -0500 
Sender: [email-masked]

Patrik,

Are you suggesting that a handle as you described be assigned to every
registry object, and that this handle should be used as the one and only
searchable identifier for the object?  Or are you suggesting a combination
of searchable identifiers, such as domain name, host name, contact e-mail
address, and such a handle (with the local part of the handle being the
domain name, host name, e-mail address, etc)?

Sorry to be dense, I'm trying to capture this precisely so it can be
accurately described for our Minneapolis "issues" discussion.

<Scott/> 

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 4:12 PM
To: Hollenbeck, Scott; 'George Belotsky'
Cc: [email-masked]
Subject: RE: Unique handle generation

At 15.38 -0500 01-03-07, Hollenbeck, Scott wrote:
>George,
>
>Maybe I'm missing something, but what's not unique about an e-mail address?

A handle is a globally unique identifier of a record in a database. 
The handle can normally be used for two things:

  - Uniqueness
  - Locality

In some cases when one design a handle, one have to choose one of 
these functions before the other, i.e. prioritize.

Each record need a handle.

A person change email address, but the handle of the record which 
contain the email address should stay the same -- and have as long 
life as possible.

The routing registries today use handles which are of the form

  <LOCAL HANDLE>-<SERVER HANDLE>

Example: PAFA1-RIPE

The local handle have to be unique within the server, and the server 
handles unique by itself. The combination of local handle and server 
handle will because of this be globally unique.

A record can if these kind of handles are used refer to objects in a 
different registry -- which I claim is a good thing.

If we have a registry of all server handles, we can even locate the 
record given the server handle -- which I claim is a good thing.

A record can though NOT with this design move from one registry to 
another, and I claim that is not needed.

With registry I mean for example the three RIR we have today, or one 
TLD registry (including registrars).

This means that all registrars for the same TLD have to use the same 
server handle, and unique local handles between themselves for this 
scheme to work.

If not, if one transfer a domain (for example) from one registrar to 
another, the handle will change. This is a bad thing.

So, my proposal is simply that the local handle is allocated / 
generated by the registry for each object, the server handle is 
registered somewhere (I have a draft which is on it's way out...but I 
missed the deadline) and unique for the registry -- and the handle 
for any object is a combination of the two.

       paf

>
><Scott/>
>
>-----Original Message-----
>From: George Belotsky [mailto:[email-masked]]
>Sent: Wednesday, March 07, 2001 3:25 PM
>To: Christopher Ambler
>Cc: Hollenbeck, Scott; [email-masked]
>Subject: Re: Unique handle generation
>
>
>Maybe we can attach some other information along with the email
>address to ensure uniqueness.  A digest of the whole handle can then
>be generated.  At this point, you basically have a UUID.  People can
>use the plain text version of their handle (easy to remember), while
>automated information exchanges can work with the digests directly.
>
>.. and I hope this is not beef liver, or you may not even remember
>     your email in a few years :) ...
>
>George.
>
>
>On Wed, Mar 07, 2001 at 10:48:36AM -0800, Christopher Ambler wrote:
>>  I have been, and remain convinced that email address, with the
>>  ability to change it as necessary, is the way to go.
>>
>>  Then again, I'm also fond of liver and onions.
>>
>>  Christopher
>>
>>  ----- Original Message -----
>>  From: "Hollenbeck, Scott" <[email-masked]>
>>  To: "'George Belotsky'" <[email-masked]>; <[email-masked]>
>>  Sent: Wednesday, March 07, 2001 10:36 AM
>>  Subject: RE: Unique handle generation
>>
>>
>>  > George,
>>  >
>>  > In terms of placing interoperability in the hands of the user, I
prefer
>the
>>  > idea of either letting them choose their own identifier (it it happens
>to be
>>  > unused by anyone else), or using an e-mail address.
InterNIC-generated
>>  > handles (which sounds similar to what you've suggested below) haven't
>proven
>>  > to be very memorable or useful in other contexts.
>>  >
>>  > <Scott/>
>>  >
>>  > -----Original Message-----
>>  > From: George Belotsky [mailto:[email-masked]]
>>  > Sent: Wednesday, March 07, 2001 11:54 AM
>>  > To: [email-masked]
>>  > Subject: Unique handle generation
>>  >
>>  >
>>  > Since unique handle creation is still an open issue, could we not
>>  > borrow/adapt a UUID generating algorithm for making such handles?
>  > >
>>  > This eliminates the need to keep a centralized database of these
>>  > things.  Anyone can have as many handles as they want, and use them as
>>  > they see fit.  This places interoperability in the hands of the user;
>>  > if someone wants their information shared between systems, they will
>>  > continue to use the same handle.
>>  >
>>  > George.

Date: Wed, 7 Mar 2001 22:11:59 +0100
To: "Hollenbeck, Scott" <[email-masked]>, "'George Belotsky'" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: RE: Unique handle generation
Cc: [email-masked]
Sender: [email-masked]

At 15.38 -0500 01-03-07, Hollenbeck, Scott wrote:
>George,
>
>Maybe I'm missing something, but what's not unique about an e-mail address?

A handle is a globally unique identifier of a record in a database. 
The handle can normally be used for two things:

  - Uniqueness
  - Locality

In some cases when one design a handle, one have to choose one of 
these functions before the other, i.e. prioritize.

Each record need a handle.

A person change email address, but the handle of the record which 
contain the email address should stay the same -- and have as long 
life as possible.

The routing registries today use handles which are of the form

  <LOCAL HANDLE>-<SERVER HANDLE>

Example: PAFA1-RIPE

The local handle have to be unique within the server, and the server 
handles unique by itself. The combination of local handle and server 
handle will because of this be globally unique.

A record can if these kind of handles are used refer to objects in a 
different registry -- which I claim is a good thing.

If we have a registry of all server handles, we can even locate the 
record given the server handle -- which I claim is a good thing.

A record can though NOT with this design move from one registry to 
another, and I claim that is not needed.

With registry I mean for example the three RIR we have today, or one 
TLD registry (including registrars).

This means that all registrars for the same TLD have to use the same 
server handle, and unique local handles between themselves for this 
scheme to work.

If not, if one transfer a domain (for example) from one registrar to 
another, the handle will change. This is a bad thing.

So, my proposal is simply that the local handle is allocated / 
generated by the registry for each object, the server handle is 
registered somewhere (I have a draft which is on it's way out...but I 
missed the deadline) and unique for the registry -- and the handle 
for any object is a combination of the two.

       paf

>
><Scott/>
>
>-----Original Message-----
>From: George Belotsky [mailto:[email-masked]]
>Sent: Wednesday, March 07, 2001 3:25 PM
>To: Christopher Ambler
>Cc: Hollenbeck, Scott; [email-masked]
>Subject: Re: Unique handle generation
>
>
>Maybe we can attach some other information along with the email
>address to ensure uniqueness.  A digest of the whole handle can then
>be generated.  At this point, you basically have a UUID.  People can
>use the plain text version of their handle (easy to remember), while
>automated information exchanges can work with the digests directly.
>
>.. and I hope this is not beef liver, or you may not even remember
>     your email in a few years :) ...
>
>George.
>
>
>On Wed, Mar 07, 2001 at 10:48:36AM -0800, Christopher Ambler wrote:
>>  I have been, and remain convinced that email address, with the
>>  ability to change it as necessary, is the way to go.
>>
>>  Then again, I'm also fond of liver and onions.
>>
>>  Christopher
>>
>>  ----- Original Message -----
>>  From: "Hollenbeck, Scott" <[email-masked]>
>>  To: "'George Belotsky'" <[email-masked]>; <[email-masked]>
>>  Sent: Wednesday, March 07, 2001 10:36 AM
>>  Subject: RE: Unique handle generation
>>
>>
>>  > George,
>>  >
>>  > In terms of placing interoperability in the hands of the user, I prefer
>the
>>  > idea of either letting them choose their own identifier (it it happens
>to be
>>  > unused by anyone else), or using an e-mail address.  InterNIC-generated
>>  > handles (which sounds similar to what you've suggested below) haven't
>proven
>>  > to be very memorable or useful in other contexts.
>>  >
>>  > <Scott/>
>>  >
>>  > -----Original Message-----
>>  > From: George Belotsky [mailto:[email-masked]]
>>  > Sent: Wednesday, March 07, 2001 11:54 AM
>>  > To: [email-masked]
>>  > Subject: Unique handle generation
>>  >
>>  >
>>  > Since unique handle creation is still an open issue, could we not
>>  > borrow/adapt a UUID generating algorithm for making such handles?
>  > >
>>  > This eliminates the need to keep a centralized database of these
>>  > things.  Anyone can have as many handles as they want, and use them as
>>  > they see fit.  This places interoperability in the hands of the user;
>>  > if someone wants their information shared between systems, they will
>>  > continue to use the same handle.
>>  >
>>  > George.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Unique handle generation
Date: Wed, 7 Mar 2001 15:38:56 -0500 
Sender: [email-masked]

George,

Maybe I'm missing something, but what's not unique about an e-mail address?

<Scott/>

-----Original Message-----
From: George Belotsky [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 3:25 PM
To: Christopher Ambler
Cc: Hollenbeck, Scott; [email-masked]
Subject: Re: Unique handle generation

Maybe we can attach some other information along with the email
address to ensure uniqueness.  A digest of the whole handle can then
be generated.  At this point, you basically have a UUID.  People can
use the plain text version of their handle (easy to remember), while
automated information exchanges can work with the digests directly.

.. and I hope this is not beef liver, or you may not even remember
    your email in a few years :) ...

George. 

On Wed, Mar 07, 2001 at 10:48:36AM -0800, Christopher Ambler wrote:
> I have been, and remain convinced that email address, with the
> ability to change it as necessary, is the way to go.
> 
> Then again, I'm also fond of liver and onions.
> 
> Christopher
> 
> ----- Original Message ----- 
> From: "Hollenbeck, Scott" <[email-masked]>
> To: "'George Belotsky'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 07, 2001 10:36 AM
> Subject: RE: Unique handle generation
> 
> 
> > George,
> > 
> > In terms of placing interoperability in the hands of the user, I prefer
the
> > idea of either letting them choose their own identifier (it it happens
to be
> > unused by anyone else), or using an e-mail address.  InterNIC-generated
> > handles (which sounds similar to what you've suggested below) haven't
proven
> > to be very memorable or useful in other contexts.
> > 
> > <Scott/>
> > 
> > -----Original Message-----
> > From: George Belotsky [mailto:[email-masked]]
> > Sent: Wednesday, March 07, 2001 11:54 AM
> > To: [email-masked]
> > Subject: Unique handle generation
> > 
> > 
> > Since unique handle creation is still an open issue, could we not
> > borrow/adapt a UUID generating algorithm for making such handles?
> > 
> > This eliminates the need to keep a centralized database of these
> > things.  Anyone can have as many handles as they want, and use them as
> > they see fit.  This places interoperability in the hands of the user;
> > if someone wants their information shared between systems, they will
> > continue to use the same handle.
> > 
> > George.

Date: Wed, 7 Mar 2001 15:25:24 -0500
From: George Belotsky <[email-masked]>
To: Christopher Ambler <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Unique handle generation
Sender: [email-masked]

Maybe we can attach some other information along with the email
address to ensure uniqueness.  A digest of the whole handle can then
be generated.  At this point, you basically have a UUID.  People can
use the plain text version of their handle (easy to remember), while
automated information exchanges can work with the digests directly.

.. and I hope this is not beef liver, or you may not even remember
    your email in a few years :) ...

George. 

On Wed, Mar 07, 2001 at 10:48:36AM -0800, Christopher Ambler wrote:
> I have been, and remain convinced that email address, with the
> ability to change it as necessary, is the way to go.
> 
> Then again, I'm also fond of liver and onions.
> 
> Christopher
> 
> ----- Original Message ----- 
> From: "Hollenbeck, Scott" <[email-masked]>
> To: "'George Belotsky'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 07, 2001 10:36 AM
> Subject: RE: Unique handle generation
> 
> 
> > George,
> > 
> > In terms of placing interoperability in the hands of the user, I prefer the
> > idea of either letting them choose their own identifier (it it happens to be
> > unused by anyone else), or using an e-mail address.  InterNIC-generated
> > handles (which sounds similar to what you've suggested below) haven't proven
> > to be very memorable or useful in other contexts.
> > 
> > <Scott/>
> > 
> > -----Original Message-----
> > From: George Belotsky [mailto:[email-masked]]
> > Sent: Wednesday, March 07, 2001 11:54 AM
> > To: [email-masked]
> > Subject: Unique handle generation
> > 
> > 
> > Since unique handle creation is still an open issue, could we not
> > borrow/adapt a UUID generating algorithm for making such handles?
> > 
> > This eliminates the need to keep a centralized database of these
> > things.  Anyone can have as many handles as they want, and use them as
> > they see fit.  This places interoperability in the hands of the user;
> > if someone wants their information shared between systems, they will
> > continue to use the same handle.
> > 
> > George.
> > 
> > 
> >  
> > -----------------------------
> > George Belotsky
> > Senior Software Architect
> > Register.com, inc.
> > [email-masked]
> > 212-798-9127 (phone)
> > 212-798-9876 (fax)
> > 
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'George Belotsky'" <[email-masked]>, <[email-masked]>
Subject: Re: Unique handle generation
Date: Wed, 7 Mar 2001 10:48:36 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

I have been, and remain convinced that email address, with the
ability to change it as necessary, is the way to go.

Then again, I'm also fond of liver and onions.

Christopher

----- Original Message ----- 
From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 07, 2001 10:36 AM
Subject: RE: Unique handle generation

> George,
> 
> In terms of placing interoperability in the hands of the user, I prefer the
> idea of either letting them choose their own identifier (it it happens to be
> unused by anyone else), or using an e-mail address.  InterNIC-generated
> handles (which sounds similar to what you've suggested below) haven't proven
> to be very memorable or useful in other contexts.
> 
> <Scott/>
> 
> -----Original Message-----
> From: George Belotsky [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 11:54 AM
> To: [email-masked]
> Subject: Unique handle generation
> 
> 
> Since unique handle creation is still an open issue, could we not
> borrow/adapt a UUID generating algorithm for making such handles?
> 
> This eliminates the need to keep a centralized database of these
> things.  Anyone can have as many handles as they want, and use them as
> they see fit.  This places interoperability in the hands of the user;
> if someone wants their information shared between systems, they will
> continue to use the same handle.
> 
> George.
> 
> 
>  
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)
> 

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>
Subject: Re: Unique handle generation
Date: Wed, 7 Mar 2001 10:43:56 -0800
Organization: Image Online Design, Inc.
Sender: [email-masked]

That depends on what you want the handle for.

If for protocol issues, certainly.

If you want the handle to be like my current NIC handle (CJA13, which
is easy to remember), then a UUID (GUID in MicroSpeak, for example)
is a terrible idea, since no user will remember it.

Christopher

----- Original Message ----- 
From: "George Belotsky" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 07, 2001 8:54 AM
Subject: Unique handle generation

> Since unique handle creation is still an open issue, could we not
> borrow/adapt a UUID generating algorithm for making such handles?
> 
> This eliminates the need to keep a centralized database of these
> things.  Anyone can have as many handles as they want, and use them as
> they see fit.  This places interoperability in the hands of the user;
> if someone wants their information shared between systems, they will
> continue to use the same handle.
> 
> George.
> 
> 
>  
> -----------------------------
> George Belotsky
> Senior Software Architect
> Register.com, inc.
> [email-masked]
> 212-798-9127 (phone)
> 212-798-9876 (fax)
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'George Belotsky'" <[email-masked]>, [email-masked]
Subject: RE: Unique handle generation
Date: Wed, 7 Mar 2001 13:36:39 -0500 
Sender: [email-masked]

George,

In terms of placing interoperability in the hands of the user, I prefer the
idea of either letting them choose their own identifier (it it happens to be
unused by anyone else), or using an e-mail address.  InterNIC-generated
handles (which sounds similar to what you've suggested below) haven't proven
to be very memorable or useful in other contexts.

<Scott/>

-----Original Message-----
From: George Belotsky [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 11:54 AM
To: [email-masked]
Subject: Unique handle generation

Since unique handle creation is still an open issue, could we not
borrow/adapt a UUID generating algorithm for making such handles?

This eliminates the need to keep a centralized database of these
things.  Anyone can have as many handles as they want, and use them as
they see fit.  This places interoperability in the hands of the user;
if someone wants their information shared between systems, they will
continue to use the same handle.

George.

 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Wed, 7 Mar 2001 11:54:03 -0500
From: George Belotsky <[email-masked]>
To: [email-masked]
Subject: Unique handle generation
Sender: [email-masked]

Since unique handle creation is still an open issue, could we not
borrow/adapt a UUID generating algorithm for making such handles?

This eliminates the need to keep a centralized database of these
things.  Anyone can have as many handles as they want, and use them as
they see fit.  This places interoperability in the hands of the user;
if someone wants their information shared between systems, they will
continue to use the same handle.

George.

 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: BEEP RFCs
Date: Mon, 5 Mar 2001 18:54:40 -0500 
Sender: [email-masked]

FWIW I saw some BEEP RFC announcements earlier today:

The Blocks Extensible Exchange Protocol Core
ftp://ftp.rfc-editor.org/in-notes/rfc3080.txt

Mapping the BEEP Core onto TCP
ftp://ftp.rfc-editor.org/in-notes/rfc3081.txt

<Scott/> 

From: [email-masked]
To: [email-masked]
Date: Tue, 6 Mar 2001 05:17:27 +0700
Subject: Re: Provreg Design Teams
Sender: [email-masked]

> We really would like to see some more people to step forward in
> the transport & security area.

I'll joint the security team. Is it still open?

My background: C, perl4, UNIX (various variants), security.
(Although I know OO languages, my head just would't allow 
me to write OO codes. Thus the perl4, thing.)
On the negative side: too many involvement in too many things :-(

Regards
-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

Date: Mon, 5 Mar 2001 12:55:51 -0500
From: George Belotsky <[email-masked]>
To: Sheer El-Showk <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Transport Team Mailing List.
Sender: [email-masked]

Thanks, Sheer.

George.

On Mon, Mar 05, 2001 at 12:34:11PM -0500, Sheer El-Showk wrote:
> I've gone ahead and created a transport list:
> 
> list:           transport-provreg-list
> post:           [email-masked]
> admin:          [email-masked]
> subscribe:      [email-masked]
> 
> I'm currently subscribed but I'll unsubscribe once I see everything up and
> running.  I'll moderate subscriptions (_not_ posts) until I hear otherwise
> from Edward, Joap, or the transport design team in general (basically
> I'll allow _only_ members of the design team to subscibe).
> 
> I propose sending a weekly digest to the general provreg list, but I'll
> wait on a more general response before doing so.
> 
> I'm willing to do the same thing for the security and the protocol list,
> but am worried that further unilateral action will get me in trouble.
> 
> George, Chris, Peter please send subscription emails and I'll push them
> through.
> 
> If anyone is interested these lists feature archive retreival and some
> other neat features ... consult http://www.ezmlm.org/ezman-0.32/index.html
> for more information.
> 
> Regards,
> Sheer
> 
> 
> On Mon, 5 Mar 2001, George Belotsky wrote:
> 
> > O.K.  Let's wait until tomorrow to hear any objections from
> > the Transport team, and then set the list up.  It would really
> > be a useful tool.
> >
> > George.
> >
> >
> > On Sat, Mar 03, 2001 at 01:03:44PM -0500, Sheer El-Showk wrote:
> > > I can set up the list right away but I think subscription
> > > (not posting, just subscription) should be moderated.  I have
> > > no problem moderating it myself (I can just check against the
> > > email address Joap posted) but it would probably be more
> > > appropriate for Joap and Edward to moderate the subscriptions.
> > >
> > > I await a response from one of them, or a general consensus
> > > from any design team (since they are supposed to be
> > > self-administering) as to how to set up the lists subscriptions.
> > >
> > > Regards,
> > > Sheer
> > >
> > >
> > > On Fri, 2 Mar 2001, George Belotsky wrote:
> > >
> > > > I would really appreciate that.  Does everyone else on the Transport
> > > > Team mind if Sheer sets up our list?
> > > >
> > > > George.
> > > >
> > > >
> > > > On Fri, Mar 02, 2001 at 07:06:10PM -0500, Sheer El-Showk wrote:
> > > > > I'll gladly host mailing lists for any of the groups that need it.  What
> > > > > are we looking for in terms of a list -- digests, archiving, all that I
> > > > > have, but a web interface would require some setting up (not that I mind,
> > > > > but it might just take a little while).  I could set up any regular
> > > > > mailing lists as soon there is a consensus.
> > > > >
> > > > > Please let me know (Joap and Edward could moderate subscription via email
> > > > > if they want to, and we could send out a weekly digest to the regular
> > > > > list).
> > > > >
> > > > > Regards,
> > > > > Sheer
> > > > >
> > > > > On Fri, 2 Mar 2001, George Belotsky wrote:
> > > > >
> > > > > >
> > > > > > Is any member of the transport team willing to set up a mailing
> > > > > > list for us?  If not, I can see about setting something up here.
> > > > > >
> > > > > > George.
> > > > > >
> > > > > >
> > > > > > -----------------------------
> > > > > > George Belotsky
> > > > > > Senior Software Architect
> > > > > > Register.com, inc.
> > > > > > [email-masked]
> > > > > > 212-798-9127 (phone)
> > > > > > 212-798-9876 (fax)
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > -----------------------------
> > > > George Belotsky
> > > > Senior Software Architect
> > > > Register.com, inc.
> > > > [email-masked]
> > > > 212-798-9127 (phone)
> > > > 212-798-9876 (fax)
> > > >
> > >
> >
> > --
> > -----------------------------
> > George Belotsky
> > Senior Software Architect
> > Register.com, inc.
> > [email-masked]
> > 212-798-9127 (phone)
> > 212-798-9876 (fax)
> >
> 
> 
> 
> 
> 
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Mon, 5 Mar 2001 10:39:51 -0500
From: George Belotsky <[email-masked]>
To: Sheer El-Showk <[email-masked]>
Cc: [email-masked]
Subject: Re: Transport Team Mailing List.
Sender: [email-masked]

O.K.  Let's wait until tomorrow to hear any objections from
the Transport team, and then set the list up.  It would really
be a useful tool.

George.

On Sat, Mar 03, 2001 at 01:03:44PM -0500, Sheer El-Showk wrote:
> I can set up the list right away but I think subscription
> (not posting, just subscription) should be moderated.  I have
> no problem moderating it myself (I can just check against the
> email address Joap posted) but it would probably be more
> appropriate for Joap and Edward to moderate the subscriptions.
> 
> I await a response from one of them, or a general consensus
> from any design team (since they are supposed to be
> self-administering) as to how to set up the lists subscriptions.
> 
> Regards,
> Sheer
> 
> 
> On Fri, 2 Mar 2001, George Belotsky wrote:
> 
> > I would really appreciate that.  Does everyone else on the Transport
> > Team mind if Sheer sets up our list?
> >
> > George.
> >
> >
> > On Fri, Mar 02, 2001 at 07:06:10PM -0500, Sheer El-Showk wrote:
> > > I'll gladly host mailing lists for any of the groups that need it.  What
> > > are we looking for in terms of a list -- digests, archiving, all that I
> > > have, but a web interface would require some setting up (not that I mind,
> > > but it might just take a little while).  I could set up any regular
> > > mailing lists as soon there is a consensus.
> > >
> > > Please let me know (Joap and Edward could moderate subscription via email
> > > if they want to, and we could send out a weekly digest to the regular
> > > list).
> > >
> > > Regards,
> > > Sheer
> > >
> > > On Fri, 2 Mar 2001, George Belotsky wrote:
> > >
> > > >
> > > > Is any member of the transport team willing to set up a mailing
> > > > list for us?  If not, I can see about setting something up here.
> > > >
> > > > George.
> > > >
> > > >
> > > > -----------------------------
> > > > George Belotsky
> > > > Senior Software Architect
> > > > Register.com, inc.
> > > > [email-masked]
> > > > 212-798-9127 (phone)
> > > > 212-798-9876 (fax)
> > > >
> > >
> > >
> >
> > --
> > -----------------------------
> > George Belotsky
> > Senior Software Architect
> > Register.com, inc.
> > [email-masked]
> > 212-798-9127 (phone)
> > 212-798-9876 (fax)
> >
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

From: "Hollenbeck, Scott" <[email-masked]>
To: "'William Tan'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Signed response
Date: Mon, 5 Mar 2001 07:55:55 -0500 
Sender: [email-masked]

I believe GRRP requirement 11-[2] in the new -00 requirements draft covers
the possibility of signature services if so desired by a registry operator.
Those requirements don't apply to whois, though, so maybe it's something to
consider if/when requirements for whois enhancements are developed.

<Scott/>

-----Original Message-----
From: William Tan [mailto:[email-masked]]
Sent: Sunday, March 04, 2001 2:45 PM
To: [email-masked]; [email-masked]
Subject: Signed response

The PKIX WG has a Online Cert Status Protocol (OCSP) proposal where
the CA runs a service like this answering queries about the status of issued
certificates,
signing the responses.

The concept of signed response by the CA (in this case, registry /
registrar) may be
an important requirement for whois and status request on provreg.  The
reasons are:

1. Result of whois & status queries have been used by lawyers as evidence in
court of law
2. Authenticity of content - client can verify the integrity of the answer
(important data to sign
would be 'Database-updated-date', the query result, or
'No-such-record-at-this-time').

Maybe we should consider this part of the requirement.

wil.

From: "William Tan" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Signed response
Date: Mon, 5 Mar 2001 03:45:15 +0800
Organization: i-DNS.net Internation Inc.
Sender: [email-masked]

The PKIX WG has a Online Cert Status Protocol (OCSP) proposal where
the CA runs a service like this answering queries about the status of issued
certificates,
signing the responses.

The concept of signed response by the CA (in this case, registry /
registrar) may be
an important requirement for whois and status request on provreg.  The
reasons are:

1. Result of whois & status queries have been used by lawyers as evidence in
court of law
2. Authenticity of content - client can verify the integrity of the answer
(important data to sign
would be 'Database-updated-date', the query result, or
'No-such-record-at-this-time').

Maybe we should consider this part of the requirement.

wil.

Date: Fri, 2 Mar 2001 19:11:31 -0500
From: George Belotsky <[email-masked]>
To: Sheer El-Showk <[email-masked]>
Cc: [email-masked]
Subject: Re: Transport Team Mailing List.
Sender: [email-masked]

I would really appreciate that.  Does everyone else on the Transport
Team mind if Sheer sets up our list?

George.

On Fri, Mar 02, 2001 at 07:06:10PM -0500, Sheer El-Showk wrote:
> I'll gladly host mailing lists for any of the groups that need it.  What
> are we looking for in terms of a list -- digests, archiving, all that I
> have, but a web interface would require some setting up (not that I mind,
> but it might just take a little while).  I could set up any regular
> mailing lists as soon there is a consensus.
> 
> Please let me know (Joap and Edward could moderate subscription via email
> if they want to, and we could send out a weekly digest to the regular
> list).
> 
> Regards,
> Sheer
> 
> On Fri, 2 Mar 2001, George Belotsky wrote:
> 
> >
> > Is any member of the transport team willing to set up a mailing
> > list for us?  If not, I can see about setting something up here.
> >
> > George.
> >
> >
> > -----------------------------
> > George Belotsky
> > Senior Software Architect
> > Register.com, inc.
> > [email-masked]
> > 212-798-9127 (phone)
> > 212-798-9876 (fax)
> >
> 
> 

-- 
-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

Date: Fri, 2 Mar 2001 18:43:41 -0500
From: George Belotsky <[email-masked]>
To: [email-masked]
Subject: Transport Team Mailing List.
Sender: [email-masked]

Is any member of the transport team willing to set up a mailing
list for us?  If not, I can see about setting something up here.

George.

-----------------------------
George Belotsky
Senior Software Architect
Register.com, inc.
[email-masked]
212-798-9127 (phone)
212-798-9876 (fax)

To: "Scott Rose" <[email-masked]>
cc: [email-masked], "Edward Lewis" <[email-masked]>
Subject: Re: Provreg Design Teams 
Date: Fri, 02 Mar 2001 21:27:05 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    If more help is needed in the Security group, I'll volunteer.  I've been
    keeping up on the mailing list and reading the drafts, and the WG is a good
    idea.

Much appreciated.

    Is there a separate list for the each group, or just this list?

The design teams (Protocol Transport & Security) of the working
group are supposed to be self organising. I will you send a private mail
with the addresses of the security design team.

	jaap

From: "Scott Rose" <[email-masked]>
To: <[email-masked]>, "Jaap Akkerhuis" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>
Subject: Re: Provreg Design Teams 
Date: Fri, 2 Mar 2001 13:31:29 -0500
Sender: [email-masked]

If more help is needed in the Security group, I'll volunteer.  I've been
keeping up on the mailing list and reading the drafts, and the WG is a good
idea.

Is there a separate list for the each group, or just this list?

Scott
===============================================================
Scott Rose
Advanced Network Technologies Division
NIST

ph: 301-975-8439                       fax: 301-590-0932
http://www.nist.gov
===============================================================

----- Original Message -----
From: "Jaap Akkerhuis" <[email-masked]>
To: <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>
Sent: Friday, March 02, 2001 8:33 AM
Subject: Re: Provreg Design Teams

> On advice and requests received, we decided to shuffle some people
> around. It leaves it somehwat low on security (but of course Bill counts
> for two :-).
>
>  Protocol                     Transport                    Security
> ------------------           ----------------------       ----------------
---
>  Scott Hollenbeck             Dave Crocker                 William Tan
>  Chris Ambler                 George Belotsky              Bill Manning
>  Takeshi Saigoh               Chris Bason                  Sheer El-Shownk
>  Rick Wesson                  Jordyn Buchanan
>  Paul George                  Paul Chow
>  Patrick Mevzek
>  Zhu Yu
>  Eric Brunner Williams
>
> We really would like to see some more people to step forward in
> the transport & security area.
>
> jaap

cc: Edward Lewis <[email-masked]>
To: [email-masked]
Subject: Re: Provreg Design Teams 
Date: Fri, 02 Mar 2001 14:33:00 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

On advice and requests received, we decided to shuffle some people
around. It leaves it somehwat low on security (but of course Bill counts
for two :-).

 Protocol                     Transport                    Security
------------------           ----------------------       -------------------
 Scott Hollenbeck             Dave Crocker                 William Tan
 Chris Ambler                 George Belotsky              Bill Manning
 Takeshi Saigoh               Chris Bason                  Sheer El-Shownk
 Rick Wesson                  Jordyn Buchanan
 Paul George                  Paul Chow                    
 Patrick Mevzek
 Zhu Yu
 Eric Brunner Williams        

We really would like to see some more people to step forward in
the transport & security area.

	jaap

Date: Thu, 01 Mar 2001 17:55:41 -0800
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: James Bryce Clark <[email-masked]>
Subject: Re: FWD: clc-e-contract  
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 09:40 AM 3/1/2001 , Eric Brunner-Williams in Portland Maine wrote:
>
>This from the Cyberspace Law Committee - Electronic Contracting list.
>In a nutshell (tm), registrANT is auto-billed for renewal by registRAR.
>See also:
>http://www.dnso.org/wgroups/wg-review/Arc02/msg01003.html
>We've discussed some aspects of temporal scope of registrations, anyone
>have any thoughts on persistence and renewal?
>
>Eric

Hello Eric and list, 

I'm the author of the e-mail Eric forwarded.   Not as a coincidence, I am
also a chair of an electronic commerce subcommittee of the American Bar
Association's business law group.  

As long as you're on the topic, I thought I would pass along some
additional background.

     *     The e-mail was sent to my committee (which is meeting in
Philadelphia in a few weeks) as the starting point for further discussions
of the manner in which contracts are formed over the Internet.

     *     In the US we have recently enacted federal statutes (and our
states are enacting additional rules) that define the proper scope of uses
of electronic affirmations such as a "Click Here" button, or PKI signature,
or et cetera.    Ideally these rules will make it clear for whom, and for
how long, and with what kind of warnings, an electronic affirmation is
given the same legal enforceability as a signature.    (Of course, a number
of other jurisdictions, and UNCITRAL for the 
UN, also have recently developed rules.  Not all of them are alike.)  

     *     In practice, the exact meaning and application of these rules
may not always be clear.   I have received several reply messages from
lawyer colleagues, who have varying ideas on how the law would apply in the
case I described.  

     *     In fact, in the specific case of my actual domain name, after an
exchange of Internet messages, I simply called the registrar's customer
support line on the day before the renewal deadline.    They responded
promptly, and apparently effectively, to the telephone request to turn off
the described "safe-renew" feature.    

     *     If anyone on this list cares to hear it, I would be happy to
share with you the results of our informal group analysis of the matter,
once we have met in late March.  Just drop me an e-mail.    

Best regards

Jamie Clark

To: [email-masked]
cc: [email-masked], [email-masked]
Subject: FWD: clc-e-contract, 
Date: Thu, 01 Mar 2001 12:40:45 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

This from the Cyberspace Law Committee - Electronic Contracting list.

In a nutshell (tm), registrANT is auto-billed for renewal by registRAR.

See also:
http://www.dnso.org/wgroups/wg-review/Arc02/msg01003.html

We've discussed some aspects of temporal scope of registrations, anyone
have any thoughts on persistence and renewal?

Eric

------- Forwarded Message

Dear Clickwrap team:

Here is a real life example of click-assent that interests me.   Last year
I registered a domain name with a domain registrar.  I used a credit card.
Now the domain is about to expire.  I got the following fascinating e-mail
from the registrar.

Perhaps this will give us something to discuss in Philadelphia.
   *  The gist of it is that they will do me the kindness of AUTOMATICALLY
running the charge back through my last year's credit card data, to renew
for another year,  UNLESS they get an affirmative instruction from me NOT
to do so.
   *   As I recall, the applicable terms and conditions document a year ago
did not give them permission to eterna-charge me, but I will seek further
verification of this point.
   *   I have a bunch of fun screen shots I will bring to Philly, to show
you what happened when I went to the registrar's site to attempt to turn
off this auto-credit-sucking-device.
   *   Bear in mind that, from this company's point of view, arguably I am
a consumer.
   *   Bear in mind that credit card systems have rules and contracts that
overlay  the law there, so there may be more operating here than just statute.

Yours in the spirit of exploration,  Jamie Clark

James Bryce Clark
Spolin Silverman & Cohen LLP
310 586 2404    [email-masked]

>From: [email-masked]
>Subject: Important information about your domain name!
>To:
>Date: Thu, 22 Feb 2001 06:30 -0500
>
>James Clark,
>
>The domain name(s) listed below will expire and be automatically
>renewed on:  MAR 01, 2001.
>
>In order to protect your online identity, it is recommended that
>you renew your domain name(s) now using the link(s) below. You
>can renew your domain name(s) today using xxxxx's easy
>Quick Renew feature. Click on the link(s) below or copy/paste
>the appropriate link (which may be broken into two lines) into
>the Address or Location field of your Web browser for each domain
>name you would like to renew:
>
>*****************************************************************
>Expiration Date: MAR 01, 2001
>
>nlicense.net
>https://secure.xxxxx.com/renewals/?_crypt_=0d42f3ecaa087741777a70e970c209ex
yz123abcetc
>&

* * *

[additional domain names and renew-URL-links omitted]
>
>*****************************************************************
>
>In an effort to protect your online identity, Xxxxx is
>providing SafeRenew(tm) Automatic Renewal Service for your domain
>name(s). This means that upon expiration, we will automatically
>renew your domain name(s) and attempt to charge the credit card
>on file for your domain name(s) for one additional year of
>registration at $35 per name.  This new service will ensure that
>your domain names are secured in the registry for one additional
>year from the current expiration date.
>
>Xxxxx's SafeRenew Service will attempt to charge the
>most recent credit card on file for your domain name(s) upon the
>expiration date of the name(s). To verify that your billing and
>credit card information is current, please log into Domain
>Manager at http://mydomain.xxxxx.com and click on the Billing
>Contact link.
>
>If you do not wish to use xxxxx's SafeRenew Automatic
>Renewal Service, you must visit the following URL and log in to
>disable this service for your domain name(s):
>
>https://secure.xxxxx.com/renewals/disable_saferenew/
>
>Note: If you have already disabled xxxxx.com's SafeRenew
>Service, and have received an email notice confirming that you
>have disabled the service, you do not need to take any further
>action to disable SafeRenew for the domain name(s) listed above.
>Please keep in mind that if you do not disable SafeRenew for your
>domain name, xxxxx.com will attempt to renew the domain name
>registration upon expiration of the name.
>
>For more information on renewing your domain name(s) through
>xxxxx.com, please visit:
>
>http://www.xxxxx.com/faq/renewal.cgi
>
>To contact a Customer Support representative online,
>please visit:
>
>http://www.xxxxx.com/create_ticket.cgi?
>
>Or call:
>Toll free in the U.S. and Canada: (877) xxx-xxxx
>Outside the U.S. and Canada: +1 (212) xxx-xxxx
>
>All domain name registrations and renewals are subject to the
>terms and conditions of our Services Agreement, which can be
>found at:
>
>http://www.xxxxx.com/service-agreement.cgi
>
>Thank you for using xxxxx . . .
>
>Customer Support
>Xxxxx
>. . .
>
>- Copy and Pasting Instructions -
>
>Highlight the URL with your cursor. Once you have highlighted the
>URL, hit CTRL + C (for Mac "Open Apple" + C) to copy the
>highlighted area.
>
>Open an Internet browser window and click in the Address or
>Location field. Hit CTRL + V (for Mac "Open Apple" + V) to paste
>the URL into the address field.  If necessary, repeat this
>process with the second line of the URL. Please be sure to delete
>spaces if there are any embedded in the URL - otherwise you will
>not be able to connect to the proper page.
>
>Once you have entered and looked over the URL, hit the 'Enter' or
>'Return' key on your keyboard. The Web page displayed will allow
>you to renew your domain name(s).
>
>Notification ID: 123456789

------- End of Forwarded Message

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Provreg Design Teams 
Date: Thu, 01 Mar 2001 12:19:22 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed, Jaap,

If it isn't too much bother, would you slide me from the transport column
to the protocol column? 

Tia,
Eric

Date: Thu, 1 Mar 2001 04:16:04 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Provreg Design Teams
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At the interim provreg working group meeting in Washington DC, a need
to form design teams was expressed. From the design teams it is
expected that they will:

    * do an in-depth study as to what needs to be included in the
      protocol specification for a particular area
    * concentrate on part of the draft -or- design
      protocol while evaluating candidate protocols

There is a need for three areas of work:
    * a team looking at the base protocol
    * a team looking at the transport mechanisms/issues
    * a team looking at security

Given the very short timeline for deliverables, it is desirable that
the next IETF meeting is the deadline for the first deliverables:
a presentation of issues and trade-offs with possible strategy
suggestions from each team.

Protocol                     Transport                    Security
------------------           ----------------------       -------------------
 Scott Hollenbeck             Eric Brunner Williams        William Tan
 Patrick Mevzek               Paul Chow                    Dave Crocker
 Chris Ambler                 George Belotsky              Bill Manning
 Takeshi Saigoh               Chris Bason                  Sheer El-Shownk
 Rick Wesson                  Jordyn Buchanan
 Paul George
 Zhu Yu

Recall that the findings of the design teams is not binding on the working
group, but should represent a concentrated, informed opinion.

The protocol team is to concentrate on the issues surrounding the
information or data sent between registr*s.

The transport team is to concentrate on the issues of moving the data.  One
decision, among many, is BEEP/non-BEEP.

The security team is to define the problem - the threats against the
protocol, issues in the use of the data (authorized use and re-use), and
map these problems into issues for the other two groups.

Preliminary findings are to be presented to the group at the Minneapolis WG
meetings (March 18-23).

In a separate email, the addresses of the members will be distributed to
the design team members only.  (Just to limit spam problems, most folks
here have already posted to the list.)

PS - Just to make sure all see this, all members are also Bcc'd on this
message.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.