Subject: RE: Registrar-registrar notification
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Date: Tue, 30 Oct 2001 11:10:37 -0500

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 10:22 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Registrar-registrar notification
> 
> 
> When reading through the drafts, the following dilemma 
> appears to be possible.
> 
> Reg A registers domain1.example, with ns1.domain1.example as the name
> server.  (I'm using just one server here for simplicity.)
> 
> Reg B has a customer arrive that wants domain2.example and use
> ns2.domain1.example as its name server.
> 
> Reg B's problem is that it needs Reg A to cooperate and create
> ns2.domain.example before B can proceed fulfilling the order.  The two
> questions here are 1) what is there to motivate A to cooperate <not a
> provreg question> and 2) how does B request A to make the change <assuming
> no hostility>.

I've long maintained that the proper behavior here would be for the customer
to create ns2.domain1.example through the registrar that manages
domain1.example.  I can't imagine a registrar wanting to create name servers
(or any other object) because another registrar wants them to.  As a domain
name registrant, I wouldn't want my registrar of choice to create anything
that falls into the domain1.example name space unless they do it on my
authority.

> The answer to 2 is either a simple call from B to A, or possibly a message
> sent via the registry (and picked up by A via polling or pushing).
> 
> The question to the group: should the protocol define such a notification
> schema/object/message?  If so, perhaps the means are already in the drafts
> - should the drafts discuss the general issue here.
> 
> BTW - the same issue rises when Reg A tries to remove domain1.example.
> ns2.domain1.example is serving domain2.example, so A needs B to break that
> bond first.

This, I think, is the more reasonable scenario.  An existing object
relationship prevents a delete from happening, and some other client has to
break the relationship to make things work.

It would be quite possible for the server to send a pushed/pulled message to
both clients when an operation fails because of an existing object
relationship.  Both clients thus become aware of what needs to change, and
they can work out the details offline.  It would be fairly straight-forward
to add text to the <delete> description to suggest that messages SHOULD be
exchanged in this situation.

I'd prefer to stay far away from any sort of direct registrar-registrar
IM-like services.  Not all registrars will be running the same sort of
clients, and I can see how such exchanges could very well contribute to
accidental or purposeful flooding attacks.

-Scott-

Date: Tue, 30 Oct 2001 10:13:50 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Update on SLC meetings
Cc: [email-masked], [email-masked]
Sender: [email-masked]

We are signed up for a 1-hour multicast slot.  For folks overseas, now is
the time to see if you can arrange for a multicast feed.  Besides getting
the MBone feed (which can be arranged via tunnels) the next issue is
getting attention in the live meeting room.  We'll have to set up an email
link (maybe just this list) for any questions that may be asked during the
sessions.  Perhaps the question won't have to be sent, just notification
that you want to speak.

So far, there is a rumored issue of the "opt-in", first mentioned in:
 http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00145.html

One other issue, one that will be raised shortly in a separate message, has
arisen - but first we should discuss that on the list.

So, being thinking of agenda items (I don't expect many), and bring them up
as soon as you can.  Perhaps we can hammer the issue out in email.

PS - I don't know when the time slot will be.  For those who are concerned
about timezones, SLC will be -0700 (US MST) during the meetings.

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

You fly too often when ... the airport taxi is on speed-dial.

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

Date: Tue, 30 Oct 2001 10:22:17 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Registrar-registrar notification
Cc: [email-masked]
Sender: [email-masked]

When reading through the drafts, the following dilemma appears to be possible.

Reg A registers domain1.example, with ns1.domain1.example as the name
server.  (I'm using just one server here for simplicity.)

Reg B has a customer arrive that wants domain2.example and use
ns2.domain1.example as its name server.

Reg B's problem is that it needs Reg A to cooperate and create
ns2.domain.example before B can proceed fulfilling the order.  The two
questions here are 1) what is there to motivate A to cooperate <not a
provreg question> and 2) how does B request A to make the change <assuming
no hostility>.

The answer to 2 is either a simple call from B to A, or possibly a message
sent via the registry (and picked up by A via polling or pushing).

The question to the group: should the protocol define such a notification
schema/object/message?  If so, perhaps the means are already in the drafts
- should the drafts discuss the general issue here.

