Subject: RE: [ietf-provreg] EPP Document Updates

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 3 Aug 2005 22:43:06 +0200 (MEST)

Thoughts below...

> -----Original Message-----
> From: Klaus Malorny [mailto:[email-masked]] 
> Sent: Wednesday, August 03, 2005 2:35 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [ietf-provreg] EPP Document Updates
> 
> I did not read the whole thread, so it may have been 
> mentioned there. Today, I 
> discovered a small syntactic issue in the examples given in 
> section 2.9. of RFC 
> 3733. The elements that are used to describe the disclosure 
> are missing the 
> final slash, as they are empty.
> 
> - - - 8< - - -
>     <contact:name type="int">
>     <contact:name type="loc">
>     <contact:org type="int">
>     <contact:org type="loc">
>     <contact:addr type="int">
>     <contact:addr type="loc">
>     <contact:voice>
>     <contact:fax>
>     <contact:email>
> 
>     Example <contact:disclose> element, flag="0":
> 
>     <contact:disclose flag="0">
>       <contact:email>
>       <contact:voice>
>     </contact:disclose>
> 
> 
>     Example <contact:disclose> element, flag="1":
> 
>     <contact:disclose flag="1">
>       <contact:name type="int">
>       <contact:org type="int">
>       <contact:addr type="int">
>     </contact:disclose>
> - - - 8< - - -
> 
> should read
> 
> - - - 8< - - -
>     <contact:name type="int"/>
>     <contact:name type="loc"/>
>     <contact:org type="int"/>
>     <contact:org type="loc"/>
>     <contact:addr type="int"/>
>     <contact:addr type="loc"/>
>     <contact:voice/>
>     <contact:fax/>
>     <contact:email/>
> 
>     Example <contact:disclose> element, flag="0":
> 
>     <contact:disclose flag="0">
>       <contact:email/>
>       <contact:voice/>
>     </contact:disclose>
> 
> 
>     Example <contact:disclose> element, flag="1":
> 
>     <contact:disclose flag="1">
>       <contact:name type="int"/>
>       <contact:org type="int"/>
>       <contact:addr type="int"/>
>     </contact:disclose>
> - - - 8< - - -

You're exactly correct.  Thanks for catching those errors.

> One thing that really puzzles me in this context is that a 
> registrar cannot 
> allow the disclosure of one component (that is normally not 
> disclosed) and to 
> disallow the disclosure of another component (that his 
> normally disclosed) at 
> the same time. But maybe I am just misunderstanding the 
> wording. I think I have 
> to reread this at a later point in time.

