Subject: Re: Message Pushing and TCP Transport
From: Patrick <[email-masked]>
To: [email-masked]
Date: Fri, 31 Aug 2001 19:56:18 +0200

On Wed, Aug 29, 2001 at 08:29:04PM -0400, Eric Brunner took time to write:
> 
> >  ... the msqQ element of the <result> item of *any* command
> > tells him how many messages are waiting.
> > (see 2.5 of the EPP draft)
> 
> >From Sec. 4 Formal Syntax, Sub 1. Base Schema
> (Note: <qDate> added in the -03 to -04 delta)
> 
>     <complexType name="msgQType">
>       <sequence>
>         <element name="qDate" type="dateTime"
>          minOccurs="0" />
>       </sequence>
>       <attribute name="count" type="unsignedLong"
>        use="optional" default="0"/>
>     </complexType>
> 
> An unsigned long type holds the type-bounded number of enqueued messages.
> A dateTime type holds the temporal identifiers of message enquements. 
> 
> There is no guarantee that the value in the long and the ordinality
> of the dateTime sequences are equal.
> 
> Restated, there are N enqueued messages, and M temporal identifiers,
> in a msgQ element. M may be equal to, or less than, or more than, N,
> and the M temporal identifiers need not be unique, or ordered.
> 
> Finally, the msgQ element's value is associated with a command, having a
> fixed momentary value.
> 
> The atomicity of EPP operations does not necessarily extend the semantics
> of the msgQ values to the acutal enquements between commands, that is, it
> is not a sychronization primitive between queue reader and writer threads.
> 
> I'm sorry to be so long winded, I agree with your observation _most_ of
> the time. I wish I could agree with it _all_ of the time.

Except that in the setup I explained to you (that is viewing the
results of NON poll queries) the problem you outline is not there,
since the drafts says :
The <qDate>
element MUST be present when returning a message in a <poll>
response, and it MUST be absent otherwise.

When the client does it businnes, in any reply he may get a count
(but no qDate). If the count exist, it means message are waiting,
then it can do a poll to grab them.

Patrick.

To: [email-masked]
cc: [email-masked]
Subject: Re: Message Pushing and TCP Transport
Date: Wed, 29 Aug 2001 20:29:04 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

>  ... the msqQ element of the <result> item of *any* command
> tells him how many messages are waiting.
> (see 2.5 of the EPP draft)

>From Sec. 4 Formal Syntax, Sub 1. Base Schema
(Note: <qDate> added in the -03 to -04 delta)

    <complexType name="msgQType">
      <sequence>
        <element name="qDate" type="dateTime"
         minOccurs="0" />
      </sequence>
      <attribute name="count" type="unsignedLong"
       use="optional" default="0"/>
    </complexType>

An unsigned long type holds the type-bounded number of enqueued messages.
A dateTime type holds the temporal identifiers of message enquements. 

There is no guarantee that the value in the long and the ordinality
of the dateTime sequences are equal.

Restated, there are N enqueued messages, and M temporal identifiers,
in a msgQ element. M may be equal to, or less than, or more than, N,
and the M temporal identifiers need not be unique, or ordered.

Finally, the msgQ element's value is associated with a command, having a
fixed momentary value.

The atomicity of EPP operations does not necessarily extend the semantics
of the msgQ values to the acutal enquements between commands, that is, it
is not a sychronization primitive between queue reader and writer threads.

I'm sorry to be so long winded, I agree with your observation _most_ of
the time. I wish I could agree with it _all_ of the time.

> There is no overhead : the client does its usual business stuff
> (that is : it does NOT use the POLL command). 
> Sometimes, as a result of whatever command, the server (Registry)
> will tell him it has some messages in queue.
> *Then* the Registrar does the poll to get them. (immediately or later
> at its convenience).
> 
> The point is that the client has *never* to send a specific command
> to know if messages are waiting. This information (the number of
> messages) is pushed (!) by the Registry with the result of a command.

I'd like to gently suggest that you simply need to add "approximate"
to your first parenthetical remark, and point out that subsequent fetch
of the (approximate) number will return the same, or perhaps a slightly
different number of messages, if it returns all of the messages enqueued 
at the moment the client-originated fetch is server-serviced. It might,
in the "at its [the client] convenience" mode of your example, return fewer
messages than the given value, as dequeue and alternate delivery are still
an option for the server.

> In that setup I see no problems of scale.

I'm going fishing, exact weights and measures are such a drag, and as a
registry operator, I don't have to panic if the transactions you loose
are yours. It shouldn't happen very often, and I guess I can always rate
throttle you if your attempt to limit the proximal variations cause me
to tend towards reduced good-put due to poll-boundedness.

Eric

From: Bruce Tonkin <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Pushing vs. Pulling
Date: Thu, 30 Aug 2001 09:54:00 +1000
Sender: [email-masked]

> 
> BTW, the Push-Pull straw poll did have one benefit.  Scott 
> suggested that
> polling is a MUST, pushing a MAY.  Perhaps this is the middle 
> ground to
> build upon.  (Comments on this, please.)
> 

I support this middle ground.

In terms of what is used commonly in practice - it will depend on the
application.
I am sure that the new registries will seek to differentiate their services
from the dominant ".com" registry, and new applications/services will
emerge.   Lets not limit the protocol to support the current dominate
registry service, but leave flexibility to build new services without
re-engineering the protocol.

Bruce Tonkin

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Pushing vs. Pulling
Date: Wed, 29 Aug 2001 19:45:29 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 6:59 PM
> To: Edward Lewis
> Cc: [email-masked]
> Subject: Re: Pushing vs. Pulling
> 
> 
> At 09:23 AM 8/29/2001, Edward Lewis wrote:
> >BTW, the Push-Pull straw poll did have one benefit.  Scott suggested that
> >polling is a MUST, pushing a MAY.  Perhaps this is the middle ground to
> >build upon.  (Comments on this, please.)
> 
> yes!

What Dave said.

I have some ideas on how this can be accomplished relatively easily, and
will float them by the list early next week if we reach rough consensus on
this approach.

<Scott/>

Date: Wed, 29 Aug 2001 16:03:55 -0700
To: Patrick Greenwell <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Cc: [email-masked]
Sender: [email-masked]

At 09:11 AM 8/29/2001, Patrick Greenwell wrote:
>As the number of registries and registrars scale, it might be much more
>appropriate to have those registries PUSHing messages only to those
>that have messages in the queue rather than having the registrars blindly
>polling each registry on a timed interval.

Patrik, this is establishing a very dangerous pattern.  Besides agreeing 
with a suggestion from Scott, I'm now forced to agree with your 
observation.  If a registrar is inactive, it should not be keeping a 
connection in place, wasting server resources.

In fact, the idea that the push could include having no connection in 
place, but have the *registry* establish the connection to the registrar, 
is not something we have discussed (as far as I have seen.)

As you note, however, there is a very strong scaling argument for that sort 
of mode of operation.  (Back in the days of doing disconnected email 
relaying, I called this "mixed initiative.)

thanks!

d/

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

Date: Wed, 29 Aug 2001 15:59:21 -0700
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Pushing vs. Pulling
Cc: [email-masked]
Sender: [email-masked]

At 09:23 AM 8/29/2001, Edward Lewis wrote:
>BTW, the Push-Pull straw poll did have one benefit.  Scott suggested that
>polling is a MUST, pushing a MAY.  Perhaps this is the middle ground to
>build upon.  (Comments on this, please.)

yes!

d/

ps.  Occasionally the meaning of must vs. may is confused (and confusing) 
in IETF discussions. My own understanding of the usage is that MUST means 
that any conforming implementation must support the capability.  However 
even a must does not mean that the capability must be USED during operation.

A MAY means that a conforming implementation is permitted to include the 
capability, but is not required to.  However the mechanism defined by the 
MAY is the "standards" way of doing the task that is defined.  In this 
case, that would mean that if push is supported by an implementation a 
standards conformant implementation will perform push in the way defined by 
the MAY.

Just for completeness, it is worth noting that a third type of requirement 
level in IETF work is in between may and must:  SHOULD.  SHOULD means that 
it is strongly recommended that the feature be supported in the 
implementation -- again note that this does not require its use during 
actual operation -- but that an implementation may choose not to support 
it... if there is a very good reason.  (That sounds fuzzy, and it 
is.  Essentially, it means that there is strong pressure to support the 
feature, but you are still allowed to claim conformance without it.  On the 
other hand, you should expect customers to ask you to defend the decision.)

Hence, MAY is actually a very modest standards level of requirement.

d/

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

Date: Wed, 29 Aug 2001 14:31:18 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: Pushing vs. Pulling
Sender: [email-masked]

Edward Lewis wrote:

>
>BTW, the Push-Pull straw poll did have one benefit.  Scott suggested that
>polling is a MUST, pushing a MAY.  Perhaps this is the middle ground to
>build upon.  (Comments on this, please.)
>
The argument that the protocol have a base set of MUSTs and any number 
of MAYs for extensions (sometimes registry-specific), IMHO, somewhat 
undoes what were trying to do, right?

Let's say the group favours a MUST for Poll and a MAY for Push.  All 
registries would implement Poll because they MUST and some registries 
MAY additionally implement Push.  If a registrar is using the same 
client software to connect to [all] EPP registries, they would implement 
Poll because they MUST, but what would be incentive for the registrar to 
implement Push code if Pull is working fine?

Is there a problem with a protocol that is too accomodating?  Could a 
single protocol that is "too" extensible eventually fracture into 
multiple protocols?  (although these last two questions might get me a 
little out of scope of the original email)

Dan

To: [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: Pushing vs. Pulling
Date: Wed, 29 Aug 2001 14:07:59 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

> Speaking as the WG chairs, we'd like to make a few comments about the
> push-pull debate.

Thanks Ed, Jaap, this is good chairing.

> There is a consensus in the group that the group wants one protocol.  We
> take this to mean that a registrar doing business with two different
> registries wants to use just one set of software.  Please allow me to delve
> into a somewhat arbitrarily concrete example.  Let's say I want to register
> names in .com and .biz.  Would I expect to be running a (software) client
> from each, or should one client be sufficient.  As it seems the group's
> desire, it would seem to me to have just one client.  (Our question: is
> this a good assumption?)

Sigh. This is only one area where lines blur. Taking off a hat I've worn to
the point of acute discomfort, I write today as an individual participant.

There exist two, possibly more, distinct implementations of a "client". This
would be "good" in the usual IETF sense (of advance to DS iff 2 independent
implementations exist), but there are complications. One implements an IDL
initially published in April, and subsequently revised, that approximates
the current drafts. One implements an approximation of the current drafts,
without the benefit (or detriment) of an IDL. Both exist in win32 and *ix
forms, and both expose JAVA and C/C++ APIs. Both (last I checked) attempt
to impose additional constraints (cruft for trademark in the IDLized one,
and cruft for listening in the other).

I'll let the registrars, NSI, Register, Bulk, Tucows, MIT, etc., offer the
definitive answer on whether they will use "one client" (Tucows') when .biz
goes live, and also whether they will use the "same" client, or will or have
already written a client.

The desire to have "just one client" is defensible if we are concerned with
those of who don't intend, unlike some of the above, to implement a second
(in a series of "seconds") client. If we are concerned with those who were
going to roll their own anyway, then we are over-specifying, probably with
the effect of selecting business models, e.g., registrar product definition
vs registry product definition. That's how I read the subtext.

> Now, the chairs realize that this is the IETF and organizations don't count
> for much, and that we are to be looking beyond the registration of domain
> names.  But we want to determine if there should be a latent assumption of
> any client software should speak full EPP (or whatever) in order to speak
> with all registries.

Should the (hypothetical) universal client be capable of provisioning
registry-specific stuff, e.g., trademark for .info, and doing so via
registry-specific mechanisms, e.g., pushed trademark "watch" notices for
.biz, and that over specific registry-profiled AAA and transport mandates,
e.g., enSASLed BEEP for .biz?

I haven't even touched the sTLDs, that may have an additional sponsor cookie
to push through the registrars to the registry, or the ccTLDs, let alone the
RIRs, which may most resemble the model of pre-ICANN memory in com/net/org.

I don't see a rational way around more than one manifestation of a client,
even if the client is feature-fat, and the "just one" position reduced to
"sorta just one, but not really".

> The chairs don't want to make a technical decision on behalf of the group.
> (Not that we feel we are being compelled to do so at this time.)  It seems
> that there is no clear winner amongst "pull" and "push" technically -
> although some folks have strong opinions.  (No clear winner = no clear
> consensus.)  But to state the WG problem - the group needs to decide and to
> do so in a timely manner.

I agree, and the limits of the pseudo-debate have prevented us from attempting
to be rational about existing scaling problems. .com is throttling registrars,
and somewhere in that truth there is one or more instances of what we call in
the transport area "unfair aggressive", usually in the context of some hack
on tcp. A similar system known to .biz has its share of thrash. Adding state
push may not be a cure so much as a concealment of existing latent design
deficiencies.

> It is clear that there are strong preferences for one or the other,
> understandably so.  But, to the strong proponents of one or the other,
> let's move away from trying to prove "'my' way is right" to some try to
> find middle ground.  (Perhaps this can't be done, but let's give it a go.)

I'm aesthetically attached to event model symmetry, hence to push. Then again,
I'm aesthetically attached to an operating system.

> BTW, the Push-Pull straw poll did have one benefit.  Scott suggested that
> polling is a MUST, pushing a MAY.  Perhaps this is the middle ground to
> build upon.  (Comments on this, please.)

We could poll registrars just as easily as we poll registries, and registrars
could optionally push (urgent or meta-transactional) events just as easily as
registries do. There is nothing holy about which calls listen.2, and which
calls connect.2

The problem arises if one is optional. We now have to dig ourselves out of
a modest hole. What is the specific behavior whan a client fails (or just
fails to listen.2)? How can we avoid being normative and "in-band" where the
current text (epp-04 2.9.2.3, para 3) allows "other mechanisms"?

MUST NOT is way clearer, easier to specify, though not what I suggest.

> Other than that, there is nothing significant in the poll results (some
> wanted one, some wanted the other).

As has been pointed out, the simplest to implement form of <push> in a <poll>
dominated model requires a distinct session. The attraction of <push> may be
dependent upon the second connection, suggested by Scott earlier, or some
other means, such as a multiplexing session layer on a single connection, my
shorthand for BEEP.

Eric
(again, writing as an individual contributor)

Date: Wed, 29 Aug 2001 10:41:58 -0700 (PDT)
From: Patrick Greenwell <[email-masked]>
To: Patrick <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

On Wed, 29 Aug 2001, Patrick wrote:

> On Wed, Aug 29, 2001 at 09:11:20AM -0700, Patrick Greenwell took time to write:
> > As the number of registries and registrars scale, it might be much more
> > appropriate to have those registries PUSHing messages only to those
> > that have messages in the queue rather than having the registrars blindly
> > polling each registry on a timed interval.
>
> Everyone should remember that the client (Registrar) does not have
> explicitely to do any command whatsoever to know if a message is
> waiting since the msqQ element of the <result> item of *any* command
> tells him how many messages are waiting.
> (see §2.5 of the EPP draft)

The point is that the client has to connect to the server and check if it
does not have any explicit "normal" transactions to perform with the
registry.

Consider that EPP is envisoned as a generic provisioning protocol and
potentially could be used to provision all sorts of differing services
from any of a number of different providers. In such a case I don't think
it would be prudent to assume that there will be a continuous/frequent
rate of client-initiated transactions with every possible registry for
every specific service a registrar may use/register under.

To be clear, I'm not arguing for PUSH or for PULL. I'm arguing for the
flexibility to let the parties involved in the transaction choose between
the two.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                               Patrick Greenwell
                       Earth is a single point of failure.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Date: 29 Aug 2001 16:44:38 -0000
From: [email-masked]
To: [email-masked]
Subject: Re: Pushing vs. Pulling
Sender: [email-masked]

On Wed, 29 Aug 2001 12:23:48 -0400 Edward Lewis <[email-masked]> wrote:
>BTW, the Push-Pull straw poll did have one benefit.  Scott suggested that
>polling is a MUST, pushing a MAY.  Perhaps this is the middle ground to
>build upon.  (Comments on this, please.)

We could live with that.

Asbjorn Steira
The Global Name Registry

-- 
 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.

Date: Wed, 29 Aug 2001 12:23:48 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Pushing vs. Pulling
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Speaking as the WG chairs, we'd like to make a few comments about the
push-pull debate.

First, we believe that this debate is one for the ages, not in grandure,
but in persistence.  (And, frankly, the issue is rather small when compared
to the scope of the problem.)  We hope that once the group comes to a
conclusion, members of the group can put this in the past and move on.
With the natural divide in the issue, it will make some folks seem like
winners and other seem like losers over this issue - but winning and losing
isn't important when it comes to engineering.  Engineering is about getting
the job done (and done right is possible).  (Yay, rah-rah, go team go, and
all that.)

There is a consensus in the group that the group wants one protocol.  We
take this to mean that a registrar doing business with two different
registries wants to use just one set of software.  Please allow me to delve
into a somewhat arbitrarily concrete example.  Let's say I want to register
names in .com and .biz.  Would I expect to be running a (software) client
from each, or should one client be sufficient.  As it seems the group's
desire, it would seem to me to have just one client.  (Our question: is
this a good assumption?)

Now, the chairs realize that this is the IETF and organizations don't count
for much, and that we are to be looking beyond the registration of domain
names.  But we want to determine if there should be a latent assumption of
any client software should speak full EPP (or whatever) in order to speak
with all registries.

The chairs don't want to make a technical decision on behalf of the group.
(Not that we feel we are being compelled to do so at this time.)  It seems
that there is no clear winner amongst "pull" and "push" technically -
although some folks have strong opinions.  (No clear winner = no clear
consensus.)  But to state the WG problem - the group needs to decide and to
do so in a timely manner.

It is clear that there are strong preferences for one or the other,
understandably so.  But, to the strong proponents of one or the other,
let's move away from trying to prove "'my' way is right" to some try to
find middle ground.  (Perhaps this can't be done, but let's give it a go.)

BTW, the Push-Pull straw poll did have one benefit.  Scott suggested that
polling is a MUST, pushing a MAY.  Perhaps this is the middle ground to
build upon.  (Comments on this, please.)

Other than that, there is nothing significant in the poll results (some
wanted one, some wanted the other).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Wed, 29 Aug 2001 18:22:33 +0200
From: Patrick <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Organization: Gandi
Sender: [email-masked]

On Wed, Aug 29, 2001 at 09:11:20AM -0700, Patrick Greenwell took time to write:
> As the number of registries and registrars scale, it might be much more
> appropriate to have those registries PUSHing messages only to those
> that have messages in the queue rather than having the registrars blindly
> polling each registry on a timed interval.

Everyone should remember that the client (Registrar) does not have
explicitely to do any command whatsoever to know if a message is
waiting since the msqQ element of the <result> item of *any* command
tells him how many messages are waiting.
(see §2.5 of the EPP draft)

There is no overhead : the client does its usual business stuff
(that is : it does NOT use the POLL command). 
Sometimes, as a result of whatever command, the server (Registry)
will tell him it has some messages in queue.
*Then* the Registrar does the poll to get them. (immediately or later
at its convenience).

The point is that the client has *never* to send a specific command
to know if messages are waiting. This information (the number of
messages) is pushed (!) by the Registry with the result of a command.

In that setup I see no problems of scale.

> As such, I definitely think PUSH should be present as an option.

As an option, I agree. But not as a MUST.

Patrick.

Date: Wed, 29 Aug 2001 09:11:20 -0700 (PDT)
From: Patrick Greenwell <[email-masked]>
To: Patrick <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

On Wed, 29 Aug 2001, Patrick wrote:

> I am interested to have explanations by people wanting the PUSH.
> As far as I see in draft-brunner-xrp-01.txt (but maybe I'm not
> looking in the right place, if this is the case, do not hesitate to
> forward me) there is no technical explanations on how the push should
> work.
>
> It raises me questions like :
> - when a Registrar is connected multiple times, on what connection
> the Registry will push ?
> - will the Registry wait for an ACK after the push ? what will be
> done if it is not received ? will the messages be pushed later ?
> how many times ? dropped ? when ? how ?

Personally, I see a lot of parallels between this and the exchange of
email which is a relatively well-understood problem set(connections,
queuing, etc.)

As the number of registries and registrars scale, it might be much more
appropriate to have those registries PUSHing messages only to those
that have messages in the queue rather than having the registrars blindly
polling each registry on a timed interval.

As such, I definitely think PUSH should be present as an option.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                               Patrick Greenwell
                       Earth is a single point of failure.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Date: Wed, 29 Aug 2001 16:42:43 +0200 (CEST)
From: Antoin Verschuren <[email-masked]>
To: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Sender: [email-masked]

On Wed, 29 Aug 2001, Patrick wrote:

> Host handles exist with some Registrar, but not all. They are NOT
> used by the Registry.

Than what do you call this:

-------
[~] antoin@admin> whois -h whois.verisign-grs.net ns1.vianetworks.nl

Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Server Name: NS1.VIANETWORKS.NL
   Registrar: GANDI
   Whois Server: whois.gandi.net
   Referral URL: http://www.gandi.net

>>> Last update of whois database: Wed, 29 Aug 2001 02:11:20 EDT <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.
-------

And more important, how can this entry be changed and by who ?
If for example it would say:
   Server Name: NS1.VIANETWORKS.NL
   Registrar: MICROSOFT
And I happened to not like Microsoft, and wanted my host to be handled by
another registrar, how could I initiate this change ?
(I expect the answer to be that nobody has ever thought about that)

Met groet,
VIA NET.WORKS Nederland

 Antoin Verschuren  
 Provisioning Team Leader
 tel. + 31 40 2 393 393
 fax  + 31 40 2 393 311
 e-mail : [email-masked]            

 http://www.vianetworks.nl/ 

Date: Wed, 29 Aug 2001 16:33:42 +0200 (CEST)
From: Antoin Verschuren <[email-masked]>
To: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Sender: [email-masked]

On Wed, 29 Aug 2001, Patrick wrote:

> In case of ccTLDs, there is no IP, thus nothing to be changed.
> In case of change of name, you must create the new record (with
> whatever Registrar, since it's in a ccTLD), update your domains, and
> delete the old one if necessary.
> 
> Thus the case you described can not happen I think.
> 
> Again, the Registry has no concept of host handles. When you register
> a domain name you provide *names* of nameserver, not some kind of
> handle. When a nameserver changes its name, you need to change each
> domain name concerned. Of course this can be automated at the
> Registrar level.

Then what is the point of registrating a nameserver for a ccTLD in the
first place ? Why is registrating nessecary in the current system if you
cannot change them, and don't need them for a glue record ?
Is it because becuase the system was simply invented like this, and let's
not take into account that some people may have ccTLD nameservers ?

Met groet,
VIA NET.WORKS Nederland

 Antoin Verschuren  
 Provisioning Team Leader
 tel. + 31 40 2 393 393
 fax  + 31 40 2 393 311
 e-mail : [email-masked]            

 http://www.vianetworks.nl/ 

Date: Wed, 29 Aug 2001 07:23:21 -0700
To: Patrick <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 05:21 AM 8/29/2001, Patrick wrote:
> > The "without queue overhead" statement is true only if the pusher has no
> > intention of retrying in case of failed delivery.

I think it is even worse that you describe, since data are being sent over 
a single connection and, therefore, must be sent serially.

Whatever portion of the system is producing items to be transmitted, the 
portion that actually does the sending might be slower, such as due to 
network congestion or a slow host on the other end of the connection.

This requires that the producing software feed a queue, for the sending 
software to do consuming from.

d/

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

Date: Wed, 29 Aug 2001 16:20:10 +0200 (CEST)
From: Antoin Verschuren <[email-masked]>
To: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Sender: [email-masked]

On Wed, 29 Aug 2001, Patrick wrote:

> And this is totally normal. IP address for your nameservers in
> Verisign database are totally useless. The Registry gives strong
> hints to Registrar not to register IP address of nameservers outside
> of .com/.net/.org. This makes totally sense, and this is why Gandi
> does it.

I agree with you here Patrick. It's the same as Jaap pointed out.
Thanx for you other reply by the way, I agree that NSI made a mess of it's
system, and I'm in a long discussion with them. But they remain the
registry...:-(, and I have to adapt to their current system to get things
done.

> > authority to make changes to this registration. As result of this, we
> 
> And you do not need to make changes at all.

And there I don't agree. Suppose we want to discontinue our nameserver,
and want to do that neatly, so modifying all domains that are delegated to
our nameserver to another one. In that case I must be able to make queries
in the database for that nameserver, or even change the hostnames for all 
records that are in the database with that host record. I can immagine
that you only allow these queries for the owner of that nameserver, and
not for every individual. So registrating who is the authoritative contact
for that nameserver is desirable. In that way, I can delete or change that
host record as a nameserver, so nobody can use it again for a new
registration without my permission.

> > cannot make the appropriate changes to these hosts to make them usable for
> > our 10.000 domains. Our nameservers are simply hijacked by one person that
> > uses our nameserver without our permission.
> 
> This is false.

I'm responsible for this nameserver. The registry database at NSI says
that this host record is maintained by Gandi, and that Gandi is the only
registrar allowed to make changes to this host record. Still, I have no
account at Gandi (I'm not a client there) that makes it possible for me to
make queries, delete or modify this host record. The only person that is
allowed to do this I suppose is the person that originaly used this
nameserver for the first time at Gandi. Or doesn't Gandi require a host
first to be registrated as a nameserver before domains can be delegated to
it ? If a host is not registrated as a nameserver, then what does Gandi do
? Registrate it as a nameserver at all times ? And who is allowed to make
changes to that host record ?

> > owner of the nameserver (and thus the domain where the nameserver resides)
> 
> You mean owner of nameserver = owner of the domain where the
> nameserver resides then.
> Ok, I can accept that. But my question remains : How the person who
> need to do it can gain authorization from the owner of the nameserver
> ?
> (in an automated way of course)

Once the nameserver is created as a host record, it can be used.
If a nameserver is not present as a host record, then no domains can be
delegated to it. I think it prevents non delegated domains. Just filling
in a bogus hostname (kfjghdfjgh.jghfkjg.com) as a nameserver should be
prevented. I think that the least thing you can do is check if the
hostname exists.
Making the owner of a domain responsible for registrating the nameservers
in his domain is I think not a great effort. If one of my clients wants to
use a nameserver where I'm responsible for (read, resides in my domain),
than he has to make that request with me to registrate that nameserver.
Delegation is not someting that stops at a topdomain level.
Another solution might be to automaticaly make the owner of the domain the
owner of the host record. This would mean that all registries need to talk
to eachother, and have the same database structure. But I thought that
that was the aim of this working group after all :-)

Met groet,
VIA NET.WORKS Nederland

 Antoin Verschuren  
 Provisioning Team Leader
 tel. + 31 40 2 393 393
 fax  + 31 40 2 393 311
 e-mail : [email-masked]            

 http://www.vianetworks.nl/ 

Date: Wed, 29 Aug 2001 15:36:59 +0200
From: Jens Wagner <[email-masked]>
Organization: Key-Systems GmbH
To: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Sender: [email-masked]

Patrick wrote:

> Jens,
>
> On Thu, Aug 23, 2001 at 04:03:14PM +0200, Jens Wagner took time to write:
> > What happens if you associate some .com domains with ns1.vianetworks.nl, and
> > the hijacker renames that host to ns1.hijacked.cx in the .com Registry?
>
> The Registrar handling a nameserver record should make sure to
> receive authorization before updating it. In case of an gTLD
> nameserver, he can get authorization from the contacts of the domain
> (which is necessarily under its management), to change the name or
> the IP. The change of name can be tricky, if the nameserver changes
> domain, the authorization should be coming also from the new
> contacts.

If you change a nameserver name from ns1.vianetworks.nl to ns1.hijacked.cx you
have no parent domain to check authorization against, at least in the c/n/o
Registry.
The authority of non-c/n/o nameservers remains usually their creator.

> In case of ccTLDs, there is no IP, thus nothing to be changed.
> In case of change of name, you must create the new record (with
> whatever Registrar, since it's in a ccTLD), update your domains, and
> delete the old one if necessary.
>
> Thus the case you described can not happen I think.

1. Hijacker registers ns1.vianetworks.nl
2. ViaNetworks registers domain1.com with the nameserver ns1.vianetworks.nl
3. Hijacker renames ns1.vianetworks.nl to ns1.hijacked.cx
4. Hijacker registers ns1.vianetworks.nl

domain1.com would use the nameserver ns1.hijacked.cx, NOT ns1.vianetworks.nl

Did I get anything wrong?

> Again, the Registry has no concept of host handles. When you register
> a domain name you provide *names* of nameserver, not some kind of
> handle. When a nameserver changes its name, you need to change each
> domain name concerned. Of course this can be automated at the
> Registrar level.
>
> Regards,
> Patrick.

Imho a registry should not allow renaming nameservers with parent domains outside
of their own TLD(s).

Best regards,

Jens Wagner

Date: Wed, 29 Aug 2001 15:03:45 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Organization: Gandi
Sender: [email-masked]

On Thu, Aug 23, 2001 at 09:58:49PM +0200, Antoin Verschuren took time to write:
> We have some 30.000 domains in our nameservers. All these domains point to
> a host record at the registrar. So the host is only registered once.
> Now that we have renamed our nameservers, I also want to change all
> registrations. Because the host is a record, and should only be registered
> once, the solution is to change that host record, and ajust the hostname.
> Because the domains point to that host record (and not to the hostname)
> all domains can be changed with changing this one host record.

Things are not working like that at the (current) Registry level.
There is no host records associated with domain names. There are
names (of nameservers) associated with domain names.

If a nameserver names change, there is NO WAY other than updating
each domain ONE by ONE, which can be automated at the Registrar
level, I agree. But the Registry can not help.

> I could probaly solve this issue by registering our new hosts at verisign,
> and let them change all our domain records in their database. The point
> I'm trying to make however is that this should not be the way to solve
> this in the future with a new registry-registrar protocol, since the whole
> point of using host records is then gone. And offcourse, it has still not

Host handles exist with some Registrar, but not all. They are NOT
used by the Registry.

> deleted the host record with Gandi. I want this record to be deleted, or
> at least be responsible for it, and want to control this host record with 
> a registrar of my choice.

It can not be deleted as long as some domains use these nameservers.
Which is the case.

Regards,
Patrick.

Date: Wed, 29 Aug 2001 14:58:27 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Organization: Gandi
Sender: [email-masked]

Jens,

On Thu, Aug 23, 2001 at 04:03:14PM +0200, Jens Wagner took time to write:
> What happens if you associate some .com domains with ns1.vianetworks.nl, and
> the hijacker renames that host to ns1.hijacked.cx in the .com Registry?

The Registrar handling a nameserver record should make sure to
receive authorization before updating it. In case of an gTLD
nameserver, he can get authorization from the contacts of the domain
(which is necessarily under its management), to change the name or
the IP. The change of name can be tricky, if the nameserver changes
domain, the authorization should be coming also from the new
contacts.

In case of ccTLDs, there is no IP, thus nothing to be changed.
In case of change of name, you must create the new record (with
whatever Registrar, since it's in a ccTLD), update your domains, and
delete the old one if necessary.

Thus the case you described can not happen I think.

Again, the Registry has no concept of host handles. When you register
a domain name you provide *names* of nameserver, not some kind of
handle. When a nameserver changes its name, you need to change each
domain name concerned. Of course this can be automated at the
Registrar level.

Regards,
Patrick.

Date: Wed, 29 Aug 2001 14:51:43 +0200
From: Patrick <[email-masked]>
To: Antoin Verschuren <[email-masked]>
Cc: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue (fwd)
Organization: Gandi
Sender: [email-masked]

On Thu, Aug 23, 2001 at 04:33:13PM +0200, Antoin Verschuren took time to write:
> On Thu, 23 Aug 2001, Hollenbeck, Scott wrote:
> 
> > What do you want to change that you can't change?  There are no IP addresses
> > associated with the hosts in the non-authoritative registry, so the only
> > thing that's changeable is the name of the host itself.  If that's what you
> > need to do, just register the new host name(s) yourself with your registrar
> > of choice and the hosts will be usable for your purposes.
> 
> But then, our current host records are not changeable anymore to
> ns1.vianetworks.nl because this hostname allready excists at this
> registrar, but with another host handle. To be more precise, we want to

(BTW host handles are specific of a Registrar, since the Registry has
no concept of them)

> change:
> 
> Host Handle: NS7389-HST
> Nameserver:  ns1.iae.nl
> IP number:   212.61.26.34
> 
> into:
> 
> Host Handle: NS7389-HST
> Nameserver:  ns1.vianetworks.nl
> IP number:   212.61.15.8
> 
> So that all 4.000 domains currently using ns1.iae.nl (NS7389-HST) will use
> ns1.vianetworks.nl. If I try that, Verisign answers:
> 
> > > Servers are registered with no IP at another registrar.  They must
> update
> > > the servers with an IP address before we can add them to our database.

Which is against Registry rules and common sense as explained here.

> If I try your solution, and then try to change NS7389-HST, I get the
> error:
> NS1.VIANETWORKS.NL Allready registrated.
> So in other words, no 2 host records with the same hostname can excist
> with Verisign, which ofcourse I think should be so.
> 
> What I think is strange however, is that I can create a new host
> ns1.vianetworks.nl at Verisign, and then nobody tells me that this

Then there is a bug at Verisign Registrar.
Even more ns1.iae.nl should not be created with an IP in the first
place :
patrick@nohope:~/Gandi/Prog/Docs/IETF/EPP$ whois -h
whois.verisign-grs.net ns1.iae.nl

Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be
registered
with many different competing registrars. Go to
http://www.internic.net
for detailed information.

   Server Name: NS1.IAE.NL
   IP Address: 212.61.26.34
   Registrar: NETWORK SOLUTIONS, INC.

Regards,
Patrick.

Date: Wed, 29 Aug 2001 14:35:51 +0200
From: Patrick <[email-masked]>
To: Antoin Verschuren <[email-masked]>
Cc: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Organization: Gandi
Sender: [email-masked]

On Thu, Aug 23, 2001 at 02:35:13PM +0200, Antoin Verschuren took time to write:
> We are the owner of the domainname vianetworks.nl. The Dutch
> domainregistry holds the glue records for ns1.vianetworks.nl and
> ns2.vianetworks.nl which is correct.
> Now that we want to start using these nameservers for some 10.000
> domainnames with Verisign, there is a problem of registrating these hosts.
> As it seems, some other party has registered a domain with Gandi using
> these nameservers, but without IP addresses. At Gandi, we don't have any

And this is totally normal. IP address for your nameservers in
Verisign database are totally useless. The Registry gives strong
hints to Registrar not to register IP address of nameservers outside
of .com/.net/.org. This makes totally sense, and this is why Gandi
does it.

> authority to make changes to this registration. As result of this, we

And you do not need to make changes at all.

> cannot make the appropriate changes to these hosts to make them usable for
> our 10.000 domains. Our nameservers are simply hijacked by one person that
> uses our nameserver without our permission.

This is false.
 
> The point that I'm trying to make is that the owner of the nameserver
> should always be able to control his host records. If anyone can register

How the person who need to do it can gain authorization from the
owner of the nameserver ? And who is the owner of a nameserver ?
Where is this information stored ? Nowhere AFAIK.

> owner of the nameserver (and thus the domain where the nameserver resides)

You mean owner of nameserver = owner of the domain where the
nameserver resides then.
Ok, I can accept that. But my question remains : How the person who
need to do it can gain authorization from the owner of the nameserver
?
(in an automated way of course)

BTW folks, no need to Cc me in this thread, I'm subscribed to the
mailing-list, thanks.

Patrick.

Date: Wed, 29 Aug 2001 14:21:52 +0200
From: Patrick <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Organization: Gandi
Sender: [email-masked]

On Thu, Aug 23, 2001 at 07:10:13AM -0400, Hollenbeck, Scott took time to write:
> >If there is one thing we do know, it is that a registry may push state to
> >a registrar, without queue overhead, or hold-down timer complications and
> >secondary access and store overhead. We also know, as Scott pointed out in
> >the sections I quoted, that deferred queue service causes registry resource
> >consumption.
> 
> The "without queue overhead" statement is true only if the pusher has no
> intention of retrying in case of failed delivery.  Push or poll, the sender
> needs to do something in response to an unresponsive recipient.  In case of
> failed delivery, the sender can either drop and discard the message
> completely, or it can queue the message for a later delivery attempt.  I
> suspect the "queue for later delivery" option will be more reasonable, and
> thus push/poll end up having similar queue resource requirements.

I totally agree with Scott on this point.

> If, on the other hand, folks are comfortable with the idea of trying to push
> a message once and throwing it away if it isn't delivered, then there is
> indeed no queue overhead to worry about.

I am interested to have explanations by people wanting the PUSH.
As far as I see in draft-brunner-xrp-01.txt (but maybe I'm not
looking in the right place, if this is the case, do not hesitate to
forward me) there is no technical explanations on how the push should
work.

It raises me questions like :
- when a Registrar is connected multiple times, on what connection
the Registry will push ?
- will the Registry wait for an ACK after the push ? what will be
done if it is not received ? will the messages be pushed later ?
how many times ? dropped ? when ? how ?

As far as I see things now we have a POLL mechanism totally described
and without more overhead than a PUSH (state of the queue is given as
results of other successfull commands), and no details about a PUSH.

This is why I am totally uneasy with adopting the PUSH mechanism.
>From what I see, I see no benefits.

Patrick.

Date: Wed, 29 Aug 2001 14:15:59 +0200
From: Patrick <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: Push vs. not Push
Organization: Gandi
Sender: [email-masked]

On Thu, Aug 23, 2001 at 11:56:29AM -0400, Edward Lewis took time to write:
> After going through the email and minutes, I think that there is a need to
> poll the list to see if folks want the "push" mechanism to be defined or
> not. 

As a Registrar of gTLDs, we prefer that the PUSH mechanism is not a
MUST. It _may_ be defined in the protocol, but only the POLL mechanism
should be a MUST.

Patrick.

Date: Tue, 28 Aug 2001 09:16:35 -0400
To: Klaus Malorny <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: host transfers
Cc: Patrick <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 2:38 PM +0200 8/27/01, Klaus Malorny wrote:
>This doesn't make sense, of course. But it's not what I wanted and what I
>tried to explain. Anybody should be able to specify any domain name server for
>his domain. No more, no less. Without any limitation. The effective control of
>access is done on the "physical" level only and not on the "administrative"
>level. It's just not the registry's responsiblity to take care of it. As the
>registry does not control the name servers - it cannot influence them in any
>way - it is absolute senseless to build a mechanism into the registry that
>allows or disallows the use of a name server. A name server is only usable for
>a different person if the owner of the name server grants the other person to
>host his zone on that name server by giving him physical access to that
>machine somehow, directly or indirectly. If he denies this, there is no way
>for the other person to use that name server. I.e. the owner has full control
>over his name server, he can determine by his own means who uses his name
>server and who not. Therefore, again, any registry level mechanism is
>superfluous and complicates things more than required.

This assumes that lame delegations are not bad.  (Yes, I know that we 
can't *prevent* lame delegations, but ensuring that the owner of a 
name server agrees to the delegation makes them a whole lot less 
likely.)

Theoretically, it could even be possible to formulate a denial of 
service attack on a name server if you pointed some popular domain 
names (such as yahoo.com) at a poor, innocent and unsuspecting name 
server.

>  >
>  > Under your scheme, neither of these domains will work.  For that
>>  matter, under your scheme, even if A and B were both in domain XXX,
>>  they would not work.  A modified version of your scheme could fix the
>>  problem by checking for such situations within a single registry, but
>>  is utterly unresolvable if the domains are in different registries.
>
>Yes, I don't dispute this. But first, I think circular references are quite
>uncommon. Second, as I said in earlier mails, I believe that it will become
>quite common that name servers are registered at different registries and that
>this little advantage will disappear.

I agree that this is not a common problem, but there's a fairly easy 
solution at least in the same zone.  I think this is actually 
becoming another issue of registry policy--registries should be able 
to decide what amount of glue they want to publish.  There are 
reasonable arguments on both sides of this debate, and no fool-proof 
solution has been presented that solves all of the issues raised.

Jordyn

Date: Mon, 27 Aug 2001 16:28:20 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Questions about containers
Sender: [email-masked]

Eric,

First, thanks for the drafts.

k, I have some questions and possibly corrections as well:

1) XRP is mentioned twice without introduction.  Is this leftover from 
the XRP drafts?

2) Do containers and their relations to other objects preclude the 
associations defined in the EPP domain draft?

3) The registrant -- that is simply a contact right.  I might have 
missed it but I don't think it explicitly says that.

4) Can you explain the difference between child objects and linked 
objects?  That wasn't completely clear to me.

5) The container delete description specifies that the authInfo must be 
provided.  This isn't right is it?

6) In container delete, what is the difference between using the none 
and the break option?  Taking no action on related objects implicitly 
breaks their association with the deleted container right?

7) The following paragraph states that a container should not be deleted 
if it is associated with other known objects.  Is that really saying 
that containers can't be delete as long as they have a parent?  The way 
it is worded there, I couldn't help but try to extrapolate a meaning 
with the previous option element (none, delete, break).  But maybe 
that's just the way I interpreted it.