BTW - the same issue rises when Reg A tries to remove domain1.example.
ns2.domain1.example is serving domain2.example, so A needs B to break that
bond first.

The group shouldn't dive into making A and B cooperate, but we should
discuss if or how they communicate (within EPP).

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

You fly too often when ... the airport taxi is on speed-dial.

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Patrick'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Domain as Nameserver
Date: Mon, 29 Oct 2001 08:13:52 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Patrick [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 7:52 AM
> 
> 
> On Mon, Oct 29, 2001 at 12:40:12PM -0000, 
> [email-masked] took time to write:
> > Hi,
> > 
> > in draft-ietf-provreg-epp-host-03.txt it states:
> > 
> >   <<This document assumes that host name objects have a subordinate
> >   relationship to a superordinate domain name object.  For 
> example, host
> >   name "ns1.example.com" has a subordinate relationship to 
> domain name
> >   "example.com".  EPP actions (such as object transfers) that do not
> >   preserve this relationship MUST be explicitly disallowed.>>
> > 
> > Let's use the .INFO Registry in our example [1]:
> > 
> > If someone registers example.INFO, the RegistrANT has full 
> control over the example.INFO zone, and he can thus use the 
> domain name itself as a nameserver if he wants to.
> > 
> > Will EPP allows the RegistrANT to add example.INFO as a 
> _nameserver_ in the Registry, or do .INFO nameserver have to 
> be on the third level?
> 
> As far as I have seem from experimentations, they do not, but they
> should (or at least it is not forbidden in the drafts, but they are
> doing many things not explained anywhere)

I agree that this sort of behavior isn't forbidden in the drafts, as it
shouldn't be.  If example.info can exist as a name server in the DNS (and it
can), the protocol should be able to provision a name server with that name.
It might be confusing, but it's DNS-legal.

-Scott-

Date: Mon, 29 Oct 2001 13:52:01 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Domain as Nameserver
Organization: Gandi
Sender: [email-masked]

On Mon, Oct 29, 2001 at 12:40:12PM -0000, [email-masked] took time to write:
> Hi,
> 
> in draft-ietf-provreg-epp-host-03.txt it states:
> 
>   <<This document assumes that host name objects have a subordinate
>   relationship to a superordinate domain name object.  For example, host
>   name "ns1.example.com" has a subordinate relationship to domain name
>   "example.com".  EPP actions (such as object transfers) that do not
>   preserve this relationship MUST be explicitly disallowed.>>
> 
> Let's use the .INFO Registry in our example [1]:
> 
> If someone registers example.INFO, the RegistrANT has full control over the example.INFO zone, and he can thus use the domain name itself as a nameserver if he wants to.
> 
> Will EPP allows the RegistrANT to add example.INFO as a _nameserver_ in the Registry, or do .INFO nameserver have to be on the third level?

As far as I have seem from experimentations, they do not, but they
should (or at least it is not forbidden in the drafts, but they are
doing many things not explained anywhere)

Patrick.

Date: 29 Oct 2001 12:40:12 -0000
From: [email-masked]
To: [email-masked]
Subject: Domain as Nameserver
Sender: [email-masked]

Hi,

in draft-ietf-provreg-epp-host-03.txt it states:

  <<This document assumes that host name objects have a subordinate
  relationship to a superordinate domain name object.  For example, host
  name "ns1.example.com" has a subordinate relationship to domain name
  "example.com".  EPP actions (such as object transfers) that do not
  preserve this relationship MUST be explicitly disallowed.>>

Let's use the .INFO Registry in our example [1]:

If someone registers example.INFO, the RegistrANT has full control over the example.INFO zone, and he can thus use the domain name itself as a nameserver if he wants to.

Will EPP allows the RegistrANT to add example.INFO as a _nameserver_ in the Registry, or do .INFO nameserver have to be on the third level?

[I am not sure if the words "subordinate" or "superordinate" are clear enough...]

Asbjorn Steira
Global Name Registry