Remember that the whole "disclose" thing got crammed into the spec at
the last minute at the demand of the IESG.  There were parts that didn't
make sense then (to me anyway) and I'm sure they still don't make sense
now.  This is another one of those things that we should really consider
removing (if no one is using it) or revising (if it's not quite right).

-Scott-

---

From: "Ram Mohan" <[email-masked]>
Date: Thu, 4 Aug 2005 19:12:42 +0200 (MEST)

Scott, all,
>This is another one of those things that we should really consider removing
>(if no one is using it) or revising (if it's not quite right).

We should consider re-initiating the provreg group.  A number of changes are
due in EPP, and enough registries are now using EPP that actual practice has
exposed both issues and deviances from the protocol.  Further, registries
have implemented extensions that, in some cases, make more sense to be part
of a standard -- the case of what happened with RGP is relevant here.

In the ICANN meeting in Luxembourg, I spoke with a number of gTLD
registries, who expressed interest in reviving the group.  Specifically, I
spoke with GNR, PIR, .TEL, MTLD, VeriSign and NeuStar; presumably direct
notes from these registries are forth-coming.  Several ccTLD registries also
expressed interest in the topic, but did not outright have an opinion on
restarting provreg.

In light of both changes in practice and interest from practitioners, I
would like to ask members of this list to express their opinion and interest
in the re-initiation of the provreg group.

-Ram
--------------------------------------------------------------------------
Ram Mohan
Chief Technology Officer
Vice President, Business Operations
Afilias (http://www.afilias.info)
p: +1.215.706.5700 x103; f: +1.215.706.5701
m: +1.215.431.0958
e: [email-masked]
--------------------------------------------------------------------------

---

From: Eugenio Pinto <[email-masked]>
Date: Thu, 4 Aug 2005 20:04:23 +0200 (MEST)

I'm OK with that

--eugenio (.PT)

Ram Mohan wrote:
<blockquote cite="[email-masked]"
 type="cite">
  Scott, all,

  

-Ram

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 4 Aug 2005 22:13:53 +0200 (MEST)

I'm OK with that too!!

I'm developing an open-registration system based on ISC's OpenReg,
which will be used
for many ccTLDs in latin america.

Francisco Obispo (.VE)

Eugenio Pinto wrote:

> I'm OK with that
>
> --eugenio (.PT)
>
>
> Ram Mohan wrote:
>
>> Scott, all,
>>
>>
>>> This is another one of those things that we should really
>>> consider removing (if no one is using it) or revising (if it's
>>> not quite right).
>>>
>>
>>
>> We should consider re-initiating the provreg group. A number of
>> changes are due in EPP, and enough registries are now using EPP
>> that actual practice has exposed both issues and deviances from
>> the protocol. Further, registries have implemented extensions
>> that, in some cases, make more sense to be part of a standard --
>> the case of what happened with RGP is relevant here.
>>
>> registries, who expressed interest in reviving the group.
>> Specifically, I spoke with GNR, PIR, .TEL, MTLD, VeriSign and
>> NeuStar; presumably direct notes from these registries are
>> forth-coming. Several ccTLD registries also expressed interest
>> in the topic, but did not outright have an opinion on restarting
>> provreg.
>>
>> In light of both changes in practice and interest from
>> practitioners, I would like to ask members of this list to
>> express their opinion and interest in the re-initiation of the
>> provreg group.
>>
>> -Ram
>> Ram Mohan Chief Technology Officer Vice President, Business
>> Operations Afilias (http://www.afilias.info) p: +1.215.706.5700
>> x103; f: +1.215.706.5701 m: +1.215.431.0958 e:
>> [email-masked]

---

From: James Gould <[email-masked]>
Date: Thu, 11 Aug 2005 20:24:18 +0200 (MEST)

All,

I believe the current text describing who receives service messages in RFC 3730 is too strict.  The text that I'm referring to reads:

Service messages MUST be  created for all clients affected by an action on an object. For  example, <transfer> actions MUST be reported to both the client that  requests an object transfer and the client that has the authority to  approve or reject the transfer request.

This means that the client making the request also receives a poll message even through the client receives the same information in the response and can receive the same information with a transfer query.  

I would prefer that the text read like the following:

Service messages MUST be  created for all clients affected by an action on an object that did not directly execute the action. For  example, <transfer> actions MUST be reported to both the client that  requests an object transfer and the client that has the authority to  approve or reject the transfer request for a server action.

Based on the update text, the client that MUST receive a poll message for each transfer operation is below (requesting client is the client that executed the transfer request and the owning client is the current owning client of the object):

Transfer Request &#8211; owning client
Transfer Approve &#8211;requesting client
Transfer Reject &#8211; requesting client
Transfer Cancel &#8211; owning client
Transfer Auto Approve &#8211; owning client and requesting client
Transfer Auto Reject &#8211; owning client and requesting client

-- 

JG 

James F. Gould
VeriSign Naming and Directory Services
[email-masked]

This message is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized use, distribution, or disclosure is strictly prohibited. If you have received this message in error, please notify sender immediately and destroy/delete the original transmission

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Aug 2005 22:29:52 +0200 (MEST)

On Thu, Aug 11, 2005 at 02:24:22PM -0400, James Gould wrote:
> All,
> 
> I believe the current text describing who receives service messages in RFC
> 3730 is too strict.  The text that I'm referring to reads:

I think you're right.  More generally, if I'm reading you correctly,
the principle is that only the uninformed parties are subject to
notification by poll queue for any case where a service message is
required.  But I think your rewording doesn't go far enough.  (I put
some discussion of this in the draft I put up recently -- it's been
submitted since the Paris meeting, but it's still currently only
available at
<http://www.afilias.info/news/events/draft-sullivan-epp-experience-00.txt>,
in case anyone is waiting, breathless).  

To me, one of the strange things about the service message
description in the RFC is that it appears to be both mandatory and
optional.  On the one hand, we have, "Service messages MUST be
created for all clients affected by an action on an object." On the
other hand, we have, "Servers MAY implement other mechanisms to
dequeue and deliver messages if queue maintenance needs exceed server
resource consumption limits."  Since one could easily construct an
argument that any queue at all causes too much overhead, the latter
permission amounts to a permission that the message queue be hooked
up to /dev/null.  Indeed, the description of service messages appears
to require that any effect at all in the repository not explicitly
requested by the client causes a service message to be generated.  So
the repository operator has to be able at least to purge the queue
sometimes, because otherwise it'll consume all the server's
resources.  Hence the provision that servers may use some other
mechanism.

Now, part of the reason for this provision is obviously that
sometimes clients won't clear out their queues.  My impression is
that the "won't clear out" problem is exacerbated by the FIFO nature
of the queue: I know that our registrars want a notification of
things that possibly cost them money (like a transfer loss or an
auto-renewal) way more than they want a notice about something that
costs them nothing (like denying a transfer request).  I'd therefore
like to suggest the addition of a "priority" attribute to the <poll>
command.  This would allow server operators to put messages of
different importance in different queues, and to publish different
retention policies for their different queues.  If a server operator
didn't want to go to the trouble of administering different queues,
the operator could still get the current behaviour by setting all the
priorities to the same value.  A magic priority value (I've suggested
1000, but some other value will do) could be used to indicate "give
me the next highest-priority message".

This approach has the advantage not only that different kinds of
messages can be put into different queues; but that for some of them,
the server could publish (out of band) a retention policy that says,
"queues with priorities 4, 5, and 6 will be retained for 0ms," which
is an effective way of tagging certain kinds of messages as ones that
will never be delivered through the poll queue (internally, an
implementer could just as well drop those messages in the bit
bucket).

If this approach is unacceptable, I think that the message queue should
either be made entirely optional, or that some class of service
messages (preferably "all the ones not explicitly required") be made
optional.  The way 3730 reads today, the message queue is a
bottleneck, and I don't think it was intended to be that way.

Thoughts?

A
-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Aug 2005 18:15:56 +0200 (MEST)

>removing (if no one is using it) or revising (if it's not quite right).

Our implementers support dumping the discloser elements as currently 
specified.  The issue is that the communication is "binary" (ON/OFF, 
YES/NO).  There is legacy data that is not tagged (it wasn't on 
collection), i.e., it should be NULL, UNSPEC, or DON'T CARE.

One bug is that on "create" the submission might be left unspecified 
because the client "doesn't care".  But on "info" the submission, if 
un"tagged" is assumed to follow default behavior.  Doesn't seem very 
symmetric in a protocol sense.

A suggestion is made to also make this a per time tag (but I have a 
sneaking submission that we nixed that in the discussions in 
early/January 2003).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Aug 2005 18:07:44 +0200 (MEST)

>of a standard -- the case of what happened with RGP is relevant here.

I think it's clear that there's a demand (as in supply and demand) 
for coordination of work involving the EPP protocol.  However, I 
don't think there's  justification for an IETF-style working group.

I think there are maybe three factors that prevent the EPP documents 
from being the epitome of perfection.

1) They were produced by humans.  (Meaning errata are needed.)
2) The audience of interest grew as the specifications were put to RFC.
    (Meaning that elements were designed for domain specific applications.)
3) The protocol is supposed to be extensible and future looking.

These are three reasons why there is a demand for EPP coordination. 
But is this demand best met by an IETF WG?

Reason #1 is fairly self-explanatory, a number of textual edits have 
been identified.  If RFC documents were "living" these changes would 
have been made without thought.  An IETF WG isn't needed for this.

Reason #2 is a bit more telling of the culture of the IETF and why I 
think an IETF-style WG might not be the correct path at this moment. 
The IETF isn't the right venue to attract interest of registries. 
For example, CENTR has a higher concentration of attendees that have 
applicable experience and interest in what is happening in EPP now. 
There was a time in which EPP development needed the input of other 
protocol engineering experts.

EPP has an extension mechanism that separates the process of adding 
new messages to the protocol from issue dealing with security and 
transport.  During the IETF run, we had to wrestle with the question 
of whether we could define SMTP as a transport for EPP elements - we 
decided no for various reasons.  This is an IETF question.  How to 
encode ENUM validation data into EPP is much less of a question that 
needs input from, say, the SMTP experts.

I'm sure another run of the PROVREG WG would gather a different and 
probably more well-rounded set of participants than the first try. 
But still, there is no guarantee that we get who we need.

Reason #3 is based on the existence of the final RFC of the original 
EPP documents (3735 I think).  Basically, there is a statement from 
the WG on how to proceed with extensions.  I don't believe this is 
enough, certainly, but I can't imagine how an IETF WG would improve.

For one, just because guidelines are documented doesn't mean that 
"generations" of following implementers will grok and comply fully. 
My other experience is in DNS - looking closely at that I see there 
was about a decade between the original specifications and the 
beginning of a "reformation" in which the ad hoc coding practices had 
"voided" some of the basic assumptions about the DNS.  The result is 
a plethora of badly written code screaming for backwards 
compatibility.

Another factor here is that there are a need to reign in on some 
extension efforts.  Sometimes there is too much freedom to expand and 
you wind up with a bloated protocol.  E.g., let's say each of the 200 
or so registries out there decides to extend EPP in some unique way. 
It's the registrars that suffer trying to maintain a client code base 
with the 200 or so unique extensions.  I don't think this is an 
effort suited to the IETF, especially because it is operations (and 
market) based.

What would be a good reason to reconvene an IETF (style) WG?   A 
reason that requires an engineering solution, a reason that requires 
cross-checking with other protocol domain engineers.

I liked the CENTR meeting that happened the day before the IETF in 
Paris.  It was a dedicated registry meeting yet co-located with the 
IETF engineering meetings.  I realize that CENTR is not the open 
forum that the IETF is, and it is not the only interested party, but 
it is a good example and has a significant  concentration of interest 
in EPP.  To emphasize this one more time - CENTR's meeting is an 
example of a non-IETF group that resulted in some interesting talk on 
EPP.  An example.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2005 21:16:08 +0200 (MEST)

I just remembered that there's one more annoyance that I've forgotten
to mention, but I think we'd benefit from addressing.

RFC 3733 requires (in section 2.4.3) that registrant country be
represented by the ISO 3166 country code.

The problem is, as I'm sure everyone is aware, that the ISO 3166
rules permit not only the obsolescence of a country code, but its
reassignment.  The possibility that a country code will come to refer
to some other country seems to be conceptually broken for our
purposes, because while countries go out of existence (and their
country code is deleted), the addresses often don't change (and even
if they did, there's be precious little way of getting the data from
the contact if one interacts with the person corresponding to the
contact object indirectly).  Formally speaking, this means that
allowing (for instance) YU in an address is not permitted today, even
though it was correct when the address was created.  This is of
course a pain, because the country code is valid at one date, and
becomes invalid later.