8) How does a registrar know which templates exist in the registry? 
 Will that information be provided out-of-band in contracts or notices 
from the registry?

9) Referring to the diagram example in the draft, if a registrar 
associated a domain to Container 3, would that domain have Host 1 (from 
Container 1) and Host 2 in it's DNS records?

I might forward more questions as I study the document a little more.

Thanks for your help,
Dan

Date: Mon, 27 Aug 2001 14:38:56 +0200
From: Klaus Malorny <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
CC: Patrick <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

"Jordyn A. Buchanan" wrote:
> 
> Hi Klaus:
> 
> I'll try to keep this short.  These messages are becoming a bit too
> long to digest easily.

Hi Jordyn,

sorry for answering so late, but I am currently really busy in creating
software for .info/.biz and since it costs me a lot of time to formulate in
more or less understandable English, I delayed this. I'll try to keep this
short, too, esp. as I don't want to repeat myself one more time.

> 
> Your proposal is to allow any registrar to create name server objects
> for any domain.  Explaining to me what useful functionality this
> achieved vs. the EPP model, you indicated:
> 
> >1. Other registrars are not able to create name servers in that domain
> >
> >2. The sponsoring registrar does not have full control over his own
> >    name servers, i.e. anyone can reference his name server and block
> >    the deletion of the name server and also the domain the
> >    name server belongs to.
> 
> There is tension between these two benefits.  You want a sponsoring
> registrar to be able to prevent the *use* of a name server within a
> domain that they sponsor, but not the *creation* of a name server in
> the same domain.  This doesn't make sense.

This doesn't make sense, of course. But it's not what I wanted and what I
tried to explain. Anybody should be able to specify any domain name server for
his domain. No more, no less. Without any limitation. The effective control of
access is done on the "physical" level only and not on the "administrative"
level. It's just not the registry's responsiblity to take care of it. As the
registry does not control the name servers - it cannot influence them in any
way - it is absolute senseless to build a mechanism into the registry that
allows or disallows the use of a name server. A name server is only usable for
a different person if the owner of the name server grants the other person to
host his zone on that name server by giving him physical access to that
machine somehow, directly or indirectly. If he denies this, there is no way
for the other person to use that name server. I.e. the owner has full control
over his name server, he can determine by his own means who uses his name
server and who not. Therefore, again, any registry level mechanism is
superfluous and complicates things more than required.

> 
> Most of the message in which you wrote this explains why glue records
> are only needed for name servers that are authoritative for their own
> domains, an argument that I'll admit I'm coming around to.  However,
> an argument against this approach that has been raised in the past is
> that it is possible to create a situation in which two (or more
> domains) use name servers in the other domain(s), so that none of
> them end up having glue or being useful.  For example:
> 
> A.XXX has name servers NS1.B.YY and NS2.B.YY.
> B.YY has name servers NS1.A.XXX and NS2.A.XXX.
> 
> Under your scheme, neither of these domains will work.  For that
> matter, under your scheme, even if A and B were both in domain XXX,
> they would not work.  A modified version of your scheme could fix the
> problem by checking for such situations within a single registry, but
> is utterly unresolvable if the domains are in different registries.

Yes, I don't dispute this. But first, I think circular references are quite
uncommon. Second, as I said in earlier mails, I believe that it will become
quite common that name servers are registered at different registries and that
this little advantage will disappear.

> 
> Klaus, I think many of your arguments are reasonable and well thought
> out.  I happen to agree with some of them, but I don't think that you
> are stupid or naive as a result of our disagreement.

Thanks ;-)

> I hope that you
> can accord the rest of us the same respect.

of course.

> 
> Jordyn

regards,

Klaus Malorny

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-container-00.txt
Date: Mon, 27 Aug 2001 06:50: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 Container
	Author(s)	: E. Brunner-Williams, A. Damaraju, N. Zhang
	Filename	: draft-ietf-provreg-epp-container-00.txt
	Pages		: 41
	Date		: 24-Aug-01
	
This memo documents how EPP container objects extends EPP objects,
supporting hierarchy and inheritance, simplifying administration and
mangement of the associated objects.

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

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-container-00.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-container-00.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-container-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-container-00.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-beep-00.txt
Date: Mon, 27 Aug 2001 06:49: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 Transport Over BEEP
	Author(s)	: E. Brunner-Williams, A. Damaraju, N. Zhang
	Filename	: draft-ietf-provreg-epp-beep-00.txt
	Pages		: 10
	Date		: 24-Aug-01
	
This memo documents how an EPP (Extensible Provisioning Protocol)
session is mapped onto a single BEEP (Blocks Extensible Exchange
Protocol) session.

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

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-beep-00.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-beep-00.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-beep-00.txt

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

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

--OtherAccess--

--NextPart--

From: Bruce Tonkin <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Push vs. not Push
Date: Sat, 25 Aug 2001 17:40:20 +1000
Sender: [email-masked]

Sounds fine to me.

> -----Original Message-----
> From: Hollenbeck, Scott [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 5:08 AM
> To: 'Edward Lewis'; [email-masked]
> Cc: 'Jaap Akkerhuis'
> Subject: RE: Push vs. not Push
> 
> 
> From a gTLD registry operator perspective...
> 
> We should have a set of MUST implement basic functions, 
> including a function
> for exchange of operational notices.  I would prefer a 
> polling mechanism in
> the set of MUSTs.  I would also like to suggest that it may 
> be possible to
> define an optional push extension that may or may not be
> transport-dependent.
> 
> <Scott/>
> 

From: Bruce Tonkin <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: Push vs. not Push
Date: Sat, 25 Aug 2001 17:37:32 +1000
Sender: [email-masked]

Hello Ed,

Speaking from Melbourne IT, an ICANN accredited registrar, registrar for
many country codes, and sole registrar for ".com.au".

I support the push mechanism being included in addition to (not instead of)
the pull mechanism.  This allows more flexibility from both the registry and
registrar perspective in implementing future services.  

Melbourne IT supports innovation at both registry and registrar level.

Bruce Tonkin
> 

From: Bruce Tonkin <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Message Pushing and TCP Transport
Date: Sat, 25 Aug 2001 15:48:53 +1000
Sender: [email-masked]

Hello All,

The issue of pushing verus pulling, is not one of OR but one of AND.

There are definitely services that a registry can create that can make use
of the PUSH protocol.  For example various notification services - e.g a
registrar can request the registry to notify it when a particular domain
name has been deleted and is available for registration.

The idea is to support the option for a registry to create a range of
services, some of which use the pull approach, and some of which use the
push approach.  We should allow a registry to innovate.

Registrars can choose what services they wish to use, and registries can
choose what services that choose to offer.  In general a registry
introducing a service that uses the PUSH function of the protocol, would
also provide the necessary toolkits to registrars to use that process.

The protocol should support the ability for a registrar and registry to
negotiate the services available at the time of establishing a session.

Regards,
Bruce Tonkin

-----Original Message-----
From: Daniel Manley [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 5:46 AM
To: Peter Chow
Cc: Bason, Chris; [email-masked]'
Subject: Re: Message Pushing and TCP Transport

I would tend to agree with Peter's comments.  I haven't heard anything 
concrete that says that pushing is superior to pulling.  I prefer 
p[ou]lling because it allows the registrar to retrieve messages when 
it's good and ready.  This is also simpler for the registry.  With 
pushing, the registry system must be aware of when a registrar is logged 
in so that it can push the messages out.  That means extra work for a 
system that's already very busy trying to handle thousands of 
domain:check commands and domain registrations, and DNS updates, and....  

And for registrars that connect with many connections, the registry has 
to manage multiple connections trying to push message from the same queue.

Registries (and their developers) have enough to worry about without 
getting to asynchronous communications to the registrars.

Dan

Peter Chow wrote:

>Chris,
>
>I was at the Provreg meeting and there was at least one
>implementor who was concerned with the extra complexity
>introduced by the push mechanism.
>
>As a registrar, we would only want the push mechanism to
>be added to the protocol only if there is a clear advantage of
>it over polling.
>
>On Fri, 17 Aug 2001, Bason, Chris wrote:
>
>>Eric, per your suggestion I revisited the message thread you referred
>>to. As far as I can tell there are no comments in that particular
>>thread about polling vs. pushing transfer notifications. There certainly
>>is no consensus on this topic in the thread. Furthermore, based on the
>>WG mailing list to date, I have not seen a majority consensus in any
>>message thread that identifies pushing notifications as an acceptable
>>addition to the protocol.
>>
>>Let me just restate then what I am looking for and why. I saw Scott
>>Hollenbeck's message on the list, "WG Discussion Summary with Draft
>>Document Impact" stating the following:
>>
>>...
>>Eric's XRP presentation and subsequent discussion led to a reopening of
the
>>message polling vs. message pushing discussion.  Folks in the room seemed
to
>>support the idea of having both mechanisms in the base protocol, with the
>>client having the ability to select a delivery mechanism from among those
>>offered by the server.  Eric will offer up suggested text to be added to
the
>>EPP draft(s).
>>...
>>
>>This statement concerns me. Let me then rephrase the question:
>>1) What justification was given that received so much support for pushing
>>transfer notifications where there was little support before?
>>2) What is advantageous about using a push mechanism for transfer
>>notification in our current registry/registrar model over
>>using a pull mechanism?
>>
>>I personally see no advantage. Although, I do see several disadvantages,
>>one of which is the unnecessary complexity that will be added to the
>>protocol. If there are no clear advantages for using a push method then
>>it should not be added to the protocol.
>>
>>Chris Bason
>>
>>
>>-----Original Message-----
>>From: Eric Brunner-Williams in Portland Maine
>>[mailto:[email-masked]]
>>Sent: Wednesday, August 15, 2001 11:51 PM
>>To: Bason, Chris
>>Cc: [email-masked]'; [email-masked]
>>Subject: Re: Message Pushing and TCP Transport
>>
>>
>>>Would someone please elaborate on why this push concept
>>>is advantageous to EPP (preferably a PUSH proponent)?
>>>
>>The issue has been discussed quite a few times on the list, not just at
-50
>>and -51. See the general discussion of transfer notification.
>>
>>Eric
>>
>
>--------------------------------------------------------------------
>_/_/_/ Peter Chow		Chief Technical Advisor
>_/_/_/ [email-masked]		Global Media Online Inc.
>_/_/_/				System Division
>_/_/_/ ICQ: 41931890		Shibuya Cerulean Tower 11F
>_/_/_/ (tel)+81-3-5456-2687	26-1 Sakuragaoka-cho, Shibuya-ku
>_/_/_/ (fax)+81-3-5456-2740	Tokyo, Japan
>_/_/_/ http://www.gmo.jp/	150-8512
>--------------------------------------------------------------------
>
>

Date: 24 Aug 2001 12:05:31 -0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: Push vs. not Push
Sender: [email-masked]

Hi,

representing The Global Name Registry (.NAME Registry Operator), we agree with
Hollenbeck's view that only <poll> should be a MUST.

Asbjorn Steira
Global Name Registry Ltd.

On Thu, 23 Aug 2001 11:56:29 -0400 Edward Lewis <[email-masked]> wrote:
>After going through the email and minutes, I think that there is a need to
>poll the list to see if folks want the "push" mechanism to be defined or
>not.  As far as the merits of such a mechanism, please refrain from
>commenting on that, as it appears in archived messages.  My sense is that
>we aren't arguing the merits of push, but rather, whether implementors
>would be willing to add this feature in response to user (registr*) needs.

-- 
 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.

Date: Thu, 23 Aug 2001 16:01:42 -0400
To: Edward Lewis <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: About the Push vs. not Push Resend ?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>
>
>I am curious about where folks are coming from, not for counting or voting.
>I see a lot of discussion that seems to be prompted from the gTLD
>community's contractural dealings with ICANN and then reverse discussion
>from some ccTLDs, and not much from "others" - including the RIR's.

I'm sorry if this gets posted twice by I did not see it show up on the 
list. Apologies if it did.

Well Ed .. I'm afraid I have a slightly different view here :

>After going through the email and minutes, I think that there is a need to
>poll the list to see if folks want the "push" mechanism to be defined or
>not.  As far as the merits of such a mechanism, please refrain from
>commenting on that, as it appears in archived messages.  My sense is that
>we aren't arguing the merits of push, but rather, whether implementors
>would be willing to add this feature in response to user (registr*) needs.

In the interest of trying to create a complete and extensible protocol 
there no good reason not to include push mechanisms, or the use of BXXP for 
that matter.  I would like to remind the list that the protocols being 
developed here may have uses outside TLD's in the future and arbitrary 
attempts to restrict its functionality purely to satisfy the limited 
requirements of that special interest group is "a bad thing" tm.

Though the RIR's may not be ready to use the output of this group at this 
time I feel it incumbent on myself to make sure that their options are not 
foreclosed.

If you don't want to use push mechanisms you don't have to. Why is it so 
difficult to develop a good registration provisioning protocol first and 
then see how it can be adapted to the needs of the TLD community vs this 
narrow and parochial view that if it isn't useful for TLD's then who cares.

And I say that as the co-Chair of the IETF ENUM working group....and FYI 
Scott Hollenbeck has recently posted a most interesting and thoughtful 
draft on how some of the work going on here might be adapted to RFC2916.

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

And though this draft does not specifically discuss the seemingly endless 
layer 9 issues of transport and push I would like it known that might be 
useful to ENUM implementers in the future and there are discussions going 
on in several countries on how 2916 might be deployed and the work of this 
group could ,in that context, set an important precedent.

So Yes to push.

>In your response, let me know which registr*'s you are speaking for, so
>that we can determine if there is a pattern to differing opinions (e.g.,
>gTLDs vs. ccTLDs).  If you feel that you don't want to disclose this
>publicly, please send the message to just "[email-masked], [email-masked]"
>- ie the chairs.  If you do this, it might be a good idea to send a public
>version of your message to the list so others know how you feel on the
>issue.

and if you havent already figured it out I have a TLD interest here as well 
. I work for NeuStar who is a JV operator of .BIZ with our partners 
Melbourne IT.

>I am looking more for a demographic behind the opinions than size.  If
>there is a systemic difference of opinion, then it is easier to try and
>adjust the solution - I hope.
>
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>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.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice 571.434.5651 Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Date: Thu, 23 Aug 2001 13:09:00 -0700
To: Daniel Manley <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 11:21 AM 8/23/2001, Daniel Manley wrote:
>>>... somewhere along the line, a process or thread will have to poll 
>>>something to see if there's anything to do.
>>
>>
>>wrong.
>
>You keep saying that I'm wrong without describing your alternative. That's 
>not very fair, is it?

thought it was obvious.  instead of having the consumer constantly polling 
the queue, the producer just dispatches the consumer, after adding to the 
queue.

>>>Except for queuing when the message can't be delivered taken right away.
>>
>>queuing is an entirely separate bit of mechanism and overhead, with equal 
>>overhead on top of push or pull.
>
>If you're going to push queued messages, then I don't see how it's an 
>entirely separate mechanism.  Yes, with equal overhead, except that 
>pulling is not done by the server, so the load is distributed a little 
>more equally between client and server.

pulling isn't done by the server?  interesting idea.  please explain how 
the client obtains the data without any work beihng done by the server.

I think you meant that pulling is not INITIATED by the server and, of 
course, that is the definitional difference between push and pull.

>>the point that is being missed is polling permits only a subset of the 
>>behaviors and efficiencies that push permits.  Push demonstrates vastly 
>>better scaling properties.
>
>Can you enumerate these behaviours, efficiencies and scaling properties? I 
>see the same messages being passed either way so the argument is over the 
>delivery method.

it has now been explained repeatedly:  constantly polling means that a 
request and a response is sent and received.  Most of the time, the queue 
is empty, so the poll is wasted effort.

A server with a large number of clients, therefore, processes a large 
number of polling requests.  That makes for amount of wasted overhead.

>But that was in a really controlled environment.  Only a handfull of big 
>clients.  Provreg is defining a generic protocol which will have many 
>application groups.  I don't think it would be fair to the smaller players 
>to impose a heavy-duty protocol.

fine.  I agree.  (I hope it is not necessary to note that I have 
substantial appreciation for the issues of getting successful Internet 
protocols designed and adopted.)

Is it fair on the larger players to impose heavy-duty 
inefficiencies?  (Please skip the obvious path of citing some current 
larger players as saying that they do not want push.)

>>The server needs to get the data to the client, no matter what.  You seem 
>>to feel that sending it immediately, rather having to wait an arbitrary 
>>amount of time, somehow incurs onerous overhead.  It doesn't.
>
>We seem to be going in circles here.  I'm saying there are two 
>activities:  generating messages and delivering messages.  Pushing puts 
>these two activities in the server, while polling splits them between the 
>server and the client, respectively.

It does no such thing.  The server is still a full participant in getting 
the data to the client.  What is changed is ONLY the question of how the 
exchange is initiated.

>   With the client pinging anyway (yes, an integral part of my argument), 
> the total overhead is roughly the same, but balanced better between two 
> parties.
>
>>Frankly I can't figure out the processing model that you are describing, 
>>since you seem to view queuing as intimately involved in the i/o model, 
>>although it does not need to be.
>
>Then *please* present an alternative so I can understand your point of 
>view better.
>
>>>What happens if there is a persistent queue for a particular registrar? 
>>>If there are a bunch of old (but not yet expired) transfer notifications 
>>>waiting around and a notification of low balance shows up, which do you 
>>>try to send the transfers first?  Do you implement a prioritized 
>>>queue?  If you do, should we include the message priorities in the 
>>>protocol spec?  Then registrars have to additionally deal with message 
>>>priorities.
>>
>>None of this is relevant to the choice of mechanism that sends the "next" 
>>entry from the queue.
>
>So you're saying that the queuing of a backlog of message must obey the 
>order in which the messages were issued?

I am saying no such thing.  I am saying that the mechanism for sorting the 
queue is independent of the mechanism for initiating transfer of the top of 
the queue to the consumer.

d/

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

Date: Thu, 23 Aug 2001 21:58:49 +0200 (CEST)
From: Antoin Verschuren <[email-masked]>
To: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Sender: [email-masked]

On Thu, 23 Aug 2001, Jens Wagner wrote:

> > What do you want to change that you can't change?  There are no IP addresses
> > associated with the hosts in the non-authoritative registry, so the only
> > thing that's changeable is the name of the host itself.  If that's what you
> > need to do, just register the new host name(s) yourself with your registrar
> > of choice and the hosts will be usable for your purposes.
> >
> > <Scott/>
> 
> What happens if you associate some .com domains with ns1.vianetworks.nl, and
> the hijacker renames that host to ns1.hijacked.cx in the .com Registry?

I cannot test that, since I don't know the hijacker, and I'm not in the
position to change the hijackers host records. That's my whole problem.
The real problem is offcourse that anyone can register any nameserver with
any registrar, without anyone checking who is the real responsible person
for that nameserver. Therefor my proposition to always let the domain
holder be responsible for all nameservers under that domain.

I think some of you are missing the point of wanting host records in the
first place. It's not only the glue record that is an issue here.

We have some 30.000 domains in our nameservers. All these domains point to
a host record at the registrar. So the host is only registered once.
Now that we have renamed our nameservers, I also want to change all
registrations. Because the host is a record, and should only be registered
once, the solution is to change that host record, and ajust the hostname.
Because the domains point to that host record (and not to the hostname)
all domains can be changed with changing this one host record.

Registering our new hostname as a new host, that is a new host record,
would mean that I would then have to change 30.000 domains manualy, one by
one, and point all of them (hoping not to miss one domain) to this new
host record. This is because each registrar only allows one host record
per hostname, so if ns1.vianetworks.nl would be registered at Verisign, I
would have no possibility anymore to change the host NS7389-HST from
ns1.iae.nl into ns1.vianetworks.nl. Verisign will say: I'm sorry, but we
allready have a host record for ns1.vianetworks.nl.

I could probaly solve this issue by registering our new hosts at verisign,
and let them change all our domain records in their database. The point
I'm trying to make however is that this should not be the way to solve
this in the future with a new registry-registrar protocol, since the whole
point of using host records is then gone. And offcourse, it has still not
deleted the host record with Gandi. I want this record to be deleted, or
at least be responsible for it, and want to control this host record with 
a registrar of my choice.

Met groet,
VIA NET.WORKS Nederland

 Antoin Verschuren  
 Provisioning Coordinator 
 tel. + 31 40 2 393 393
 fax  + 31 40 2 393 311
 e-mail : [email-masked]            

 http://www.vianetworks.nl/ 

Date: Thu, 23 Aug 2001 12:32:43 -0700
To: "Hollenbeck, Scott" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: Push vs. not Push
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked], "'Jaap Akkerhuis'" <[email-masked]>
Sender: [email-masked]

I really hate it when I have to agree with someone from NSI...

but this is one of those times.

Just as there is a concern about imposing extra complexity on registration 
participants who have a light load, there needs to be concern about 
imposing inefficiencies on participants who have a heavy load.

Pursuing a core specification which is simpler, with optional extensions 
that provide more power, is the classic -- and exactly appropriate -- 
solution to this sort of debate.

d/

At 12:07 PM 8/23/2001, Hollenbeck, Scott wrote:
> >From a gTLD registry operator perspective...
>
>We should have a set of MUST implement basic functions, including a function
>for exchange of operational notices.  I would prefer a polling mechanism in
>the set of MUSTs.  I would also like to suggest that it may be possible to
>define an optional push extension that may or may not be
>transport-dependent.
>
><Scott/>

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

Date: Thu, 23 Aug 2001 12:33:48 -0400
To: Edward Lewis <[email-masked]>, [email-masked]
From: Richard Shockey <[email-masked]>
Subject: Re: Push vs. not Push
Cc: [email-masked]
Sender: [email-masked]

>
>After going through the email and minutes, I think that there is a need to
>poll the list to see if folks want the "push" mechanism to be defined or
>not.  As far as the merits of such a mechanism, please refrain from
>commenting on that, as it appears in archived messages.  My sense is that
>we aren't arguing the merits of push, but rather, whether implementors
>would be willing to add this feature in response to user (registr*) needs.

In the interest of trying to create a complete protocol there no good 
reason not to include push mechanisms... I would like to remind the list 
that the protocols being developed here may have uses outside TLD's in the 
future and arbitrary attempts to restrict its functionality purely to 
satisfy the limited requirements of that interest group is "a bad thing" tm.

And I say that as the co-Chair of the ENUM working group....and Scott 
Hollenbeck has recently posted a most interesting draft on the subject.

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

>In your response, let me know which registr*'s you are speaking for, so
>that we can determine if there is a pattern to differing opinions (e.g.,
>gTLDs vs. ccTLDs).  If you feel that you don't want to disclose this
>publicly, please send the message to just "[email-masked], [email-masked]"
>- ie the chairs.  If you do this, it might be a good idea to send a public
>version of your message to the list so others know how you feel on the
>issue.

and yes I'm have a TLD interest here ... .BIZ

>In either case, we (the chairs) will put a sanitized summary out on the
>list is short order.
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>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.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice 571.434.5651 Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: "'Jaap Akkerhuis'" <[email-masked]>
Subject: RE: Push vs. not Push
Date: Thu, 23 Aug 2001 15:07:44 -0400
Sender: [email-masked]

>From a gTLD registry operator perspective...

We should have a set of MUST implement basic functions, including a function
for exchange of operational notices.  I would prefer a polling mechanism in
the set of MUSTs.  I would also like to suggest that it may be possible to
define an optional push extension that may or may not be
transport-dependent.

<Scott/>

Date: Thu, 23 Aug 2001 15:08:25 -0400
To: Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: About the Push vs. not Push
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 11:56 AM -0400 8/23/01, Edward Lewis wrote:
>In your response, let me know which registr*'s you are speaking for, so
>that we can determine if there is a pattern to differing opinions (e.g.,
>gTLDs vs. ccTLDs).

Someone raised a question about my motivation in asking the above.  Here
was my response:

I am curious about where folks are coming from, not for counting or voting.
I see a lot of discussion that seems to be prompted from the gTLD
community's contractural dealings with ICANN and then reverse discussion
from some ccTLDs, and not much from "others" - including the RIR's.

I am looking more for a demographic behind the opinions than size.  If
there is a systemic difference of opinion, then it is easier to try and
adjust the solution - I hope.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Thu, 23 Aug 2001 15:17:03 -0400
From: Daniel Manley <[email-masked]>
To: Daniel Manley <[email-masked]>
CC: Dave Crocker <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

Just a small correction to a sentence I wrote:

"I don't think it would be fair to the smaller players to impose a 
heavy-duty protocol. "

should have read....

"I don't think it would be fair to the smaller players to be imposed a 
heavy-duty protocol. "

sorry for the mixup.

Dan

To: Daniel Manley <[email-masked]>
cc: Rick H Wesson <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport 
Date: Thu, 23 Aug 2001 14:45:41 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> A separate listener/handler is the way to go.

Yup.

Nice technical note Rick. How the IETF should be.

Eric

Date: Thu, 23 Aug 2001 14:52:06 -0400
From: Daniel Manley <[email-masked]>
To: Edward Lewis <[email-masked]>
CC: [email-masked]
Subject: Re: Push vs. not Push
Sender: [email-masked]

Ed,

Tucows, as ...
    - the operator of the Saint Vincent Registry (.vc),
    - a registrar for multiple registries (com/net/org, ca, 
co.uk/org.uk,cc,vc and other gTLDs coming soon),
    - the .info registry outsourcer

... and on behalf of (or at least as a player in) the EPP-RTK on 
Sourceforge, votes to not include push in the EPP spec.

Dan

From: "Bason, Chris" <[email-masked]>
To: Edward Lewis <[email-masked]>, [email-masked]
Subject: RE: Push vs. not Push
Date: Thu, 23 Aug 2001 14:30:50 -0400
Sender: [email-masked]

As an implementer from a gTLD registry perspective, my preference is for
polling.

I can't speak directly for any registrar. Although I would like to
point out that in my past experience I have implemented the gTLD registrar
end of the system. Drawing from that experience I would again vote
for polling. I can see many easy solutions for implementing polling
on the registrar end.

Chris Bason

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 11:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: Push vs. not Push

At the conclusion of the in-person meeting in London, the sense of the room
was that Scott would amend the EPP drafts to include a "push" mechanism to
send messages from registries to registrars.  In the time since the
meeting, there have been some strong objections in email to this change.

After going through the email and minutes, I think that there is a need to
poll the list to see if folks want the "push" mechanism to be defined or
not.  As far as the merits of such a mechanism, please refrain from
commenting on that, as it appears in archived messages.  My sense is that
we aren't arguing the merits of push, but rather, whether implementors
would be willing to add this feature in response to user (registr*) needs.

In your response, let me know which registr*'s you are speaking for, so
that we can determine if there is a pattern to differing opinions (e.g.,
gTLDs vs. ccTLDs).  If you feel that you don't want to disclose this
publicly, please send the message to just "[email-masked], [email-masked]"
- ie the chairs.  If you do this, it might be a good idea to send a public
version of your message to the list so others know how you feel on the
issue.

In either case, we (the chairs) will put a sanitized summary out on the
list is short order.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Thu, 23 Aug 2001 14:21:59 -0400
From: Daniel Manley <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

Dave Crocker wrote:

>
> You seemed to have missed my point, that such pinging is not a good 
> thing.   If the server wants to be shutting down inactive connections, 
> then the folks running the server are not going to appreciate your 
> circumventing their management policies.  They will then add 
> mechanisms for disabling the ping, in whatever form it is commonly 
> achieved. 

All the registries that my employer and I work with, who will remain 
nameless, encourage regular pinging to maintain connections.  Having to 
reconnect after a server cuts you off after a period of inactivity is a 
pain and can represent a momentary interruption in service to our 
clients.  Secure connections are relatively expensive to establish.

>> clientA issues a transfer for an object and places a message on an 
>> internal queue for clientB.
>
>
> Huh?  ClientA places a message on a queue for ClientB.  What ARE you 
> talking about? 

Sorry, it was a slip of the keyboard.  I was trying to say that the 
server would place a notification on the queue of clientB.

>
> You have a strang model of server and thread implementation.  The idea 
> that it requires internal polling, no matter what, is simply wrong. 

Hey, there's all kinds of schools of thought on server and thread 
implementations.  I personally don't find mine strange -- I'm building 
on my experience with servers that I've worked on in the past.

>> ... somewhere along the line, a process or thread will have to poll 
>> something to see if there's anything to do.
>
>
> wrong. 

You keep saying that I'm wrong without describing your alternative. 
 That's not very fair, is it?

>
>>> Actually, no.  Pushing has no wasted effort, unlike polling.  Hence 
>>> the overhead of push is only incurred when there is something to push.
>>
>>
>> Except for queuing when the message can't be delivered taken right away.
>
>
> queuing is an entirely separate bit of mechanism and overhead, with 
> equal overhead on top of push or pull. 

If you're going to push queued messages, then I don't see how it's an 
entirely separate mechanism.  Yes, with equal overhead, except that 
pulling is not done by the server, so the load is distributed a little 
more equally between client and server.

>
>
> the point that is being missed is polling permits only a subset of the 
> behaviors and efficiencies that push permits.  Push demonstrates 
> vastly better scaling properties. 

Can you enumerate these behaviours, efficiencies and scaling properties? 
 I see the same messages being passed either way so the argument is over 
the delivery method.

>
>
> Internet application protocols have intentionally chosen simplistic 
> transaction models, in the past.  That has been fine for small scale 
> activities.  As we try to permit serious, large-scale applications, we 
> need to use the kinds of mechanisms that modern, large-scale 
> transaction systems use.
>
> And have used for a very long time.  (Which is a semi-polite way of 
> suggesting that most of us need to realize that we are amateurs in the 
> field of transaction processing. Amateurs usually find the work of 
> professionals to be "more complicated" than we are used to...)
>
> (For reference, please note the "we".  That is not just for 
> politeness.  I very much include myself.  The difference, right now, 
> is that I have been trying to appreciate the nature of this other area 
> of expertise, rather than to automatically reject it because it makes 
> protocol work a bit more complicated.)

I've worked with Local Number Portability myself.  TMN, CMIP, GDMO and 
all that jazz.  Let me tell you, the toolkit we used was not a cakewalk. 
 I worked with a really bright crew, but only the system architects and 
the lead senior developers touched that code.  Cool stuff but what a 
headache.

But that was in a really controlled environment.  Only a handfull of big 
clients.  Provreg is defining a generic protocol which will have many 
application groups.  I don't think it would be fair to the smaller 
players to impose a heavy-duty protocol.

>
> The server needs to get the data to the client, no matter what.  You 
> seem to feel that sending it immediately, rather having to wait an 
> arbitrary amount of time, somehow incurs onerous overhead.  It doesn't. 

We seem to be going in circles here.  I'm saying there are two 
activities:  generating messages and delivering messages.  Pushing puts 
these two activities in the server, while polling splits them between 
the server and the client, respectively.  With the client pinging anyway 
(yes, an integral part of my argument), the total overhead is roughly 
the same, but balanced better between two parties.

>
> Frankly I can't figure out the processing model that you are 
> describing, since you seem to view queuing as intimately involved in 
> the i/o model, although it does not need to be. 

Then *please* present an alternative so I can understand your point of 
view better.

>> What happens if there is a persistent queue for a particular 
>> registrar? If there are a bunch of old (but not yet expired) transfer 
>> notifications waiting around and a notification of low balance shows 
>> up, which do you try to send the transfers first?  Do you implement a 
>> prioritized queue?  If you do, should we include the message 
>> priorities in the protocol spec?  Then registrars have to 
>> additionally deal with message priorities.
>
>
> None of this is relevant to the choice of mechanism that sends the 
> "next" entry from the queue. 

So you're saying that the queuing of a backlog of message must obey the 
order in which the messages were issued?  If that's true, then my 
concerns in the paragraph above disappear.

Dan

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Push vs. not Push 
Date: Thu, 23 Aug 2001 13:43:55 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

The .biz registry operator has implemented <push> in its server and in
its client. The .biz registry operator wants the push mechanism.

Eric

Date: Thu, 23 Aug 2001 10:02:51 -0700
To: Daniel Manley <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 09:18 AM 8/23/2001, Daniel Manley wrote:
>>And you are placing a load on the server that the registry operator 
>>should not appreciate very much.
>
>Ok, let's say push replaces poll.  The registrars will still have to ping 
>the registry to keep persistent connections alive.

You seemed to have missed my point, that such pinging is not a good 
thing.   If the server wants to be shutting down inactive connections, then 
the folks running the server are not going to appreciate your circumventing 
their management policies.  They will then add mechanisms for disabling the 
ping, in whatever form it is commonly achieved.

So, you want to believe that polling will happen no matter what.  I am 
trying to point out the negative side of such an activity.

>Thinking also of a possible server design:  a multi-threaded or -processed 
>server is working for many clients.

yup.  that's why the pinging creates an aggregate overhead that server 
operators will not appreciate.

>clientA issues a transfer for an object and places a message on an 
>internal queue for clientB.

Huh?  ClientA places a message on a queue for ClientB.  What ARE you 
talking about?

>any of the threads working for clientB has to read the the queue when it 
>has time (i.e. "poll" the queue) and then pushes the message to the 
>registrar.

You have a strang model of server and thread implementation.  The idea that 
it requires internal polling, no matter what, is simply wrong.

>... somewhere along the line, a process or thread will have to poll 
>something to see if there's anything to do.

wrong.

>>Actually, no.  Pushing has no wasted effort, unlike polling.  Hence the 
>>overhead of push is only incurred when there is something to push.
>
>Except for queuing when the message can't be delivered taken right away.

queuing is an entirely separate bit of mechanism and overhead, with equal 
overhead on top of push or pull.

the point that is being missed is polling permits only a subset of the 
behaviors and efficiencies that push permits.  Push demonstrates vastly 
better scaling properties.

Internet application protocols have intentionally chosen simplistic 
transaction models, in the past.  That has been fine for small scale 
activities.  As we try to permit serious, large-scale applications, we need 
to use the kinds of mechanisms that modern, large-scale transaction systems 
use.

And have used for a very long time.  (Which is a semi-polite way of 
suggesting that most of us need to realize that we are amateurs in the 
field of transaction processing. Amateurs usually find the work of 
professionals to be "more complicated" than we are used to...)

(For reference, please note the "we".  That is not just for politeness.  I 
very much include myself.  The difference, right now, is that I have been 
trying to appreciate the nature of this other area of expertise, rather 
than to automatically reject it because it makes protocol work a bit more 
complicated.)

>>So I have no idea how your are calculating a "multiplied" overhead.
>>Feel free to provide detail for your claim.
>
>I haven't invested any research time to back my claim.  I was just using 
>common sense.

>Let's say that 10 registrars are connected to the registry.  In a polling 
>system, the registry sits back and waits for requests from the 
>servers.  Much or most of the CPU time is dedicated to serving requests.