[1] Please email me privately for account details... ;-)

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: preparing for Salt Lake City (part 1)
Date: Fri, 26 Oct 2001 10:21:35 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 10:12 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: preparing for Salt Lake City (part 1)
> 
> 
> Even with this issue (which should be presented on the list first anyway),
> and a WG status report, I can't think of more than an hour's worth of
> material.  I think it is time to get some implementation feedback being
> that we've moved into the phase of registries adopting EPP.  It might be
> reasonable to have some discussion on the container draft as it is the
> least mature.
> 
> 1) Will we want to discuss the opt-in schema?

I'd suggest adding it as an agenda item iff a proposal is presented to the
list (with sufficient time for review) first.  If no proposal is
forthcoming, we should move on.

> 2) Are there implementors that are willing to present commentary on the
> specifications?

Yes.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: More EPP-BEEP Comments
Date: Fri, 26 Oct 2001 10:16:27 -0400
Sender: [email-masked]

I have a few more comments/questions after a more thorough reading of Eric,
Ayesha, and Ning's document:

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

1. "Conventions Used In This Document" appears twice, once on page 1 and
again on page 2.  One of these instances should be removed (I'd suggest
removing the second instance).

2. Section 2 says that:

"A EPP session is established when a BEEP channel is established.  The EPP
greeting message will be sent on the BEEP channel when the BEEP channel is
established."

Which channel does this statement refer to?  Is it channel 0 (used for
channel management), or a new channel that has to be created per section
2.3.1.2 of RFC 3080?  The text isn't clear on this significant detail.
Similarly, ending the EPP session as described in the following paragraph
doesn't clearly identify which channel or channels must be released when
ending an EPP session.  Could a forward reference to section 2.1.4 or some
explicit text be added to note that a new channel is created?

3. We've talked about URI schemes for profile identification, and Marshall
Rose has a draft that describes a proposal to identify IETF-defined
profiles.  Assuming that the URI listed in section 2.1 is going to change
based on earlier list discussions, a reference to Marshall's draft should be
added to section 2.1.

4. Section 2.1.2 describes connection establishment, but again there's no
mention of the BEEP channel on which EPP exchanges should take place.
Again, it would be helpful to either say explicitly that a new channel is
created, or provide a forward reference to section 2.1.4.

5. We've already talked about changing the Content-Type value described in
section 2.1.2.

6. Section 2.1.6 says that "Each EPP command/response payload is preceded by
the EPP tag <epp version="1.0">..."  This isn't true; the version info is
carried in the URI as illustrated in the given example.

7. Section 2.1.7 says that "EPP session termination is performed as part of
data exchange on the channel with the EPP <logout> command, which also
terminates the respective BEEP channel.".  Which BEEP channel?  The one
created for the EPP profile, channel 0, or both?

8. Given the different security profiles available for BEEP, would it be
possible to add some text to the "Security Considerations" section to
reference a specific set of security profiles?  Yes, TLS and SASL are
described, but could the profiles be explicitly identified (and referenced)?

That's it, nothing earth-shattering.

-Scott- 

Date: Fri, 26 Oct 2001 10:11:49 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: preparing for Salt Lake City (part 1)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Even with this issue (which should be presented on the list first anyway),
and a WG status report, I can't think of more than an hour's worth of
material.  I think it is time to get some implementation feedback being
that we've moved into the phase of registries adopting EPP.  It might be
reasonable to have some discussion on the container draft as it is the
least mature.

1) Will we want to discuss the opt-in schema?
2) Are there implementors that are willing to present commentary on the
specifications?

Other than that there is the always persent desire to add enhancements, but
it is way to early to begin on that.  I'd like to wait until we have at
least sent the documents to the IESG.

I'd like to hear comments on this as the IETF planning clock is ticking.
If we can shrink to an hour, we might have a better chance at getting a
multicast session.  (I'm guessing, I haven't asked yet.  I will inquire in
my next outgoing message.  I promise.)

At 8:49 AM -0400 10/23/01, Hollenbeck, Scott wrote:
>We have an open issue ("opt-in" schema, recently raised by Paul Kane [1])
>awaiting a proposal for continued discussion.  We may need discussion time
>if a proposal is available before the meeting.
>
>Paul/Pindar: Have you made any progress in putting together a proposal?
>Will it be available in time to start a discussion on the list, and maybe
>talk about it in Salt Lake City?

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

You fly too often when ... the airport taxi is on speed-dial.

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

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: preparing for Salt Lake City (part 1) 
Date: Fri, 26 Oct 2001 09:57:06 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Based on this, it seems that we don't really need a second hour. 