I know that people elsewhere in the IETF are struggling with this
problem for considerably more important cases than this one; but is
there anything we can do about it now, while we're looking at these
documents?

A

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Aug 2005 21:40:06 +0200 (MEST)

>there anything we can do about it now, while we're looking at these

Maybe I'm in a particularly prickly mood today (;)) towards opening 
up new work, so here are some comments just to stew over...

1) If a group elsewhere is working on this, maybe it's best to lay 
back.  Especially if there are subject matter experts "over there".

2) Maybe this is an issue not for the EPP interface but for database 
"archival" functions.

I'm counterbalancing the energy to engineer at every corner, that's 
what I am doing.

I admire the desire to "fix" this and the desire to engineer a 
solution, but I would "leave it to the experts" and "solve the 
problem where it truly lay."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2005 22:04:34 +0200 (MEST)

> back.  Especially if there are subject matter experts "over there".

Yes.  I think I may not have been perfectly clear, but part of what I
was trying to say is, "Does anyone know what the status of that work
is?  Did it get anywhere, or was the moaning and gnashing of teeth I
heard the only thing that happened?"  I have no idea what people are
actually going to do about the whole YU/CS debacle, but if someone
else came up with an answer, we might be able just to include it now
while we're at it.

> 2) Maybe this is an issue not for the EPP interface but for database 