and pings and/or polling requests for non-existent data.  so, it is 
spending time for each client, doing unproductive overhead.

>In a pushing system, the registry has to be proactive and take up CPU 
>cycles from serving requests to push notifications to the registrars.

The server needs to get the data to the client, no matter what.  You seem 
to feel that sending it immediately, rather having to wait an arbitrary 
amount of time, somehow incurs onerous overhead.  It doesn't.

What it DOES do is a) impose delay, and b) force extra overhead from 
unproductive polling.

>That might not seem so bad at first, but, as I mentioned above in this 
>email, if the registrar is not connected or if an acknowledgment is not 
>returned, the registry has to take the time to queue this message 
>(dropping it then and there doesn't seem like a good idea) and try to 
>deliver it later.  Now the server  is performing housework for the client, 
>taking more time away from serving requests.
>
>This is where the "multiplied" part comes in:  the registry is now 
>performing delivery work for X registrars while the registrar clients 
>happily sit around waiting for something from the server while still 
>inundating the server with more requests.

Frankly I can't figure out the processing model that you are describing, 
since you seem to view queuing as intimately involved in the i/o model, 
although it does not need to be.

>What happens if there is a persistent queue for a particular registrar? If 
>there are a bunch of old (but not yet expired) transfer notifications 
>waiting around and a notification of low balance shows up, which do you 
>try to send the transfers first?  Do you implement a prioritized 
>queue?  If you do, should we include the message priorities in the 
>protocol spec?  Then registrars have to additionally deal with message 
>priorities.

None of this is relevant to the choice of mechanism that sends the "next" 
entry from the queue.

d/

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

Date: Thu, 23 Aug 2001 12:53:12 -0400
From: Daniel Manley <[email-masked]>
To: Rick H Wesson <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

Rick,
That sounds like a very good design.  I agree with you 100% that main 
processing threads should not handle the polled responses.  A separate 
listener/handler is the way to go.

Dan

Rick H Wesson wrote:

>Dan,
>
>I've had to implement EPP connection pools in a multithreaded environment.
>Each epp connection polls to keep the session alive, however these
>sessions won't handle any queued messages.
>
>A seporate thread handles all gathering of pooled messages. I use a
>registered callback, actually a Message Driven Bean in java to handle the
>polled messages.
>
>In my design, I can deal with push or poll in the same way.
>
>IMHO, the connections used for pre-sales and post-sales proceses wouldn't
>be encouranged to do event handling unless you are fetching them from the
>same epp connection pool. At any rate either facility will work just fine
>for me.
>
>that my $.02
>
>-rick
>
>
>On Thu, 23 Aug 2001, Daniel Manley wrote:
>
>>(my apoligies to making these a little long, but it's required to
>>describe the scenarios that polling and pushing could create.  the last
>>couple of paragraphs contain questions and issues I have with pushing)
>>
>>Dave Crocker wrote:
>>
>>>At 05:23 PM 8/22/2001, Daniel Manley wrote:
>>>
>>>>>The usual response is "polling" but that means constantly polling,
>>>>>and in this case constantly polling for something that is typically
>>>>>not present.  Hence, substantial overhead, for negative benefit.
>>>>>
>>>>
>>>>If you're using poll to ping a connection to keep it alive, then
>>>>you're already doing it anyhow.
>>>>
>>>
>>>And you are placing a load on the server that the registry operator
>>>should not appreciate very much.
>>>
>>Ok, let's say push replaces poll.  The registrars will still have to
>>ping the registry to keep persistent connections alive.  Poll, IMHO,
>>seemed like a very good candidate for pinging.  Without it, registrars
>>will likely either turn to "hello" or "domain:check", both having no
>>data modification effects on data.
>>
>>So then, the registrars are still pinging to stay alive and the registry
>>is now also spontaneously sending notifications to the registrar.  The
>>registrar then has to be ready to perform any of three actions at any
>>time:  send requests and read the responses, ping the connection in
>>periods of inactivity and read the in-bound pipe for notifications from
>>the server.
>>
>>Thinking also of a possible server design:  a multi-threaded or
>>-processed server is working for many clients.  clientA issues a
>>transfer for an object and places a message on an internal queue for
>>clientB.  any of the threads working for clientB has to read the the
>>queue when it has time (i.e. "poll" the queue) and then pushes the
>>message to the registrar.
>>
>>I imagine my argument is getting old and worn out but... somewhere along
>>the line, a process or thread will have to poll something to see if
>>there's anything to do.  You could try to minimize that by making all
>>the threads in the registry cognisant of each other so that these
>>notifications could be pushed around, but as Scott says, if the message
>>is undeliverable or unacknowledge, then the registry would likely want
>>to queue it and then poll that queue later.
>>
>>>>So I don't think there's a negative benefit. Pushing pushes the
>>>>substantial overhead *multiplied* by each registrar client to the
>>>>server, who's already overworked anyway.
>>>>
>>>
>>>Actually, no.  Pushing has no wasted effort, unlike polling.  Hence
>>>the overhead of push is only incurred when there is something to push.
>>>
>>Except for queuing when the message can't be delivered taken right away.
>>
>>>
>>>So I have no idea how your are calculating a "multiplied" overhead.
>>>Feel free to provide detail for your claim.
>>>
>>I haven't invested any research time to back my claim.  I was just using
>>common sense.
>>
>>Let's say that 10 registrars are connected to the registry.  In a
>>polling system, the registry sits back and waits for requests from the
>>servers.  Much or most of the CPU time is dedicated to serving requests.
>> [most of this paragraph  can be skipped, the last sentence sums it up]
>>Registrars process requests:  object registrations, modifications,
>>transfers, etc... and pinging to keep idle connections alive.  If the
>>registry has something to tell the registrar out of normal
>>requests/responses (like a pending transfer notification), it places the
>>message and accompanying data on a queue for the registrar to pick up at
>>any time.  Some might contain time-sensitive data, and the registrar, in
>>it's agreement with the registry *and* the suggestion from the protocol
>>spec, knows that it should check this queue periodically to pick up
>>messages.   So the registry in its role of serving registrars will
>>retrieve queued messages if the requests ask for that.
>>
>>In a pushing system, the registry has to be proactive and take up CPU
>>cycles from serving requests to push notifications to the registrars.
>> That might not seem so bad at first, but, as I mentioned above in this
>>email, if the registrar is not connected or if an acknowledgment is not
>>returned, the registry has to take the time to queue this message
>>(dropping it then and there doesn't seem like a good idea) and try to
>>deliver it later.  Now the server  is performing housework for the
>>client, taking more time away from serving requests.
>>
>>This is where the "multiplied" part comes in:  the registry is now
>>performing delivery work for X registrars while the registrar clients
>>happily sit around waiting for something from the server while still
>>inundating the server with more requests.
>>
>>What happens if there is a persistent queue for a particular registrar?
>> If there are a bunch of old (but not yet expired) transfer
>>notifications waiting around and a notification of low balance shows up,
>>which do you try to send the transfers first?  Do you implement a
>>prioritized queue?  If you do, should we include the message priorities
>>in the protocol spec?  Then registrars have to additionally deal with
>>message priorities.
>>
>>It just seems black and white to me:  the protocol says the registrar
>>should poll for messages, the registry/registrar agreements and
>>certification tests should enforce that, if messages expire or build up,
>>then they could unloaded and an out-of-band report could be sent.  The
>>registrar could choose to process that with a program, but it's likely
>>that many of those messages would be useless or meaningless by then anyhow.
>>
>>Dan
>>
>>
>>
>

Date: Thu, 23 Aug 2001 09:30:11 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Daniel Manley <[email-masked]>
cc: Dave Crocker <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

Dan,

I've had to implement EPP connection pools in a multithreaded environment.
Each epp connection polls to keep the session alive, however these
sessions won't handle any queued messages.

A seporate thread handles all gathering of pooled messages. I use a
registered callback, actually a Message Driven Bean in java to handle the
polled messages.

In my design, I can deal with push or poll in the same way.

IMHO, the connections used for pre-sales and post-sales proceses wouldn't
be encouranged to do event handling unless you are fetching them from the
same epp connection pool. At any rate either facility will work just fine
for me.

that my $.02

-rick

On Thu, 23 Aug 2001, Daniel Manley wrote:

> (my apoligies to making these a little long, but it's required to
> describe the scenarios that polling and pushing could create.  the last
> couple of paragraphs contain questions and issues I have with pushing)
>
> Dave Crocker wrote:
>
> > At 05:23 PM 8/22/2001, Daniel Manley wrote:
> >
> >>> The usual response is "polling" but that means constantly polling,
> >>> and in this case constantly polling for something that is typically
> >>> not present.  Hence, substantial overhead, for negative benefit.
> >>
> >>
> >> If you're using poll to ping a connection to keep it alive, then
> >> you're already doing it anyhow.
> >
> >
> > And you are placing a load on the server that the registry operator
> > should not appreciate very much.
>
> Ok, let's say push replaces poll.  The registrars will still have to
> ping the registry to keep persistent connections alive.  Poll, IMHO,
> seemed like a very good candidate for pinging.  Without it, registrars
> will likely either turn to "hello" or "domain:check", both having no
> data modification effects on data.
>
> So then, the registrars are still pinging to stay alive and the registry
> is now also spontaneously sending notifications to the registrar.  The
> registrar then has to be ready to perform any of three actions at any
> time:  send requests and read the responses, ping the connection in
> periods of inactivity and read the in-bound pipe for notifications from
> the server.
>
> Thinking also of a possible server design:  a multi-threaded or
> -processed server is working for many clients.  clientA issues a
> transfer for an object and places a message on an internal queue for
> clientB.  any of the threads working for clientB has to read the the
> queue when it has time (i.e. "poll" the queue) and then pushes the
> message to the registrar.
>
> I imagine my argument is getting old and worn out but... somewhere along
> the line, a process or thread will have to poll something to see if
> there's anything to do.  You could try to minimize that by making all
> the threads in the registry cognisant of each other so that these
> notifications could be pushed around, but as Scott says, if the message
> is undeliverable or unacknowledge, then the registry would likely want
> to queue it and then poll that queue later.
>
> >
> >> So I don't think there's a negative benefit. Pushing pushes the
> >> substantial overhead *multiplied* by each registrar client to the
> >> server, who's already overworked anyway.
> >
> >
> > Actually, no.  Pushing has no wasted effort, unlike polling.  Hence
> > the overhead of push is only incurred when there is something to push.
>
> Except for queuing when the message can't be delivered taken right away.
>
> >
> >
> > So I have no idea how your are calculating a "multiplied" overhead.
> > Feel free to provide detail for your claim.
>
> I haven't invested any research time to back my claim.  I was just using
> common sense.
>
> Let's say that 10 registrars are connected to the registry.  In a
> polling system, the registry sits back and waits for requests from the
> servers.  Much or most of the CPU time is dedicated to serving requests.
>  [most of this paragraph  can be skipped, the last sentence sums it up]
> Registrars process requests:  object registrations, modifications,
> transfers, etc... and pinging to keep idle connections alive.  If the
> registry has something to tell the registrar out of normal
> requests/responses (like a pending transfer notification), it places the
> message and accompanying data on a queue for the registrar to pick up at
> any time.  Some might contain time-sensitive data, and the registrar, in
> it's agreement with the registry *and* the suggestion from the protocol
> spec, knows that it should check this queue periodically to pick up
> messages.   So the registry in its role of serving registrars will
> retrieve queued messages if the requests ask for that.
>
> In a pushing system, the registry has to be proactive and take up CPU
> cycles from serving requests to push notifications to the registrars.
>  That might not seem so bad at first, but, as I mentioned above in this
> email, if the registrar is not connected or if an acknowledgment is not
> returned, the registry has to take the time to queue this message
> (dropping it then and there doesn't seem like a good idea) and try to
> deliver it later.  Now the server  is performing housework for the
> client, taking more time away from serving requests.
>
> This is where the "multiplied" part comes in:  the registry is now
> performing delivery work for X registrars while the registrar clients
> happily sit around waiting for something from the server while still
> inundating the server with more requests.
>
> What happens if there is a persistent queue for a particular registrar?
>  If there are a bunch of old (but not yet expired) transfer
> notifications waiting around and a notification of low balance shows up,
> which do you try to send the transfers first?  Do you implement a
> prioritized queue?  If you do, should we include the message priorities
> in the protocol spec?  Then registrars have to additionally deal with
> message priorities.
>
> It just seems black and white to me:  the protocol says the registrar
> should poll for messages, the registry/registrar agreements and
> certification tests should enforce that, if messages expire or build up,
> then they could unloaded and an out-of-band report could be sent.  The
> registrar could choose to process that with a program, but it's likely
> that many of those messages would be useless or meaningless by then anyhow.
>
> Dan
>
>
>

Date: Thu, 23 Aug 2001 12:18:03 -0400
From: Daniel Manley <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

(my apoligies to making these a little long, but it's required to 
describe the scenarios that polling and pushing could create.  the last 
couple of paragraphs contain questions and issues I have with pushing)

Dave Crocker wrote:

> At 05:23 PM 8/22/2001, Daniel Manley wrote:
>
>>> The usual response is "polling" but that means constantly polling, 
>>> and in this case constantly polling for something that is typically 
>>> not present.  Hence, substantial overhead, for negative benefit.
>>
>>
>> If you're using poll to ping a connection to keep it alive, then 
>> you're already doing it anyhow.
>
>
> And you are placing a load on the server that the registry operator 
> should not appreciate very much. 

Ok, let's say push replaces poll.  The registrars will still have to 
ping the registry to keep persistent connections alive.  Poll, IMHO, 
seemed like a very good candidate for pinging.  Without it, registrars 
will likely either turn to "hello" or "domain:check", both having no 
data modification effects on data.  

So then, the registrars are still pinging to stay alive and the registry 
is now also spontaneously sending notifications to the registrar.  The 
registrar then has to be ready to perform any of three actions at any 
time:  send requests and read the responses, ping the connection in 
periods of inactivity and read the in-bound pipe for notifications from 
the server.

Thinking also of a possible server design:  a multi-threaded or 
-processed server is working for many clients.  clientA issues a 
transfer for an object and places a message on an internal queue for 
clientB.  any of the threads working for clientB has to read the the 
queue when it has time (i.e. "poll" the queue) and then pushes the 
message to the registrar.  

I imagine my argument is getting old and worn out but... somewhere along 
the line, a process or thread will have to poll something to see if 
there's anything to do.  You could try to minimize that by making all 
the threads in the registry cognisant of each other so that these 
notifications could be pushed around, but as Scott says, if the message 
is undeliverable or unacknowledge, then the registry would likely want 
to queue it and then poll that queue later.

>
>> So I don't think there's a negative benefit. Pushing pushes the 
>> substantial overhead *multiplied* by each registrar client to the 
>> server, who's already overworked anyway.
>
>
> Actually, no.  Pushing has no wasted effort, unlike polling.  Hence 
> the overhead of push is only incurred when there is something to push. 

Except for queuing when the message can't be delivered taken right away.

>
>
> So I have no idea how your are calculating a "multiplied" overhead.  
> Feel free to provide detail for your claim. 

I haven't invested any research time to back my claim.  I was just using 
common sense.  

Let's say that 10 registrars are connected to the registry.  In a 
polling system, the registry sits back and waits for requests from the 
servers.  Much or most of the CPU time is dedicated to serving requests. 
 [most of this paragraph  can be skipped, the last sentence sums it up] 
Registrars process requests:  object registrations, modifications, 
transfers, etc... and pinging to keep idle connections alive.  If the 
registry has something to tell the registrar out of normal 
requests/responses (like a pending transfer notification), it places the 
message and accompanying data on a queue for the registrar to pick up at 
any time.  Some might contain time-sensitive data, and the registrar, in 
it's agreement with the registry *and* the suggestion from the protocol 
spec, knows that it should check this queue periodically to pick up 
messages.   So the registry in its role of serving registrars will 
retrieve queued messages if the requests ask for that.

In a pushing system, the registry has to be proactive and take up CPU 
cycles from serving requests to push notifications to the registrars. 
 That might not seem so bad at first, but, as I mentioned above in this 
email, if the registrar is not connected or if an acknowledgment is not 
returned, the registry has to take the time to queue this message 
(dropping it then and there doesn't seem like a good idea) and try to 
deliver it later.  Now the server  is performing housework for the 
client, taking more time away from serving requests.  

This is where the "multiplied" part comes in:  the registry is now 
performing delivery work for X registrars while the registrar clients 
happily sit around waiting for something from the server while still 
inundating the server with more requests.

What happens if there is a persistent queue for a particular registrar? 
 If there are a bunch of old (but not yet expired) transfer 
notifications waiting around and a notification of low balance shows up, 
which do you try to send the transfers first?  Do you implement a 
prioritized queue?  If you do, should we include the message priorities 
in the protocol spec?  Then registrars have to additionally deal with 
message priorities.

It just seems black and white to me:  the protocol says the registrar 
should poll for messages, the registry/registrar agreements and 
certification tests should enforce that, if messages expire or build up, 
then they could unloaded and an out-of-band report could be sent.  The 
registrar could choose to process that with a program, but it's likely 
that many of those messages would be useless or meaningless by then anyhow.

Dan

Date: Thu, 23 Aug 2001 11:56:29 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Push vs. not Push
Cc: [email-masked]
Sender: [email-masked]

At the conclusion of the in-person meeting in London, the sense of the room
was that Scott would amend the EPP drafts to include a "push" mechanism to
send messages from registries to registrars.  In the time since the
meeting, there have been some strong objections in email to this change.

After going through the email and minutes, I think that there is a need to
poll the list to see if folks want the "push" mechanism to be defined or
not.  As far as the merits of such a mechanism, please refrain from
commenting on that, as it appears in archived messages.  My sense is that
we aren't arguing the merits of push, but rather, whether implementors
would be willing to add this feature in response to user (registr*) needs.

In your response, let me know which registr*'s you are speaking for, so
that we can determine if there is a pattern to differing opinions (e.g.,
gTLDs vs. ccTLDs).  If you feel that you don't want to disclose this
publicly, please send the message to just "[email-masked], [email-masked]"
- ie the chairs.  If you do this, it might be a good idea to send a public
version of your message to the list so others know how you feel on the
issue.

In either case, we (the chairs) will put a sanitized summary out on the
list is short order.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: "'Antoin Verschuren'" <[email-masked]>, [email-masked]
Subject: RE: host transfers -- actually, out-of-zone-glue (fwd)
Date: Thu, 23 Aug 2001 11:36:12 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Antoin Verschuren [mailto:[email-masked]]
>Sent: Thursday, August 23, 2001 10:33 AM
>To: [email-masked]
>Subject: RE: host transfers -- actually, out-of-zone-glue (fwd)
>
>
>On Thu, 23 Aug 2001, Hollenbeck, Scott wrote:
>
>> What do you want to change that you can't change?  There are no IP
addresses
>> associated with the hosts in the non-authoritative registry, so the only
>> thing that's changeable is the name of the host itself.  If that's what
you
>> need to do, just register the new host name(s) yourself with your
registrar
>> of choice and the hosts will be usable for your purposes.
>
>But then, our current host records are not changeable anymore to
>ns1.vianetworks.nl because this hostname allready excists at this
>registrar, but with another host handle. To be more precise, we want to
>change:
>
>Host Handle: NS7389-HST
>Nameserver:  ns1.iae.nl
>IP number:   212.61.26.34
>
>into:
>
>Host Handle: NS7389-HST
>Nameserver:  ns1.vianetworks.nl
>IP number:   212.61.15.8

If I'm reading this correctly, the real issue here is with the way one
particular registrar manages hosts.  They shouldn't attempt to create a new
host object if the host you need to delegate to is already in the registry.
If they would just accept the name change as you described above (they
really don't need to collect address info as we're all well aware), all of
the domains currently delegated to ns1.iae.nl would be delegated to
ns1.vianetworks.nl and everything would work.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jens Wagner'" <[email-masked]>, [email-masked]
Subject: RE: host transfers -- actually, out-of-zone-glue
Date: Thu, 23 Aug 2001 10:56:36 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Jens Wagner [mailto:[email-masked]]
>Sent: Thursday, August 23, 2001 10:03 AM
>To: [email-masked]
>Subject: Re: host transfers -- actually, out-of-zone-glue
>
>
>What happens if you associate some .com domains with ns1.vianetworks.nl,
and
>the hijacker renames that host to ns1.hijacked.cx in the .com Registry?

You register ns1.vianetworks.nl, update the associated domains, and
delegations get fixed with the next zone update.

<Scott/>

Date: Thu, 23 Aug 2001 10:22:43 -0400
To: Antoin Verschuren <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: host transfers -- actually, out-of-zone-glue
Cc: [email-masked], Patrick <[email-masked]>
Sender: [email-masked]

At 8:35 AM -0400 8/23/01, Antoin Verschuren wrote:
>I also wonder how registration of nameservers will take place in the
>future with DNSsec. As far as I can tell, this will probably make it
>nessecary that the maintainer of the host record is indeed the owner of
>the actual nameserver, because he will have to be able to access the
>nameserver and negociate the encryption keys.

Speaking as someone who has spent years on DNSSEC (and not as a WG chair):
Neither the NS set nor glue records are signed, hence DNSSEC doesn't play a
role in name server data.  DNSSEC will impact delegations, but quite
frankly, how DNSSEC will is being reviewed in the DNSEXT and DNSOP WGs.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Thu, 23 Aug 2001 16:33:13 +0200 (CEST)
From: Antoin Verschuren <[email-masked]>
To: [email-masked]
Subject: RE: host transfers -- actually, out-of-zone-glue (fwd)
Sender: [email-masked]

On Thu, 23 Aug 2001, Hollenbeck, Scott wrote:

> What do you want to change that you can't change?  There are no IP addresses
> associated with the hosts in the non-authoritative registry, so the only
> thing that's changeable is the name of the host itself.  If that's what you
> need to do, just register the new host name(s) yourself with your registrar
> of choice and the hosts will be usable for your purposes.

But then, our current host records are not changeable anymore to
ns1.vianetworks.nl because this hostname allready excists at this
registrar, but with another host handle. To be more precise, we want to
change:

Host Handle: NS7389-HST
Nameserver:  ns1.iae.nl
IP number:   212.61.26.34

into:

Host Handle: NS7389-HST
Nameserver:  ns1.vianetworks.nl
IP number:   212.61.15.8

So that all 4.000 domains currently using ns1.iae.nl (NS7389-HST) will use
ns1.vianetworks.nl. If I try that, Verisign answers:

> > Servers are registered with no IP at another registrar.  They must
update
> > the servers with an IP address before we can add them to our database.
> > 
> > Sam
> > 
> > Server Name: NS1.VIANETWORKS.NL
> >    Registrar: GANDI
> >    Whois Server: whois.gandi.net
> >    Referral URL: http://www.gandi.net
> > 
> > 
> > Server Name: NS2.VIANETWORKS.NL
> >    Registrar: GANDI
> >    Whois Server: whois.gandi.net
> >    Referral URL: http://www.gandi.net

For these nameserver registrations, I'm probably not authorative with
Gandi according to the current registration practice. And even worse, I
don't even have a way of knowing who did registrate them.

If I try your solution, and then try to change NS7389-HST, I get the
error:
NS1.VIANETWORKS.NL Allready registrated.
So in other words, no 2 host records with the same hostname can excist
with Verisign, which ofcourse I think should be so.

What I think is strange however, is that I can create a new host
ns1.vianetworks.nl at Verisign, and then nobody tells me that this
hostname allready excist at Gandi, it is simply created, but if I want to
change my current host record into ns1.vianetworks.nl then this check with
other registrars is suddenly made..

Met groet,
VIA NET.WORKS Nederland

 Antoin Verschuren  
 Provisioning Coordinator 
 tel. + 31 40 2 393 393
 fax  + 31 40 2 393 311
 e-mail : [email-masked]            

 http://www.vianetworks.nl/ 

Date: Thu, 23 Aug 2001 16:03:14 +0200
From: Jens Wagner <[email-masked]>
Organization: Key-Systems GmbH
To: [email-masked]
Subject: Re: host transfers -- actually, out-of-zone-glue
Sender: [email-masked]

"Hollenbeck, Scott" wrote:

> >-----Original Message-----
> >From: Antoin Verschuren [mailto:[email-masked]]
> >Sent: Thursday, August 23, 2001 8:35 AM
> >To: [email-masked]
> >Cc: Patrick
> >Subject: Re: host transfers -- actually, out-of-zone-glue
> >
> >
> >We are the owner of the domainname vianetworks.nl. The Dutch
> >domainregistry holds the glue records for ns1.vianetworks.nl and
> >ns2.vianetworks.nl which is correct.
> >Now that we want to start using these nameservers for some 10.000
> >domainnames with Verisign, there is a problem of registrating these hosts.
> >As it seems, some other party has registered a domain with Gandi using
> >these nameservers, but without IP addresses. At Gandi, we don't have any
> >authority to make changes to this registration. As result of this, we
> >cannot make the appropriate changes to these hosts to make them usable for
> >our 10.000 domains. Our nameservers are simply hijacked by one person that
> >uses our nameserver without our permission.
>
> What do you want to change that you can't change?  There are no IP addresses
> associated with the hosts in the non-authoritative registry, so the only
> thing that's changeable is the name of the host itself.  If that's what you
> need to do, just register the new host name(s) yourself with your registrar
> of choice and the hosts will be usable for your purposes.
>
> <Scott/>

What happens if you associate some .com domains with ns1.vianetworks.nl, and
the hijacker renames that host to ns1.hijacked.cx in the .com Registry?

Kind regards,

Jens Wagner
Key-Systems GmbH

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Antoin Verschuren'" <[email-masked]>, [email-masked]
Cc: Patrick <[email-masked]>
Subject: RE: host transfers -- actually, out-of-zone-glue
Date: Thu, 23 Aug 2001 09:07:41 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Antoin Verschuren [mailto:[email-masked]]
>Sent: Thursday, August 23, 2001 8:35 AM
>To: [email-masked]
>Cc: Patrick
>Subject: Re: host transfers -- actually, out-of-zone-glue
>
>
>We are the owner of the domainname vianetworks.nl. The Dutch
>domainregistry holds the glue records for ns1.vianetworks.nl and
>ns2.vianetworks.nl which is correct.
>Now that we want to start using these nameservers for some 10.000
>domainnames with Verisign, there is a problem of registrating these hosts.
>As it seems, some other party has registered a domain with Gandi using
>these nameservers, but without IP addresses. At Gandi, we don't have any
>authority to make changes to this registration. As result of this, we
>cannot make the appropriate changes to these hosts to make them usable for
>our 10.000 domains. Our nameservers are simply hijacked by one person that
>uses our nameserver without our permission.

What do you want to change that you can't change?  There are no IP addresses
associated with the hosts in the non-authoritative registry, so the only
thing that's changeable is the name of the host itself.  If that's what you
need to do, just register the new host name(s) yourself with your registrar
of choice and the hosts will be usable for your purposes.

<Scott/>

Date: Thu, 23 Aug 2001 14:35:13 +0200 (CEST)
From: Antoin Verschuren <[email-masked]>
To: [email-masked]
Cc: Patrick <[email-masked]>
Subject: Re: host transfers -- actually, out-of-zone-glue
Sender: [email-masked]

On Fri, 17 Aug 2001, Jordyn A. Buchanan wrote:

> At 4:52 PM +0200 8/17/01, Jaap Akkerhuis wrote:
> >     A.XXX has name servers NS1.B.YY and NS2.B.YY.
> >     B.YY has name servers NS1.A.XXX and NS2.A.XXX.
> >This is a basic problem. People should not do things like that.  I
> 
> This is a good point, and I wasn't intending to suggest that out of 
> zone glue was the solution.  The B.YY and A.XXX problem is probably 
> not solvable today, but the if both A and B are in .XXX, then the 
> extremely limited view of what sort of glue should exist that Klaus 
> has been advocating is probably too narrow.

This problem is solvable, if all registries treat host records and control
of the host records the same.
I would say that host records always should have a direct connection with
the domainname, meaning that the person responsible for the domainname is
always responsible for (all) the nameservers under that domain.
In the example above, A.XXX should always ask permission to B.YY to use
it's nameservers, and B.YY should register these hosts (NS1.B.YY and
NS2.B.YY) with registry YY and XXX. As maintainer of the domain B.YY I
would not want it to happen in any other way.

This brings me to the point that in this discussion a lot has been said in
favour of a registration system with the priority to domain registration
as a "common practice these days". Recent problems have given me another
thought about a "as liberal as possible" registration procedure.

We are the owner of the domainname vianetworks.nl. The Dutch
domainregistry holds the glue records for ns1.vianetworks.nl and
ns2.vianetworks.nl which is correct.
Now that we want to start using these nameservers for some 10.000
domainnames with Verisign, there is a problem of registrating these hosts.
As it seems, some other party has registered a domain with Gandi using
these nameservers, but without IP addresses. At Gandi, we don't have any
authority to make changes to this registration. As result of this, we
cannot make the appropriate changes to these hosts to make them usable for
our 10.000 domains. Our nameservers are simply hijacked by one person that
uses our nameserver without our permission.

The point that I'm trying to make is that the owner of the nameserver
should always be able to control his host records. If anyone can register
any nameserver, then the risk of non-delegation is higher. People just
simply fill in a nameserver because they have too, without making sure
that nameserver works. As maintainer of ns1.vianetworks.nl, I want to be
sure that all domains delegated to my nameserver work, and I don't want
domains flying around with my nameservers that I'm not aware about. If
anyone wants to use my nameserver, I want to know about that, so I can
make sure it works.
Many registries check delegation before accepting registrations. I'm in
favour of this. gTLD registries do not check delegations, so another
mechanism should be thougth of. This can only made possible if the actual
owner of the nameserver (and thus the domain where the nameserver resides)
can control his host record, and is authoritive for making queries with
each registrar for example.
I also wonder how registration of nameservers will take place in the
future with DNSsec. As far as I can tell, this will probably make it
nessecary that the maintainer of the host record is indeed the owner of
the actual nameserver, because he will have to be able to access the
nameserver and negociate the encryption keys. I'm not too deep in DNSsec,
so perhaps someone else can reflect on this. As far as I understand, the
encryption is between registry-nameserver and registrant-nameserver, and
thus the encryption appointment is made between the nameserver maintainer
and the registry, and not the registrar. So in that case the host
registration is a registry issue and not a registrar issue..
In that case only one host record for a given nameserver can excist, and
should be maintained at the registry. In that case I would certainly
choose for the domain owner to be in control of that record.

Met groet,
VIA NET.WORKS Nederland

 Antoin Verschuren  
 Provisioning Coordinator 
 tel. + 31 40 2 393 393
 fax  + 31 40 2 393 311
 e-mail : [email-masked]            

 http://www.vianetworks.nl/ 

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Message Pushing and TCP Transport 
Date: Thu, 23 Aug 2001 07:10:13 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Wednesday, August 22, 2001 10:39 PM
>To: Daniel Manley
>Cc: [email-masked]'; [email-masked]
>Subject: Re: Message Pushing and TCP Transport 
>
>
>If there is one thing we do know, it is that a registry may push state to
>a registrar, without queue overhead, or hold-down timer complications and
>secondary access and store overhead. We also know, as Scott pointed out in
>the sections I quoted, that deferred queue service causes registry resource
>consumption.

The "without queue overhead" statement is true only if the pusher has no
intention of retrying in case of failed delivery.  Push or poll, the sender
needs to do something in response to an unresponsive recipient.  In case of
failed delivery, the sender can either drop and discard the message
completely, or it can queue the message for a later delivery attempt.  I
suspect the "queue for later delivery" option will be more reasonable, and
thus push/poll end up having similar queue resource requirements.

If, on the other hand, folks are comfortable with the idea of trying to push
a message once and throwing it away if it isn't delivered, then there is
indeed no queue overhead to worry about.

<Scott/>

Date: Wed, 22 Aug 2001 22:27:52 -0700
To: Daniel Manley <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 05:23 PM 8/22/2001, Daniel Manley wrote:
>>The usual response is "polling" but that means constantly polling, and in 
>>this case constantly polling for something that is typically not 
>>present.  Hence, substantial overhead, for negative benefit.
>
>If you're using poll to ping a connection to keep it alive, then you're 
>already doing it anyhow.

And you are placing a load on the server that the registry operator should 
not appreciate very much.

>So I don't think there's a negative benefit. Pushing pushes the 
>substantial overhead *multiplied* by each registrar client to the server, 
>who's already overworked anyway.

Actually, no.  Pushing has no wasted effort, unlike polling.  Hence the 
overhead of push is only incurred when there is something to push.

So I have no idea how your are calculating a "multiplied" overhead.  Feel 
free to provide detail for your claim.

>>Do you like constantly checking for email, when there is none?  Would you 
>>not prefer that email "just arrive" when it is available?
>>
>>Imagine never getting telephone calls.  Instead you have to call a 
>>number, to see whether there is anyone waiting to talk with you.
>
>But I might want the message to go to voice mail if I'm too busy, and I'll 
>get it later when it's convenient for me.

The comparison was not about whether sometimes it is nice to use voicemail, 
but whether you would like having ONLY voicemail, with no phone calls 
*ever* coming in.  Without push, you get no phone calls.

>>THAT is why push is better than pull, for some scenarios.

Voicemail is pull.  You check to see whether there is a message.

d/

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

To: Daniel Manley <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Message Pushing and TCP Transport 
Date: Wed, 22 Aug 2001 22:38:33 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Dan,

> ... <someone> will be using a (hold-down timer) 5 day waiting period.
and
> ... <someone else> is considering (no hold-down timer) forgoing the
> transfer wait period with the reasoning that the auth info from the 
> registrant is enough to consider the transfer ligit.

Correct, so far as I keep track of the someone's and their business rules.

The protocol issue is are we doing the right thing by making a non-zero
hold-down timer manditory? I don't think so, it is overspecification.

I'll pass on the comparisons of US and Canadian Universities, you have
the better beer, not really a challenge that, and besides, I took my degree
in maths at Berkeley, so of necessity, the rest is left to the reader ...

> Having the registry purge old/expired notifications and bulk emailing 
> them to the registrar isn't such a bad idea.

Both here, and earlier where you mention guidelines, in effect you've put
a portion of the state machine outside of the available mechanisms we are
describing in a protocol. Old and expired are relative terms, and how do
we know these aren't (somewhere) equal to new and current? add/mod/del by
protocol, notify by postal worker... 

> >Broadly, we're looking at the scaling properties of the protcol
>
> I don't quite understand what you are saying here.  Polling isn't 
> scalable?  How? 

As you alluded to in your earlier message

> system that's already very busy trying to handle thousands of 
> domain:check commands and domain registrations, and DNS updates, and....  

poll is only one component of the message flow between a registry and its
registrars. As you also alluded, significant load, if only from checks, is
a given. Additionally, bursty, resource exhausting behavior is known to
exist in the NeuStar number portability data base and Verisign .com registry,
both having poll-only state management mechanisms.

If there is one thing we do know, it is that a registry may push state to
a registrar, without queue overhead, or hold-down timer complications and
secondary access and store overhead. We also know, as Scott pointed out in
the sections I quoted, that deferred queue service causes registry resource
consumption.

Queue service with arbitrary deferral by readers has different limiting
properties than queue service without deferral.

My note to Jordyn from April 9th from that other list is my best attempt
(YMMV) to state the issue:

> Date: Mon, 09 Apr 2001 20:09:16 -0400
> Reply-To: [email-masked]
> Subject: Re: [foobarbaz] Notifications - Pull / Push 
> 
> In our model we've a registry with some number of registrars concurrently
> managing state, and just to keep things on the back of a napkin, I'll use
> the numbers 1 and 67 for the respective cardinalities.
> 
> One choice, which looks a lot like a common real-time event model, is to
> poll the state manager for state transition data. Another choice, which
> looks a lot like a common time-sharing event model, is to interrupt the
> state transition clients.
> 
> We usually observe that when building network subsystems (my background)
> that livelock avoidance skews us towards the first design point, but the
> number of state transition participants is usually quite small, usually
> four or fewer.
> 
> What we should anticipate with an event-poll model is that the server will
> experience periodic synchronous load events that are event-poll artifacts
> having no corrolation with actual state transitions. What we should also
> anticipate with an event-interrupt (push) model is that the server will not
> experience such events, regardless of the number of state-transition clients.
> 
> The complication, as I've pointed out previously, is server-side connection
> initiation. However, it scales, like multicast.
> 
> The simplification of polling of course is two-fold, the first as has been
> observed, and the second is that it doesn't scale, so the asymptotic server
> behavior may keep the number of registrars a registry can economically feed
> down to something not much different from the present.
> 
> Does anybody care if server-side polling overhead limits the number of
> client-side pollers? Not having been an RRP registry operator, registrar,
> or reseller, we've an opinion, but it isn't an informed one.

Scott has made responsived comments to this.

... transfer, billing, outages, watch ... elided

> >How do you propose to solve these?
>
> Again, pardon the injection of "process" here,

Nope. Fish or cut bait. Either these are technically interesting questions
for which you've got answers, even if they are of the form "use some other
protocol", or you don't. If we were to put down our pencils at the first
point where money is made, rather than complete the protocol, we would do
so _before_ transfer, delete, or modify, and fob that off onto the other
protocol, whatever that is. Standards have costs that propritary solutions
don't have -- the cost of time and the benefit of scrutiny and correctness.

> which means the developement of heterogeneous 
> registry agents by registrars

Didn't you get to this conclusion simply by reading 2.9.2.3? Every operator
can set timers and pick OOB mechanism(s) and discard behavior(s).

> (what the defunct list, [1], was trying to 
> avoid all along).

Milage varies. I didn't think that was the purpose of that botch. It was
to demonstrate the possibility of technical cooperation. The form was not
material. The result was conclusive. EOL.

Eric

Date: Wed, 22 Aug 2001 20:23:47 -0400
From: Daniel Manley <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

> The usual response is "polling" but that means constantly polling, and 
> in this case constantly polling for something that is typically not 
> present.  Hence, substantial overhead, for negative benefit. 

If you're using poll to ping a connection to keep it alive, then you're 
already doing it anyhow.  So I don't think there's a negative benefit. 
 Pushing pushes the substantial overhead *multiplied* by each registrar 
client to the server, who's already overworked anyway.

> Do you like constantly checking for email, when there is none?  Would 
> you not prefer that email "just arrive" when it is available?
>
> Imagine never getting telephone calls.  Instead you have to call a 
> number, to see whether there is anyone waiting to talk with you. 

But I might want the message to go to voice mail if I'm too busy, and 
I'll get it later when it's convenient for me.

>
>
> THAT is why push is better than pull, for some scenarios.
>
>
> At 10:04 PM 8/20/2001, Peter Chow wrote:
>
>> I was at the Provreg meeting and there was at least one
>> implementor who was concerned with the extra complexity
>> introduced by the push mechanism.
>
>
> Added features ALWAYS means added complexity, so there is nothing 
> special about someone being concerned about complexity.
>
> The focus needs to be on the question of added benefit.  Is there 
> enough benefit?
>
> For simple, low-volume registration scenarios, no doubt a simplistic 
> protocol is preferred.
>
> If provreg is trying to produce a protocol that can support 
> high-volume transactions, it needs to use modern transaction 
> technology models.
>
> d/
>
>
> ----------
> Dave Crocker  <mailto:[email-masked]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464
>

Date: Wed, 22 Aug 2001 20:09:34 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

Eric Brunner-Williams in Portland Maine wrote:

>Dan, Peter, and Chris,
>
>If your issue is process, then please direct your remarks to the Chairs, and
>to the process issue. Your claim must of necessity be that at some point the
>chairs did find that "rough consensus" existed for poll-only state management.
>
No process issues here.

>
>I don't mind being on the "loosing end" of whatever happens, we just pick up
>our EPP extension drafts (in the I-D Administrator's queue this week) and put
>them back into XRP-is-a-compeating-protocol format, and take our chances with
>the process. May the better draft(s) win.
>
<snip> ... </snip>

>
>Fundamentally there are three parties, the winning and loosing registrars
>and the registry. The winning registrar initiates the transfer. The problem
>to be solved is how the change of state in the registry is communicated to
>the loosing registrar. Numerous mechanisms exist. Fundamentally all the "poll"
>mechanisms require some temporal guarantee that the transfer will not take
>place until a poll-timer has expired. This requirement is absent where state
>change notification may be initiated by the holder of the changed state. 
>
I agree.  Reasonably thinking here, many new registries will likely 
imitate the Verisign RRP registry for com/net/org domains (imitation is 
the sincerest form of flattery, right :).  Afilias' .info registry, I 
believe, will be using a 5 day waiting period.  They are also 
encouraging registrars to use the "poll" for the dual purpose of message 
retrieval and connection pinging, as the RRP 'describe' command is often 
used.  If a registrar isn't going to poll within a 5-day period, then 
it's likely that they won't poll at all and the registry will probably 
contact them to say that they are not following the guidelines set forth 
in the registrar certication test.

Now, I understand that the .biz registry is considering forgoing the 
transfer wait period with the reasoning that the auth info from the 
registrant is enough to consider the transfer ligit.  So a pushed 
notification would be simply be "hey, you just lost a domain" anyway -- 
no delivering timing issues there.

>
>
>One common implementation mechanism is a hold-down timer, the other is a
>listen process. Both are the subject of first-year programming curricula at
>technical colleges. Neither are particularly complicated.
>
Multi-threaded listening processes in first year???

Here's an implementation I've seen (post-university):

Open a TCP socket and share between two or more threads.  One thread is 
always listening and queuing received messages internally.  The other(s) 
send(s) requests to the server.  After a request is sent, the sender 
looks at the received messages queue checking for a response with a 
matching transaction id.  When it finally appears, take the response and 
react accordingly to it.  Also some other thread has to periodically 
wake up and take care of async notifications that might have arrived.

vs.

Open a single socket.  when there is something to pass along, sent it 
over the socket.  now wait for the first reponse.  When it comes, react 
to it.  If some time has past since the last time you did something, 
then go to the server to retrieve any notifications. (no shared 
resourses to worry about, no multi-threading required)

>
>
>When we look to "advantage" of one mechanism over the other, we need to look
>beyond the single-instance transaction. Scott clearly anticipated this in
>draft-ietf-provreg-epp-04.txt, 2.9.2.3 EPP <poll> Command.
>
>If we [servers] (para 2)
>	operators SHOULD consider time-sensitivity and resource management
>	factors when selecting a delivery method for service information
>	because some message types MAY be reasonably delivered using non-
>	protocol methods that require fewer server resources.
>
>and if we [servers] (para 3)
>
>	"MAY implement other mechanisms to dequeue and deliver messages
>	if queue maintenance needs exceed resource consumption limits.
>
>then push is at least as good a mechanism as going out-of-band, or dropping
>the transactions on the floor. Personally I consider either of the latter
>non-solutions, or errata to an incomplete protocol specification.
>
Having the registry purge old/expired notifications and bulk emailing 
them to the registrar isn't such a bad idea.  The registrar (a human in 
this case) would look at the first report of that kind and think, "Gosh, 
look at all the important messages we're missing, maybe we should poll 
like the EPP spec says we should."

>
>
>Design and implementation of a per-registry out-of-band notification handler,
>or a per-registry silently discarded transaction discovery rule, appear to be
>interesting technical challenges.
>
>Broadly, we're looking at the scaling properties of the protcol, as the
>volume of transaction increases, and as the volume of transaction participants
>increases, and not the single-transaction instance.
>
I don't quite understand what you are saying here.  Polling isn't 
scalable?  How?

>
>
>The planned (and unplanned) maintenance events don't have a state change
>initiator corresponding to a "winning registrar", and the "watch service"
>from our (specification) perspective is a random interrupt generator. Both
>affect one or more registrars per event.
>
>
>
>The billing events may be predictable from the concerned registrar, thus
>amenable to registrar-initiated discovery via poll, but there is no real
>guarantee that a registrar's finances are well-known, even to the registrar.
>Quite a few complicated business rules concerning reserves, margins, and time
>are known to exist
>
Wether these come through the registry via push or pull, we'll probably 
just end up emailing a system administrator and that person will have to 
be diligent enough to check their email (i.e. "poll" their account).

>
>
>How do you propose to solve these?
>
Again, pardon the injection of "process" here, but I think it comes down 
to the deciding people evaluating the two and picking one (of course, if 
I've got the process all wrong here then just ignore that sentence).  I 
don't think it would be good for the protocol to give registries and 
registrars the choice, because then some registries might not want to 
give the choice (because of the extra development work involved, or 
personal philosophies) which means the developement of heterogeneous 
registry agents by registrars (what the defunct list, [1], was trying to 
avoid all along).

I'm a geek.  I'll be the first to admit it.  Pushing is cool, but time 
is money.  Registries want to get their systems up and running and 
stable as soon possible so that registrars can get their system up and 
running as soon (and simply) as possible so they can start selling domains.

>
>
>If its technical, to me. If its process, to the chairs, and _not_ to me.
>
>Eric
>
>[1] defunct since 1 May.
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Message Pushing and TCP Transport 
Date: Wed, 22 Aug 2001 19:47:12 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 7:14 PM
> To: [email-masked]'
> Subject: RE: Message Pushing and TCP Transport 
> 
> 
> At 06:44 AM 8/17/2001, Bason, Chris wrote:
> >2) What is advantageous about using a push mechanism for transfer
> >notification in our current registry/registrar model over
> >using a pull mechanism?
> 
> How can you do a pull if you do not even know there is 
> anything to pull?
> 
> The usual response is "polling" but that means constantly 
> polling, and in 
> this case constantly polling for something that is typically not 
> present.  Hence, substantial overhead, for negative benefit.
> 
> Do you like constantly checking for email, when there is 
> none?  Would you 
> not prefer that email "just arrive" when it is available?
> 
> Imagine never getting telephone calls.  Instead you have to 
> call a number, 
> to see whether there is anyone waiting to talk with you.
> 
> THAT is why push is better than pull, for some scenarios.

There's no need to poll constantly to determine if messages are queued for
delivery because the protocol currently provides a notification mechanism
that is carried on other common responses to let the client know that queued
messages are available.  It's true that a client that does absolutely
nothing else will need to execute a potentially empty poll, but in the far
more typical scenario clients _will_ know when messages are available
without having to poll fruitlessly.

<Scott/>

Date: Wed, 22 Aug 2001 16:14:21 -0700
To: "[email-masked]'" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: Message Pushing and TCP Transport 
Sender: [email-masked]

At 06:44 AM 8/17/2001, Bason, Chris wrote:
>2) What is advantageous about using a push mechanism for transfer
>notification in our current registry/registrar model over
>using a pull mechanism?

How can you do a pull if you do not even know there is anything to pull?

The usual response is "polling" but that means constantly polling, and in 
this case constantly polling for something that is typically not 
present.  Hence, substantial overhead, for negative benefit.

Do you like constantly checking for email, when there is none?  Would you 
not prefer that email "just arrive" when it is available?

Imagine never getting telephone calls.  Instead you have to call a number, 
to see whether there is anyone waiting to talk with you.

THAT is why push is better than pull, for some scenarios.

At 10:04 PM 8/20/2001, Peter Chow wrote:
>I was at the Provreg meeting and there was at least one
>implementor who was concerned with the extra complexity
>introduced by the push mechanism.

Added features ALWAYS means added complexity, so there is nothing special 
about someone being concerned about complexity.

The focus needs to be on the question of added benefit.  Is there enough 
benefit?

For simple, low-volume registration scenarios, no doubt a simplistic 
protocol is preferred.

If provreg is trying to produce a protocol that can support high-volume 
transactions, it needs to use modern transaction technology models.

d/

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

To: Daniel Manley <[email-masked]>
cc: Peter Chow <[email-masked]>, "Bason, Chris" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Message Pushing and TCP Transport 
Date: Wed, 22 Aug 2001 17:14:16 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Dan, Peter, and Chris,

If your issue is process, then please direct your remarks to the Chairs, and
to the process issue. Your claim must of necessity be that at some point the
chairs did find that "rough consensus" existed for poll-only state management.

This is distinct from finding that consensus existed to adopt a particular
document or set of documents, and to exercise change management over them,
unless you also claim that the documents were in final form last week.

Personally I concurred in adopting Scott's initial draft, I just don't think
they are in final form, yet.

Please let me know when and how that is reflected in the record of the WG, as
I've advocated against over-specification since the kick-off in San Diego, and
what you propose is unnecessary overspecification of the event model.

I don't mind being on the "loosing end" of whatever happens, we just pick up
our EPP extension drafts (in the I-D Administrator's queue this week) and put
them back into XRP-is-a-compeating-protocol format, and take our chances with
the process. May the better draft(s) win.

If your issue is something other than process, then I'm happy to respond to
any and all technical issues.

I do share your "show me" skepticism about feature-creep, and those who are
currently RRP celebrants would reasonably view any deviation from the core of
that protocol as "feature creep". But lets work through the details before
reaching conclusions.

The following four use cases involve a change of state at the registry:

	o object transfer
	o planned (and unplanned) maintenance
	o billing events
	o watch services (whatever thay may be, some random event model)

We have discussed transfer, in all four of our face-to-face meetings (-51,
-50, the pre-50 interim, and the -49 BoF), and on this list, and a list [1]
each of you (Dan, Peter and Chris) are aware of.

Fundamentally there are three parties, the winning and loosing registrars
and the registry. The winning registrar initiates the transfer. The problem
to be solved is how the change of state in the registry is communicated to
the loosing registrar. Numerous mechanisms exist. Fundamentally all the "poll"
mechanisms require some temporal guarantee that the transfer will not take
place until a poll-timer has expired. This requirement is absent where state
change notification may be initiated by the holder of the changed state. 

One common implementation mechanism is a hold-down timer, the other is a
listen process. Both are the subject of first-year programming curricula at
technical colleges. Neither are particularly complicated.

When we look to "advantage" of one mechanism over the other, we need to look
beyond the single-instance transaction. Scott clearly anticipated this in
draft-ietf-provreg-epp-04.txt, 2.9.2.3 EPP <poll> Command.

If we [servers] (para 2)
	operators SHOULD consider time-sensitivity and resource management
	factors when selecting a delivery method for service information
	because some message types MAY be reasonably delivered using non-
	protocol methods that require fewer server resources.

and if we [servers] (para 3)

	"MAY implement other mechanisms to dequeue and deliver messages
	if queue maintenance needs exceed resource consumption limits.

then push is at least as good a mechanism as going out-of-band, or dropping
the transactions on the floor. Personally I consider either of the latter
non-solutions, or errata to an incomplete protocol specification.

Design and implementation of a per-registry out-of-band notification handler,
or a per-registry silently discarded transaction discovery rule, appear to be
interesting technical challenges.

Broadly, we're looking at the scaling properties of the protcol, as the
volume of transaction increases, and as the volume of transaction participants
increases, and not the single-transaction instance.

The planned (and unplanned) maintenance events don't have a state change
initiator corresponding to a "winning registrar", and the "watch service"
from our (specification) perspective is a random interrupt generator. Both
affect one or more registrars per event.

The billing events may be predictable from the concerned registrar, thus
amenable to registrar-initiated discovery via poll, but there is no real
guarantee that a registrar's finances are well-known, even to the registrar.
Quite a few complicated business rules concerning reserves, margins, and time
are known to exist.

How do you propose to solve these?

If its technical, to me. If its process, to the chairs, and _not_ to me.

Eric

[1] defunct since 1 May.

Date: Wed, 22 Aug 2001 15:45:45 -0400
From: Daniel Manley <[email-masked]>
To: Peter Chow <[email-masked]>
CC: "Bason, Chris" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Sender: [email-masked]

I would tend to agree with Peter's comments.  I haven't heard anything 
concrete that says that pushing is superior to pulling.  I prefer 
p[ou]lling because it allows the registrar to retrieve messages when 
it's good and ready.  This is also simpler for the registry.  With 
pushing, the registry system must be aware of when a registrar is logged 
in so that it can push the messages out.  That means extra work for a 
system that's already very busy trying to handle thousands of 
domain:check commands and domain registrations, and DNS updates, and....  

And for registrars that connect with many connections, the registry has 
to manage multiple connections trying to push message from the same queue.

Registries (and their developers) have enough to worry about without 
getting to asynchronous communications to the registrars.

Dan

Peter Chow wrote:

>Chris,
>
>I was at the Provreg meeting and there was at least one
>implementor who was concerned with the extra complexity
>introduced by the push mechanism.
>
>As a registrar, we would only want the push mechanism to
>be added to the protocol only if there is a clear advantage of
>it over polling.
>
>On Fri, 17 Aug 2001, Bason, Chris wrote:
>
>>Eric, per your suggestion I revisited the message thread you referred
>>to. As far as I can tell there are no comments in that particular
>>thread about polling vs. pushing transfer notifications. There certainly
>>is no consensus on this topic in the thread. Furthermore, based on the
>>WG mailing list to date, I have not seen a majority consensus in any
>>message thread that identifies pushing notifications as an acceptable
>>addition to the protocol.
>>
>>Let me just restate then what I am looking for and why. I saw Scott
>>Hollenbeck's message on the list, "WG Discussion Summary with Draft
>>Document Impact" stating the following:
>>
>>...
>>Eric's XRP presentation and subsequent discussion led to a reopening of the
>>message polling vs. message pushing discussion.  Folks in the room seemed to
>>support the idea of having both mechanisms in the base protocol, with the
>>client having the ability to select a delivery mechanism from among those
>>offered by the server.  Eric will offer up suggested text to be added to the
>>EPP draft(s).
>>...
>>
>>This statement concerns me. Let me then rephrase the question:
>>1) What justification was given that received so much support for pushing
>>transfer notifications where there was little support before?
>>2) What is advantageous about using a push mechanism for transfer
>>notification in our current registry/registrar model over
>>using a pull mechanism?
>>
>>I personally see no advantage. Although, I do see several disadvantages,
>>one of which is the unnecessary complexity that will be added to the
>>protocol. If there are no clear advantages for using a push method then
>>it should not be added to the protocol.
>>
>>Chris Bason
>>
>>
>>-----Original Message-----
>>From: Eric Brunner-Williams in Portland Maine
>>[mailto:[email-masked]]
>>Sent: Wednesday, August 15, 2001 11:51 PM
>>To: Bason, Chris
>>Cc: [email-masked]'; [email-masked]
>>Subject: Re: Message Pushing and TCP Transport
>>
>>
>>>Would someone please elaborate on why this push concept
>>>is advantageous to EPP (preferably a PUSH proponent)?
>>>
>>The issue has been discussed quite a few times on the list, not just at -50
>>and -51. See the general discussion of transfer notification.
>>
>>Eric
>>
>
>--------------------------------------------------------------------
>_/_/_/ Peter Chow		Chief Technical Advisor
>_/_/_/ [email-masked]		Global Media Online Inc.
>_/_/_/				System Division
>_/_/_/ ICQ: 41931890		Shibuya Cerulean Tower 11F
>_/_/_/ (tel)+81-3-5456-2687	26-1 Sakuragaoka-cho, Shibuya-ku
>_/_/_/ (fax)+81-3-5456-2740	Tokyo, Japan
>_/_/_/ http://www.gmo.jp/	150-8512
>--------------------------------------------------------------------
>
>

To: Rick H Wesson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: PROVREG and XML Protocol
From: [email-masked]
Date: Wed, 22 Aug 2001 11:33:07 -0400
Sender: [email-masked]

Rick H Wesson writes:

>> I'd love to buse BXXP and 
>> I just can't find any
>> way to justify using SOAP.

Though I don't claim to be expert on BEEP, I have heard Marshall Rose give 
an intro or two.  I would suggest that the strength of protocols like BXXP 
is in the ability to manage things like multiplexing, conversations, etc. 
Like SOAP, it uses XML where applicable as a structuring mechanism, but 
mainly for its own purposes.

My impression is that  SOAP really picks up about where BEEP leaves off, 
to solve a different and higher level set of issues.  SOAP puts a lot of 
emphasis into managing the structure of an envelope, particularly so that 
extensions can be managed and processed appropriately over time. 
Furthermore, SOAP has as an explicit goal the ability to integrate with 
and leverage a broad range of XML-based middleware being developed in a 
variety of commercial and other settings.  My impression is that XML is 
more a tool for BEEP, than an explicit goal.

So, I think the reason to use SOAP is [a] if its ability to manage things 
like envelope structure and versioning (e.g. mustUnderstand) is useful, 
[b] if you value the ability to leverage what is expected to be quite 
ubiquitous tooling for SOAP, probably WSDL, and related offerings and/or 
[c] if you need to tell a story about how a single application level 
message (e.g. purchase order) will flow through BEEP, for example, into 
your organization, from there through MQSeries to your application, etc. 
SOAP attempts to model such integration.  Of course, if you want to model 
things as a simple form of RPC, for easier access from scripting languages 
etc., SOAP provides support for that, but does not require its use.

SOAP isn't the answer to all problems, but those are the reaons I would 
consider.  Many of us hope that there will emerge a truly first class 
binding for SOAP to run on top of BEEP.  I do think there is likely 
overlap between BEEP and SOAP in areas such as security, and it would be 
really good if the two approaches turned out to be compatible.  For 
example, it would be really nice if, when SOAP is mapped onto BEEP, the 
resulting security story looked sensible, rather than patchwork.  As you 
can see from other emails on dist-app, the protocols WG is trying hard to 
ensure that such mappings from SOAP are generally possible.  Of course, 
there is a lot of detail to be considered to make sure one has a really 
good solution, and not just a patchwork integration.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

To: Rick H Wesson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: PROVREG and XML Protocol
From: [email-masked]
Date: Wed, 22 Aug 2001 11:33:07 -0400
Sender: [email-masked]

Rick H Wesson writes:

>> I'd love to buse BXXP and 
>> I just can't find any
>> way to justify using SOAP.

Though I don't claim to be expert on BEEP, I have heard Marshall Rose give 
an intro or two.  I would suggest that the strength of protocols like BXXP 
is in the ability to manage things like multiplexing, conversations, etc. 
Like SOAP, it uses XML where applicable as a structuring mechanism, but 
mainly for its own purposes.

My impression is that  SOAP really picks up about where BEEP leaves off, 
to solve a different and higher level set of issues.  SOAP puts a lot of 
emphasis into managing the structure of an envelope, particularly so that 
extensions can be managed and processed appropriately over time. 
Furthermore, SOAP has as an explicit goal the ability to integrate with 
and leverage a broad range of XML-based middleware being developed in a 
variety of commercial and other settings.  My impression is that XML is 
more a tool for BEEP, than an explicit goal.

So, I think the reason to use SOAP is [a] if its ability to manage things 
like envelope structure and versioning (e.g. mustUnderstand) is useful, 
[b] if you value the ability to leverage what is expected to be quite 
ubiquitous tooling for SOAP, probably WSDL, and related offerings and/or 
[c] if you need to tell a story about how a single application level 
message (e.g. purchase order) will flow through BEEP, for example, into 
your organization, from there through MQSeries to your application, etc. 
SOAP attempts to model such integration.  Of course, if you want to model 
things as a simple form of RPC, for easier access from scripting languages 
etc., SOAP provides support for that, but does not require its use.

SOAP isn't the answer to all problems, but those are the reaons I would 
consider.  Many of us hope that there will emerge a truly first class 
binding for SOAP to run on top of BEEP.  I do think there is likely 
overlap between BEEP and SOAP in areas such as security, and it would be 
really good if the two approaches turned out to be compatible.  For 
example, it would be really nice if, when SOAP is mapped onto BEEP, the 
resulting security story looked sensible, rather than patchwork.  As you 
can see from other emails on dist-app, the protocols WG is trying hard to 
ensure that such mappings from SOAP are generally possible.  Of course, 
there is a lot of detail to be considered to make sure one has a really 
good solution, and not just a patchwork integration.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Date: Tue, 21 Aug 2001 09:47:20 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: EPP reliance on registrar sponsorship model
Sender: [email-masked]

Again, this is probably too specific to the TLD registries and 
registrars, but allowing any registrar to update registry objects as 
long as the "auth info" is known would be a headache.  Would renewals be 
allowed?  And we'd have to go on word of honour that the non-sponsoring 
registrars don't keep a copy of the auth info for objects they don't own?

Registrars would almost have to build two systems:  one for their loyal 
customers and another to deal with the cusomters of other fly-by-night 
registrars that collect registrations dirt cheap but don't provide 
adequate maintainance functionality.  This would be a big burden on 
registrars and could be confusing to registrants.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Jarle Greipsland [mailto:[email-masked]]
>>Sent: Wednesday, August 08, 2001 7:16 AM
>>To: [email-masked]
>>Subject: EPP reliance on registrar sponsorship model
>>
>>
>>I think we would be better served by having the registrar sponsorship
>>concept replaced by a more general authorization mechanism.
>>Registries that wish to work within the registrar sponsorship model
>>can then do so by (explicitly or implicitly) authorizing the "current
>>registrar" to make any changes to a given object, including the right
>>to reject or accept a transfer.  Registries that wish to operate
>>within another model, e.g. the registry will register digital
>>certificates for individuals or organizations, and attach attributes
>>to objects authorizing certificate holders to perform a given set of
>>operations on the object (provided the request is properly signed by
>>the holder) no matter what registrar forwards the request to the
>>registry, can then do so.
>>
>
>The EPP drafts were first written without object-specific authorization
>information.  It was added in an attempt to address one person's comments.
>It was subsequently removed as a result of larger WG discussion to simplify
>operations.
>
>I think there is a larger data consistency issue that is introduced if the
>client sponsorship model is abandoned.  As changes are made across clients,
>all of the previously involved clients will probably like to know about
>changes made through other clients so that whatever locally-copied data they
>maintain remains consistent with that of the server.  It's a many-to-one
>relationship.  With the client sponsorship model, there's a one-to-one
>relationship that is _far_ easier to manage.
>
><Scott/>
>

Date: Mon, 20 Aug 2001 06:25:03 -0700 (PDT)
From: [email-masked]
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Hi All,

I think Chris asked very good question. I really like to know the answer too
!

Thanks, 

_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/

Date: Tue, 21 Aug 2001 14:04:13 +0900 (JST)
From: Peter Chow <[email-masked]>
To: "Bason, Chris" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: Message Pushing and TCP Transport 
Sender: [email-masked]

Chris,

I was at the Provreg meeting and there was at least one
implementor who was concerned with the extra complexity
introduced by the push mechanism.

As a registrar, we would only want the push mechanism to
be added to the protocol only if there is a clear advantage of
it over polling.

On Fri, 17 Aug 2001, Bason, Chris wrote:

> Eric, per your suggestion I revisited the message thread you referred
> to. As far as I can tell there are no comments in that particular
> thread about polling vs. pushing transfer notifications. There certainly
> is no consensus on this topic in the thread. Furthermore, based on the
> WG mailing list to date, I have not seen a majority consensus in any
> message thread that identifies pushing notifications as an acceptable
> addition to the protocol.
>
> Let me just restate then what I am looking for and why. I saw Scott
> Hollenbeck's message on the list, "WG Discussion Summary with Draft
> Document Impact" stating the following:
>
> ...
> Eric's XRP presentation and subsequent discussion led to a reopening of the
> message polling vs. message pushing discussion.  Folks in the room seemed to
> support the idea of having both mechanisms in the base protocol, with the
> client having the ability to select a delivery mechanism from among those
> offered by the server.  Eric will offer up suggested text to be added to the
> EPP draft(s).
> ...
>
> This statement concerns me. Let me then rephrase the question:
> 1) What justification was given that received so much support for pushing
> transfer notifications where there was little support before?
> 2) What is advantageous about using a push mechanism for transfer
> notification in our current registry/registrar model over
> using a pull mechanism?
>
> I personally see no advantage. Although, I do see several disadvantages,
> one of which is the unnecessary complexity that will be added to the
> protocol. If there are no clear advantages for using a push method then
> it should not be added to the protocol.
>
> Chris Bason
>
>
> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 11:51 PM
> To: Bason, Chris
> Cc: [email-masked]'; [email-masked]
> Subject: Re: Message Pushing and TCP Transport
>
>
> > Would someone please elaborate on why this push concept
> > is advantageous to EPP (preferably a PUSH proponent)?
>
> The issue has been discussed quite a few times on the list, not just at -50
> and -51. See the general discussion of transfer notification.
>
> Eric
>