Agree.

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Trafficking documents 
Date: Fri, 26 Oct 2001 09:32:15 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> It appears to me that we want to advance (when ready) documents #2,3,4,5 as
> a unit, and docs #6,7 optionally as the same unit - or at least separately
> but at close to the same time.
> 
> Document #8 isn't tied to the base specification and can travel separately.
>
> I'm not sure if we still need document #9.

I agree.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>, Edward Lewis <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Trafficking documents
Date: Thu, 25 Oct 2001 14:50:17 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Thursday, October 25, 2001 2:41 PM
> To: Edward Lewis
> Cc: [email-masked]; [email-masked]
> Subject: Re: Trafficking documents
> 
> 
> 
> Ed,
> 
> what about the e164 mapping scott added a while back?

(Jumping in...)

That's an individual submission that the ENUM WG has expressed some interest
in, but I don't think it fits into our current charter.

-Scott- 

Date: Thu, 25 Oct 2001 11:40:32 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: Re: Trafficking documents
Sender: [email-masked]

Ed,

what about the e164 mapping scott added a while back?

-rick

On Thu, 25 Oct 2001, Edward Lewis wrote:

> The WG has a few internet drafts under consideration:
>
> 1) The requirements
> 2) EPP base
> 3)   EPP domain mapping
> 4)   EPP host mapping
> 5)   EPP contact mapping
> 6)   EPP over TCP
> 7)   EPP over BEEP
> 8)   Containers in EPP
> 9) Definitions
>
> Doc #1 has been returned to the IESG.  I haven't heard any feedback on that
> yet.
>
> It appears to me that we want to advance (when ready) documents #2,3,4,5 as
> a unit, and docs #6,7 optionally as the same unit - or at least separately
> but at close to the same time.
>
> Document #8 isn't tied to the base specification and can travel separately.
>
> I'm not sure if we still need document #9.
>
> Any comments on this plan?
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
>
> You fly too often when ... the airport taxi is on speed-dial.
>
> Opinions expressed are property of my evil twin, not my employer.
>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Trafficking documents
Date: Thu, 25 Oct 2001 14:22:23 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Thursday, October 25, 2001 1:27 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Trafficking documents
> 
> 
> The WG has a few internet drafts under consideration:
> 
> 1) The requirements
> 2) EPP base
> 3)   EPP domain mapping
> 4)   EPP host mapping
> 5)   EPP contact mapping
> 6)   EPP over TCP
> 7)   EPP over BEEP
> 8)   Containers in EPP
> 9) Definitions
> 
> Doc #1 has been returned to the IESG.  I haven't heard any feedback on
that
> yet.
> 
> It appears to me that we want to advance (when ready) documents #2,3,4,5
as
> a unit, and docs #6,7 optionally as the same unit - or at least separately
> but at close to the same time.

I'd rather not explicitly tie #6 and #7 given the relative maturity of the
two documents.  I suspect that #6 is closer to being "done" than #7, so it
may make sense to move #6 forward as part of the #2-#5 package so that
there's at least one transport document to complete the package.  2-5
without a transport document isn't a complete package.

There haven't been very many comments directed towards epp-BEEP; I'd like to
know if that's due to folks being happy with the draft, not having looked at
it yet, or if there's a lack of interest.  I've provided some comments based
on a cursory read, but I haven't yet had a chance to give it the more
thorough reading that's needed for me to feel as comfortable with it as I do
with epp-TCP.

-Scott-

Date: Thu, 25 Oct 2001 13:26:49 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Trafficking documents
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The WG has a few internet drafts under consideration:

1) The requirements
2) EPP base
3)   EPP domain mapping
4)   EPP host mapping
5)   EPP contact mapping
6)   EPP over TCP
7)   EPP over BEEP
8)   Containers in EPP
9) Definitions

Doc #1 has been returned to the IESG.  I haven't heard any feedback on that
yet.

It appears to me that we want to advance (when ready) documents #2,3,4,5 as
a unit, and docs #6,7 optionally as the same unit - or at least separately
but at close to the same time.

Document #8 isn't tied to the base specification and can travel separately.