Surely not.  If the database has a contact in it with a country code
of YU, and someone does a <contact:info> on that contact, the
repository need to return YU, even though YU is no longer valid under
the normative reference.  (Or, if your view of the normative
reference is that it refers only to the 3166-1 from 1997, replace
this example with some other effective one -- I think the CD/ZR one
will do.)  I suppose I'm being a protocol lawyer, though: we all know
what the _point_ of the reference is, so maybe implicity it's really
3166 for any value of "3166's history".  (That still doesn't solve
the CS-is-Czechoslovakia/CS-is-Serbia-and-Montenegro problem,
though.)

A

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Aug 2005 22:21:43 +0200 (MEST)

Hi,

Taking my cue from your .sig, I have a feeling I don't know what
you're thinking here (since I think I don't understand this).  

> don't think there's  justification for an IETF-style working group.

I read that to mean that you think that there are some people who
think that EPP needs work, but that such work shouldn't go on in an
IETF wg.  And I agree with you that simple changes to the documents
don't need a working group.  

But I'm not sure I follow the subsequent arguments that the IETF is
the wrong place to pursue updates or changes to the protocol.

I appreciate that the IETF doesn't always attract all the registrar
and registry people we might like for feedback on these issues; but
that's a problem I'd suggest we solve by soliciting the feedback of
people in those communities, and _not_ by trying to take our protocol
developments to some other forum.  I have no direct experience of
CENTR, but my few experiences with ICANN committees &c. have left me
with a very strong impression that the technical knowledge does not
there exist to do good protocol development.  That's no indictment of
ICANN: they're doing their policy work, and relying on the technical
community of the Internet to do the technical work.  That community
works within the IETF, no?