--------------------------------------------------------------------
_/_/_/ Peter Chow		Chief Technical Advisor
_/_/_/ [email-masked]		Global Media Online Inc.
_/_/_/				System Division
_/_/_/ ICQ: 41931890		Shibuya Cerulean Tower 11F
_/_/_/ (tel)+81-3-5456-2687	26-1 Sakuragaoka-cho, Shibuya-ku
_/_/_/ (fax)+81-3-5456-2740	Tokyo, Japan
_/_/_/ http://www.gmo.jp/	150-8512
--------------------------------------------------------------------

To: "Bason, Chris" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Message Pushing and TCP Transport 
Date: Fri, 17 Aug 2001 16:19:54 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Chris,

I'm a contributor, not a chair, I don't make consensus calls.

I didn't take minutes either, especially while presenting on
extending EPP. That reminds me however, I've got to make sure
my slides are available to the co-chairs.

Thanks,
Eric

Date: Fri, 17 Aug 2001 10:57:20 -0400
To: Jaap Akkerhuis <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: host transfers -- actually, out-of-zone-glue
Cc: Klaus Malorny <[email-masked]>, Patrick <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 4:52 PM +0200 8/17/01, Jaap Akkerhuis wrote:
>     A.XXX has name servers NS1.B.YY and NS2.B.YY.
>     B.YY has name servers NS1.A.XXX and NS2.A.XXX.
>This is a basic problem. People should not do things like that.  I
>have been told that modern versions of nameserver lately don't
>accept out of zone glue to prvent cache poisoning. So even if you
>put it in your zone file, things stll might not work with such a
>configuration.
>
>In the .nl registry for years we never allowed out of zone glue in
>the zonefile. We have only once seen that somebody shot his/her
>foot with a configuration like this.

This is a good point, and I wasn't intending to suggest that out of 
zone glue was the solution.  The B.YY and A.XXX problem is probably 
not solvable today, but the if both A and B are in .XXX, then the 
extremely limited view of what sort of glue should exist that Klaus 
has been advocating is probably too narrow.

Jordyn

To: "Jordyn A. Buchanan" <[email-masked]>
cc: Klaus Malorny <[email-masked]>, Patrick <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: host transfers -- actually, out-of-zone-glue
Date: Fri, 17 Aug 2001 16:52:44 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    Most of the message in which you wrote this explains why glue records 
    are only needed for name servers that are authoritative for their own 
    domains, an argument that I'll admit I'm coming around to.  However, 
    an argument against this approach that has been raised in the past is 
    that it is possible to create a situation in which two (or more 
    domains) use name servers in the other domain(s), so that none of 
    them end up having glue or being useful.  For example:
    
    A.XXX has name servers NS1.B.YY and NS2.B.YY.
    B.YY has name servers NS1.A.XXX and NS2.A.XXX.
    
    Under your scheme, neither of these domains will work.  For that 
    matter, under your scheme, even if A and B were both in domain XXX, 
    they would not work.  A modified version of your scheme could fix the 
    problem by checking for such situations within a single registry, but 
    is utterly unresolvable if the domains are in different registries.

This is a basic problem. People should not do things like that.  I
have been told that modern versions of nameserver lately don't
accept out of zone glue to prvent cache poisoning. So even if you
put it in your zone file, things stll might not work with such a
configuration.

In the .nl registry for years we never allowed out of zone glue in
the zonefile. We have only once seen that somebody shot his/her
foot with a configuration like this.

	jaap

From: "Bason, Chris" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Message Pushing and TCP Transport 
Date: Fri, 17 Aug 2001 09:44:10 -0400
Sender: [email-masked]

Eric, per your suggestion I revisited the message thread you referred 
to. As far as I can tell there are no comments in that particular 
thread about polling vs. pushing transfer notifications. There certainly 
is no consensus on this topic in the thread. Furthermore, based on the 
WG mailing list to date, I have not seen a majority consensus in any 
message thread that identifies pushing notifications as an acceptable 
addition to the protocol.

Let me just restate then what I am looking for and why. I saw Scott 
Hollenbeck's message on the list, "WG Discussion Summary with Draft 
Document Impact" stating the following:

...
Eric's XRP presentation and subsequent discussion led to a reopening of the
message polling vs. message pushing discussion.  Folks in the room seemed to
support the idea of having both mechanisms in the base protocol, with the
client having the ability to select a delivery mechanism from among those
offered by the server.  Eric will offer up suggested text to be added to the
EPP draft(s).
...

This statement concerns me. Let me then rephrase the question: 
1) What justification was given that received so much support for pushing 
transfer notifications where there was little support before? 
2) What is advantageous about using a push mechanism for transfer
notification in our current registry/registrar model over 
using a pull mechanism?

I personally see no advantage. Although, I do see several disadvantages, 
one of which is the unnecessary complexity that will be added to the 
protocol. If there are no clear advantages for using a push method then 
it should not be added to the protocol.

Chris Bason

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 11:51 PM
To: Bason, Chris
Cc: [email-masked]'; [email-masked]
Subject: Re: Message Pushing and TCP Transport 

> Would someone please elaborate on why this push concept 
> is advantageous to EPP (preferably a PUSH proponent)? 

The issue has been discussed quite a few times on the list, not just at -50
and -51. See the general discussion of transfer notification.

Eric

To: Richard Shockey <[email-masked]>
cc: Rick H Wesson <[email-masked]>, Mark Nottingham <[email-masked]>, [email-masked], XML Distributed Applications List <[email-masked]>, [email-masked]
Subject: Re: PROVREG and XML Protocol 
Date: Thu, 16 Aug 2001 12:57:04 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

I agree with the general observation:

> This admonition not to use HTTP has been made quite clear in several ID's 
> that are making their way to RFC's.  See:
> 
> draft-moore-using-http-01.txt
> 
> Several work groups went down the path of using HTTP as a transport, the 
> Internet Print Protocol for instance, and that decision has caused them a 
> boatload of grief.

However. draft-moore-using-<whatever> is another matter.

Having had the pleasure (none) of attempting to get technical content into
draft-iesg-http-cookies-03.txt before it was RFC'd as a BCP, (another Moore
draft, co-authored by Ned Freed), the unqualified citation of a cautionary
you'll-set-your-hair-on-fire polemic is low on my list of authoritative
references.

Let's please leave the flamage of port:80 (mis)use to [email-masked],
and stick to core epp objects, operations, transport, extensions, and the
operational problems we can solve. draft-foo-epp-http, draft-bar-epp-smtp,
draft-baz-epp-avian-carrier, ... these are all reasonable things to attempt.

Eric

Date: Thu, 16 Aug 2001 09:34:32 -0700
From: Mark Nottingham <[email-masked]>
To: Richard Shockey <[email-masked]>
Cc: Rick H Wesson <[email-masked]>, [email-masked], XML Distributed Applications List <[email-masked]>
Subject: Re: PROVREG and XML Protocol
Sender: [email-masked]

On Thu, Aug 16, 2001 at 12:20:38PM -0400, Richard Shockey wrote:
> 
> There is another serious reason NOT to consider SOAP. The IETF and
> the IESG are rather adamant that HTTP not be used as an transport
> by future application protocols.

Of course. However, SOAP is not constrained to HTTP. 

Think of it as an XML messaging framework, NOT
rpc-using-xml-over-http. The BEEP binding of SOAP is just as valid as
the HTTP one.

Just to reiterate, I'm less concerned with getting PROVREG to
consider SOAP as a solution, and more interested in getting a bit of
cross-fertilisation, as both groups are tackling the same problems in
many areas.

Cheers,

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Date: Thu, 16 Aug 2001 12:20:38 -0400
To: Rick H Wesson <[email-masked]>, Mark Nottingham <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: PROVREG and XML Protocol
Cc: <[email-masked]>, XML Distributed Applications List <[email-masked]>
Sender: [email-masked]

At 09:59 PM 8/15/2001 -0700, Rick H Wesson wrote:

>Mark,

See note below...

>frankly when EPP started SOAP was just an idea with HTTP as atransport and
>a Apache module. The Registries need a highly robust transport with as
>little cruft ( Apache would be ALOT of cruft ) as possable.
>
>There was also the fact that no transport for SOAP existed at the time
>so it was easy to see that SOAP was not an option.
>
>you can still write up the docs for the transport, but you would have to
>convince a registry to use if.
>
>IMHO, SOAP isns't anything you would use where speed and security are
>required. When it comes down to brass tacks, if we picked SOAP when we
>started we wouldn't have any registries going live any time soon, and we
>have one up and two more out the door in a couple of months.
>
>Companies cant wait for standards w/o transports.The last time I checked,
>I think  thats what we do here, write the standards for whats one the
>wire.
>
>Why doesn't the W3C just standardise on BXXP? Or, should I just not ask
>that question and leave all the layer 10 questions out of it?

There is another serious reason NOT to consider SOAP. The IETF and the IESG 
are rather adamant that HTTP not be used as an transport by future 
application protocols.

One of the major justifications for the creation of BXXP in the first place 
was to create a generalized application transport framework for future IETF 
protocols and attempt to end the abuse of HTTP and Port 80 by protocol 
designers.  This has been a goal of the applications area directors for 
many many years.

There are drafts on binding BXXP to SOAP that I would recommend looking at:

http://www.ietf.org/internet-drafts/draft-etal-beep-soap-01.txt

This admonition not to use HTTP has been made quite clear in several ID's 
that are making their way to RFC's.  See:

draft-moore-using-http-01.txt

Several work groups went down the path of using HTTP as a transport, the 
Internet Print Protocol for instance, and that decision has caused them a 
boatload of grief.

Though I do understand the reluctance of some in the provreg community to 
using  BXXP considering its recent creation, I still believe it is 
technically the "right thing to do".

>-rick
> > --
> > Mark Nottingham, Research Scientist
> > Akamai Technologies (San Mateo, CA USA)
> >

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice 571.434.5651 Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

To: Mark Nottingham <[email-masked]>
cc: [email-masked], XML Distributed Applications List <[email-masked]>, [email-masked]
Subject: Re: PROVREG and XML Protocol 
Date: Thu, 16 Aug 2001 10:45:30 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Mark,

By way of background, while at Engage and participating in the CPExchange
privacy working group, the anticeedent(s) to the current W3C XML Protocol
(rpc-like thingee) was the subject of some discussion in the CPExchange
list, and more so in the ebXML lists.

The core of the provisioning model is some objects, some operations on them,
and some possibly distinct entities with mediated or shared access to these
operations on theses objects. Transport is necessary, if the entities are in
fact distinct. HTTP is one of several possible transports. XML is nice, but
not necessary. 

I know some people consider the application (of epp) is the registration of
domain names, I used to be one, but there are two data types (names, addrs)
and two name spaces (gTLD, ccTLD), and two name types (TLD, xLD), two registry
types (monolithic, disjoint registrar), and two registry models (thick, thin),
and possibly two turtle doves as well.

I will read the  SOAP 1.2 working draft [12], and generate feedback to the
[email-masked] list, in my copious fee time.

I'm glad you came to provreg.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Mark Nottingham'" <[email-masked]>, Rick H Wesson <[email-masked]>
Cc: [email-masked], XML Distributed Applications List <[email-masked]>
Date: Thu, 16 Aug 2001 06:59:03 -0400
Subject: RE: PROVREG and XML Protocol
Sender: [email-masked]

>-----Original Message-----
>From: Mark Nottingham [mailto:[email-masked]]
>Sent: Thursday, August 16, 2001 12:46 AM
>To: Rick H Wesson
>Cc: [email-masked]; XML Distributed Applications List
>Subject: Re: PROVREG and XML Protocol
>
>
>
>Rick,
>
>So, if the work in PROVREG was done with an awareness of SOAP, the
>question that I find interesting is:
>
>Why does EPP use XML for messaging, yet not use what will be XML's
>messaging framework? Is it simply a matter of timing (SOAP is new,
>and there is no TCP binding defined), or is there some other, more
>functional reason?
>
>Anyone else from PROVREG care to comment?