I'm not sure if we still need document #9.

Any comments on this plan?

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

You fly too often when ... the airport taxi is on speed-dial.

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

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: preparing for Salt Lake City (part 1)
Date: Tue, 23 Oct 2001 08:49:49 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Monday, October 22, 2001 2:16 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: preparing for Salt Lake City (part 1)
> 
> 
> I've submitted a request for a time slot at the meetings coming up in Salt
> Lake City.  I have asked for a two hour slot, but wonder if perhaps we can
> get by with a one hour slot.

We have an open issue ("opt-in" schema, recently raised by Paul Kane [1])
awaiting a proposal for continued discussion.  We may need discussion time
if a proposal is available before the meeting.

Paul/Pindar: Have you made any progress in putting together a proposal?
Will it be available in time to start a discussion on the list, and maybe
talk about it in Salt Lake City?

-Scott-

[1] Paul's note:
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00145.html

To: Rick H Wesson <[email-masked]>
cc: Bruce Tonkin <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: FW: preparing for Salt Lake City (part 1) 
Date: Tue, 23 Oct 2001 01:19:30 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Rick,

The PRC is currently restricting travel to the US, due to the "instability",
which affects .CN's participation at the MdR meeting of ICANN, and may also
affect the participation of cnnic staff at IETF-52.

Eric

Date: Mon, 22 Oct 2001 21:57:58 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Bruce Tonkin <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: FW: preparing for Salt Lake City (part 1)
Sender: [email-masked]

Bruce,

although the media would have you believe otherwze the USA is not at WAR.

-rick

On Tue, 23 Oct 2001, Bruce Tonkin wrote:

>
>
> -----Original Message-----
> From: Bruce Tonkin
> Sent: Tuesday, October 23, 2001 1:01 PM
> To: 'Edward Lewis'
> Subject: RE: preparing for Salt Lake City (part 1)
>
>
> Hello Edward,
>
> Is there a chance that the provreg meeting might be multi-cast over the
> Internet?
>
> Getting corporate approval to travel to the USA is getting increasingly
> difficult for many of us based outside the USA given recent military and
> terrorist action, and it would be good to continue to get involvement from
> an international perspective in provreg.  For example travel insurance is
> often void when a country is at war.
>
> Regards,
> Bruce Tonkin
>