There does seem to be a live question of whether all the issues
everyone has identified with EPP can be accommodated without a
protocol change (including, of course, by instead developing
extensions).  So far, I'm not totally convinced; but I'd sure like to
be, which is why I'm pursuing these conversations now.

A

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Aug 2005 09:00:46 -0400

>you're thinking here (since I think I don't understand this).

The quote was derived from a language teacher's comment about a 
sentence "yes, you have to know what the speaker is thinking to 
understand it."  The .sig came to me as I strolled down a street in 
that country some months later.

However, I think you have gotten what I meant.

>don't need a working group.

The idiom "needs work" isn't what I would use.  There are 
enhancements desired to EPP, and extensions for new problem domains. 
However, I have not seen or heard of changes that require a 
re-engineering of the basic protocol.  (Not that there aren't needed 
changes lurking around the corner, but not real to date.)

>works within the IETF, no?

I have a less optimistic view of the IETF process when it comes to 
getting feedback on issues.  When Jaap and I were the co-chairs, most 
of our efforts were to spread the word on EPP.  We were not the kind 
of co-chairs that took a heavy hand in the technical solution, we 
spent more time on process.  Personally I saw my role as "mediating" 
between the reputation EPP garnered as "son of RRP" and "yet another 
tool" of the market dominating player versus the technical benefit it 
provided derived by being initiated by the people with the most 
experience.

It wasn't very easy getting the circle of review to widen.  My 
employer did not have a budget to send my out of the US.  When I did 
have the opportunity, I found that ccTLDs were reluctant to pursue 
EPP for a few reasons, a lot of time because of the resources 
(people) needed.  I recall conversations with "small" ccTLD 
operations that felt they didn't need to look at the documents (not 
enough transaction volume) and that they wouldn't be able to steer 
the IETF anyway.  I saw mail from another ccTLD that was irritated by 
the meddling of "a high ranking IETF official" when trying to get 
them to comment on their proprietary work on the protocol.