With the provreg work being done in the IETF, there is a very strong desire,
perhaps even a mandate, to define transport mechanisms based on other IETF
standard protocols.  As Rick noted, when I first started working on EPP SOAP
wasn't really mature enough (see your "what will be" comment above) to be
considered a viable transport candidate, plus there was/is no IETF work
happening to make it a standards track protocol.  That doesn't mean it won't
ever happen, but I do believe it's something that would need to happen
(perhaps as a joint IETF/W3C effort) before XML protocols being developed in
the IETF could consider SOAP transport.

<Scott/>

Date: Wed, 15 Aug 2001 15:29:08 -0700
From: Mark Nottingham <[email-masked]>
To: [email-masked]
Cc: XML Distributed Applications List <[email-masked]>
Subject: PROVREG and XML Protocol
Sender: [email-masked]

[ I'm posting this message to both the PROVREG
  <[email-masked]> and XMLP <[email-masked]> lists, to
  promote discussion.  AFAIK both lists accept posts from
  non-subscribed addresses; please trim the distribution if your
  message would only be interesting to one, or if the discussion
  starts to take up too much bandwidth. Thanks. ]

I got up at the PROVREG meeting in London to point out some
similarities in that group's work and the XMLP WG in the W3C.

This note is intended to generate discussion of SOAP as a potential
framework for use by PROVREG, as well as to stimulate feedback to the
XML Protocol WG regarding SOAP's suitability for such uses.

* Introduction

The IETF Provisioning Registry (PROVREG) Working Group has been
chartered [1] to provide a "protocol that enables a registrar to
access multiple registries." Furthermore, the group "... will
consider support for multiple operational choices, such as for
transport and security; it will create no new transport or security
protocols."

The W3C XML Protocol Working Group has been chartered [2] to provide
a framework for XML messaging, using SOAP [3] as a starting point.
Although SOAP is commonly believed to be only
'RPC-using-XML-over-HTTP', the group is bound to deliver
transport-agnostic services which enable a wide variety of
applications beyond RPC.

Superficially, it appears that XMLP may provide a framework with
which to implement a PROVREG protocol, with a number of advantages
and efficiencies, as such uses are within the scope of its charter.

This note seeks to examine the requirements of PROVREG from the
perspective of SOAP, both to bring XMLP's work to the attention of
PROVREG, and to generate feedback to XMLP about the suitability of
SOAP for uses such as PROVREG's. Additionally, it attempts to point
out the requirements and context of PROVREG to XMLP, in the hope that
it will serve as a use case for XMLP.

This note does not propose a SOAP-based registry protocol, and only
represents the thoughts of the author. Discussion should be directed
to the provreg mailing list [4] and the xml-dist-app [5] mailing list
as appropriate.

* XMLP Context and Deliverables

The XML Protocol Working group is charged with delivering a framework
for XML messaging, based on the SOAP submission. There are four
defined deliverables;

 1. A Message Envelope, which contains the XML message
 2. A Serialization Mechanism, to represent data structures as XML
 3. A Transport Binding, to move messages around; initially, HTTP
 4. An RPC Convention, to enable applications which require this common
    funtionality

However, the charter implies a more abstract architecture which, in
combination with these basic deliverables, has the following
attributes;

- A message processing model, which allows common functionality to be
  modularised.

  SOAP's processing model enables common functions like encryption,
  application of policy, caching, message routing, etc. to be
  standardized as Modules. This promotes interoperability and reduces
  the amount of replicated code - and specification - necessary to
  enable a service.

  Currently, a few modules have been defined, including one for XML
  Digital Signatures [6], which also encompasses encryption, and
  SOAP-RP [7], which enables multi-hop routing in SOAP.

- Intermediary targetting, to allow message processing to be
  distributed across nodes.

  SOAP is unique, in that it allows message functionality to be
  targetted at particular intermediary nodes. This allows, for
  example, a caching Module to be applied at a particular place in
  the network, or likewise a non-repudiation Module to be invoked
  between two unknown parties. SOAP's intermediary targetting
  operates as a modification of the message processing model (the
  'actor' attribute).

- Transport abstraction, allowing XML messages to be bound to and
  moved around by a variety of protocols.

  One of the core requirements for XML Protocol is to be able to bind
  messages to an arbitrary "underlying protocol", whether it be HTTP,
  BEEP, TCP or UDP.  This, more than anything, frames XMLP (and
  therefore SOAP) as an XML messaging framework, rather than a
  purpose-specific protocol. SOAP originally defined a HTTP binding;
  more recently, a BEEP binding [8] has been drafted, with discussion
  of bindings to TCP and SMTP in the near future.

- A framework for message exchange patterns, to allow business
  protocols to be defined.

  One of the consequences of transport abstraction is the ability to
  build application message exchange patterns that are separate from
  the underlying protocols' messaging patterns. For example, while
  HTTP has a request-response pattern, SOAP applications may use it
  as part of a larger, orchestrated service that spans multiple HTTP
  connections or even multiple underlying protocols.

- A means of propogating status and error information, through
  Faults.

* PROVREG Context and Requirements

PROVREG is charged with delivering a business protocol that enables
registration. The target application is the registration of domain
names, but the group is also considering other uses of a registration
mechanism.

PROVREG's preliminary requirements [9] include:

  Communications Interfaces

    Registries, registrars, and registrants interact using a wide
    spectrum of communications interfaces built upon multiple
    protocols, including transport layer protocols such as TCP and
    application layer protocols such as SMTP.  The protocol SHOULD be
    serviceable over multiple standard communications protocols.

  Extensibility

    Extensibility is a measure of the extent to which a protocol can
    be adapted for future uses that were not readily evident when the
    protocol was originally designed.  The protocol SHOULD provide
    features that at a minimum allow for the management of new object
    types without requiring revisions to the protocol itself.

The initial specification of a PROVREG protocol is the Extensible
Provisioning Protocol (EPP) [10]. EPP describes itself as;

  EPP is an XML protocol that can be layered over multiple transport
  protocols.  Protected using lower-layer security protocols, clients
  exchange identification, authentication, and option information,
  and then engage in a series of client-initiated command-response
  exchanges.  All EPP commands are atomic and idempotent.

  EPP provides four basic service elements: service discovery,
  commands, responses, and an extension framework that supports
  definition of managed objects and the relationship of protocol
  requests and responses to those objects.

EPP abstracts out the transport by allowing multiple mappings; the
first [11] is onto TCP.  Establishing a mapping to BEEP has been
discussed.

* Recommendations

Both of these efforts are works in progress; XMLP is more than
halfway through a clarification process which will culminate in SOAP
1.2; PROVREG is just staring to gather consensus about its
requirements, and is still entertaining candidates for a protocol.

Fundamentally, this note is intended to generate cross-discussion
between the groups, to introduce the work in SOAP to PROVREG, and to
gather feedback about SOAP from PROVREG.

In particular, PROVREG may benefit from considering SOAP, in part or
whole, as a framework for its deliverables. If there is sufficient
interest, an I-D outlining how EPP could use SOAP may be generated.
Otherwise, PROVREG may benefit from individual works in XMLP,
including the concepts surrounding the transport abstraction, the
transport bindings themselves, and XMLP's tentative use of XML
Infoset to describe a protocol.

Likewise, if after consideration SOAP is felt inappropriate to
PROVREG's purposes, or if it is deemed unintelligable, this feedback
is valueable to XMLP, as uses such as PROVREG should be addressable
by the output of the Working Group.

I'd ask that, to start, interested PROVREG WG members read the SOAP
1.2 working draft [12], and generate feedback to both lists as
appropriate. I'll be happy to draft an I-D (with help, hopefully) if
there's interest.

  [1] http://www.ietf.org/html.charters/provreg-charter.html
  [2] http://www.w3.org/2000/09/XML-Protocol-Charter
  [3] http://www.w3.org/TR/SOAP/
  [4] To subscribe; mailto:[email-masked]
      Archives; http://www.cafax.se/ietf-provreg/maillist/
  [5] To subscribe; mailto:[email-masked]
      Archives; http://lists.w3.org/Archives/Public/xml-dist-app/
  [6] http://www.w3.org/TR/SOAP-dsig/
  [7] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
  [8] http://search.ietf.org/internet-drafts/draft-etal-beep-soap-03.txt
  [9] http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-03.txt
  [10] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
  [11] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-02.txt
  [12] http://www.w3.org/TR/soap12/

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Date: Wed, 15 Aug 2001 17:15:22 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Mark Nottingham <[email-masked]>
cc: <[email-masked]>, XML Distributed Applications List <[email-masked]>
Subject: Re: PROVREG and XML Protocol
Sender: [email-masked]

Mark,

I looked at SOAP and BXXP (some call it BEEP) and our TCP transport.
I can live with TLS/TCP, I'd love to buse BXXP and I just can't find any
way to justify using SOAP.

While I appreciate your intro on it, you can write a EPP over SOAP
transfer if you like, but most registries have chosen BXXO or TLS/TCP.

-rick

ps my view on soap isn't from an I hate anything that uses http as
   a transport either.

On Wed, 15 Aug 2001, Mark Nottingham wrote:

>
> [ I'm posting this message to both the PROVREG
>   <[email-masked]> and XMLP <[email-masked]> lists, to
>   promote discussion.  AFAIK both lists accept posts from
>   non-subscribed addresses; please trim the distribution if your
>   message would only be interesting to one, or if the discussion
>   starts to take up too much bandwidth. Thanks. ]
>
> I got up at the PROVREG meeting in London to point out some
> similarities in that group's work and the XMLP WG in the W3C.
>
> This note is intended to generate discussion of SOAP as a potential
> framework for use by PROVREG, as well as to stimulate feedback to the
> XML Protocol WG regarding SOAP's suitability for such uses.
>
>
> * Introduction
>
> The IETF Provisioning Registry (PROVREG) Working Group has been
> chartered [1] to provide a "protocol that enables a registrar to
> access multiple registries." Furthermore, the group "... will
> consider support for multiple operational choices, such as for
> transport and security; it will create no new transport or security
> protocols."
>
> The W3C XML Protocol Working Group has been chartered [2] to provide
> a framework for XML messaging, using SOAP [3] as a starting point.
> Although SOAP is commonly believed to be only
> 'RPC-using-XML-over-HTTP', the group is bound to deliver
> transport-agnostic services which enable a wide variety of
> applications beyond RPC.
>
> Superficially, it appears that XMLP may provide a framework with
> which to implement a PROVREG protocol, with a number of advantages
> and efficiencies, as such uses are within the scope of its charter.
>
> This note seeks to examine the requirements of PROVREG from the
> perspective of SOAP, both to bring XMLP's work to the attention of
> PROVREG, and to generate feedback to XMLP about the suitability of
> SOAP for uses such as PROVREG's. Additionally, it attempts to point
> out the requirements and context of PROVREG to XMLP, in the hope that
> it will serve as a use case for XMLP.
>
> This note does not propose a SOAP-based registry protocol, and only
> represents the thoughts of the author. Discussion should be directed
> to the provreg mailing list [4] and the xml-dist-app [5] mailing list
> as appropriate.
>
>
> * XMLP Context and Deliverables
>
> The XML Protocol Working group is charged with delivering a framework
> for XML messaging, based on the SOAP submission. There are four
> defined deliverables;
>
>  1. A Message Envelope, which contains the XML message
>  2. A Serialization Mechanism, to represent data structures as XML
>  3. A Transport Binding, to move messages around; initially, HTTP
>  4. An RPC Convention, to enable applications which require this common
>     funtionality
>
> However, the charter implies a more abstract architecture which, in
> combination with these basic deliverables, has the following
> attributes;
>
> - A message processing model, which allows common functionality to be
>   modularised.
>
>   SOAP's processing model enables common functions like encryption,
>   application of policy, caching, message routing, etc. to be
>   standardized as Modules. This promotes interoperability and reduces
>   the amount of replicated code - and specification - necessary to
>   enable a service.
>
>   Currently, a few modules have been defined, including one for XML
>   Digital Signatures [6], which also encompasses encryption, and
>   SOAP-RP [7], which enables multi-hop routing in SOAP.
>
> - Intermediary targetting, to allow message processing to be
>   distributed across nodes.
>
>   SOAP is unique, in that it allows message functionality to be
>   targetted at particular intermediary nodes. This allows, for
>   example, a caching Module to be applied at a particular place in
>   the network, or likewise a non-repudiation Module to be invoked
>   between two unknown parties. SOAP's intermediary targetting
>   operates as a modification of the message processing model (the
>   'actor' attribute).
>
> - Transport abstraction, allowing XML messages to be bound to and
>   moved around by a variety of protocols.
>
>   One of the core requirements for XML Protocol is to be able to bind
>   messages to an arbitrary "underlying protocol", whether it be HTTP,
>   BEEP, TCP or UDP.  This, more than anything, frames XMLP (and
>   therefore SOAP) as an XML messaging framework, rather than a
>   purpose-specific protocol. SOAP originally defined a HTTP binding;
>   more recently, a BEEP binding [8] has been drafted, with discussion
>   of bindings to TCP and SMTP in the near future.
>
> - A framework for message exchange patterns, to allow business
>   protocols to be defined.
>
>   One of the consequences of transport abstraction is the ability to
>   build application message exchange patterns that are separate from
>   the underlying protocols' messaging patterns. For example, while
>   HTTP has a request-response pattern, SOAP applications may use it
>   as part of a larger, orchestrated service that spans multiple HTTP
>   connections or even multiple underlying protocols.
>
> - A means of propogating status and error information, through
>   Faults.
>
>
>
> * PROVREG Context and Requirements
>
> PROVREG is charged with delivering a business protocol that enables
> registration. The target application is the registration of domain
> names, but the group is also considering other uses of a registration
> mechanism.
>
> PROVREG's preliminary requirements [9] include:
>
>   Communications Interfaces
>
>     Registries, registrars, and registrants interact using a wide
>     spectrum of communications interfaces built upon multiple
>     protocols, including transport layer protocols such as TCP and
>     application layer protocols such as SMTP.  The protocol SHOULD be
>     serviceable over multiple standard communications protocols.
>
>   Extensibility
>
>     Extensibility is a measure of the extent to which a protocol can
>     be adapted for future uses that were not readily evident when the
>     protocol was originally designed.  The protocol SHOULD provide
>     features that at a minimum allow for the management of new object
>     types without requiring revisions to the protocol itself.
>
> The initial specification of a PROVREG protocol is the Extensible
> Provisioning Protocol (EPP) [10]. EPP describes itself as;
>
>   EPP is an XML protocol that can be layered over multiple transport
>   protocols.  Protected using lower-layer security protocols, clients
>   exchange identification, authentication, and option information,
>   and then engage in a series of client-initiated command-response
>   exchanges.  All EPP commands are atomic and idempotent.
>
>   EPP provides four basic service elements: service discovery,
>   commands, responses, and an extension framework that supports
>   definition of managed objects and the relationship of protocol
>   requests and responses to those objects.
>
> EPP abstracts out the transport by allowing multiple mappings; the
> first [11] is onto TCP.  Establishing a mapping to BEEP has been
> discussed.
>
>
> * Recommendations
>
> Both of these efforts are works in progress; XMLP is more than
> halfway through a clarification process which will culminate in SOAP
> 1.2; PROVREG is just staring to gather consensus about its
> requirements, and is still entertaining candidates for a protocol.
>
> Fundamentally, this note is intended to generate cross-discussion
> between the groups, to introduce the work in SOAP to PROVREG, and to
> gather feedback about SOAP from PROVREG.
>
> In particular, PROVREG may benefit from considering SOAP, in part or
> whole, as a framework for its deliverables. If there is sufficient
> interest, an I-D outlining how EPP could use SOAP may be generated.
> Otherwise, PROVREG may benefit from individual works in XMLP,
> including the concepts surrounding the transport abstraction, the
> transport bindings themselves, and XMLP's tentative use of XML
> Infoset to describe a protocol.
>
> Likewise, if after consideration SOAP is felt inappropriate to
> PROVREG's purposes, or if it is deemed unintelligable, this feedback
> is valueable to XMLP, as uses such as PROVREG should be addressable
> by the output of the Working Group.
>
> I'd ask that, to start, interested PROVREG WG members read the SOAP
> 1.2 working draft [12], and generate feedback to both lists as
> appropriate. I'll be happy to draft an I-D (with help, hopefully) if
> there's interest.
>
>
>   [1] http://www.ietf.org/html.charters/provreg-charter.html
>   [2] http://www.w3.org/2000/09/XML-Protocol-Charter
>   [3] http://www.w3.org/TR/SOAP/
>   [4] To subscribe; mailto:[email-masked]
>       Archives; http://www.cafax.se/ietf-provreg/maillist/
>   [5] To subscribe; mailto:[email-masked]
>       Archives; http://lists.w3.org/Archives/Public/xml-dist-app/
>   [6] http://www.w3.org/TR/SOAP-dsig/
>   [7] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
>   [8] http://search.ietf.org/internet-drafts/draft-etal-beep-soap-03.txt
>   [9] http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-03.txt
>   [10] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
>   [11] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-02.txt
>   [12] http://www.w3.org/TR/soap12/
>
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)
>

To: "Bason, Chris" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Message Pushing and TCP Transport 
Date: Wed, 15 Aug 2001 23:50:52 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Would someone please elaborate on why this push concept 
> is advantageous to EPP (preferably a PUSH proponent)? 

The issue has been discussed quite a few times on the list, not just at -50
and -51. See the general discussion of transfer notification.

Eric

Date: Wed, 15 Aug 2001 21:59:17 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Mark Nottingham <[email-masked]>
cc: <[email-masked]>, XML Distributed Applications List <[email-masked]>
Subject: Re: PROVREG and XML Protocol
Sender: [email-masked]

Mark,

frankly when EPP started SOAP was just an idea with HTTP as atransport and
a Apache module. The Registries need a highly robust transport with as
little cruft ( Apache would be ALOT of cruft ) as possable.

There was also the fact that no transport for SOAP existed at the time
so it was easy to see that SOAP was not an option.

you can still write up the docs for the transport, but you would have to
convince a registry to use if.

IMHO, SOAP isns't anything you would use where speed and security are
required. When it comes down to brass tacks, if we picked SOAP when we
started we wouldn't have any registries going live any time soon, and we
have one up and two more out the door in a couple of months.

Companies cant wait for standards w/o transports.The last time I checked,
I think  thats what we do here, write the standards for whats one the
wire.

Why doesn't the W3C just standardise on BXXP? Or, should I just not ask
that question and leave all the layer 10 questions out of it?

-rick

On Wed, 15 Aug 2001, Mark Nottingham wrote:

>
> Rick,
>
> So, if the work in PROVREG was done with an awareness of SOAP, the
> question that I find interesting is:
>
> Why does EPP use XML for messaging, yet not use what will be XML's
> messaging framework? Is it simply a matter of timing (SOAP is new,
> and there is no TCP binding defined), or is there some other, more
> functional reason?
>
> Anyone else from PROVREG care to comment?
>
> Cheers,
>
>
>
> On Wed, Aug 15, 2001 at 05:15:22PM -0700, Rick H Wesson wrote:
> >
> >
> > Mark,
> >
> > I looked at SOAP and BXXP (some call it BEEP) and our TCP transport.
> > I can live with TLS/TCP, I'd love to buse BXXP and I just can't find any
> > way to justify using SOAP.
> >
> > While I appreciate your intro on it, you can write a EPP over SOAP
> > transfer if you like, but most registries have chosen BXXO or TLS/TCP.
> >
> >
> > -rick
> >
> > ps my view on soap isn't from an I hate anything that uses http as
> >    a transport either.
> >
> >
> > On Wed, 15 Aug 2001, Mark Nottingham wrote:
> >
> > >
> > > [ I'm posting this message to both the PROVREG
> > >   <[email-masked]> and XMLP <[email-masked]> lists, to
> > >   promote discussion.  AFAIK both lists accept posts from
> > >   non-subscribed addresses; please trim the distribution if your
> > >   message would only be interesting to one, or if the discussion
> > >   starts to take up too much bandwidth. Thanks. ]
> > >
> > > I got up at the PROVREG meeting in London to point out some
> > > similarities in that group's work and the XMLP WG in the W3C.
> > >
> > > This note is intended to generate discussion of SOAP as a potential
> > > framework for use by PROVREG, as well as to stimulate feedback to the
> > > XML Protocol WG regarding SOAP's suitability for such uses.
> > >
> > >
> > > * Introduction
> > >
> > > The IETF Provisioning Registry (PROVREG) Working Group has been
> > > chartered [1] to provide a "protocol that enables a registrar to
> > > access multiple registries." Furthermore, the group "... will
> > > consider support for multiple operational choices, such as for
> > > transport and security; it will create no new transport or security
> > > protocols."
> > >
> > > The W3C XML Protocol Working Group has been chartered [2] to provide
> > > a framework for XML messaging, using SOAP [3] as a starting point.
> > > Although SOAP is commonly believed to be only
> > > 'RPC-using-XML-over-HTTP', the group is bound to deliver
> > > transport-agnostic services which enable a wide variety of
> > > applications beyond RPC.
> > >
> > > Superficially, it appears that XMLP may provide a framework with
> > > which to implement a PROVREG protocol, with a number of advantages
> > > and efficiencies, as such uses are within the scope of its charter.
> > >
> > > This note seeks to examine the requirements of PROVREG from the
> > > perspective of SOAP, both to bring XMLP's work to the attention of
> > > PROVREG, and to generate feedback to XMLP about the suitability of
> > > SOAP for uses such as PROVREG's. Additionally, it attempts to point
> > > out the requirements and context of PROVREG to XMLP, in the hope that
> > > it will serve as a use case for XMLP.
> > >
> > > This note does not propose a SOAP-based registry protocol, and only
> > > represents the thoughts of the author. Discussion should be directed
> > > to the provreg mailing list [4] and the xml-dist-app [5] mailing list
> > > as appropriate.
> > >
> > >
> > > * XMLP Context and Deliverables
> > >
> > > The XML Protocol Working group is charged with delivering a framework
> > > for XML messaging, based on the SOAP submission. There are four
> > > defined deliverables;
> > >
> > >  1. A Message Envelope, which contains the XML message
> > >  2. A Serialization Mechanism, to represent data structures as XML
> > >  3. A Transport Binding, to move messages around; initially, HTTP
> > >  4. An RPC Convention, to enable applications which require this common
> > >     funtionality
> > >
> > > However, the charter implies a more abstract architecture which, in
> > > combination with these basic deliverables, has the following
> > > attributes;
> > >
> > > - A message processing model, which allows common functionality to be
> > >   modularised.
> > >
> > >   SOAP's processing model enables common functions like encryption,
> > >   application of policy, caching, message routing, etc. to be
> > >   standardized as Modules. This promotes interoperability and reduces
> > >   the amount of replicated code - and specification - necessary to
> > >   enable a service.
> > >
> > >   Currently, a few modules have been defined, including one for XML
> > >   Digital Signatures [6], which also encompasses encryption, and
> > >   SOAP-RP [7], which enables multi-hop routing in SOAP.
> > >
> > > - Intermediary targetting, to allow message processing to be
> > >   distributed across nodes.
> > >
> > >   SOAP is unique, in that it allows message functionality to be
> > >   targetted at particular intermediary nodes. This allows, for
> > >   example, a caching Module to be applied at a particular place in
> > >   the network, or likewise a non-repudiation Module to be invoked
> > >   between two unknown parties. SOAP's intermediary targetting
> > >   operates as a modification of the message processing model (the
> > >   'actor' attribute).
> > >
> > > - Transport abstraction, allowing XML messages to be bound to and
> > >   moved around by a variety of protocols.
> > >
> > >   One of the core requirements for XML Protocol is to be able to bind
> > >   messages to an arbitrary "underlying protocol", whether it be HTTP,
> > >   BEEP, TCP or UDP.  This, more than anything, frames XMLP (and
> > >   therefore SOAP) as an XML messaging framework, rather than a
> > >   purpose-specific protocol. SOAP originally defined a HTTP binding;
> > >   more recently, a BEEP binding [8] has been drafted, with discussion
> > >   of bindings to TCP and SMTP in the near future.
> > >
> > > - A framework for message exchange patterns, to allow business
> > >   protocols to be defined.
> > >
> > >   One of the consequences of transport abstraction is the ability to
> > >   build application message exchange patterns that are separate from
> > >   the underlying protocols' messaging patterns. For example, while
> > >   HTTP has a request-response pattern, SOAP applications may use it
> > >   as part of a larger, orchestrated service that spans multiple HTTP
> > >   connections or even multiple underlying protocols.
> > >
> > > - A means of propogating status and error information, through
> > >   Faults.
> > >
> > >
> > >
> > > * PROVREG Context and Requirements
> > >
> > > PROVREG is charged with delivering a business protocol that enables
> > > registration. The target application is the registration of domain
> > > names, but the group is also considering other uses of a registration
> > > mechanism.
> > >
> > > PROVREG's preliminary requirements [9] include:
> > >
> > >   Communications Interfaces
> > >
> > >     Registries, registrars, and registrants interact using a wide
> > >     spectrum of communications interfaces built upon multiple
> > >     protocols, including transport layer protocols such as TCP and
> > >     application layer protocols such as SMTP.  The protocol SHOULD be
> > >     serviceable over multiple standard communications protocols.
> > >
> > >   Extensibility
> > >
> > >     Extensibility is a measure of the extent to which a protocol can
> > >     be adapted for future uses that were not readily evident when the
> > >     protocol was originally designed.  The protocol SHOULD provide
> > >     features that at a minimum allow for the management of new object
> > >     types without requiring revisions to the protocol itself.
> > >
> > > The initial specification of a PROVREG protocol is the Extensible
> > > Provisioning Protocol (EPP) [10]. EPP describes itself as;
> > >
> > >   EPP is an XML protocol that can be layered over multiple transport
> > >   protocols.  Protected using lower-layer security protocols, clients
> > >   exchange identification, authentication, and option information,
> > >   and then engage in a series of client-initiated command-response
> > >   exchanges.  All EPP commands are atomic and idempotent.
> > >
> > >   EPP provides four basic service elements: service discovery,
> > >   commands, responses, and an extension framework that supports
> > >   definition of managed objects and the relationship of protocol
> > >   requests and responses to those objects.
> > >
> > > EPP abstracts out the transport by allowing multiple mappings; the
> > > first [11] is onto TCP.  Establishing a mapping to BEEP has been
> > > discussed.
> > >
> > >
> > > * Recommendations
> > >
> > > Both of these efforts are works in progress; XMLP is more than
> > > halfway through a clarification process which will culminate in SOAP
> > > 1.2; PROVREG is just staring to gather consensus about its
> > > requirements, and is still entertaining candidates for a protocol.
> > >
> > > Fundamentally, this note is intended to generate cross-discussion
> > > between the groups, to introduce the work in SOAP to PROVREG, and to
> > > gather feedback about SOAP from PROVREG.
> > >
> > > In particular, PROVREG may benefit from considering SOAP, in part or
> > > whole, as a framework for its deliverables. If there is sufficient
> > > interest, an I-D outlining how EPP could use SOAP may be generated.
> > > Otherwise, PROVREG may benefit from individual works in XMLP,
> > > including the concepts surrounding the transport abstraction, the
> > > transport bindings themselves, and XMLP's tentative use of XML
> > > Infoset to describe a protocol.
> > >
> > > Likewise, if after consideration SOAP is felt inappropriate to
> > > PROVREG's purposes, or if it is deemed unintelligable, this feedback
> > > is valueable to XMLP, as uses such as PROVREG should be addressable
> > > by the output of the Working Group.
> > >
> > > I'd ask that, to start, interested PROVREG WG members read the SOAP
> > > 1.2 working draft [12], and generate feedback to both lists as
> > > appropriate. I'll be happy to draft an I-D (with help, hopefully) if
> > > there's interest.
> > >
> > >
> > >   [1] http://www.ietf.org/html.charters/provreg-charter.html
> > >   [2] http://www.w3.org/2000/09/XML-Protocol-Charter
> > >   [3] http://www.w3.org/TR/SOAP/
> > >   [4] To subscribe; mailto:[email-masked]
> > >       Archives; http://www.cafax.se/ietf-provreg/maillist/
> > >   [5] To subscribe; mailto:[email-masked]
> > >       Archives; http://lists.w3.org/Archives/Public/xml-dist-app/
> > >   [6] http://www.w3.org/TR/SOAP-dsig/
> > >   [7] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
> > >   [8] http://search.ietf.org/internet-drafts/draft-etal-beep-soap-03.txt
> > >   [9] http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-03.txt
> > >   [10] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
> > >   [11] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-02.txt
> > >   [12] http://www.w3.org/TR/soap12/
> > >
> > >
> > > --
> > > Mark Nottingham, Research Scientist
> > > Akamai Technologies (San Mateo, CA USA)
> > >
> >
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)
>

Date: Wed, 15 Aug 2001 21:45:32 -0700
From: Mark Nottingham <[email-masked]>
To: Rick H Wesson <[email-masked]>
Cc: [email-masked], XML Distributed Applications List <[email-masked]>
Subject: Re: PROVREG and XML Protocol
Sender: [email-masked]

Rick,

So, if the work in PROVREG was done with an awareness of SOAP, the
question that I find interesting is:

Why does EPP use XML for messaging, yet not use what will be XML's
messaging framework? Is it simply a matter of timing (SOAP is new,
and there is no TCP binding defined), or is there some other, more
functional reason?

Anyone else from PROVREG care to comment?

Cheers,

On Wed, Aug 15, 2001 at 05:15:22PM -0700, Rick H Wesson wrote:
> 
> 
> Mark,
> 
> I looked at SOAP and BXXP (some call it BEEP) and our TCP transport.
> I can live with TLS/TCP, I'd love to buse BXXP and I just can't find any
> way to justify using SOAP.
> 
> While I appreciate your intro on it, you can write a EPP over SOAP
> transfer if you like, but most registries have chosen BXXO or TLS/TCP.
> 
> 
> -rick
> 
> ps my view on soap isn't from an I hate anything that uses http as
>    a transport either.
> 
> 
> On Wed, 15 Aug 2001, Mark Nottingham wrote:
> 
> >
> > [ I'm posting this message to both the PROVREG
> >   <[email-masked]> and XMLP <[email-masked]> lists, to
> >   promote discussion.  AFAIK both lists accept posts from
> >   non-subscribed addresses; please trim the distribution if your
> >   message would only be interesting to one, or if the discussion
> >   starts to take up too much bandwidth. Thanks. ]
> >
> > I got up at the PROVREG meeting in London to point out some
> > similarities in that group's work and the XMLP WG in the W3C.
> >
> > This note is intended to generate discussion of SOAP as a potential
> > framework for use by PROVREG, as well as to stimulate feedback to the
> > XML Protocol WG regarding SOAP's suitability for such uses.
> >
> >
> > * Introduction
> >
> > The IETF Provisioning Registry (PROVREG) Working Group has been
> > chartered [1] to provide a "protocol that enables a registrar to
> > access multiple registries." Furthermore, the group "... will
> > consider support for multiple operational choices, such as for
> > transport and security; it will create no new transport or security
> > protocols."
> >
> > The W3C XML Protocol Working Group has been chartered [2] to provide
> > a framework for XML messaging, using SOAP [3] as a starting point.
> > Although SOAP is commonly believed to be only
> > 'RPC-using-XML-over-HTTP', the group is bound to deliver
> > transport-agnostic services which enable a wide variety of
> > applications beyond RPC.
> >
> > Superficially, it appears that XMLP may provide a framework with
> > which to implement a PROVREG protocol, with a number of advantages
> > and efficiencies, as such uses are within the scope of its charter.
> >
> > This note seeks to examine the requirements of PROVREG from the
> > perspective of SOAP, both to bring XMLP's work to the attention of
> > PROVREG, and to generate feedback to XMLP about the suitability of
> > SOAP for uses such as PROVREG's. Additionally, it attempts to point
> > out the requirements and context of PROVREG to XMLP, in the hope that
> > it will serve as a use case for XMLP.
> >
> > This note does not propose a SOAP-based registry protocol, and only
> > represents the thoughts of the author. Discussion should be directed
> > to the provreg mailing list [4] and the xml-dist-app [5] mailing list
> > as appropriate.
> >
> >
> > * XMLP Context and Deliverables
> >
> > The XML Protocol Working group is charged with delivering a framework
> > for XML messaging, based on the SOAP submission. There are four
> > defined deliverables;
> >
> >  1. A Message Envelope, which contains the XML message
> >  2. A Serialization Mechanism, to represent data structures as XML
> >  3. A Transport Binding, to move messages around; initially, HTTP
> >  4. An RPC Convention, to enable applications which require this common
> >     funtionality
> >
> > However, the charter implies a more abstract architecture which, in
> > combination with these basic deliverables, has the following
> > attributes;
> >
> > - A message processing model, which allows common functionality to be
> >   modularised.
> >
> >   SOAP's processing model enables common functions like encryption,
> >   application of policy, caching, message routing, etc. to be
> >   standardized as Modules. This promotes interoperability and reduces
> >   the amount of replicated code - and specification - necessary to
> >   enable a service.
> >
> >   Currently, a few modules have been defined, including one for XML
> >   Digital Signatures [6], which also encompasses encryption, and
> >   SOAP-RP [7], which enables multi-hop routing in SOAP.
> >
> > - Intermediary targetting, to allow message processing to be
> >   distributed across nodes.
> >
> >   SOAP is unique, in that it allows message functionality to be
> >   targetted at particular intermediary nodes. This allows, for
> >   example, a caching Module to be applied at a particular place in
> >   the network, or likewise a non-repudiation Module to be invoked
> >   between two unknown parties. SOAP's intermediary targetting
> >   operates as a modification of the message processing model (the
> >   'actor' attribute).
> >
> > - Transport abstraction, allowing XML messages to be bound to and
> >   moved around by a variety of protocols.
> >
> >   One of the core requirements for XML Protocol is to be able to bind
> >   messages to an arbitrary "underlying protocol", whether it be HTTP,
> >   BEEP, TCP or UDP.  This, more than anything, frames XMLP (and
> >   therefore SOAP) as an XML messaging framework, rather than a
> >   purpose-specific protocol. SOAP originally defined a HTTP binding;
> >   more recently, a BEEP binding [8] has been drafted, with discussion
> >   of bindings to TCP and SMTP in the near future.
> >
> > - A framework for message exchange patterns, to allow business
> >   protocols to be defined.
> >
> >   One of the consequences of transport abstraction is the ability to
> >   build application message exchange patterns that are separate from
> >   the underlying protocols' messaging patterns. For example, while
> >   HTTP has a request-response pattern, SOAP applications may use it
> >   as part of a larger, orchestrated service that spans multiple HTTP
> >   connections or even multiple underlying protocols.
> >
> > - A means of propogating status and error information, through
> >   Faults.
> >
> >
> >
> > * PROVREG Context and Requirements
> >
> > PROVREG is charged with delivering a business protocol that enables
> > registration. The target application is the registration of domain
> > names, but the group is also considering other uses of a registration
> > mechanism.
> >
> > PROVREG's preliminary requirements [9] include:
> >
> >   Communications Interfaces
> >
> >     Registries, registrars, and registrants interact using a wide
> >     spectrum of communications interfaces built upon multiple
> >     protocols, including transport layer protocols such as TCP and
> >     application layer protocols such as SMTP.  The protocol SHOULD be
> >     serviceable over multiple standard communications protocols.
> >
> >   Extensibility
> >
> >     Extensibility is a measure of the extent to which a protocol can
> >     be adapted for future uses that were not readily evident when the
> >     protocol was originally designed.  The protocol SHOULD provide
> >     features that at a minimum allow for the management of new object
> >     types without requiring revisions to the protocol itself.
> >
> > The initial specification of a PROVREG protocol is the Extensible
> > Provisioning Protocol (EPP) [10]. EPP describes itself as;
> >
> >   EPP is an XML protocol that can be layered over multiple transport
> >   protocols.  Protected using lower-layer security protocols, clients
> >   exchange identification, authentication, and option information,
> >   and then engage in a series of client-initiated command-response
> >   exchanges.  All EPP commands are atomic and idempotent.
> >
> >   EPP provides four basic service elements: service discovery,
> >   commands, responses, and an extension framework that supports
> >   definition of managed objects and the relationship of protocol
> >   requests and responses to those objects.
> >
> > EPP abstracts out the transport by allowing multiple mappings; the
> > first [11] is onto TCP.  Establishing a mapping to BEEP has been
> > discussed.
> >
> >
> > * Recommendations
> >
> > Both of these efforts are works in progress; XMLP is more than
> > halfway through a clarification process which will culminate in SOAP
> > 1.2; PROVREG is just staring to gather consensus about its
> > requirements, and is still entertaining candidates for a protocol.
> >
> > Fundamentally, this note is intended to generate cross-discussion
> > between the groups, to introduce the work in SOAP to PROVREG, and to
> > gather feedback about SOAP from PROVREG.
> >
> > In particular, PROVREG may benefit from considering SOAP, in part or
> > whole, as a framework for its deliverables. If there is sufficient
> > interest, an I-D outlining how EPP could use SOAP may be generated.
> > Otherwise, PROVREG may benefit from individual works in XMLP,
> > including the concepts surrounding the transport abstraction, the
> > transport bindings themselves, and XMLP's tentative use of XML
> > Infoset to describe a protocol.
> >
> > Likewise, if after consideration SOAP is felt inappropriate to
> > PROVREG's purposes, or if it is deemed unintelligable, this feedback
> > is valueable to XMLP, as uses such as PROVREG should be addressable
> > by the output of the Working Group.
> >
> > I'd ask that, to start, interested PROVREG WG members read the SOAP
> > 1.2 working draft [12], and generate feedback to both lists as
> > appropriate. I'll be happy to draft an I-D (with help, hopefully) if
> > there's interest.
> >
> >
> >   [1] http://www.ietf.org/html.charters/provreg-charter.html
> >   [2] http://www.w3.org/2000/09/XML-Protocol-Charter
> >   [3] http://www.w3.org/TR/SOAP/
> >   [4] To subscribe; mailto:[email-masked]
> >       Archives; http://www.cafax.se/ietf-provreg/maillist/
> >   [5] To subscribe; mailto:[email-masked]
> >       Archives; http://lists.w3.org/Archives/Public/xml-dist-app/
> >   [6] http://www.w3.org/TR/SOAP-dsig/
> >   [7] http://www.gotdotnet.com/team/xml_wsspecs/soap-rp/default.html
> >   [8] http://search.ietf.org/internet-drafts/draft-etal-beep-soap-03.txt
> >   [9] http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-03.txt
> >   [10] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
> >   [11] http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-02.txt
> >   [12] http://www.w3.org/TR/soap12/
> >
> >
> > --
> > Mark Nottingham, Research Scientist
> > Akamai Technologies (San Mateo, CA USA)
> >
> 

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Date: Fri, 10 Aug 2001 02:44:07 +0900 (JST)
From: Peter Chow <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: [email-masked]
Subject: Re: XRP to WG status?
Sender: [email-masked]