Date: Mon, 22 Oct 2001 23:58:30 -0400
To: Bruce Tonkin <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: FW: preparing for Salt Lake City (part 1)
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Good point.  I can ask, but I would not be optimistic.  Although we were
multicasted from London, we aren't one of the largest groups and I'm not
sure we are one of the most country-distributed.  (Perhaps the ccTLD
element makes us rate higher, I just don't know.)

At 11:01 PM -0400 10/22/01, Bruce Tonkin wrote:
>-----Original Message-----
>From: Bruce Tonkin
>Sent: Tuesday, October 23, 2001 1:01 PM
>To: 'Edward Lewis'
>Subject: RE: preparing for Salt Lake City (part 1)
>
>
>Hello Edward,
>
>Is there a chance that the provreg meeting might be multi-cast over the
>Internet?
>
>Getting corporate approval to travel to the USA is getting increasingly
>difficult for many of us based outside the USA given recent military and
>terrorist action, and it would be good to continue to get involvement from
>an international perspective in provreg.  For example travel insurance is
>often void when a country is at war.
>
>Regards,
>Bruce Tonkin

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

You fly too often when ... the airport taxi is on speed-dial.

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

From: Bruce Tonkin <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: preparing for Salt Lake City (part 1)
Date: Tue, 23 Oct 2001 13:01:40 +1000
Sender: [email-masked]

-----Original Message-----
From: Bruce Tonkin 
Sent: Tuesday, October 23, 2001 1:01 PM
To: 'Edward Lewis'
Subject: RE: preparing for Salt Lake City (part 1)

Hello Edward,

Is there a chance that the provreg meeting might be multi-cast over the
Internet?

Getting corporate approval to travel to the USA is getting increasingly
difficult for many of us based outside the USA given recent military and
terrorist action, and it would be good to continue to get involvement from
an international perspective in provreg.  For example travel insurance is
often void when a country is at war.

Regards,
Bruce Tonkin

Date: Mon, 22 Oct 2001 14:15:32 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: preparing for Salt Lake City (part 1)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I've submitted a request for a time slot at the meetings coming up in Salt
Lake City.  I have asked for a two hour slot, but wonder if perhaps we can
get by with a one hour slot.

The current state of the WG is: the requirements document has been returned
to the IESG and is awaiting action, recent updating of most of the WG EPP
drafts, and discussions of largely detailed nature on the list - with the
list being mostly quite in recent weeks.

Based on this, it seems that we don't really need a second hour.  Does
anyone have a reason to believe that we need a two hour meeting (as opposed
to a one hour meeting)?

Sooner or later we will being to address an agenda for the meeting.

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

You fly too often when ... the airport taxi is on speed-dial.

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

From: Bruce Tonkin <[email-masked]>
To: [email-masked]
Subject: ".au" - first country code to require EPP
Date: Mon, 22 Oct 2001 15:07:47 +1000
Sender: [email-masked]

Hello All,

In response to public comments on the initial ".au" technical standard,
".au" is now the first significant country code (that I know of) to require
the use of EPP.

See:
http://www.auda.org.au/docs/registry-rft-part7.pdf

".au" is a domain space with a strong policy requirement and will be
implemented as a thick registry.  It will provide useful experience in the
refinement of EPP to an IETF standard.

Bruce Tonkin

Date: Mon, 15 Oct 2001 08:57:32 +0200 (MEST)
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Broken mailer at cafax.se.
From: Lars-Johan Liman <[email-masked]>
Sender: [email-masked]

Friends,

On October 6 I upgraded sendmail to version 8.12.1 on nic.cafax.se,
the box that handles the lists mentioned above. It's now clear that
that version contains a serious bug that shows its ugly face on NetBSD
and some other OSs, but only when you try to send mail by forking off a
new sendmail, and you happen to be a non-root user. This is true for
local users with old MUAs, and for Majordomo. This is not true for
most part of the mail traffic (including my own) that goes through
that machine. My friend Johnny (local user) spotted the problmem on
the 10th, and the problem was worked around. The bug was identified
and a final fix was installed on the 12th.

The consequence of the bug is that messages to lists managed by
Majordomo on my box, just "disappeared" without any more alarm than a
silent whisper in the log file, in the style of:

Oct 10 13:54:57 nic sendmail[6978]: NOQUEUE: SYSERR(majordom):
  drop_privileges: setgid(14) failed: Operation not permitted

This mainly hit the lists

  [email-masked]
  [email-masked]
  [email-masked]

If you sent a message to any of the above lists during the period
October 6 - October 12, I'll have to ask you to resend it. It didn't
even reach the mail archives at nic.cafax.se.

My profuse apologies. :-(

				Best regards,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman		! E-mail: [email-masked]
# Senior Systems Specialist     ! HTTP  : //www.autonomica.se/
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72
#----------------------------------------------------------------------

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: EPP Document Update 
Date: Thu, 4 Oct 2001 07:49:38 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Tuesday, October 02, 2001 3:35 PM
>To: Hollenbeck, Scott
>Cc: [email-masked]'
>Subject: Re: EPP Document Update 
>
>
>http fails,
>anonymous (command-line) ftp fails, can cd pub/epp/20011002, dir fails.

If anyone else is having trouble retrieving the sample instnace and schema
files, I've made them available from another source that should work for
anyone with a web browser.  Here's the link:

http://www.verisign-grs.com/files/

Older versions of the files are up there as well for comparison purposes.

<Scott/>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-tcp-03.txt
Date: Thu, 04 Oct 2001 07:04:21 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Transport Over TCP
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-tcp-03.txt
	Pages		: 9
	Date		: 03-Oct-01
	
This document describes how an Extensible Provisioning Protocol (EPP)
session is mapped onto a single Transmission Control Protocol (TCP)
connection.  This mapping requires use of the Transport Layer Security
(TLS) Protocol to protect information exchanged between an EPP client
and an EPP server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-tcp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-tcp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-tcp-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-tcp-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-host-03.txt
Date: Thu, 04 Oct 2001 07:04:15 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Host Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-host-03.txt
	Pages		: 30
	Date		: 03-Oct-01
	
This document describes an Extensible Provisioning Protocol (EPP) map-
ping for the provisioning and management of Internet host names stored
in a shared central repository.  Specified in XML, the mapping defines
EPP command syntax and semantics as applied to host names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-host-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-host-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-host-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-host-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-domain-03.txt
Date: Thu, 04 Oct 2001 07:04:09 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Domain Name Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-domain-03.txt
	Pages		: 9
	Date		: 03-Oct-01
	
This document describes an Extensible Provisioning Protocol (EPP) map-
ping for the provisioning and management of Internet domain names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-domain-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-domain-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-domain-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-domain-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-contact-03.txt
Date: Thu, 04 Oct 2001 07:04:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Contact Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-contact-03.txt
	Pages		: 40
	Date		: 03-Oct-01
	
This document describes an Extensible Provisioning Protocol (EPP) map-
ping for the provisioning and management of individual or organiza-
tional social information identifiers (known as 'contacts') stored in
a shared central repository. Specified in XML, the mapping defines EPP
command syntax and semantics as applied to contacts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-contact-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-contact-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-contact-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-contact-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-05.txt
Date: Thu, 04 Oct 2001 07:03:55 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-05.txt
	Pages		: 73
	Date		: 03-Oct-01
	
This document describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared cen-
tral repository.  Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects.  This document includes a protocol
specification, an object mapping template, and an XML media type
registration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: EPP Document Update 
Date: Tue, 2 Oct 2001 16:38:15 -0400 
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 3:35 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: EPP Document Update 
> 
> 
> http fails,
> anonymous (command-line) ftp fails, can cd pub/epp/20011002, 
> dir fails.

Command line works just fine for me, though I do have problems getting to
the server via http from my office environment:

> ftp ftp.verisign.com
Connected to ftp.verisign.com.
220-Welcome to the anonymous FTP server at VeriSign, Inc.
220-
220-All commands are logged.  Unauthorized use of this server
220-is strictly prohibited.
220-
220-If you have any questions or comments, please contact
[email-masked].
220-
220-The local time is now: Tue Oct  2 13:39:15 2001
220-
220 ftp1 FTP server (Version wu-2.6.1(1) Wed May 30 12:13:57 PDT 2001)
ready.
Name (ftp.verisign.com:foo): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password:
230 Guest login ok, access restrictions apply.
ftp>  cd pub/epp/20011002
250 CWD command successful.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 116
drwxr-sr-x   2 root     ftp          512 Oct  2 11:07 .
drwxr-sr-x   5 root     ftp          512 Oct  2 11:01 ..
-rw-r--r--   1 root     ftp         5012 Oct  2 11:04 e164-01.tar.gz
-rw-r--r--   1 root     ftp         8114 Oct  2 11:04 e164-01.zip
-rw-r--r--   1 root     ftp        10548 Oct  2 11:04 epp-05.tar.gz
-rw-r--r--   1 root     ftp        32206 Oct  2 11:04 epp-05.zip
226 Transfer complete.
398 bytes received in 0.026 seconds (14.98 Kbytes/s)
ftp>

I _have_ seen some strange behavior when trying to do an "ls" command in
either /pub or /pub/epp, but the "dir" command seems to work for me quite
well.  I can do the above using both Sun Solaris 2.8 and Windows 2000; what
kind of client are you using?

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: EPP Document Update 
Date: Tue, 02 Oct 2001 15:35:11 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

http fails,
anonymous (command-line) ftp fails, can cd pub/epp/20011002, dir fails.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP Document Update
Date: Tue, 2 Oct 2001 14:25:08 -0400 
Sender: [email-masked]

Earlier today I sent updated EPP documents to the I-D administrator.  I
expect they'll be announced tomorrow barring any unforeseen problems.  I've
also pushed updated .zip and .tar.gz archives containing updated instance
examples and schema files to a public ftp server for anonymous retrieval.
Here's the URL:

ftp://ftp.verisign.com/pub/epp/20011002

Command line ftp should work if your browser has trouble getting through to
the server.

These updates address the things described earlier as "to-do" [1] and
discussion that took place since the to-do items were sent to the list.  A
first cut at data collection policy element definition is included, but
there's nothing in there for opt-in or opt-out specification.

<Scott/>

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