I'm making this sound more dire than it is.  The volunteer nature of 
the IETF sometimes is a detriment to the process.  Although I have 
been disappointed with ICANN - it has not met my engineering tastes - 
it is where the money transacted because of EPP resides.  CENTR is an 
organization of registries, a much more concentrated population of 
interest in EPP.  I'm holding up ICANN and CENTR as examples, not as 
solutions, only because they are the ones I am most familiar with in 
this case.

>be, which is why I'm pursuing these conversations now.

That's a healthy attitude and approach, and this mailing list is 
probably the best venue for that.  Starting up an IETF WG takes some 
effort anyway, and even if it could be done with out a BoF, the next 
meeting wouldn't be until November.

I'll say that I am reluctant to propose a new WG in anticipation of 
problems.  Only if there is an engineering problem to hammer out 
would I want to create a group.  In a volunteer organization, 
reactionary stances seem the most efficient.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: "Ram Mohan" <[email-masked]>
Date: Tue, 16 Aug 2005 17:12:00 -0400

Ed, all,
As much as CENTR [or other groups - CDNC comes to mind] is a model for
interested registries to talk EPP implementation details, IETF is likely the
right place for the protocol elements to get moved forward, in an open
"come-right-in" manner. (I expect you already agree with this, I'm simply
saying it explicitly).

> don't think there's  justification for an IETF-style working group.

If you read draft-sullivan-epp-experience, there are at least a few areas
that need engineers to come together to talk protocol and discuss how to
move things forward to the core protocol.

Scott (Hollenbeck), for instance, in some cases advocates the exclusive use
of extensions for modified or new functionality, and in other cases (RGP)
has helped write it into the protocol.

My goal is to not have the EPP documents become the "epitome of perfection",
but one goal would/could/should be to ensure that diversity of
implementations in EPP via extensions for the exact same functionality,
aimed at the exact same community, and used by the exact same participants
not become the lazy alternative to active discussion on which elements
should become part of the core protocol.

> protocol engineering experts.

IETF wg output (and in some cases, even ID track) gets read and digested -
as you know, there a lot of lurkers and only a few active speakers.  Folks I
speak with at many ccTLDs find the IETF work to be both clueful and
participatory, if they choose to.

> But still, there is no guarantee that we get who we need.

There never is a guarantee, but it seems to me that we have a confluence of
demand (not just market demand, but actual engineering ones), interest from
participants, and practical knowledge waiting to be applied appropriately.

-Ram

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 17 Aug 2005 12:14:23 +0200

Ram, all,

I note that this ID seems to concentrate on issues for gTLD type
registries. As en example, the problems signalled over Domain
Registry Grace Period. What I would like to see is a similar document
decsribing more ccTLD centered issues.

    IETF wg output (and in some cases, even ID track) gets read and
    digested - as you know, there a lot of lurkers and only a few
    active speakers.  Folks I speak with at many ccTLDs find the
    IETF work to be both clueful and participatory, if they choose
    to.

Experience learns that these "lurking ccTLD's" go of and do there
own version grumbling that the IETF doesn't really (want to)
understand their need. It would really be much more benificial when
this grumbling would take place during the protocol development and
not during or after last call. You really want most (all) players
on board and be participating.

An other problem, is that there is some work involved setting up
an IETF-WG. There should at least be a BOF which a provisional
charter etc. I think one wants prevent having WG "to discuss
operational issues" which might linger on forever.

When the WG was closed Ed remarked:

	I'd like to thank those involved for helping achieve what
	we set out to do.  I hope that the effort pushes on to Draft
	Standard without the formalization of a new WG.

And yes, getting from Proposed to Draft is another thing that needs
some sonsideration.

	jaap

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Aug 2005 10:34:29 -0400

> decsribing more ccTLD centered issues.

Well, I wrote it on the basis of my experience; and so far, the
primary areas where I've noted difficulties in the protocol are due
to my experiences working with gTLDs.  That isn't to say that the
ccTLDs we support don't have any of these problems; the overloading
of some status values' meanings is, IMO, a difficulty in those
registries as well.

> on board and be participating.

That's precisely why we're beating the bushes looking for people's
experience. 

A