On Fri, 10 Aug 2001, Peter Chow wrote:

> > Jaap and I are leaning towards inclusion of XRP documents
> > (draft-brunner-...) as a WG document.  If you have a strong reason *not* to
> > include this, please speak up, I believe that the sense of the room was
> > that the document belongs.
> 
> There was talk during the meeting to break up the document as 
> extensions to EPP.  Is the author planning to do this before we
> make them WG documents?

My apologies, I just saw Eric's message about his plans for the
new drafts.

--------------------------------------------------------------------
_/_/_/ Peter Chow		Chief Technical Advisor
_/_/_/ [email-masked]		Global Media Online Inc.
_/_/_/				System Division
_/_/_/ ICQ: 41931890		Shibuya Cerulean Tower 11F
_/_/_/ (tel)+81-3-5456-2687	26-1 Sakuragaoka-cho, Shibuya-ku
_/_/_/ (fax)+81-3-5456-2740	Tokyo, Japan
_/_/_/ http://www.gmo.jp/	150-8512
--------------------------------------------------------------------

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Mark Nottingham'" <[email-masked]>, Rick H Wesson <[email-masked]>
Cc: [email-masked], XML Distributed Applications List <[email-masked]>
Subject: RE: PROVREG and XML Protocol
Date: Thu, 16 Aug 2001 06:59:03 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Mark Nottingham [mailto:[email-masked]]
>Sent: Thursday, August 16, 2001 12:46 AM
>To: Rick H Wesson
>Cc: [email-masked]; XML Distributed Applications List
>Subject: Re: PROVREG and XML Protocol
>
>
>
>Rick,
>
>So, if the work in PROVREG was done with an awareness of SOAP, the
>question that I find interesting is:
>
>Why does EPP use XML for messaging, yet not use what will be XML's
>messaging framework? Is it simply a matter of timing (SOAP is new,
>and there is no TCP binding defined), or is there some other, more
>functional reason?
>
>Anyone else from PROVREG care to comment?

With the provreg work being done in the IETF, there is a very strong desire,
perhaps even a mandate, to define transport mechanisms based on other IETF
standard protocols.  As Rick noted, when I first started working on EPP SOAP
wasn't really mature enough (see your "what will be" comment above) to be
considered a viable transport candidate, plus there was/is no IETF work
happening to make it a standards track protocol.  That doesn't mean it won't
ever happen, but I do believe it's something that would need to happen
(perhaps as a joint IETF/W3C effort) before XML protocols being developed in
the IETF could consider SOAP transport.

<Scott/>

Date: Wed, 15 Aug 2001 12:28:09 -0400
To: Klaus Malorny <[email-masked]>, Patrick <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: host transfers
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Hi Klaus:

I'll try to keep this short.  These messages are becoming a bit too 
long to digest easily.

Your proposal is to allow any registrar to create name server objects 
for any domain.  Explaining to me what useful functionality this 
achieved vs. the EPP model, you indicated:

>1. Other registrars are not able to create name servers in that domain
>
>2. The sponsoring registrar does not have full control over his own
>    name servers, i.e. anyone can reference his name server and block
>    the deletion of the name server and also the domain the
>    name server belongs to.

There is tension between these two benefits.  You want a sponsoring 
registrar to be able to prevent the *use* of a name server within a 
domain that they sponsor, but not the *creation* of a name server in 
the same domain.  This doesn't make sense.  If it's desirable to 
prohibit the use of a name server that has been registered already in 
the registry; presumably, it may also be desirable to prohibit the 
use of a name server that exists within the domain, but hasn't been 
registered yet.

Additionally, the second of these objectives could be accomplished by 
the use of a status that indicates that new associations with the 
name server (or contact, for that matter) are disallowed.

I also asked why the sponsorship model would be problematic if 
transfers were able to be accomplished from one registrar to another 
easily.  Your response was:

>because they have to pay for. People usually don't transfer domains
>if 1 1/2 years or so are left from the registration period. And, eventually,
>they have some other domains registered via a third registrar.

For someone who often accuses those that disagree with him of being 
overly tied to the gTLD model, the above statement seems to assume 
the exact same model.  There's nothing within the EPP protocol that 
requires payment of any fee for the domain name at transfer time. 
This is a matter of registry policy.

Finally, in a response to Patrick you conclude by writing:

>I don't want to be offensive. But the more I read in this list here the more I
>am missing the 'global view' of the participants, the view beyond 
>the borders of
>the registry system. Big efforts are taken to have some consistency 
>in a single
>registry and they are defended by all means - although their 
>contribution to the
>stability of the Domain Name System are marginally. Even worse, due 
>to the fact
>that we get more and more ccTLD/gTLD registries around the world (especially
>think of the upcomming separation of the com/net/org registry), it will become
>quite uncommon that the name servers of a domain belong to the same TLD which
>make these efforts useless. On the other hand, problems that may 
>arise from this
>fact are not considered in any way. The assumptions the current name server
>concept is based on are from a time long ago where NSI was the only 
>BIG registry
>and where customers directly registered with NSI. Therefore, the emerging
>protocols that have been proposed here until now may be new, but 
>their concepts
>are still the same old ones. No real advance.
>
>This disappoints me somehow.

I'm not sure where the above commentary is coming from.  This whole 
thread started with the suggestion by Sheer that name server objects 
from domains not registered within a specific registry should be 
transferable outside of the domain sponsorship model.  This seems to 
be an explicit recognition of a problem posed by multiple registries.

Most of the message in which you wrote this explains why glue records 
are only needed for name servers that are authoritative for their own 
domains, an argument that I'll admit I'm coming around to.  However, 
an argument against this approach that has been raised in the past is 
that it is possible to create a situation in which two (or more 
domains) use name servers in the other domain(s), so that none of 
them end up having glue or being useful.  For example:

A.XXX has name servers NS1.B.YY and NS2.B.YY.
B.YY has name servers NS1.A.XXX and NS2.A.XXX.

Under your scheme, neither of these domains will work.  For that 
matter, under your scheme, even if A and B were both in domain XXX, 
they would not work.  A modified version of your scheme could fix the 
problem by checking for such situations within a single registry, but 
is utterly unresolvable if the domains are in different registries.

Klaus, I think many of your arguments are reasonable and well thought 
out.  I happen to agree with some of them, but I don't think that you 
are stupid or naive as a result of our disagreement.  I hope that you 
can accord the rest of us the same respect.

Jordyn

From: "Bason, Chris" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Message Pushing and TCP Transport
Date: Wed, 15 Aug 2001 08:02:22 -0400
Sender: [email-masked]

Would someone please elaborate on why this push concept 
is advantageous to EPP (preferably a PUSH proponent)? 

I apologize if this is redundant but I was not at the
IETF meeting and would like to hear the justification
for putting this into the protocol.

Chris Bason

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 8:01 AM
To: [email-masked]'
Subject: Message Pushing and TCP Transport

Discussion requested:

One of the items to come out of last week's provreg meeting was a desire to
add message push features to the base EPP specification so that clients and
servers can negotiate the preferred message delivery method.  Text to be
added to the base spec is fairly straight-forward; I'll work that out with
Eric.

A more complex situation arises when we consider how to support message
pushing with TCP transport (no snide remarks from the BEEP proponents,
please).  Right now we've specified use of a single TCP port for exchanging
commands and responses; the addition of message pushing means that the
"client" end should be willing and able to receive unsolicited messages from
the "server".

This can be accomplished using a single port, but it may be easier to do
using two ports in a fashion similar to the way ftp works.  As the "server"
needs to push messages within the bounds of an established session, it can
open a connection to the "client" on the second port, push the data, and
close the connection.

Anyway, I'd like to get a feel for how folks would like to see this
specified.  I'd like to add it to the TCP draft as REQUIRED if you intend to
do message pushing, but not used is message pushing isn't used.

<Scott/>

Date: Wed, 15 Aug 2001 12:36:16 +0200
From: Klaus Malorny <[email-masked]>
To: Edward Lewis <[email-masked]>
CC: [email-masked]
Subject: Re: Meeting straw poll
Sender: [email-masked]

Edward Lewis wrote:
> 
> Towards the end of the meeting at the 51st IETF there was a straw poll
> held.  I wanted to allow those not present to voice responses.
> 
> First, I asked for a show of hands of implementors.  Not that this is a
> decision point, if you are building an implementation and don't mind doing
> so, please mention this to the chairs - not that we are going to do
> anything with the data.
> 

If you include client implementations, I think I should raise my hand.

> (I suppose I should set forth a data collection policy ;) - the data is
> simply to give an indication of the number of efforts.  We won't be
> reselling the contact information. ;))
> 
> Second, and this is a decision point.  If members want to delay an answer
> until the minutes are available, this is understandable.
> 
> 1) Are you "loyal" to EPP?
> 2) Are you "loyal" to XRP?

1&2: no, why should I? For explanation, see the last section of my latest
posting in the "host transfers" thread.

> 3) Do you want just one to be defined?  IOW, you'll be dealing with so many
> folks, you can't afford to have two dissimilar systems.

I don't want to have just one to be defined, I would like to see the best
being defined here. Although Scott did a lot of adjustments based on the
critics here, I thought the purpose of this WG would be more than finishing up
EPP and then deciding between EPP and XRP...

BTW: I'm wondering what the silence of the ccTLD representatives -- which are
in this list hopefully -- means.

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Message Pushing and TCP Transport
Date: Tue, 14 Aug 2001 08:01:26 -0400
Sender: [email-masked]

Discussion requested:

One of the items to come out of last week's provreg meeting was a desire to
add message push features to the base EPP specification so that clients and
servers can negotiate the preferred message delivery method.  Text to be
added to the base spec is fairly straight-forward; I'll work that out with
Eric.

A more complex situation arises when we consider how to support message
pushing with TCP transport (no snide remarks from the BEEP proponents,
please).  Right now we've specified use of a single TCP port for exchanging
commands and responses; the addition of message pushing means that the
"client" end should be willing and able to receive unsolicited messages from
the "server".

This can be accomplished using a single port, but it may be easier to do
using two ports in a fashion similar to the way ftp works.  As the "server"
needs to push messages within the bounds of an established session, it can
open a connection to the "client" on the second port, push the data, and
close the connection.

Anyway, I'd like to get a feel for how folks would like to see this
specified.  I'd like to add it to the TCP draft as REQUIRED if you intend to
do message pushing, but not used is message pushing isn't used.

<Scott/>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-03.txt
Date: Tue, 14 Aug 2001 07:01:28 -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		: Generic Registry-Registrar Protocol Requirements
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-grrp-reqs-03.txt
	Pages		: 25
	Date		: 13-Aug-01
	
This document describes high-level functional and interface
requirements for a client-server protocol for the registration and
management of Internet domain names in shared registries. Specific
technical requirements detailed for protocol design are not presented
here.  Instead, this document focuses on the basic functions and
interfaces required of a protocol to support multiple registry and
registrar operational models.

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

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-grrp-reqs-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-grrp-reqs-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-grrp-reqs-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-grrp-reqs-03.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: "[email-masked]'" <[email-masked]>
Subject: Requirements Draft Update
Date: Mon, 13 Aug 2001 10:32:36 -0400
Sender: [email-masked]

I just sent an updated requirements draft to the I-D administrator; it
should be announced tomorrow or as soon as they get out from under whatever
backlog they're working through.  Here's a summary of the changes:

-02 to -03: IESG review and WG experience updates.

  Added Acknowledgements section.

  Changed use of the term "TLD" where the generic terms "zone" and "name
  space" are more appropriate per IESG comments.  Added definitions of
  zone and name space.

  Numerous changes of MUST/MAY/SHOULD/etc. to lower case with minor
  edits to multiple sentences to distinguish protocol requirements from
  use descriptions per IESG comments.

  Modified 3.4.1-[6] to remove "returned when created" text per WG
  discussion on object identifiers in protocol responses.

  Modified 3.4.2-[3] and 3.4.2-[5] per IESG comments.

  Deleted 3.4.2-[4] because it repeated a requirement described in
  3.4.3-[1]; renumbered remaining requirements.

  Modified paragraphs in 3.4.9 to note recent WG decisions on use of
  object authorization information.

<Scott/>

To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: WG Discussion Summary with Draft Document Impact 
Date: Sun, 12 Aug 2001 20:46:35 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> At 6:46 AM -0400 8/9/01, Hollenbeck, Scott wrote:
> >existed.  Even in their most current review, the IESG did not provide any
> >comments suggesting more generalization.
> >
> >If anyone wants a more generalized requirements draft, I suggest writing
> >another draft.
> 
> I agree.  The IESG has already commented once and gave us specific
> comments.  This doesn't mean that the IESG won't send back more comments,
> but let's not try to draw them out.  (At the same time, we don't want to
> try to sneak anything past 'em.)

OK.

Eric

To: [email-masked]
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Meeting straw poll 
Date: Sun, 12 Aug 2001 09:09:04 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Sheer,

Assume some transport-independent set of operations on some set of operands,
e.g., draft-ietf-provreg-epp-04 et seq.

The sense of the 3rd straw poll (the 1st being on draft-jseng-provreg-opp,
the 2nd on the question of data collection remaining in the requirements),
was on the adoption of:

	addition of a second transport mapping (first being tcp)
	addition of a push operator with appropriate operands
	addition of a second data abstraction mapping (first being flat)

These consisting of a draft, a revision of an existing draft, and a draft,
respectively, though currently packaged as a single draft called "XRP".
For clarity, these are:

	draft-ietf-provreg-epp-beep-00.txt
	changes to draft-ietf-provreg-epp-04.txt
	draft-ietf-provreg-epp-containers-00.txt

Co-chairs and contributors present at London please correct as necessary.

> 	... something as complex and untested as BEEP ...
and later
>	... loath to insist that any operation registrar or registry
>	needs to be able to implement or use such a complex protocol
>	...
and still later
>	... how are we supposed to support this ...

This doesn't appear to be a protocol specification concern, and rfc3080
is standards track.

>   ... by problem domains I meant something a little more fundemental --
> registrar-registry versus registry-registry

Mechanisms for end-point initiation of instances of communication, e.g.,
"client" uni- vs "peer" bi-directional, are orthogonal to mechanisms for
session management within an established instance of communication, e.g.,
rfc793 (none, see: segment, window, sequence numbers) vs rfc3080 (numerous),
with mechanisms for end-point selection, e.g., registry, registrar, ICANN
contract escrow agent, etc.

>From the context and your willingness for "Epp ... broken down into protocols
wich would rarely overlap ... gTLD ... (RIR) ... ccTLD", I understand you to
be interested in the business model, not the actual transport mapping, nor
the EPP core.

I hope this helps. It would help me if you could seperate specification
issues from commercial operational issues.

Eric

From: Bruce Tonkin <[email-masked]>
To: [email-masked]
Subject: RE: Meeting straw poll
Date: Sun, 12 Aug 2001 09:12:47 +1000
Sender: [email-masked]

Hello All,

As Rick Wesson points out:

	I prefer a single specification of the XML Schemas that we converse
about,
	I don't care that there are diferent transports. I would encourage
the use
	of BXXP as I'm sure the IESG would...

The discussion seems to be getting bogged down in issues of transport
protocols.
I would like to see the new ideas of XRP that relate to the XML schemas,
commands etc (e.g incorporating the ability to push information as well as
poll for it) in the one EPP document.

Then we can separately specify how to run EPP over BEEP, TCP, email etc.
I expect to see initial implementations using mainstream protocols, with
some "cutting-edge" users opting to use the latest protocols.  It would be
wise not to be "locked-in" to one way or the other in the outputs of this
working group.

So lets integrate the ideas of XRP into the existing drafts where
appropriate, and create separate documents that deal with data extensions or
methods of using different transport/session protocols.

Regards,
Bruce Tonkin

Date: Sat, 11 Aug 2001 01:48:11 +0100
From: Klaus Malorny <[email-masked]>
To: Patrick <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

Patrick wrote:
> 
> Dear all,
> 
> Sorry to be late and sorry if I am a little heavy(?) with what
> follows, I just want to be sure to understand everything.
> 
> On Thu, Aug 09, 2001 at 11:17:24AM +0200, Klaus Malorny took time to write:
> > Registrant R goes to registrar A and registers a.com with ns1.a.com and
> > ns2.a.com. Some time later. Now, registrar B has a good offer, and R wants to
> > register a domain with him, lets say b.com with ns.b.com and ns3.a.com.
> > "Sorry, we can't do that, you can't use ns3.a.com" - "Why, a.com is my
> > domain?" ... and so on...
> 
> Ok, this is true. But see above, I think your proposal does create
> the same problem :
> client goes to registrar B to make changes in IP and it does not see
> they are used at all (since it should have gone through A).
>

Unfortunately, I don't understand your example. Eventually this will help you:
If the client asks registrar B to change something, it typically changes only
domains registered via B and not those registered via A.

> > Situation:
> > ----------
> >
> > Two registrars: R1, R2
> >
> > R1:
> >   A.com, using ns1.A.com, ns2.A.com
> >     ns1.A.com, 1.1.1.1
> >     ns2.A.com, 2.2.2.2
> >     ns3.A.com, 3.3.3.3
> > R2:
> >   B.com, using ns1.B.com, ns3.A.com
> >     ns1.B.com, 4.4.4.4
> 
> [..]
> 
> > my model:
> > ---------
> >
> > situation #1: R2 shares ns3.A.com with R1
> >
> > registry objects:
> >
> > domain       A.com, N1, N2 (R1)
> > name server  N1: ns1.A.com, 1.1.1.1 (R1)
> > name server  N2: ns2.A.com, 2.2.2.2 (R1)
> > name server  N3: ns3.A.com, 3.3.3.3 (R1)
> >
> > domain       B.com, N4, N3 (R2)
> > name server  N4: ns1.B.com, 4.4.4.4 (R2)
> >
> > zone file:
> >
> > A.com.       NS         ns1.A.com.
> > A.com.       NS         ns2.A.com.
> > ns1.A.com.   A          1.1.1.1
> > ns2.A.com.   A          2.2.2.2
> > B.com.       NS         ns1.B.com.
> > B.com.       NS         ns3.A.com.
> > ns1.B.com.   A          4.4.4.4
> >
> > note that no A record exists for ns3.A.com.
> 
> Why don't you have glue record for ns3.A.com ??

Why should I? They are not required. Why doesn't www.A.com appear here? Because
it's not required. ns3.A.com is not used to operate the A.com domain. The zone
file for .com IS NOT AUTHORITIVE for A.com, therefore it is not authoritive for
any A record (or any other record) in the A.com zone. Please remember that glue
records are an aid to solve a technical problem and they definitely break the
concept of authoritative zones.

> I do not understand.
> ns1.A.com / ns2.A.com / ns3.A.com are 3 nameservers, and they should
> be treated in the same way.

But they are not identical. What about a name server, e.g.,
ns.microsoft.customers.A.com? Is it o.k. that it appears in the TLD zone? I
don't think so.

> 
> Do you mean that the glue record is not needed since IP address of
> ns3.A.com is in ns{1,2}.A.com authoritatives for A.com ?
> If yes, I do not think it is a good idea to have one setup for the
> first two nameservers, and another for the others.

Yes and no, as there seems to be a misunderstanding.

No. Any name server below A.com that IS USED AS a name server FOR the domain
A.com should get its glue record. If the A.com has five NS records with
ns1.A.com ... ns5.A.com, all should get a glue record, of course.

Yes. A name server that is not enlisted in the domain's NS list should NOT get a
glue record.

> 
> > situation #2: R2 has an own object for ns3.A.com
> >
> > domain       A.com, N1, N2 (R1)
> > name server  N1: ns1.A.com, 1.1.1.1 (R1)
> > name server  N2: ns2.A.com, 2.2.2.2 (R1)
> > name server  N3: ns3.A.com, 3.3.3.3 (R1)
> >
> > domain       B.com, N4, N5 (R2)
> > name server  N4: ns1.B.com, 4.4.4.4 (R2)
> > name server  N5: ns3.A.com (R2)
> >
> > zone file:
> >
> > exactly the same as above, even if R2 specifies an (arbitrary) IP address for
> > N5.
> 
> And then there is the problem outlined above :
> when the client will want to change IP address of ns3.a.com if he
> goes through registrar B, it will be possible, but will have not
> useful use. Whatever IP the client will try to put, it will NOT be
> reflected in the zone file, since to do that he should go through
> Registrar A.

Compare this to the contacts. My real world address in the contact isn't
normally used, except in some case of 'emergency'. Similarily, the specified
addresses are only used if and only if we have this special emergency case of
'zone bootstrapping', where glue records are required. This needs to be
communicated to the people.

> Of course it can just be written/explained to the client that he
> needs to go through Registrar A. But people make assumptions, and if
> the client sees it possible to change IP through B, he will try, and
> will not understand why it does not work at all.

I think people are able to understand that they can only modify a name server's
IP at the registrar where the corresponding domain is registered. To be correct,
they have to look into the domain record, look at the referenced name server and
determine the sponsoring registrar. Another way is to create a new record and
update the domain accordingly. It's exactly the same process as the modification
of, let's say, the phone number of a technical contact.

> 
> In fact, with your proposal, even IP address of ns3.A.com through
> Registrar A has no meaning since it is not included in zone file,
> thus the problem outlined just below do not exist. But still I do not
> understand/think it is a good idea that ns3.A.com is not in the zone
> file.

As I mentioned earlier, the zone file of the domain is the authoritative source,
not the registry. It is an unnecessary duplication of information.

> 
> But do your model with another example : Registrar B for B.com uses
> ns2.A.com and not ns3.A.com
> How do you will handle it ? The problem outlined above then exists :
> Registrar A chooses IP address of ns2.A.com

> If you try to change it through Registrar B (which have also a record
> for ns2.A.com), the change will not appear in zone file.

Registrar B's copy of the record is not referenced in A's domain object as a
name server, but A's own record. Therefore, not the IP address of B's record is
used, but the IP address of A's record. So it behaves as you describe. And it
should behave like this, because the registry does not know whether registrar B
has the right to update the IP address. As long as we are stuck with this
"registrar sponsoring model", there is no other solution. A registrar may grant
another registrar the right to choose the IP address by referencing a name
server object of him in the domain (as in situation #1 with domain B.com).
Theoretically, the following is possible:

domain       A.com, N1, N2 (R1)
name server  N1: ns1.A.com, 1.1.1.1 (R1)
name server  N2: ns2.A.com, 2.2.2.2 (R2)
                                     ^^

In this situation, R2 and only R2 is able to change the IP of N2. R1 may update
domain A.com, of course, and switch to another name server object that also
describes ns2.A.com and that is sponsored by R1, resulting in the original
situation. Although this is a quite unusual situation, I don't see any cause why
this should be prevented by the registry. It's not the registry's duty.

> 
> > situation #3: R2 has an own object for ns3.A.com, R1 not
> >
> >
> > domain       A.com, N1, N2 (R1)
> > name server  N1: ns1.A.com, 1.1.1.1 (R1)
> > name server  N2: ns2.A.com, 2.2.2.2 (R1)
> >
> > domain       B.com, N4, N5 (R2)
> > name server  N4: ns1.B.com, 4.4.4.4 (R2)
> > name server  N5: ns3.A.com (R2)
> >
> > zone file:
> >
> > exactly the same as above, even if R2 specifies an (arbitrary) IP address for
> > N5.
> 
> In that case, please also take into account another (current)
> problem.
> Right now, for example if you want to destroy domain A.com you can
> not until there are no more nameservers child of this domain used
> anywhere else.

This is not true, with my definition of "anywhere else". See below.

> In your model, will Registrar A be able to delete A.com if he wants,
> since Registrar B has created ns3.A.com and I think that Registrar A
> has no way to know that ?
> If no, then it is a big problem.

Our company, Knipp, owns the domain knipp.de. We have name servers (beside
others) ns2.knipp.de and ns3.knipp.de, that customer can use as
primary/secondary name servers. 

So he may register a domain, e.g. B.com with the name servers ns2.knipp.de and
ns3.knipp.de. Knipp could delete the domain knipp.de at DENIC. Nobody at
Verisign/NSI would take notice about that. Nevertheless, the domain B.com would
become disfunctional. 

Vice versa, Knipp could use the name servers ns1.knipp.net and ns2.knipp.net for
the domain knipp.de, but Verisign/NSI would not prohibit me of deleting these
name servers or even the domain knipp.net, despite the ongoing usage.

Even if a customer registers the domain B.com with ns3.A.com and ns4.A.com, the
operator of these name servers could push the power switch and render the
(obviously) holy grail of strong binding of name servers to their domains
useless.

Whether it is a problem at all, and whether it is a small or a big one, it
already exists.

I don't want to be offensive. But the more I read in this list here the more I
am missing the 'global view' of the participants, the view beyond the borders of
the registry system. Big efforts are taken to have some consistency in a single
registry and they are defended by all means - although their contribution to the
stability of the Domain Name System are marginally. Even worse, due to the fact
that we get more and more ccTLD/gTLD registries around the world (especially
think of the upcomming separation of the com/net/org registry), it will become
quite uncommon that the name servers of a domain belong to the same TLD which
make these efforts useless. On the other hand, problems that may arise from this
fact are not considered in any way. The assumptions the current name server
concept is based on are from a time long ago where NSI was the only BIG registry
and where customers directly registered with NSI. Therefore, the emerging
protocols that have been proposed here until now may be new, but their concepts
are still the same old ones. No real advance.

This disappoints me somehow.

> 
> Regards,
> Patrick Mevzek.

regards,
Klaus Malorny

Date: Fri, 10 Aug 2001 09:14:24 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: Re: Meeting straw poll
Sender: [email-masked]

Ed,

On Thu, 9 Aug 2001, Edward Lewis wrote:

> Towards the end of the meeting at the 51st IETF there was a straw poll
> held.  I wanted to allow those not present to voice responses.
>
> First, I asked for a show of hands of implementors.  Not that this is a
> decision point, if you are building an implementation and don't mind doing
> so, please mention this to the chairs - not that we are going to do
> anything with the data.

hmmm... I implement these things.

> (I suppose I should set forth a data collection policy ;) - the data is
> simply to give an indication of the number of efforts.  We won't be
> reselling the contact information. ;))
>
> Second, and this is a decision point.  If members want to delay an answer
> until the minutes are available, this is understandable.
>
> 1) Are you "loyal" to EPP?

loyal is probably the wrong thing to be asking here. I use EPP and I write
applications that use EPP, I also provide services to others that are
required to use EPP by a Registry.

> 2) Are you "loyal" to XRP?

well, I haven't see XRP, and as I understood it XRP is just EPP over a
diferent Transpport; now ask me if I like BEEP ;-)

> 3) Do you want just one to be defined?  IOW, you'll be dealing with so many
> folks, you can't afford to have two dissimilar systems.

the registries will all implement diferent policy and that will require a
registrars to implement this policy; they may have diferent implementations
just to deal with the diferent policy they must implement to deal with the
registyry <-> registrar <-> registrant communications.

> I don't want to know if EPP is better or worse than XRP.  I just want to
> gauge what the group needs to settle upon.

I prefer a single specification of the XML Schemas that we converse about,
I don't care that there are diferent transports. I would encourage the use
of BXXP as I'm sure the IESG would...

> BTW, the largest bloc of hands was for #3 during the meeting.
>
> This poll is not intended to kill off ERP and/or XRP, but rather to
> determine if we need to hammer the two into one - as opposed to being
> parallel.

yes, one specification for the message formats, transactions etc, but lets
keep the transports seporate as they should be.

-rick

Date: Fri, 10 Aug 2001 11:45:24 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: Edward Lewis <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Meeting straw poll 
Sender: [email-masked]

> >                                                                 ... relies
> > on beep as the session layer makes it a poor candidate for me (I don't
> > think we can adopt a protcol that only supports beep).
>
> There is at least one technical comment in this - a single transport map.
> There may be a second one concerning the sessions mechanism, but I'd like
> to be sure before attempting to respond.
>

Well my point was more about using only one transport mechanism and
depending upon BEEP in particular as a session mechanism.  I'm not
strictly opposed to integrating another protocol to address part of the
needs of provreg (I think this is good reuse, so long as that protocol
doesn't come with a whole new suite of limitations), I'm just not sure I
like something as complex and untested as BEEP being integrated into a
protocol that's already supposed to be operational in high-volume
environments (and sadly enough we've missed that deadline already).

> >               ... the parrallel but only if they addressed sufficienty
> > different problem domains ...
>
> So, the transport mapping. One, several, or one per <what>?
>

Well, by problem domains I meant something a little more fundemental --
registrar-registry versus registry-registry (as you and Jordyn were
discussing).  As far as different transport mappings I see those as
different solutions addressing the same problem domain.  What I was saying
there is that I would like to see two different protocols only if their
usage was different enough that there would rarely be a question of
overlap or of using one protocol instead of the other.  I think we've done
too much in Epp to try and address the needs of everyone and I wouldn't
mind seeing it broken down into protocols which would rarely overlap in
the same operational environment (I think that a commercial gTLD registry is a
very different entity than a IP registry or even a ccTLD registry --
unfortunately we need to integrate accross a lot of these).

> Both multicast and unicast ... cast. Do they address sufficiently different
> problem domains? That just to get the juices flowing.
>
> The existence of a control and two or more (256 to be exhaustive) data
> channels per connection allows one tcp connection to connect two end
> points with two or more administrative roles, e.g., a single operator
> node offering access to two or more registries, and a single registrar
> node offering access to the same registries. Several gTLD operators now
> or may also be ccTLD operators, and presumably different polices apply
> to each registry, but no technical requirements necessitate protocol,
> transport, port, or even connection level isolation of one repository
> from another. The operations over these two channels are asychronous.
>
> The existence of a control and two or more (256 to be exhaustive) data
> "channels" per connection allows one tcp connection to connect two end
> points with two or more functional roles, e.g., an add and a delete op
> for distinct objects undertaken asychronously. An exhaustive example
> we see frequently is <check> for variation of name. One can run 255
> instances of <check> asychronously, as opposed to 255 instances sequentially.
>

I've looked over the BEEP rfc's and am pretty familiar with its virtues.
I think if BEEP were a more proven technology then I would be very happy
to see a protocol that maps naturally into it (though I still wouldn't
like tieing the protocol entirely to it).  I agree with you entirely that
it provides a lot of very nice functionality.  But even looking over the
BEEP Api's that are out there (and they are pretty limited -- only Java
and Phython that I found) and I would be loath to insist that any
operation registrar or registry needs to be able to implement or use such
a complex protocol.  Also, and I'm really not sure how XRP addresses this
(I havn't even checked), depending on such a "rich" protocol to handle
session management and authentication for you means that it is very
difficult to extract your base XRP protocol and implement it in a
different environment -- such as SMTP or even plain batch files.

> This note I hope motivates reading rfc3080 and rfc3081, and the draft
> available at http://nic-naa.net/draft-brunner-xrp-01.txt, at least the
> section on BEEP, or better still, the pending pre-ID version of the
> draft, draft-ietf-provreg-epp-beep-00.txt, which I'll get out in about
> a week. There are _lots_ of things a profiled, striped, set of paths that
> share end-points can do, that a single path can't, or can't do easily.
>

Right, but given that the protocol has to operate, under certain
conditions, in an environment with a single path, how are we supposed to
support this.

> I haven't addressed the aspect of authentication, another significant
> distinction.
>
> This gets us towards the <what> of the "one per <what>" view of transport
> maps, and your view was also expressed by Dave at the meeting. One view
> holds that connection == what, another view holds that asychronous !=
> synchronous, multiplex != uniplex, confidentiality + authentication !=
> confidentiality ... hence connection != what.
>

I'm really not sure I follow you here Eric, would you mind elucidating ...
what do you mean by one transport mapping per <what> where what ==
connection, or am I misunderstanding you?

> Personally I look forward to transport mappings for smtp (connectionless),
> http (1.0 c-less, 1.1 c-full, or cookie session provisioned), and for file
> system(s) (nfs/udp and afs/tcp).

Please tell me the NFS/AFS thing is a joke.  NFS has enough problems
working as a file sharing protocol without needing the extra burden of
authentication, confidentiality, and what not that we'de place on it ;->
Please let's not pull a "because we could" here.

Enjoy indian dining, wish I was there ...

Sheer

Date: Fri, 10 Aug 2001 14:45:23 +0200
From: Patrick <[email-masked]>
To: Klaus Malorny <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: host transfers
Organization: Gandi
Sender: [email-masked]

Dear all,

Sorry to be late and sorry if I am a little heavy(?) with what
follows, I just want to be sure to understand everything.

On Thu, Aug 09, 2001 at 11:17:24AM +0200, Klaus Malorny took time to write:
> Registrant R goes to registrar A and registers a.com with ns1.a.com and
> ns2.a.com. Some time later. Now, registrar B has a good offer, and R wants to
> register a domain with him, lets say b.com with ns.b.com and ns3.a.com.
> "Sorry, we can't do that, you can't use ns3.a.com" - "Why, a.com is my
> domain?" ... and so on...

Ok, this is true. But see above, I think your proposal does create
the same problem :
client goes to registrar B to make changes in IP and it does not see
they are used at all (since it should have gone through A).

> Situation:
> ----------
> 
> Two registrars: R1, R2
> 
> R1:
>   A.com, using ns1.A.com, ns2.A.com
>     ns1.A.com, 1.1.1.1
>     ns2.A.com, 2.2.2.2
>     ns3.A.com, 3.3.3.3
> R2:
>   B.com, using ns1.B.com, ns3.A.com
>     ns1.B.com, 4.4.4.4

[..]

> my model:
> ---------
> 
> situation #1: R2 shares ns3.A.com with R1
> 
> registry objects:
> 
> domain       A.com, N1, N2 (R1)
> name server  N1: ns1.A.com, 1.1.1.1 (R1)
> name server  N2: ns2.A.com, 2.2.2.2 (R1)
> name server  N3: ns3.A.com, 3.3.3.3 (R1)
> 
> domain       B.com, N4, N3 (R2)
> name server  N4: ns1.B.com, 4.4.4.4 (R2)
> 
> zone file:
> 
> A.com.       NS         ns1.A.com.
> A.com.       NS         ns2.A.com.
> ns1.A.com.   A          1.1.1.1
> ns2.A.com.   A          2.2.2.2
> B.com.       NS         ns1.B.com.
> B.com.       NS         ns3.A.com.
> ns1.B.com.   A          4.4.4.4
> 
> note that no A record exists for ns3.A.com.

Why don't you have glue record for ns3.A.com ??
I do not understand.
ns1.A.com / ns2.A.com / ns3.A.com are 3 nameservers, and they should
be treated in the same way.

Do you mean that the glue record is not needed since IP address of
ns3.A.com is in ns{1,2}.A.com authoritatives for A.com ?
If yes, I do not think it is a good idea to have one setup for the
first two nameservers, and another for the others.

> situation #2: R2 has an own object for ns3.A.com
> 
> domain       A.com, N1, N2 (R1)
> name server  N1: ns1.A.com, 1.1.1.1 (R1)
> name server  N2: ns2.A.com, 2.2.2.2 (R1)
> name server  N3: ns3.A.com, 3.3.3.3 (R1)
> 
> domain       B.com, N4, N5 (R2)
> name server  N4: ns1.B.com, 4.4.4.4 (R2)
> name server  N5: ns3.A.com (R2)
> 
> zone file:
> 
> exactly the same as above, even if R2 specifies an (arbitrary) IP address for
> N5.

And then there is the problem outlined above :
when the client will want to change IP address of ns3.a.com if he
goes through registrar B, it will be possible, but will have not
useful use. Whatever IP the client will try to put, it will NOT be
reflected in the zone file, since to do that he should go through
Registrar A.
Of course it can just be written/explained to the client that he
needs to go through Registrar A. But people make assumptions, and if
the client sees it possible to change IP through B, he will try, and
will not understand why it does not work at all.

In fact, with your proposal, even IP address of ns3.A.com through
Registrar A has no meaning since it is not included in zone file,
thus the problem outlined just below do not exist. But still I do not
understand/think it is a good idea that ns3.A.com is not in the zone
file.

But do your model with another example : Registrar B for B.com uses
ns2.A.com and not ns3.A.com
How do you will handle it ? The problem outlined above then exists :
Registrar A chooses IP address of ns2.A.com
If you try to change it through Registrar B (which have also a record
for ns2.A.com), the change will not appear in zone file.

> situation #3: R2 has an own object for ns3.A.com, R1 not
> 
> 
> domain       A.com, N1, N2 (R1)
> name server  N1: ns1.A.com, 1.1.1.1 (R1)
> name server  N2: ns2.A.com, 2.2.2.2 (R1)
> 
> domain       B.com, N4, N5 (R2)
> name server  N4: ns1.B.com, 4.4.4.4 (R2)
> name server  N5: ns3.A.com (R2)
> 
> zone file:
> 
> exactly the same as above, even if R2 specifies an (arbitrary) IP address for
> N5.

In that case, please also take into account another (current)
problem.
Right now, for example if you want to destroy domain A.com you can
not until there are no more nameservers child of this domain used
anywhere else.
In your model, will Registrar A be able to delete A.com if he wants,
since Registrar B has created ns3.A.com and I think that Registrar A
has no way to know that ?
If no, then it is a big problem.

Regards,
Patrick Mevzek.

Date: Fri, 10 Aug 2001 14:25:09 +0200
From: Patrick <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Meeting straw poll
Organization: Gandi
Sender: [email-masked]

Dear all,

My answer is quite similar to the previous one of Mr Sheer, but here
it goes anyway.

On Thu, Aug 09, 2001 at 10:57:51AM -0400, Edward Lewis took time to write:
> Towards the end of the meeting at the 51st IETF there was a straw poll
> held.  I wanted to allow those not present to voice responses.
> 
> First, I asked for a show of hands of implementors.  Not that this is a
> decision point, if you are building an implementation and don't mind doing
> so, please mention this to the chairs - not that we are going to do
> anything with the data.

In fact, I am the person implementing Registry clients at Gandi
(Registrar). We are building something close to DBI/DBD in Perl to be
able to support as many Registries and protocols as possible. It is a
work in progress, and may be available later as free software.

Right now in fact I'm building Perl EPP modules (near finished).

So, you can count me as implementor.

> 1) Are you "loyal" to EPP?
> 2) Are you "loyal" to XRP?
> 3) Do you want just one to be defined?  IOW, you'll be dealing with so many
> folks, you can't afford to have two dissimilar systems.
> 
> I don't want to know if EPP is better or worse than XRP.  I just want to
> gauge what the group needs to settle upon.

As far as I have seen since now from the drafts, XRP is kind of EPP
over BEEP. Seems to me more complicated. If it solves problems not
solved by EPP, then ok. Otherwise I always prefer the simpler
solutions.

For me, as far as I've seen, BEEP is exactly like TCP (with windows,
ack for each frame/packet, etc...) but on a different layer. I am
still not sure that this is really something useful, seems to be like
an ``application TCP'' over TCP.

I have not deeply studied things so it is just my point of view, and
I do not want to offense anyone.

> BTW, the largest bloc of hands was for #3 during the meeting.
> 
> This poll is not intended to kill off ERP and/or XRP, but rather to
> determine if we need to hammer the two into one - as opposed to being
> parallel.

It is ok to me to have EPP and XRP one along the other, if both are
doing things the other can not. If both are doing the same thing, then
they should be merged IMNSHO.

In any case our software framework is build to be able to support as
many as possible. And we will need to since Afilias seems to use EPP
and Neulevel XRP. But if complexity can be reduced, we are all for
it.

Regards,
Patrick Mevzek

To: Sheer El-Showk <[email-masked]>
cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Meeting straw poll 
Date: Fri, 10 Aug 2001 04:10:54 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Sheer,

>                                                                 ... relies
> on beep as the session layer makes it a poor candidate for me (I don't
> think we can adopt a protcol that only supports beep).

There is at least one technical comment in this - a single transport map.
There may be a second one concerning the sessions mechanism, but I'd like
to be sure before attempting to respond. 

>               ... the parrallel but only if they addressed sufficienty
> different problem domains ...
 
So, the transport mapping. One, several, or one per <what>?

Both multicast and unicast ... cast. Do they address sufficiently different
problem domains? That just to get the juices flowing.

The existence of a control and two or more (256 to be exhaustive) data
channels per connection allows one tcp connection to connect two end
points with two or more administrative roles, e.g., a single operator
node offering access to two or more registries, and a single registrar
node offering access to the same registries. Several gTLD operators now
or may also be ccTLD operators, and presumably different polices apply
to each registry, but no technical requirements necessitate protocol,
transport, port, or even connection level isolation of one repository
from another. The operations over these two channels are asychronous.

The existence of a control and two or more (256 to be exhaustive) data
"channels" per connection allows one tcp connection to connect two end
points with two or more functional roles, e.g., an add and a delete op
for distinct objects undertaken asychronously. An exhaustive example
we see frequently is <check> for variation of name. One can run 255
instances of <check> asychronously, as opposed to 255 instances sequentially.

This note I hope motivates reading rfc3080 and rfc3081, and the draft
available at http://nic-naa.net/draft-brunner-xrp-01.txt, at least the
section on BEEP, or better still, the pending pre-ID version of the
draft, draft-ietf-provreg-epp-beep-00.txt, which I'll get out in about
a week. There are _lots_ of things a profiled, striped, set of paths that
share end-points can do, that a single path can't, or can't do easily.

I haven't addressed the aspect of authentication, another significant
distinction.

This gets us towards the <what> of the "one per <what>" view of transport
maps, and your view was also expressed by Dave at the meeting. One view
holds that connection == what, another view holds that asychronous !=
synchronous, multiplex != uniplex, confidentiality + authentication !=
confidentiality ... hence connection != what.

Personally I look forward to transport mappings for smtp (connectionless),
http (1.0 c-less, 1.1 c-full, or cookie session provisioned), and for file
system(s) (nfs/udp and afs/tcp).

Enjoy the weekend.
Eric

Date: Thu, 9 Aug 2001 22:56:02 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: Re: Meeting straw poll
Sender: [email-masked]

> Towards the end of the meeting at the 51st IETF there was a straw poll
> held.  I wanted to allow those not present to voice responses.
>
> First, I asked for a show of hands of implementors.  Not that this is a
> decision point, if you are building an implementation and don't mind doing
> so, please mention this to the chairs - not that we are going to do
> anything with the data.

I've been involved (and still am) with implementations of various kinds --
using and writings APIs and supporting associated registrar-registry
rulesets.

>
> (I suppose I should set forth a data collection policy ;) - the data is
> simply to give an indication of the number of efforts.  We won't be
> reselling the contact information. ;))
>
> Second, and this is a decision point.  If members want to delay an answer
> until the minutes are available, this is understandable.
>
> 1) Are you "loyal" to EPP?
> 2) Are you "loyal" to XRP?
> 3) Do you want just one to be defined?  IOW, you'll be dealing with so many
> folks, you can't afford to have two dissimilar systems.
>
> I don't want to know if EPP is better or worse than XRP.  I just want to
> gauge what the group needs to settle upon.
>

I havn't, in all fairness, studied XRP enough, but the fact that it relies
on beep as the session layer makes it a poor candidate for me (I don't
think we can adopt a protcol that only supports beep).  Thus I'm probably
for #1 -- sorry Eric ;->

> BTW, the largest bloc of hands was for #3 during the meeting.
>
> This poll is not intended to kill off ERP and/or XRP, but rather to
> determine if we need to hammer the two into one - as opposed to being
> parallel.
>

I could live with the parrallel but only if they addressed sufficienty
different problem domains, and I havn't purused XRP enough to say.

Regards,
Sheer

From: "Ross Wm. Rader" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: XRP to WG status? 
Date: Thu, 9 Aug 2001 22:34:55 -0400
Sender: [email-masked]

>
> > these questions and comments may be naive, but...
>
> I welcome technical comments or questions.

Then let's hope that someone else out there is interested in process and
form.

-rwr

To: "Ross Wm. Rader" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: XRP to WG status? 
Date: Thu, 09 Aug 2001 20:55:18 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ross,

> these questions and comments may be naive, but...

I welcome technical comments or questions.

Eric

From: Bruce Tonkin <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: XRP to WG status?
Date: Fri, 10 Aug 2001 05:09:47 +1000
Sender: [email-masked]

Hello Scott,

That agrees with my interpretation of the outcome of the meeting.

I think it is also consistent with a recent posting from Eric.

Regards,
Bruce Tonkin

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Friday, August 10, 2001 3:28 AM
To: 'Edward Lewis'; [email-masked]
Subject: RE: XRP to WG status?

>-----Original Message-----
>From: Edward Lewis [mailto:[email-masked]]
>Sent: Thursday, August 09, 2001 10:58 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: XRP to WG status?
>
>
>Jaap and I are leaning towards inclusion of XRP documents
>(draft-brunner-...) as a WG document.  If you have a strong reason *not* to
>include this, please speak up, I believe that the sense of the room was
>that the document belongs.

I agree that the sense of the room was that there was a place for the
documents described by Eric, but I would like to request consideration of
the following comments:

I for one would find things far less confusing if we as a WG referred to EPP
extensions as EPP extensions instead of something that sounds confusingly
like a second protocol.  One of the two options described yesterday (the
multi-document approach) was clearly (in my mind anyway) described to the
room as EPP extensions.  Let the document titles and text reflect that
status.

Along those lines, a BEEP transport draft for EPP clearly fits within the
current charter of the WG.  If the document describes BEEP transport for
EPP, let it in.

The containers draft made me think about a different issue.  Our WG charter
currently focuses our efforts to a set of specified object types.  A
container object is not one of the objects included in the current charter.
I _want_ to see this draft accepted as an EPP extension, but I think this
leads us to a "next steps" discussion about expanding our charter.  Are we
now at a point where we actively wish to encourage submission of new object
mapping drafts, and if so, where do we draw the line on in-scope objects and
out-of-scope objects?

I think the "push" draft could just as easily be managed in an exchange
between Eric and I to merge the features into the current EPP drafts.  If
the draft is indeed a description of requested changes to the EPP drafts we
can just change the EPP drafts and be done with it, ensuring a single
editing path as we go forward.

<Scott/>

To: Peter Chow <[email-masked]>
cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Subject: Re: XRP to WG status? 
Date: Thu, 09 Aug 2001 14:33:32 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

yup.

Reply-To: "Ross Wm. Rader" <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: <[email-masked]>
Subject: Re: XRP to WG status?
Date: Thu, 9 Aug 2001 14:03:27 -0400
Organization: Tucows Inc.
Sender: [email-masked]

Scott,

I think you've hit the nail squarely on the head as far as my "discomfort"
goes. Not having had a chance to debrief with our people that are there,
these questions and comments may be naive, but...

It's my preference that we deal with "in-scope" until such time that the
"core" has been nailed down. Concerning "extensions", is it contemplated
that these would largely be optional in nature along the same lines as the
implementors choice of transport? (which I assume is still part of the
projected path)

Lastly, re: push - let's try and stay, focused and cohesive with our
movement going forward. A merger of features will quickly expose
inconsistencies whereas separate document tracks may leave us with documents
that compete on certain points. Obviously, I favor the former over the
latter.

-rwr

> I for one would find things far less confusing if we as a WG referred to
EPP
> extensions as EPP extensions instead of something that sounds confusingly
> like a second protocol.  One of the two options described yesterday (the
> multi-document approach) was clearly (in my mind anyway) described to the
> room as EPP extensions.  Let the document titles and text reflect that
> status.
>
> Along those lines, a BEEP transport draft for EPP clearly fits within the
> current charter of the WG.  If the document describes BEEP transport for
> EPP, let it in.
>
> The containers draft made me think about a different issue.  Our WG
charter
> currently focuses our efforts to a set of specified object types.  A
> container object is not one of the objects included in the current
charter.
> I _want_ to see this draft accepted as an EPP extension, but I think this
> leads us to a "next steps" discussion about expanding our charter.  Are we
> now at a point where we actively wish to encourage submission of new
object
> mapping drafts, and if so, where do we draw the line on in-scope objects
and
> out-of-scope objects?
>
> I think the "push" draft could just as easily be managed in an exchange
> between Eric and I to merge the features into the current EPP drafts.  If
> the draft is indeed a description of requested changes to the EPP drafts
we
> can just change the EPP drafts and be done with it, ensuring a single
> editing path as we go forward.
>
> <Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: XRP to WG status?
Date: Thu, 9 Aug 2001 13:27:34 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Edward Lewis [mailto:[email-masked]]
>Sent: Thursday, August 09, 2001 10:58 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: XRP to WG status?
>
>
>Jaap and I are leaning towards inclusion of XRP documents
>(draft-brunner-...) as a WG document.  If you have a strong reason *not* to
>include this, please speak up, I believe that the sense of the room was
>that the document belongs.

I agree that the sense of the room was that there was a place for the
documents described by Eric, but I would like to request consideration of
the following comments:

I for one would find things far less confusing if we as a WG referred to EPP
extensions as EPP extensions instead of something that sounds confusingly
like a second protocol.  One of the two options described yesterday (the
multi-document approach) was clearly (in my mind anyway) described to the
room as EPP extensions.  Let the document titles and text reflect that
status.

Along those lines, a BEEP transport draft for EPP clearly fits within the
current charter of the WG.  If the document describes BEEP transport for
EPP, let it in.

The containers draft made me think about a different issue.  Our WG charter
currently focuses our efforts to a set of specified object types.  A
container object is not one of the objects included in the current charter.
I _want_ to see this draft accepted as an EPP extension, but I think this
leads us to a "next steps" discussion about expanding our charter.  Are we
now at a point where we actively wish to encourage submission of new object
mapping drafts, and if so, where do we draw the line on in-scope objects and
out-of-scope objects?

I think the "push" draft could just as easily be managed in an exchange
between Eric and I to merge the features into the current EPP drafts.  If
the draft is indeed a description of requested changes to the EPP drafts we
can just change the EPP drafts and be done with it, ensuring a single
editing path as we go forward.

<Scott/>

Date: Fri, 10 Aug 2001 02:18:22 +0900 (JST)
From: Peter Chow <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: [email-masked]
Subject: Re: XRP to WG status?
Sender: [email-masked]

On Thu, 9 Aug 2001, Edward Lewis wrote:

> Jaap and I are leaning towards inclusion of XRP documents
> (draft-brunner-...) as a WG document.  If you have a strong reason *not* to
> include this, please speak up, I believe that the sense of the room was
> that the document belongs.

There was talk during the meeting to break up the document as 
extensions to EPP.  Is the author planning to do this before we
make them WG documents?

--------------------------------------------------------------------
_/_/_/ Peter Chow		Chief Technical Advisor
_/_/_/ [email-masked]		Global Media Online Inc.
_/_/_/				System Division
_/_/_/ ICQ: 41931890		Shibuya Cerulean Tower 11F
_/_/_/ (tel)+81-3-5456-2687	26-1 Sakuragaoka-cho, Shibuya-ku
_/_/_/ (fax)+81-3-5456-2740	Tokyo, Japan
_/_/_/ http://www.gmo.jp/	150-8512
--------------------------------------------------------------------

Date: Thu, 09 Aug 2001 18:47:25 +0200
From: Klaus Malorny <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
CC: Sheer El-Showk <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

"Jordyn A. Buchanan" wrote:
> 
> Klaus:
> 
> I just have a couple of questions:
> 
> 1) Much of your suggestion seems to be related to registrars being
> able to refer to name server objects created by other registrars.
> Can't this just as easily be accomplished under EPP's existing model,
> in which name server objects are automatically sponsored by the
> sponsor of their parent domain?  In other words, if name servers can
> always be used by other registrars, why does it matter where the
> sponsorship lies?
> 

1. Other registrars are not able to create name servers in that domain

2. The sponsoring registrar does not have full control over his own
   name servers, i.e. anyone can reference his name server and block
   the deletion of the name server and also the domain the
   name server belongs to.

> 2) As far as I can tell from your examples, the only circumstance in
> which it becomes important for a non-sponsoring registrar to be able
> to create a new name server within a domain is a situation like this:
> 
> >situation #3: R2 has an own object for ns3.A.com, R1 not
> >
> >
> >domain       A.com, N1, N2 (R1)
> >name server  N1: ns1.A.com, 1.1.1.1 (R1)
> >name server  N2: ns2.A.com, 2.2.2.2 (R1)
> >
> >domain       B.com, N4, N5 (R2)
> >name server  N4: ns1.B.com, 4.4.4.4 (R2)
> >name server  N5: ns3.A.com (R2)
> 
> Presumably this is because the registrant now likes R2 more than R1.
> Assuming transfers work well, why can't they simply transfer A.com to
> R2 and then perform the action?

because they have to pay for. People usually don't transfer domains
if 1 1/2 years or so are left from the registration period. And, eventually,
they have some other domains registered via a third registrar.

> What is the value in a single
> registrant being able to manage domains (and objects, such as name
> servers, within those domains) across multiple registrars?  This is
> not clear to me, and seems to be a fundamental premise of your
> argument.

Money, satisfaction with the service provided by the registrars/resellers etc.
And they don't shift hundreds of domains around in one step.

> 
> 3) In the example above, how does the owner of A.com prevent the
> creation of ns3.A.com by R2 if they *don't want* anyone else to use
> that name server?

Why should he want this? The registry is only a mapping of the real world, not
vice versa. If someone creates a name server in the registry which does not
exist in the real world, what can he do with it? - absolutely nothing. That
name server must be listed in the A.com's zone file (which is hopefully under
the control of registrant of A.com) to be usable. The other way around: The
current model does not really prevent anything. As long as the name server is
registered, it can be used by anyone. And for so-called non-authoritive name
servers (those with different TLDs) there is absolutely no protection. I
believe, that most of the new TLDs will be served by name servers in the
existing ccTLDs/gTLDs. So the restrictions are becoming more annoying than
helpful.

> 
> Jordyn

I don't think that my model is optimal, surely not. The cause I'm talking
about it is that I am somehow uncomfortable with the EPP's model and similar
ones. It has the fixed premise that there is one registry, N registrars, that
each registrant directly or indirectly registers all his domains with a single
registrar.
This is far from the reality. We, for example, are a member of the Council of
Registrars (CORE). Technically, CORE, as an abstract entity, is the registrar,
and we are a reseller. People are directly registering domains with us, but we
also have resellers and we know that some of these even have resellers for
their own. So this is a real hierarchical system. Resellers and registrants
choose from time to time to change their source for domains and occassionally
jump over the border to another registrar.
Well, it may not be the purpose of the registry system to model the *whole*
world (I think Scott once argued like this). But the part it models should
reflect the reality. This rule is violated for all object types - contacts,
name servers and domains. The behavior of the system depends on the question
which registrar sponsors the specific object and not which registrant is the
owner of the object. Well, the registrar acts as a representative of the
registrant. But the model does not allow the fact that more than one registrar
may represent a single registrant in a certain case (e.g. creation of a name
server in a domain of a different registrar). On the other hand, it allows
free sharing of contacts and (existing!) name servers, whether the domains
belong to the same registrant or not. This is quite contradictionary! As I
tried to explain in my earlier e-mails, there is no risk, neither in terms of
stability nor terms of misuse, of allowing the unlimited use of all name
servers. In fact, the world largest ccTLD, .de, works this way (and well).

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

Date: Thu, 9 Aug 2001 11:35:29 -0400
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: WG Discussion Summary with Draft Document Impact
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 6:46 AM -0400 8/9/01, Hollenbeck, Scott wrote:
>existed.  Even in their most current review, the IESG did not provide any
>comments suggesting more generalization.
>
>If anyone wants a more generalized requirements draft, I suggest writing
>another draft.

I agree.  The IESG has already commented once and gave us specific
comments.  This doesn't mean that the IESG won't send back more comments,
but let's not try to draw them out.  (At the same time, we don't want to
try to sneak anything past 'em.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Thu, 9 Aug 2001 10:57:51 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Meeting straw poll
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Towards the end of the meeting at the 51st IETF there was a straw poll
held.  I wanted to allow those not present to voice responses.

First, I asked for a show of hands of implementors.  Not that this is a
decision point, if you are building an implementation and don't mind doing
so, please mention this to the chairs - not that we are going to do
anything with the data.

(I suppose I should set forth a data collection policy ;) - the data is
simply to give an indication of the number of efforts.  We won't be
reselling the contact information. ;))

Second, and this is a decision point.  If members want to delay an answer
until the minutes are available, this is understandable.

1) Are you "loyal" to EPP?
2) Are you "loyal" to XRP?
3) Do you want just one to be defined?  IOW, you'll be dealing with so many
folks, you can't afford to have two dissimilar systems.

I don't want to know if EPP is better or worse than XRP.  I just want to
gauge what the group needs to settle upon.

BTW, the largest bloc of hands was for #3 during the meeting.

This poll is not intended to kill off ERP and/or XRP, but rather to
determine if we need to hammer the two into one - as opposed to being
parallel.

And, one more time - if you were at the meeting, you've already been
"counted."  (Not that the IETF votes...)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Thu, 9 Aug 2001 10:57:51 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: XRP to WG status?
Cc: [email-masked]
Sender: [email-masked]

Jaap and I are leaning towards inclusion of XRP documents
(draft-brunner-...) as a WG document.  If you have a strong reason *not* to
include this, please speak up, I believe that the sense of the room was
that the document belongs.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Thu, 9 Aug 2001 10:57:48 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Meeting slide sets & notes
Cc: [email-masked]
Sender: [email-masked]

For those who have presented, I would appreciate your sending a set of
slides to the chairs ([email-masked],[email-masked]) for inclusion in the
minutes.  (Cathy - if you don't mind sending the notes you spoke from,
please do.)

Also, if you have fairly full notes of the meeting, please send them.
There will be a round of minutes to the list for partial edits before we
send it off to be part of the permanent record.

PS - thanks scott - I found yours

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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]'" <[email-masked]>
Subject: RE: WG Discussion Summary with Draft Document Impact 
Date: Thu, 9 Aug 2001 06:46:43 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Thursday, August 09, 2001 5:04 AM
>To: [email-masked]'
>Cc: Hollenbeck, Scott; [email-masked]
>Subject: Re: WG Discussion Summary with Draft Document Impact 
>
>
>
>I've sent out a summary of nits in the requirements draft, as I'd really
like
>to see it a "generic" and not "generic domain name" requirements draft, and
>there are a few minor errors. I'll work with Scott on this off-list.

As I said at the meeting yesterday, the current requirements draft is true
to the original stated need for producing the document as described by
members of the IAB and IESG that I conferred with long before provreg
existed.  Even in their most current review, the IESG did not provide any
comments suggesting more generalization.

If anyone wants a more generalized requirements draft, I suggest writing
another draft.

<Scott/>

Date: Thu, 9 Aug 2001 11:17:02 +0100
To: Klaus Malorny <[email-masked]>, Sheer El-Showk <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: host transfers
Cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Klaus:

I just have a couple of questions:

1) Much of your suggestion seems to be related to registrars being 
able to refer to name server objects created by other registrars. 
Can't this just as easily be accomplished under EPP's existing model, 
in which name server objects are automatically sponsored by the 
sponsor of their parent domain?  In other words, if name servers can 
always be used by other registrars, why does it matter where the 
sponsorship lies?

2) As far as I can tell from your examples, the only circumstance in 
which it becomes important for a non-sponsoring registrar to be able 
to create a new name server within a domain is a situation like this:

>situation #3: R2 has an own object for ns3.A.com, R1 not
>
>
>domain       A.com, N1, N2 (R1)
>name server  N1: ns1.A.com, 1.1.1.1 (R1)
>name server  N2: ns2.A.com, 2.2.2.2 (R1)
>
>domain       B.com, N4, N5 (R2)
>name server  N4: ns1.B.com, 4.4.4.4 (R2)
>name server  N5: ns3.A.com (R2)

Presumably this is because the registrant now likes R2 more than R1. 
Assuming transfers work well, why can't they simply transfer A.com to 
R2 and then perform the action?  What is the value in a single 
registrant being able to manage domains (and objects, such as name 
servers, within those domains) across multiple registrars?  This is 
not clear to me, and seems to be a fundamental premise of your 
argument.

3) In the example above, how does the owner of A.com prevent the 
creation of ns3.A.com by R2 if they *don't want* anyone else to use 
that name server?

Jordyn

Date: Thu, 09 Aug 2001 11:17:24 +0200
From: Klaus Malorny <[email-masked]>
To: Sheer El-Showk <[email-masked]>
CC: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

Sheer El-Showk wrote:
> 
> > [...]
> 
> While I can't disagree with you on the horrors involved in Registrar
> tracking of nameserver/domain relations, in a well designed and
> self-consistant system the registrar has a full on-site database that
> mirrors registry database operations and maintains consistency relatively
> easily by this virtue alone (all operations are performed on the
> regsitrar database and passed through to the registry).  I'm not speaking
> abstractly -- I've been there ... and I did say well designed system; of
> course tracking the rules is not easy and maintaining consistency with
> the registry on failed commands is no fun.  The only real issue is
> sudden, silent acquisition of nameservers through a transfer and that's
> what the poll mechanism is for.

You are right regarding the consistency. But we often have a situation like
this:

Registrant R goes to registrar A and registers a.com with ns1.a.com and
ns2.a.com. Some time later. Now, registrar B has a good offer, and R wants to
register a domain with him, lets say b.com with ns.b.com and ns3.a.com.
"Sorry, we can't do that, you can't use ns3.a.com" - "Why, a.com is my
domain?" ... and so on...

So many things may be logical from a registry's view, but when it comes down
to the registrant, it may look quite different.

> 
> > [...]
> >
> > The model I have in mind is the following:
> >
> >  - anyone can register any name server, and multiple name server objects
> >    may exist for a single "real" name server (similar to a person who
> >    can have multiple contacts with exactly the same data).
> >
> 
> Then what happens in the following situation:
> 
> registrar A registers ns1.A.com and uses it for A.com
> registrar B registers ns1.A.com and uses it for B.com
> 
> then registrar B renames ns1.A.com to ns1.B.com -- which nameserver does
> this affect.  Both?  Only it's "view" of ns1.A.com?  Is your proposal a
> seperate nameserver "namespace" for each registrar with the authoritative
> glue records only emerging from the "namespace" owning the appropriate
> parent domain (as per your comment below).
> 
> This seems like hidden behaviour to me which is something I'm
> uncomfortable with (never mind that the domain registration world is
> already full of such hidden behaviour).  I think you're thinking of a
> nameserver as only an IP address alias ... its more than that ... its a
> database entity (not tied to its name) that domains can form relations
> with independent of IP address or name changes -- this behaviour is very
> important for large ISPs who may host many domains on a single machine
> which can be renamed or move to a new subnet without changing its domain
> relations.
> 

Like with contacts, a registrar may not change an object that is sponsored by
another one. He may use the ns object of the other registrar, but need not.
Also, he could create another object for this name server. My modelrequires,
of course, that the registry objects for name servers are not identified by
the domain name of the name server, but by a handle, or, in EPP-speak, by a
ROID. So, answering your question:

A.com uses ns1.A.com
B.com uses ns1.B.com

The terminology "alias" you use is a good way to describe the function of the
name server object in the registry's repository, but it is not an alias for
the IP addresses of the name server, instead, for the name server as a whole.
Changing the object changes all domains associated with it, but not the name
server per se.

> I'm not sure if I misrepresented you in trying to understand how you would
> allow multiple represtations of a single nameserver.  Please correct me if
> I'm in error.  As I understand your system now however, I think it may
> make registrar's lives easier by providing them by their own stomping
> ground namespace within the registry but it plays havok on generating
> viable zones in a predictable way.

I wouldn't call this namespace. A registrar would be free to use a different
registrar's ns object, create a single object for his own purpose or even a
dozen. It's the purpose of the registrar to do a suitable housekeeping.
Nevertheless, I don't see a havoc. To the contrary, I propose to rely more on
the DNS itself for the resolution of name server IP addresses by limiting the
generation of glue records. As I mentioned earlier, the proposed model acts
similar to the current model if this deals with name servers for which it is
not authoritive. So if you see a havoc here, do you also see a havoc there?

Maybe the following example explains a bit:

Situation:
----------

Two registrars: R1, R2

R1:
  A.com, using ns1.A.com, ns2.A.com
    ns1.A.com, 1.1.1.1
    ns2.A.com, 2.2.2.2
    ns3.A.com, 3.3.3.3
R2:
  B.com, using ns1.B.com, ns3.A.com
    ns1.B.com, 4.4.4.4

current model:
--------------

registry objects:

domain        A.com, ns1.A.com, ns2.A.com (R1)
name server   ns1.A.com, 1.1.1.1 (R1)
name server   ns2.A.com, 2.2.2.2 (R1)
name server   ns3.A.com, 3.3.3.3 (R1)

domain        B.com, ns1.B.com, ns3.A.com (R2)
name server   ns1.B.com, 4.4.4.4 (R2)

zone file:

A.com.       NS         ns1.A.com.
A.com.       NS         ns2.A.com.
ns1.A.com.   A          1.1.1.1
ns2.A.com.   A          2.2.2.2
ns3.A.com.   A          3.3.3.3
B.com.       NS         ns1.B.com.
B.com.       NS         ns3.A.com.
ns1.B.com.   A          4.4.4.4

Please correct me if this is incorrect.

my model:
---------

situation #1: R2 shares ns3.A.com with R1

registry objects:

domain       A.com, N1, N2 (R1)
name server  N1: ns1.A.com, 1.1.1.1 (R1)
name server  N2: ns2.A.com, 2.2.2.2 (R1)
name server  N3: ns3.A.com, 3.3.3.3 (R1)

domain       B.com, N4, N3 (R2)
name server  N4: ns1.B.com, 4.4.4.4 (R2)

zone file:

A.com.       NS         ns1.A.com.
A.com.       NS         ns2.A.com.
ns1.A.com.   A          1.1.1.1
ns2.A.com.   A          2.2.2.2
B.com.       NS         ns1.B.com.
B.com.       NS         ns3.A.com.
ns1.B.com.   A          4.4.4.4

note that no A record exists for ns3.A.com.

situation #2: R2 has an own object for ns3.A.com

domain       A.com, N1, N2 (R1)
name server  N1: ns1.A.com, 1.1.1.1 (R1)
name server  N2: ns2.A.com, 2.2.2.2 (R1)
name server  N3: ns3.A.com, 3.3.3.3 (R1)

domain       B.com, N4, N5 (R2)
name server  N4: ns1.B.com, 4.4.4.4 (R2)
name server  N5: ns3.A.com (R2)

zone file:

exactly the same as above, even if R2 specifies an (arbitrary) IP address for
N5.

situation #3: R2 has an own object for ns3.A.com, R1 not

domain       A.com, N1, N2 (R1)
name server  N1: ns1.A.com, 1.1.1.1 (R1)
name server  N2: ns2.A.com, 2.2.2.2 (R1)

domain       B.com, N4, N5 (R2)
name server  N4: ns1.B.com, 4.4.4.4 (R2)
name server  N5: ns3.A.com (R2)

zone file:

exactly the same as above, even if R2 specifies an (arbitrary) IP address for
N5.

If registrant of A changes the IP address of ns3.A.com in the DNS(!!), B will
continue to work. R2 can easily migrate to a different name server just by
changing N5. All other domains also using N5 would migrate, too.

You may say: "It could be that ns3.A.com does not exist". That's quite true.
But the current model does not guarantee this neither. Even if you define an A
record for ns3.A.com, the IP address may be wrong or the machine behind this
may not be configured correctly.

change:
name server:  N5: ns2.B.com, 5.5.5.5 (R2)

A.com.       NS         ns1.A.com.
A.com.       NS         ns2.A.com.
ns1.A.com.   A          1.1.1.1
ns2.A.com.   A          2.2.2.2
B.com.       NS         ns1.B.com.
B.com.       NS         ns2.B.com.
ns1.B.com.   A          4.4.4.4
ns2.B.com.   A          5.5.5.5

> 
> Regards,
> Sheer

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

To: "[email-masked]'" <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: WG Discussion Summary with Draft Document Impact 
Date: Thu, 09 Aug 2001 05:04:17 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> For the benefit of those of you who weren't able to attend today's WG
> session at IETF-51:

We'd about 75 attendees present, there was mbone coverage (Hi Mom!), and
I made the 2nd WG presentation on the set of three non-schema extensions
to EPP we call XRP, viz:
	1. transport mapping for BEEP [rfc3080], which has a transport
	   mapping for TCP [rfc3081], with authentication, asynchronity,
	   and 256 message- and user-profiled channels per tcp connection, 
and
	2. addition of <push>, which allows registries to initiate, and
	   requires registrars to listen (or indicate that they won't),
and (not presented at IETF-50)
	3. container extension of the object model, adding inheritance
	   and nesting, allowing "patterns" for common cases and making
	   bulk ops trivial.

> There were a few discussions that will have an impact on the current draft
> EPP documents:
> 
> By a very slim majority, folks in the room expressed a preference to defer
> protocol design to address data collection policy requirement 8.4-[1] rather
> than allowing it to be a "must have" prior to document progression.  Some
> others in the room expressed discomfort with this option, but the WGs
> ability to design features to address this requirement as-written remain.

This is the fourth extension I've proposed, an extension to add language to
express the data collection policies of data collectors using epp. For the
first time in IETF history discussion of the subject didn't slip down the
twin illdefined ratholes of "security" and "privacy", to the credit of the
contributors present.

>                     ... Eric will offer up suggested text to be added to the
> EPP draft(s).

The first will be draft-ietf-provreg-epp-beep-00.txt, assuming that the WG
wants to accept the document. I'll send a pre-ID version of the draft to
the list by the 10th.

The second is a series of changes to draft-ietf-provreg-epp-04. I'll send a
suggested delta to Scott by the 10th, or earlier as Scott desires.

The third will be draft-ietf-provreg-epp-containers-00.txt, again assuming
that the WG wants to accept the document. I'll send a pre-ID version of the
draft to the list by the 10th.        

The fourth is rather more work, as Scott noted, it is time to design or to
defer. I hope that we chose to design. Provreg is specifying a protocol in
the "onward transport" area of personal and technical data collection.

In another industry consortia I worked in last year (CPExchange) the problem
of logging the data collection policy in force at each node in a transit path
has been solved, which included noting the controlling jurisdiction. In that
work we used the P3P vocabulary then available. This isn't intractible, and
pretending governments don't exist may have reached its end-of-shelf-life in
this technical area.

I'll send a draft skeleton and a series of memos on bits that could/should
go into the fully developed draft, starting this weekend, with the goal of
getting a candidate draft ready for the I-D editor as an individual or as a
WG draft by the end of August. Mark Nottingham, who is also on the W3C P3P
Specification Working Group along with me, and co-chairs the Apps WEBI WG, 
has graciously offered to help.

> The requirements draft will be updated soon to address the IESG's comments.
> I'll then begin working on EPP draft updates to deal with these changes and
> others that may arise out of today's list discussions.

I've sent out a summary of nits in the requirements draft, as I'd really like
to see it a "generic" and not "generic domain name" requirements draft, and
there are a few minor errors. I'll work with Scott on this off-list.

> If I've misstated anything, please feel free to clarify.

Ditto.

Eric

Date: Wed, 8 Aug 2001 23:15:20 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: Klaus Malorny <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

> As you asked, Scott ;-)
>
> You know, I have a somewhat diametric opinion to that. Tieing name servers to
> domains may be not too difficult for the registry itself, but it generates a
> lot of problems at the registrar level and beneath, esp. if a registrant
> registers his domains with multiple registrars/resellers and starts moving
> them around. As someone who develops software in this context the whole thing
> of linking name servers to domains, additionally depending on the name
> servers' TLDs, is an artificial obstacle, good for nothing, a graveyard for
> LOCs ;-) and is repeatedly a cause to reject registrations/changes. Therefore
> I prefer a system without this tieing.

While I can't disagree with you on the horrors involved in Registrar
tracking of nameserver/domain relations, in a well designed and
self-consistant system the registrar has a full on-site database that
mirrors registry database operations and maintains consistency relatively
easily by this virtue alone (all operations are performed on the
regsitrar database and passed through to the registry).  I'm not speaking
abstractly -- I've been there ... and I did say well designed system; of
course tracking the rules is not easy and maintaining consistency with
the registry on failed commands is no fun.  The only real issue is
sudden, silent acquisition of nameservers through a transfer and that's
what the poll mechanism is for.

>
> In an earlier discussion, you mentioned a way to get faked IP addresses for
> e.g. www.microsoft.com into the system. But this was caused by the fact that
> your current model always generates glue records for a name server that is
> contained in the registry's TLD(s). If the glue record generation is more
> stringent, this problem can be avoided.
>
> The model I have in mind is the following:
>
>  - anyone can register any name server, and multiple name server objects
>    may exist for a single "real" name server (similar to a person who
>    can have multiple contacts with exactly the same data).
>

Then what happens in the following situation:

registrar A registers ns1.A.com and uses it for A.com
registrar B registers ns1.A.com and uses it for B.com

then registrar B renames ns1.A.com to ns1.B.com -- which nameserver does
this affect.  Both?  Only it's "view" of ns1.A.com?  Is your proposal a
seperate nameserver "namespace" for each registrar with the authoritative
glue records only emerging from the "namespace" owning the appropriate
parent domain (as per your comment below).

This seems like hidden behaviour to me which is something I'm
uncomfortable with (never mind that the domain registration world is
already full of such hidden behaviour).  I think you're thinking of a
nameserver as only an IP address alias ... its more than that ... its a
database entity (not tied to its name) that domains can form relations
with independent of IP address or name changes -- this behaviour is very
important for large ISPs who may host many domains on a single machine
which can be renamed or move to a new subnet without changing its domain
relations.

>  - IP addresses can be attached to any name server, but there is no
>    guarantee that these are used (see below)
>

See above ... this seems like you're just misguiding the user by allowing
them to enter data you ignore.

>  - especially, there is no difference between name servers that belong
>    to the registry's TLD(s) or not.
>
>  - in the zone file, a glue record (A/AAAA/A6 record) is generated
>    iff the name server lies in a domain which references this name server
>    (i.e. the domain specifies it in its NS record).
>

I'm not sure if I misrepresented you in trying to understand how you would
allow multiple represtations of a single nameserver.  Please correct me if
I'm in error.  As I understand your system now however, I think it may
make registrar's lives easier by providing them by their own stomping
ground namespace within the registry but it plays havok on generating
viable zones in a predictable way.

Regards,
Sheer

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: WG Discussion Summary with Draft Document Impact
Date: Wed, 8 Aug 2001 17:10:25 -0400 
Sender: [email-masked]

For the benefit of those of you who weren't able to attend today's WG
session at IETF-51:

There were a few discussions that will have an impact on the current draft
EPP documents:

By a very slim majority, folks in the room expressed a preference to defer
protocol design to address data collection policy requirement 8.4-[1] rather
than allowing it to be a "must have" prior to document progression.  Some
others in the room expressed discomfort with this option, but the WGs
ability to design features to address this requirement as-written remain.

Eric's XRP presentation and subsequent discussion led to a reopening of the
message polling vs. message pushing discussion.  Folks in the room seemed to
support the idea of having both mechanisms in the base protocol, with the
client having the ability to select a delivery mechanism from among those
offered by the server.  Eric will offer up suggested text to be added to the
EPP draft(s).

The requirements draft will be updated soon to address the IESG's comments.
I'll then begin working on EPP draft updates to deal with these changes and
others that may arise out of today's list discussions.

If I've misstated anything, please feel free to clarify.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: host transfers 
Date: Wed, 8 Aug 2001 16:41:41 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Wednesday, August 08, 2001 6:47 AM
>To: Jordyn A. Buchanan
>Cc: Sheer El-Showk; [email-masked]; [email-masked]
>Subject: Re: host transfers 
>
>
>Scott's proposed IM'ing as an OOB downstream notice mechanism. It isn't my
>own first choice.

If "IM'ing" means Interpersonal Messaging, I am at a complete loss to find
any reference to any proposal of mine that even comes close to what you've
written above.  However, I assume that we're past the poll vs. push issue
given the discussion that took place during today's WG session.

I'll summarize for folks in another message.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jarle Greipsland'" <[email-masked]>, [email-masked]
Subject: RE: EPP reliance on registrar sponsorship model
Date: Wed, 8 Aug 2001 16:35:36 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Jarle Greipsland [mailto:[email-masked]]
>Sent: Wednesday, August 08, 2001 7:16 AM
>To: [email-masked]
>Subject: EPP reliance on registrar sponsorship model
>
>
>I think we would be better served by having the registrar sponsorship
>concept replaced by a more general authorization mechanism.
>Registries that wish to work within the registrar sponsorship model
>can then do so by (explicitly or implicitly) authorizing the "current
>registrar" to make any changes to a given object, including the right
>to reject or accept a transfer.  Registries that wish to operate
>within another model, e.g. the registry will register digital
>certificates for individuals or organizations, and attach attributes
>to objects authorizing certificate holders to perform a given set of
>operations on the object (provided the request is properly signed by
>the holder) no matter what registrar forwards the request to the
>registry, can then do so.

The EPP drafts were first written without object-specific authorization
information.  It was added in an attempt to address one person's comments.
It was subsequently removed as a result of larger WG discussion to simplify
operations.

I think there is a larger data consistency issue that is introduced if the
client sponsorship model is abandoned.  As changes are made across clients,
all of the previously involved clients will probably like to know about
changes made through other clients so that whatever locally-copied data they
maintain remains consistent with that of the server.  It's a many-to-one
relationship.  With the client sponsorship model, there's a one-to-one
relationship that is _far_ easier to manage.

<Scott/>

To: "Jordyn A. Buchanan" <[email-masked]>
cc: Jarle Greipsland <[email-masked]>, [email-masked], [email-masked]
Subject: Re: EPP reliance on registrar sponsorship model 
Date: Wed, 08 Aug 2001 09:33:05 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ditto, and ditto.

> Glad to have your comments.  Your concerns reflect others that 
> several folks from the ccTLD community have raised, and I feel like 
> we need to do a better job addressing them because so many ccTLD 
> folks have similar reactions to the existing drafts.  (For that 
> matter, we've got similar problems with non-DNS registries such as 
> the RIRs.)

I know we are getting ARIN and RIPE input as of today, so the RIR & LIR
lacuna is being fixed.

> It's true that the existing documents rely on a registrar sponsorship 
> model.  I've heard the following explanations of why reseller/broker 
> approaches are different from the registrar model:
...
> EPP drafts don't explicilty allow for this [sponsor scoped commands]
> at present, but that 
> wouldn't be very hard to fix (and I certainly wouldn't have any 
> problem with it).

Ditto.

> Jarle makes the specific suggestion of allow authorization of each 
> command by providing a password, digital signature, etc.  This is 
> potentially a helpful suggestion, and not that long ago, Scott's 
> drafts included a requirement that some sort of authentication be 
> made for each write command.  There's no fundamental reason that this 
> can't be done, but the suggestion makes me wonder whether there are 
> any registries using a policy like this today?  (In other words, do 
> you allow your resellers to make changes to objects in your registry 
> by providing some sort of authentication that is known to the 
> registrant?)  It might be helpful to see how this works in the real 
> world before we try to implement it in the protocol.

We are going to try this, AFAIK. It has an effect of vastly simplifying
the transfer set of messages.

> Jarle also suggests:
> 
> >A more general authorization model will also make it possible to
> >restrict the referencing of registry objects.  This can be useful in
> >situations where for instance an ISP is working hard to decommision an
> >old name server, and don't want referenced in any new domain name
> >registrations.  If the registry supports a notion of "reference
> >approvals", the ISP can put an attribute on the name server object
> >that rejects any new references.

We think we've got a nice mechanism to meet this in containers, and their
templates. I'll go over this in more detail if time allows, but I'm better
at writing than speaking.

> It seems like we could accomplish this through the use of a status 
> that disallows new associations.  I think this is a separate issue, 
> but it may be a useful feature to add nonetheless.

It is.

> Jordyn

Eric

To: "Jordyn A. Buchanan" <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, Sheer El-Showk <[email-masked]>, [email-masked], [email-masked]
Subject: Re: host transfers 
Date: Wed, 08 Aug 2001 09:19:10 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>At 5:41 AM -0400 8/8/01, Hollenbeck, Scott wrote (quoting me):
>>  >Does EPP need a registry-to-registry communication mechanism?
>>>If not, does a registry-to-registry communication mechanism need to
>>>exist separate from EPP?
>>
>>As things stand right now, there's nothing that prevents a server from
>>switching into client mode to communicate with another server.

True, but to communicate with a registrar would require that the registrar
also cross dress.

>Indeed.  Eric's suggestion that we have peer-to-peer communications 
>mechanisms allows for (in my mind at least) an even more 
>straightforward relationship between registries using EPP, although I 
>tend to think the difference is a pretty minor one.

Yup, no role-reversal ballet, and entities-other-than-registrars could
include escrow agents, as well as registries of the same, or different
types, e.g., xLDop -> yLTop, where x > y, and y >= g (aka "0").

>Of course, it's not as simple as just saying 'let registries talk 
>using EPP'.

To be sure.

>         ... As currently designed, EPP doesn't provide a mechanism 
>to authenticate against an object without initiating a transfer. 
>Similarly, although the <info> command does provide the needed 
>authentication information, registries may not find it desirable to 
>make all of the data contained within the <info> response available 
>to every other registry.  Similarly, we've discussed in the past the 
>need for registries to communicate changes in the names of registered 
>name servers to other registries.  EPP doesn't provide a mechanism 
>even vaguely like this at present.

Good points.

>I don't think that a more fundamental question has been addressed in 
>the discussions thus far:  is EPP the right way for registry-registry 
>communications?  I haven't thought about it enough to come to a firm 
>conclusion, but my current opinion is that the answer is 'no'.  EPP 
>is, and should continue to be, a provisioning protocol, not a 
>nameserver update announcement protocol or contact object 
>authentication protocol.  Registries need these later types of 
>functions from other registries, and I think that they look 
>differently enough that it will be difficult to 'fix' EPP to the 
>extent that it performs all of these functions well.

Lets answer the "why no <push>" question, preferably in the affirmative,
then consider the scope of to whom registries initiate the transfer of
state to, and which state is transferred.

Oh, and lets make sure we're as generic as we can sensibly be too, as
the addr reg people haven't weighed in previously.

>Jordyn

Date: Wed, 8 Aug 2001 09:14:53 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: host transfers
Sender: [email-masked]

> I still think it a VERY bad idea to allow transfer of a host like
> ns1.example.com separate from a transfer of example.com, but there may be
> some merit to allowing transfer of ns1.example.foo within a registry not
> authoritative for .foo.

Scott I am completely in agreement with you as regards transfers of native
TLD nameservers.  To allows ns1.example.com to be transfered without
example.com will break any reasonably authorization systems within the
transfering registrars (since a registrar will likeley want limit
nameserver modifications to the owner of the parent domain just like
registries do) and give two different entities (the two different
registrars) control over different elements of a domain.  My comment was
not directed towards these nameservers, but rather towards non-TLD
nameservers which are more like domains (in that they are registered on a
first-come-first-serve basis and access to them is controlled only by the
registrant).  I think in the heated argument about associated host
transfers (subordinate nameservers of a domain) a while back people
forgot that there are nameservers without any associated domains and
these need to be transferable as well.

>
> Anyone else?  It's been a while since this topic was originally discussed on
> the list, so maybe people have had time to think about things for a while.
>

I certainly don't think we should reverse the requirement and limitation
that in-TLD hosts are only transfered with their parent domain.

Regards,
Sheer

Date: Wed, 08 Aug 2001 15:17:20 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "'Sheer El-Showk'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

"Hollenbeck, Scott" wrote:

> I still think it a VERY bad idea to allow transfer of a host like
> ns1.example.com separate from a transfer of example.com, but there may be
> some merit to allowing transfer of ns1.example.foo within a registry not
> authoritative for .foo.
> 
> Anyone else?  It's been a while since this topic was originally discussed on
> the list, so maybe people have had time to think about things for a while.
> 
> <Scott/>

As you asked, Scott ;-)

You know, I have a somewhat diametric opinion to that. Tieing name servers to
domains may be not too difficult for the registry itself, but it generates a
lot of problems at the registrar level and beneath, esp. if a registrant
registers his domains with multiple registrars/resellers and starts moving
them around. As someone who develops software in this context the whole thing
of linking name servers to domains, additionally depending on the name
servers' TLDs, is an artificial obstacle, good for nothing, a graveyard for
LOCs ;-) and is repeatedly a cause to reject registrations/changes. Therefore
I prefer a system without this tieing.

In an earlier discussion, you mentioned a way to get faked IP addresses for
e.g. www.microsoft.com into the system. But this was caused by the fact that
your current model always generates glue records for a name server that is
contained in the registry's TLD(s). If the glue record generation is more
stringent, this problem can be avoided.

The model I have in mind is the following:

 - anyone can register any name server, and multiple name server objects
   may exist for a single "real" name server (similar to a person who
   can have multiple contacts with exactly the same data).

 - IP addresses can be attached to any name server, but there is no
   guarantee that these are used (see below)

 - especially, there is no difference between name servers that belong
   to the registry's TLD(s) or not.

 - in the zone file, a glue record (A/AAAA/A6 record) is generated 
   iff the name server lies in a domain which references this name server
   (i.e. the domain specifies it in its NS record).

It is simple and works*. In fact, this model treats nearly all name servers as
the current model handles "foreign" name servers (those that don't belong to
the registry's TLDs). Transfers of name servers are possible, but it is
technically not required, as the other one just can create a new object. Quite
easy for anyone - registries, registrars, resellers, registrants.

Well, someone may argue that the integrity is not as strong as in the current
model. Independently whether this true or not, I honestly think that the part
the registry contributes to the integrity of a domain is quite marginal (as
long as the registry does not permanently probe the associated name servers
for correct configuration) so that doesn't matter.

Klaus Malorny

* the registry for .de works this way, except that there are no independent
name server objects (the name server data is just a part of the domain data).

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

Date: Wed, 8 Aug 2001 14:03:15 +0100
To: Jarle Greipsland <[email-masked]>, [email-masked]
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: EPP reliance on registrar sponsorship model
Sender: [email-masked]

Hi Jarle:

Glad to have your comments.  Your concerns reflect others that 
several folks from the ccTLD community have raised, and I feel like 
we need to do a better job addressing them because so many ccTLD 
folks have similar reactions to the existing drafts.  (For that 
matter, we've got similar problems with non-DNS registries such as 
the RIRs.)

It's true that the existing documents rely on a registrar sponsorship 
model.  I've heard the following explanations of why reseller/broker 
approaches are different from the registrar model:

1) Resellers have the right to register objects, but once the domain 
is registered, they're done.  After the initial registration, all 
modifications and other operations must be performed by the registry. 
In this case, I think the solution is to only enable the registration 
of new objects.  Commands other than <create> can be disabled.  The 
EPP drafts don't explicilty allow for this at present, but that 
wouldn't be very hard to fix (and I certainly wouldn't have any 
problem with it).

2) Resellers are just like registrars, but the contractual 
relationship is different (in other words, the registrant is 
contracting with the registry, not with the registrar, but the 
registrar can still maintain the objects on behalf of the 
registrant).  If this is the case, I think the existing protocol 
works fine.  The difference in this case is not a technical one.

No one has described (that I can remember) a model other than these 
that is in use today.  It's likely that they exist, but I think we 
need to have a better understanding of what they are in order to 
accommodate them.

Jarle makes the specific suggestion of allow authorization of each 
command by providing a password, digital signature, etc.  This is 
potentially a helpful suggestion, and not that long ago, Scott's 
drafts included a requirement that some sort of authentication be 
made for each write command.  There's no fundamental reason that this 
can't be done, but the suggestion makes me wonder whether there are 
any registries using a policy like this today?  (In other words, do 
you allow your resellers to make changes to objects in your registry 
by providing some sort of authentication that is known to the 
registrant?)  It might be helpful to see how this works in the real 
world before we try to implement it in the protocol.

Jarle also suggests:

>A more general authorization model will also make it possible to
>restrict the referencing of registry objects.  This can be useful in
>situations where for instance an ISP is working hard to decommision an
>old name server, and don't want referenced in any new domain name
>registrations.  If the registry supports a notion of "reference
>approvals", the ISP can put an attribute on the name server object
>that rejects any new references.

It seems like we could accomplish this through the use of a status 
that disallows new associations.  I think this is a separate issue, 
but it may be a useful feature to add nonetheless.

Jordyn

To: [email-masked]
cc: [email-masked]
Subject: technical vs social and address registries (was Re: data collection)
Date: Wed, 08 Aug 2001 08:27:47 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

In my response to Scott on the two changes he proposed, I pointed out that
reducing the scope of data collection policy (preference in Scott's note)
from "data" to "social data" didn't allow data collection policy rules to
apply to technical data, where some data collection practices variation in
fact does occur (see the SIG and NXT vs NO discussions in the dnssec list,
I used a less esoteric example in my earlier note).

I also pointed out that absent a significantly greater degree of difficulty,
there was no compelling reason to make a distinction and limit the scope of
the proposed mechanism (a p3p-esque XML vocab).

An additional difficulty came to mind when discussing the issue of where
persistent state (thick vs thin) is held in the address registry model(s),
and what is "technical data". My thanks to Joao and Melissa for their time.

Address registries perform reverse mappings, so they and name registries
share the "zone vs non-zone" distinction of data use. However, address
registries view other data as technical operational data, unlike name
registries which view all other data as non-technical (e.g., billing) data.

Given this additional information (generic requirement), limiting the data
collection policy announcement mechanism (p3p-esque XML phrases) to a name
registry specific partition of data appears wrong.

Eric

Date: Wed, 8 Aug 2001 12:37:15 +0100
To: Sheer El-Showk <[email-masked]>, <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: problems with info command
Sender: [email-masked]

At 4:43 PM -0400 8/7/01, Sheer El-Showk wrote:
>First, the mandatory inclusion of sub-ordinate hosts, on which there is
>no specified limit for a domain, means that a domain query will be that
>much more expensive of a command.  Each info command will now have to
>determine a second set of relations and return an arbitrarily large
>data set.  From an implementation perspective it seems like a much better
>idea to provide an option (as in the transfer command) specifying which
>kind of nameserver's should be displayed along with the domain -- subordinate
>or delegate.

This isn't a bad idea.

>Second, the ability of non-owning registrars to query each others registry
>objects strikes me as a very serious performance concern.  Registrars can
>now start treating the registry database like a whois database and data
>mining it.  I've heard arguments that this is a good thing since the
>registrars are a controlled community with controlled access, but I don't
>think this is valid.  First, registrars allow resellers automated access
>to their systems and resellers are not a controlled community.  Second, this
>offloads whois work onto the core registry database and attempts to make
>the latter serve as the former.  However, the two systems exist in in very
>different operating environments.  The whois systems have the luxury of lazy
>sychronization, simplistic load-balancing, and are primarily read-only.
>The core registry database, however is very expensive/difficult to
>load-balance and must bear the burden of write and read locking (I'm not
>being database specific -- this is a operational limitation of any kind of
>database serving as a registry canonical store).  Essentially there can be
>at most a few instances of a registry database and it is extremely
>expensive to synchronize them, while it is trivial to replicate whois
>databases.

Technically, there's nothing to prevent a registry from offloading 
info commands into a separate database that is well-optimized for 
that purpose instead of taxing the central read-write database.  A 
bit of added intelligence to your EPP servers to select the 
appropriate database for the appropriate instance, some one-way data 
synchronization, and voila!

I'm not sure what the alternative is to the info command.  As Scott 
mentioned, registry policy will dictate whether or not other 
registrars will be able to use the info command for objects they 
don't sponsor.  Another idea would be for registries to change the 
set of information that is returned by the infor command for 
non-sponsoring registrars.  For example, it might be desirable to 
return the 'delegate' name servers for a domain and its sponsoring 
registrar.  I agree that we don't want this command to become a 
replacement for Whois, but I think it's complicated enough for 
registrars to put together comparable data to Whois output that 
they'll just use Whois instead.

Jordyn

To: [email-masked]
Subject: Requirements and Protocol Issues
Date: Wed, 08 Aug 2001 07:20:36 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Here are my issues:

requirements:
overspecification (domain names), ditto without requirement (client-server),
[abstract],
unnecessary references to closed systems (exclusive) and error or wrong
document [intro],
unclear apparently normative text [general description],
unnecessary UI/HW/SW references [external interface]
lack of push, scale [performance]
duplications [design]
verbiage and unspec and duplication [service]
duplication and an error [other]

This sounds worse than it is, but these are all improvable.

protocol:
beep transport mapping
performance and scale bottleneck in a poll-only state management mechanism,
improved data abstraction
data collection

The first three of these are in the current XRP draft [1], the first two
were in the prior individual submission, and I can submit these as four
EPP extensions drafts, or as a single XRP draft. I'd like these resolved
before the protocol draft progresses.

http://nic-naa.net/draft-brunner-xrp-01.txt

Eric

Date: Wed, 8 Aug 2001 12:21:10 +0100
To: "Hollenbeck, Scott" <[email-masked]>, Sheer El-Showk <[email-masked]>, [email-masked]
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: host transfers
Sender: [email-masked]

At 5:41 AM -0400 8/8/01, Hollenbeck, Scott wrote (quoting me):
>  >Does EPP need a registry-to-registry communication mechanism?
>>If not, does a registry-to-registry communication mechanism need to
>>exist separate from EPP?
>
>As things stand right now, there's nothing that prevents a server from
>switching into client mode to communicate with another server.

Indeed.  Eric's suggestion that we have peer-to-peer communications 
mechanisms allows for (in my mind at least) an even more 
straightforward relationship between registries using EPP, although I 
tend to think the difference is a pretty minor one.

Of course, it's not as simple as just saying 'let registries talk 
using EPP'.  As currently designed, EPP doesn't provide a mechanism 
to authenticate against an object without initiating a transfer. 
Similarly, although the <info> command does provide the needed 
authentication information, registries may not find it desirable to 
make all of the data contained within the <info> response available 
to every other registry.  Similarly, we've discussed in the past the 
need for registries to communicate changes in the names of registered 
name servers to other registries.  EPP doesn't provide a mechanism 
even vaguely like this at present.

I don't think that a more fundamental question has been addressed in 
the discussions thus far:  is EPP the right way for registry-registry 
communications?  I haven't thought about it enough to come to a firm 
conclusion, but my current opinion is that the answer is 'no'.  EPP 
is, and should continue to be, a provisioning protocol, not a 
nameserver update announcement protocol or contact object 
authentication protocol.  Registries need these later types of 
functions from other registries, and I think that they look 
differently enough that it will be difficult to 'fix' EPP to the 
extent that it performs all of these functions well.

Jordyn

Date: Wed, 08 Aug 2001 13:16:25 +0200 (CEST)
To: [email-masked]
Subject: EPP reliance on registrar sponsorship model
From: Jarle Greipsland <[email-masked]>
Sender: [email-masked]

Hi,

first I am sorry for not getting in to the game at an earlier stage.

I have just recently read through the protocol requirements document,
and I found it a good read, and most of its contents to be independent
of whatever registry model a registry follows.  However, the concept
of registrar sponsorships permeates a couple of the chapters,
particularly 3.4.5 Object Transfer.  Searching through the mailing
list archives I found indications that not all registries have a
notion of registrar sponsorships, but that their registrars to a large
degree operates as brokers or resellers.  The requirement ("MUST")
that a registry behave in a specified way towards the registrars,
e.g. the original sponsoring registrar MUST have the opportunity to
reject or accept an object transfer, this, will prove difficult to
implement if the registry does not recognize registrar sponsorships.

To me it seems that the requirements document mostly uses the
registrar sponsorships as an authorization mechanism, i.e. the
registrar is authorized to make changes to whatever objects it
sponsors, while other non-sponsoring registrars have a much more
limited sets of rights with regards to the objects (i.e. typically
only a right to reference the object or initiate a transfer).  This of
course fits well with the current operational models of the existing
gTLDs.

I think we would be better served by having the registrar sponsorship
concept replaced by a more general authorization mechanism.
Registries that wish to work within the registrar sponsorship model
can then do so by (explicitly or implicitly) authorizing the "current
registrar" to make any changes to a given object, including the right
to reject or accept a transfer.  Registries that wish to operate
within another model, e.g. the registry will register digital
certificates for individuals or organizations, and attach attributes
to objects authorizing certificate holders to perform a given set of
operations on the object (provided the request is properly signed by
the holder) no matter what registrar forwards the request to the
registry, can then do so.

A more general authorization model will also make it possible to
restrict the referencing of registry objects.  This can be useful in
situations where for instance an ISP is working hard to decommision an
old name server, and don't want referenced in any new domain name
registrations.  If the registry supports a notion of "reference
approvals", the ISP can put an attribute on the name server object
that rejects any new references.

Thoughts?
					-jarle

To: "Jordyn A. Buchanan" <[email-masked]>
cc: Sheer El-Showk <[email-masked]>, [email-masked], [email-masked]
Subject: Re: host transfers 
Date: Wed, 08 Aug 2001 06:47:25 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> This points to an issue that Scott Hollenbeck and Eric
> Brunner-Williams had words about a few days back.  Since it's come up
> twice in the last week, I'll throw the question(s) out there:
> 
> Does EPP need a registry-to-registry communication mechanism?
> If not, does a registry-to-registry communication mechanism need to
> exist separate from EPP?             

The first technical issue is can a registry initiate an instance of
communication. If so, then in the transfer object use case, the registry
can "push" state to the non-initiating registry, (or to a 3rd-party, as
ICANN gTLD regisry contracts call for a form of 3rd-party archival data
flow, and possibly to a distinct registry).

As a specification issue, and as a working group process and document
issue, we have a document that specifies an asymetric event model, aka
"client-server". Where does this constraint arise?

I hope we can remove the "client-server" bits from the abstract of the
current grrq, and from the tcp mapping doc, which are the only places
I know it exists (corrections welcome), and add a push command. I do have
the text ;-)

Once we answer the question "does EPP need a registry-to-anything"
communication mechanism (and our experience is an unqualified "yes",
where "anything" == registrars, and use case == xfr, as preregproto
participants know, and we put it into our -00 XRP draft), then we can 
sensibly ask "registrars?, escrow-agents?, registries?"

Scott's proposed IM'ing as an OOB downstream notice mechanism. It isn't my
own first choice.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Sheer El-Showk'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: host transfers
Date: Wed, 8 Aug 2001 05:50:12 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Sheer El-Showk [mailto:[email-masked]]
>Sent: Tuesday, August 07, 2001 12:23 PM
>To: [email-masked]
>Subject: host transfers
>
>
>First, hosts MUST be transferable, even if subordinate hosts are implicitly
>transfered with their parent domain.  The reason for this is registered
>nameservers from another TLD.  If I were to register ns1.sheer.ma at
Versign's
>registry through one registrar I need to be able to transfer it to another
>registrar if I want to stop using my original registrar.  Even though no IP
>addresses are kept for the host, it has associated domain relations that
are
>preserved even when the hostname is changed.  Thus the host is an actual
>registry entity, not just a placeholder for an external system (ie its
>relevant because I can change ns1.sheer.ma to ns2.sheer.ma and all domains
>using it should automatically be switched over to the new name).  This
>suggests the need for an authinfo field in the host as well.

I still think it a VERY bad idea to allow transfer of a host like
ns1.example.com separate from a transfer of example.com, but there may be
some merit to allowing transfer of ns1.example.foo within a registry not
authoritative for .foo.

Anyone else?  It's been a while since this topic was originally discussed on
the list, so maybe people have had time to think about things for a while.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jordyn A. Buchanan'" <[email-masked]>, Sheer El-Showk <[email-masked]>, [email-masked]
Subject: RE: host transfers
Date: Wed, 8 Aug 2001 05:41:20 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Jordyn A. Buchanan [mailto:[email-masked]]
>Sent: Tuesday, August 07, 2001 6:58 PM
>To: Sheer El-Showk; [email-masked]
>Subject: Re: host transfers
>
>
>Does EPP need a registry-to-registry communication mechanism?
>If not, does a registry-to-registry communication mechanism need to 
>exist separate from EPP?

As things stand right now, there's nothing that prevents a server from
switching into client mode to communicate with another server.  However,
therein lies a huge assumption that all registries (let's limit this to
domain name registries for now) are running the same registry protocol(s).
Even when we eventually have a standard, I don't think we will ever have all
domain name registries running the same sort of registration systems using
the same protocol(s).  Some registries will be continue to operate using
more manual processes; how are those variances accommodated?

It may be possible to automate some level of cross-registry object
authentication, but this becomes a very slippery slope.  Registries will be
required to keep track of every other registry in which "their" information
is being used so that updates can be distributed directly, or instead some
sort of broadcast or multicast capability has to be developed.
Acknowledgement of distributed updates will be required to ensure
consistency.  Cross-registry synchronization will continue to be difficult,
perhaps more difficult than it is now.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Sheer El-Showk'" <[email-masked]>, [email-masked]
Subject: RE: problems with info command
Date: Wed, 8 Aug 2001 05:20:08 -0400 
Sender: [email-masked]

Sheer,

Both of the points you raised below have been discussed on the list in the
past, though the option you mentioned in your first point is new.  Adding
such options appears to be a good idea.

The second point touches on something that is _not_ currently a required
feature of the protocol.  There are already words in the base spec that say
something like "queries SHOULD be limited to the sponsoring client", and
those words are there because some folks thought that we should let
registries decide how they wish to deal with cross-client info queries.

If folks think we should instead explicitly prohibit cross-client queries
again (as the initial versions of the specs did), please voice your support
for Sheer's suggestion.

<Scott/>

>-----Original Message-----
>From: Sheer El-Showk [mailto:[email-masked]]
>Sent: Tuesday, August 07, 2001 4:43 PM
>To: [email-masked]
>Subject: problems with info command
>
>
>Hi,
>
>I think the current EPP "info" command has several 
>shortcomings that will
>have significant bearing on performance (especially considering it is
>likeley to be the second most popular command after "check").
>
>First, the mandatory inclusion of sub-ordinate hosts, on which there is
>no specified limit for a domain, means that a domain query will be that
>much more expensive of a command.  Each info command will now have to
>determine a second set of relations and return an arbitrarily large
>data set.  From an implementation perspective it seems like a 
>much better
>idea to provide an option (as in the transfer command) specifying which
>kind of nameserver's should be displayed along with the domain 
>-- subordinate
>or delegate.
>
>Second, the ability of non-owning registrars to query each 
>others registry
>objects strikes me as a very serious performance concern.  
>Registrars can
>now start treating the registry database like a whois database and data
>mining it.  I've heard arguments that this is a good thing since the
>registrars are a controlled community with controlled access, 
>but I don't
>think this is valid.  First, registrars allow resellers 
>automated access
>to their systems and resellers are not a controlled community. 
> Second, this
>offloads whois work onto the core registry database and 
>attempts to make
>the latter serve as the former.  However, the two systems 
>exist in in very
>different operating environments.  The whois systems have the 
>luxury of lazy
>sychronization, simplistic load-balancing, and are primarily read-only.
>The core registry database, however is very expensive/difficult to
>load-balance and must bear the burden of write and read 
>locking (I'm not
>being database specific -- this is a operational limitation of 
>any kind of
>database serving as a registry canonical store).  Essentially 
>there can be
>at most a few instances of a registry database and it is extremely
>expensive to synchronize them, while it is trivial to replicate whois
>databases.
>
>regards,
>Sheer
>

Date: Tue, 7 Aug 2001 23:58:12 +0100
To: Sheer El-Showk <[email-masked]>, <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

At 4:39 PM -0400 8/7/01, Sheer El-Showk wrote:
>  > This is a very good point that I had not thought about at all.  This
>>  also raises the issue of authentication at the time of registration
>>  for nameservers outside of the domain, no?  (How do we know that the
>>  registrar putting ns1.example.com into the .foo registry really
>>  controls example.com?)
>
>This issues seems to have been largely unaddressed before since there has
>only been one large operational protocol based registry (that I know of).

There are others.  I'm pretty sure that all of .uk (sort of), .ca, 
.tv, .ws,, and .cc have "protocol based" registration mechanisms.  I 
think there may be others:  .nu, .la spring to mind.  Did Tucows ever 
get .vc up and running with OpenXRS?  I don't think there's been a 
good forum for them to talk about issues like this, however.  There 
are probably related issues that this isn't the proper forum to deal 
with either, for that matter.

>I could, for example register ns1.example.foo at NSI even though in the
>.foo registry someone else owns example.foo.  Other's using
>ns1.example.foo for .com/.net/.org domains find that its already been
>registered by someone else at NSI and just start using it as the
>nameserver for their domains.   Then, the registrar who registered it at
>NSI can just maliciously rename it to ns2.example.foo even though the
>actual nameserver at the original .foo registry was never modified and
>break resolution of all the linked domains.

This is true, and was the issue I was attempting to highlight.

>
>I don't know if anything can be done about this until the ROID system is
>developed more and registries start using it... then perhaps we can use
>entity authorization information (currently used for registrar-registrar
>transfers) to authorize use of an extra-registry entity by querying the
>outside registry.  Just a thought.

This points to an issue that Scott Hollenbeck and Eric 
Brunner-Williams had words about a few days back.  Since it's come up 
twice in the last week, I'll throw the question(s) out there:

Does EPP need a registry-to-registry communication mechanism?
If not, does a registry-to-registry communication mechanism need to 
exist separate from EPP?

Jordyn

Date: Tue, 7 Aug 2001 16:43:19 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: <[email-masked]>
Subject: problems with info command
Sender: [email-masked]

Hi,

I think the current EPP "info" command has several shortcomings that will
have significant bearing on performance (especially considering it is
likeley to be the second most popular command after "check").

First, the mandatory inclusion of sub-ordinate hosts, on which there is
no specified limit for a domain, means that a domain query will be that
much more expensive of a command.  Each info command will now have to
determine a second set of relations and return an arbitrarily large
data set.  From an implementation perspective it seems like a much better
idea to provide an option (as in the transfer command) specifying which
kind of nameserver's should be displayed along with the domain -- subordinate
or delegate.

Second, the ability of non-owning registrars to query each others registry
objects strikes me as a very serious performance concern.  Registrars can
now start treating the registry database like a whois database and data
mining it.  I've heard arguments that this is a good thing since the
registrars are a controlled community with controlled access, but I don't
think this is valid.  First, registrars allow resellers automated access
to their systems and resellers are not a controlled community.  Second, this
offloads whois work onto the core registry database and attempts to make
the latter serve as the former.  However, the two systems exist in in very
different operating environments.  The whois systems have the luxury of lazy
sychronization, simplistic load-balancing, and are primarily read-only.
The core registry database, however is very expensive/difficult to
load-balance and must bear the burden of write and read locking (I'm not
being database specific -- this is a operational limitation of any kind of
database serving as a registry canonical store).  Essentially there can be
at most a few instances of a registry database and it is extremely
expensive to synchronize them, while it is trivial to replicate whois
databases.

regards,
Sheer

Date: Tue, 7 Aug 2001 16:39:41 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
cc: <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

> This is a very good point that I had not thought about at all.  This
> also raises the issue of authentication at the time of registration
> for nameservers outside of the domain, no?  (How do we know that the
> registrar putting ns1.example.com into the .foo registry really
> controls example.com?)

This issues seems to have been largely unaddressed before since there has
only been one large operational protocol based registry (that I know of).

I could, for example register ns1.example.foo at NSI even though in the
.foo registry someone else owns example.foo.  Other's using
ns1.example.foo for .com/.net/.org domains find that its already been
registered by someone else at NSI and just start using it as the
nameserver for their domains.   Then, the registrar who registered it at
NSI can just maliciously rename it to ns2.example.foo even though the
actual nameserver at the original .foo registry was never modified and
break resolution of all the linked domains.

I don't know if anything can be done about this until the ROID system is
developed more and registries start using it... then perhaps we can use
entity authorization information (currently used for registrar-registrar
transfers) to authorize use of an extra-registry entity by querying the
outside registry.  Just a thought.

Sheer

Date: Tue, 7 Aug 2001 19:23:56 +0100
To: Sheer El-Showk <[email-masked]>, <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: host transfers
Sender: [email-masked]

At 12:22 PM -0400 8/7/01, Sheer El-Showk wrote:
>First, hosts MUST be transferable, even if subordinate hosts are implicitly
>transfered with their parent domain.  The reason for this is registered
>nameservers from another TLD.  If I were to register ns1.sheer.ma at Versign's
>registry through one registrar I need to be able to transfer it to another
>registrar if I want to stop using my original registrar.  Even though no IP
>addresses are kept for the host, it has associated domain relations that are
>preserved even when the hostname is changed.  Thus the host is an actual
>registry entity, not just a placeholder for an external system (ie its
>relevant because I can change ns1.sheer.ma to ns2.sheer.ma and all domains
>using it should automatically be switched over to the new name).  This
>suggests the need for an authinfo field in the host as well.

This is a very good point that I had not thought about at all.  This 
also raises the issue of authentication at the time of registration 
for nameservers outside of the domain, no?  (How do we know that the 
registrar putting ns1.example.com into the .foo registry really 
controls example.com?)

Jordyn

Date: Tue, 7 Aug 2001 12:22:37 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: <[email-masked]>
Subject: host transfers
Sender: [email-masked]

Hi,

This is a first posting after a prolonged absense from the list, so please
forgive me if I'm a little out of touch with recent discussions.  I've
seen several issues in the recent EPP drafts (actually in the EPP in general)
which I'd like to bring up (some may have been partially addressed
before).

I'm not going to be in London but I hope that some of these issues might be
hashed out there if they are deemed relevant enough to get on the agenda.

First, hosts MUST be transferable, even if subordinate hosts are implicitly
transfered with their parent domain.  The reason for this is registered
nameservers from another TLD.  If I were to register ns1.sheer.ma at Versign's
registry through one registrar I need to be able to transfer it to another
registrar if I want to stop using my original registrar.  Even though no IP
addresses are kept for the host, it has associated domain relations that are
preserved even when the hostname is changed.  Thus the host is an actual
registry entity, not just a placeholder for an external system (ie its
relevant because I can change ns1.sheer.ma to ns2.sheer.ma and all domains
using it should automatically be switched over to the new name).  This
suggests the need for an authinfo field in the host as well.

I have several other issues regarding the "info" command and the usage of
the client/server transaction identifiers.  I will bring these up in
seperate emails so they can be addressed seperately.

Enjoy London,
Sheer

To: Shane Kerr <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: IETF-51 WhoisFix BoF Announcement 
Date: Wed, 01 Aug 2001 09:47:53 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Shane, Ross, and others,

The annoucement went to several lists, provreg included. It is not in
provreg's scope to discuss whois. I suggest sending comments to me or
Dave, or the ietf-whois list, or even the apps and or ops area open
discussion lists.

Cheers,
Eric

To: [email-masked], [email-masked]
Subject: Re: IETF-51 WhoisFix BoF Announcement 
Date: Wed, 01 Aug 2001 11:17:19 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    I wonder, would it make sense to consider putting together a survey of
    Whois (and similar) servers and clients, to get a feel for what Whois
    really means these days?  It would be nice to know how it is actually
    used, so we don't spend too much time scratching our heads.
    
    If people consider this a good idea, I can go ahead and present a brief
    summary of what I think should be in such a document.

The DNSO is already running such a survey. See
http://www.icann.org/dnso/whois-survey-en-10jun01.htm for details.
    
    This seems totally on-topic to me!  At least, for the Whois BOF.  Should
    we take the ProvReg WG off of the recipient list?
    
Probably, allthough I didn't yet.

	jaap

Date: Wed, 1 Aug 2001 09:55:28 +0200
From: Shane Kerr <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: IETF-51 WhoisFix BoF Announcement
Sender: [email-masked]

On 2001-07-31 14:46:40 -0400, Ross Wm. Rader wrote:
> 
> Correct me if my recollection is wrong, but the last go-round of this
> was severely bogged down by a focus on the protocol specified in RFC
> 954 when in fact the discussion was more suited to the concepts and
> facilities presented in 1580 (starting on page 38). Is it the intent
> to focus on the latter than the former this time around?

Hmm... I wouldn't necessarily have a problem focusing on the *concepts*
behind 1580, but the *details* have mostly changed, I think.  Does
anyone run a mail Whois server these days?  ;)

> While I couldn't agree more that changes are due, it strikes me that
> updating 954 may prove to be next to impossible because of the hidden
> install base...

I wonder, would it make sense to consider putting together a survey of
Whois (and similar) servers and clients, to get a feel for what Whois
really means these days?  It would be nice to know how it is actually
used, so we don't spend too much time scratching our heads.

If people consider this a good idea, I can go ahead and present a brief
summary of what I think should be in such a document.

> Sorry if this is off-topic for this list - I won't be in London to
> speak my piece...

This seems totally on-topic to me!  At least, for the Whois BOF.  Should
we take the ProvReg WG off of the recipient list?

-- 
Shane