Subject: Contact Client ID Namespace Management

From: Robert Burbidge <[email-masked]>
Date: Fri, 19 Apr 2002 11:00:46 +0100

Sources :
draft-ietf-provreg-epp-06.txt
draft-ietf-provreg-epp-contact-04.txt

According to the contacts specification, page 17:

  ...  
  A <contact:id> element that contains the desired server-unique
  identifier for the contact to be created.
  ...

<contact:id> values are server(registry)-unique but
client(registrar)-created. It would seem reasonable to partition the
possible values of <contact:id> among the various contacts so as to reduce
the possibility of name collisions on creation of new contacts. This would
be a matter of server policy. One possible scheme would be to allocate a 4
character prefix to each registrar, and allow the registrar to allocate
their own 12-character suffix. Doing so would allow each registrar to manage
a subset of the complete namespace without too much overhead.

If we adopt this scheme, or a similar one, there's nothing in EPP itself to
prevent one client using identifiers from another client's subset of the
contact:id values. Would it be reasonable for a server to maintain allowed
prefixes each client, and validate incoming <contact:create> commands to
ensure that <contact:id> fields match allowed values? Again this would be a
matter of service policy?

Any thoughts on the above would be appreciated.

Rob Burbidge

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Apr 2002 09:48:20 -0400

> -----Original Message-----
> From: Robert Burbidge [mailto:[email-masked]]
> Sent: Friday, April 19, 2002 6:01 AM
> To: Ietf-Provreg (E-mail)
> Subject: Contact Client ID Namespace Management
> 
> 
> Sources :

Your suggestion is based on the (possibly false) premises that the IDs
should always be client-created and that the registry-registrar model is the
only one at work.  My thought going in was that the IDs would in fact be
end-user suggested in a manner similar to the way many 'net services (think
ebay, yahoo, etc.) allow individuals to create their own user IDs, and the
client would act as agent in an attempt to create the ID with the server.
Some domain name registrars might be doing it differently, but that doesn't
mean that the protocol should be limited to supporting such a model.

> Any thoughts on the above would be appreciated.

I'd prefer to keep this sort of policy model out of the specs completely.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Contact Client ID Namespace Management
Date: Mon, 22 Apr 2002 09:48:20 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Robert Burbidge [mailto:[email-masked]]
> Sent: Friday, April 19, 2002 6:01 AM
> To: Ietf-Provreg (E-mail)
> Subject: Contact Client ID Namespace Management
> 
> 
> Sources :

Your suggestion is based on the (possibly false) premises that the IDs
should always be client-created and that the registry-registrar model is the
only one at work.  My thought going in was that the IDs would in fact be
end-user suggested in a manner similar to the way many 'net services (think
ebay, yahoo, etc.) allow individuals to create their own user IDs, and the
client would act as agent in an attempt to create the ID with the server.
Some domain name registrars might be doing it differently, but that doesn't
mean that the protocol should be limited to supporting such a model.

> Any thoughts on the above would be appreciated.

I'd prefer to keep this sort of policy model out of the specs completely.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: <postalInfo> element in contact management
Date: Mon, 22 Apr 2002 09:33:41 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Robert Burbidge [mailto:[email-masked]]
> Sent: Friday, April 19, 2002 5:39 AM
> To: Ietf-Provreg (E-mail)
> Subject: <postalInfo> element in contact management
> 
> 
> Source :draft-ietf-provreg-epp-contact-04.txt
> 
> Quote from the <contact:info> command page 11
>   ... 
>   One or two <contact:postalInfo> elements that contain postal address
>   information.  Two elements are provided so that address information
>   can be provided in both internationalized and localized 
> forms.  If an
>   internationalized form is provided, it MUST be listed first and
>   element content MUST be represented in a subset of UTF-8 that can be
>   represented in the 7-bit US-ASCII character set.  If a 
> localized form
>   is provided, element content MAY be represented in 
> unrestricted UTF-8.
>   ...
> 
> If two <contact:postalInfo> elements are provided the above 
> paragraph makes
> it clear which one is the internationalized form and which is 
> the localized
> form. However, if only one <contact:postalInfo> element is 
> supplied, is it
> understood to be internationalized or localized?

That depends on the characters used.  If characters outside the ASCII range
are used, you have something that's localized.  ASCII only ->
internationalized.  This might be more clear if we add an attribute to the
<postalInfo> element; at least it would allow one to decide without having
to examine all of the data directly.

Disclaimer: again, we're still waiting for IESG feedback on the last call.
I can't change anything easily at this point, though I will queue this idea
for discussion with the IESG when they get back to us with comments.

-Scott-

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Contact Client ID Namespace Management
Date: Fri, 19 Apr 2002 11:00:46 +0100
Sender: [email-masked]

Sources :

  ...  

Rob Burbidge

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: <postalInfo> element in contact management
Date: Fri, 19 Apr 2002 10:38:50 +0100
Sender: [email-masked]

Source :draft-ietf-provreg-epp-contact-04.txt

Quote from the <contact:info> command page 11
  ... 
  One or two <contact:postalInfo> elements that contain postal address
  information.  Two elements are provided so that address information
  can be provided in both internationalized and localized forms.  If an
  internationalized form is provided, it MUST be listed first and
  element content MUST be represented in a subset of UTF-8 that can be
  represented in the 7-bit US-ASCII character set.  If a localized form
  is provided, element content MAY be represented in unrestricted UTF-8.
  ...

If two <contact:postalInfo> elements are provided the above paragraph makes
it clear which one is the internationalized form and which is the localized
form. However, if only one <contact:postalInfo> element is supplied, is it
understood to be internationalized or localized?

A similar comment applies to <contact:create>. Our registry database has the
ability to store two postalInfo entries, and distinguishes between
internationalized and localized addresses. If <contact:create> supplies only
one <contact:postalInfo>, where do we put the data?

Thanks for any help you can give; prompt replies to earlier questions (even
idiot ones) has been much appreciated.

Rob Burbidge

From: "Hollenbeck, Scott" <[email-masked]>
To: "Newton, Andrew" <[email-masked]>
Cc: [email-masked]
Subject: RE: XML Digital Signatures for EPP.
Date: Thu, 18 Apr 2002 12:06:17 -0400
Sender: [email-masked]

Andy,

I don't think canonicalization (c14n) is really an issue since it's a just a
process that describes how to produce a consistent representation of a
well-formed instance.  Looking at the spec [1] right now I don't see any
real issues.

On the other hand, you're probably right about trying to provide integrity,
authentication, and non-repudiation services at some other layer.  The XML
DSIG specs allow multiple transforms (such as c14n and perhaps compression)
to be applied prior to signing, but XML signatures add a lot of "wrapper"
that add to bandwidth and processing horsepower requirements.

Just for yuks I worked up an example [2] of a host <create> command
contained with an XML signature wrapper.  Don't try to validate this
signature since all I did was steal data to make the XML parser happy, but
it's illustrative of the overhead required.

-Scott-

[1]
http://www.w3.org/TR/xml-c14n

[2]
(long lines are going to get wrapped; sorry)

<?xml version='1.0'?>
<Signature Id="EPPSig" xmlns="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.w3.org/2000/09/xmldsig#
   xmldsig-core-schema.xsd">
   
  <SignedInfo>
    <CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710">
    </CanonicalizationMethod>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa">
    </SignatureMethod>
    <Reference URI="http://www.w3.org/TR/REC-xml-names/">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1">
      </DigestMethod>
      <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue>
    </Reference>
  </SignedInfo>

<SignatureValue>MC0CFFrVLtRlkMc3Daon4BqqnkhCOlEaAhUAk8pH1iRNK+q1I+sisDTz2TFE
ALE=</SignatureValue>
  
  <KeyInfo>
    <KeyValue>
      <DSAKeyValue>
 
<P>2iY3w062sDB3/DIlLWOeG9+4UpmDZ0dyqRk9dLlNQ6qaXI7tOrjdIhm6n/eOw45AQtuYSp6sp
Ct9cQcNBAj22KvygvfJIIXX9sSQrugfGqifeSvY3VX5Sd1j+z0MSZ/n5jNt88uh2C11SAqX6nrXT
Y/1RwkoWRN23SYhOlaG0hU=</P>
        <Q>9B5ypLY9pMOmtxCeTDHgwdNFeGs=</Q>
 
<G>MuGAlqeB1ax+vyO2+Osubjhl7pHxLu47RIH+/M52DjESA9KMSrwzsYx8yNR2WooByrE0t6fu0
VncK7UK8olO4t7wpv2z4AFQPRVCKFwo0qgn5aKIkICGMlrRy81avb27wGcWothx3iPPMtFXtoDqK
0JItaI9R8zc1msFhM1GKMY=</G>
 
<Y>ctA8YGxrtngg/zKVvqEOefnwmViFztcnPBYPlJsvh6yKI4iDm68fnp4Mi3RrJ6bZAygFrUIQL
xLjV+OJtgJAEto0xAs+Mehuq1DkSFEpP3oDzCTOsrOiS1DwQe4oIb7zVk/9l7aPtJMHW0LVlMdwZ
NFNNJoqMcT2ZfCPrfvYvQ0=</Y>
      </DSAKeyValue>
    </KeyValue>
  </KeyInfo>
  
  <Object>
    <SignatureProperties>
      <SignatureProperty Target="#EPPSig">
        <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
         epp-1.0.xsd">
          <command>
            <create>
              <host:create
               xmlns:host="urn:ietf:params:xml:ns:host-1.0"
               xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
               host-1.0.xsd">
                <host:name>ns1.example.tld</host:name>
                <host:addr ip="v4">192.1.2.3</host:addr>
                <host:addr ip="v4">198.1.2.3</host:addr>
                <host:addr
                 ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
              </host:create>
            </create>
            <clTRID>ABC-12345</clTRID>
          </command>
        </epp>
      </SignatureProperty>
    </SignatureProperties>
  </Object>
</Signature>

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 11:37 AM
> To: Hollenbeck, Scott
> Cc: 'Roger Castillo Cortazar'; [email-masked]
> Subject: RE: XML Digital Signatures for EPP.
> 
> 
> It has been a bit since I looked at this stuff, so forgive if 
> I get any
> of it wrong.  But it is my understanding that XML D-Sig uses XML
> Canonicalization which is DTD based.  This may pose a problem with EPP
> since its schema language is XML Schema.
> 
> I think doing this at the application transport level is a 
> better idea. 
> You also get the advantage of being able to run compression 
> against the
> XML instance before encryption.
> 
> -andy
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Roger Castillo Cortazar'" <[email-masked]>, [email-masked]
Subject: RE: XML Digital Signatures for EPP.
Date: Wed, 17 Apr 2002 17:23:41 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 2:31 PM
> To: [email-masked]
> Subject: XML Digital Signatures for EPP.
> 
> 
> Hi everybody.
> 
> We are working on an implementation of EPP for NIC-MX.
> 
> In our requirements we included a digital signature for all the
> object transform commands.
> 
> This will provide the means to authenticate the sender,
> verify the integrity of the information and to assure
> the non-repudiation of the command.
> 
> There is a lot of work from IETF and W3C on XML Signatures,
> we have some RFC's on signing models, canonical forms, etc.
> There are also a few SDK's for XML digital signatures.
> 
> This seems to be quite interesting and useful, any comments ?
> Is anyone working on something like this ?
> 
> Maybe this could be an interesting extension for EPP.
> What do you think ?

Roger,

I've been thinking about this from the very beginning, but haven't really
wanted to get started until the EPP core documents were finished and the XML
DSIG stuff firmed up a bit.  Now that we're getting close to finishing the
core documents and RFC 3275 has been published I plan on looking at it much
more closely.

One other thought: digital signatures can also be applied via Open PGP or
S/MIME, and this might play into the whole email transport thing that we've
talked about but not yet crafted an I-D for.  Maybe there's two or three
documents to be written around email, including a core spec and one each
describing PGP and S/MIME security wrappers.

-Scott-

Date: Wed, 17 Apr 2002 13:30:44 -0500
To: [email-masked]
From: Roger Castillo Cortazar <[email-masked]>
Subject: XML Digital Signatures for EPP.
Sender: [email-masked]

Hi everybody.

We are working on an implementation of EPP for NIC-MX.

In our requirements we included a digital signature for all the
object transform commands.

This will provide the means to authenticate the sender,
verify the integrity of the information and to assure
the non-repudiation of the command.

There is a lot of work from IETF and W3C on XML Signatures,
we have some RFC's on signing models, canonical forms, etc.
There are also a few SDK's for XML digital signatures.

This seems to be quite interesting and useful, any comments ?
Is anyone working on something like this ?

Maybe this could be an interesting extension for EPP.
What do you think ?

Greetings.

Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx
Top Level Domain .MX

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: <domain:info> command and <host>
Date: Mon, 15 Apr 2002 12:41:47 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Robert Burbidge [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 11:49 AM
> To: Ietf-Provreg (E-mail)
> Subject: <domain:info> command and <host>
> 
> 
> Can someone clarify the <host> return tag on the <domain:info> command? In
> "draft-ietf-provreg-epp-domain-04.txt" page 11, it is stated that <host>
> records contain "the fully qualified names of subordinate host objects
that
> exist under this superordinate domain object".  I can't see the point of
> this or how it can be achieved.
> 
> Given the following hypothetical scenario:
> 
> * The registry is for the ".tld" top level domain
> * A client has successfully created the domain "wibble.tld" along with
valid
> nameservers etc.
> * The client performs a <domain:info> query on "wibble.tld".
> 
> How can the registry return any information at all that relates to
> subordinate objects of "wibble.tld"? Presumably it has delegated
management
> of that domain to the domain's owner via the registrar, and presumably the
> owners DNS system is the only place that holds the definitive subordinate
> object listing. Or have I missed  something?

You've missed something.  The host draft states (section 1.1) that host
objects have a subordinate relationship to a domain object.  So, the
registry knows about all hosts in the repository created as children of
"wibble.tld", such as "ns1.wibble.tld".  The <info> command gives the client
the option to retrieve only subordinate hosts like ns1.wibble.tld, only
delegated hosts (the name servers to which wibble.tld has been delegated),
both delegated and subordinate hosts, or neither.  There is no requirement
for a client to register _all_ of the hosts that might exist in the
wibble.tld zone.

So, if you're asking if folks MUST create hosts objects for all wibble.tld
hosts, the answer is no.  Some server operator may come up with creative
things to do with host objects other than using them as name servers, and if
they get registered they'll be visible via the domain's <info> command.
However, the domain <info> command will not generally know anything about
hosts that exist only in the wibble.tld zone.

-Scott-

Date: Mon, 15 Apr 2002 09:30:52 -0700
To: Rick Wesson <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Decision on containers - status?
Cc: "Ietf-Provreg (E-mail)" <[email-masked]>
Sender: [email-masked]

At 09:15 AM 4/15/2002 -0700, Rick Wesson wrote:
>I'd actually disagree as mainiaing the efficiencies of contains is not
>very a complex task from a registrar point of view -- and since I've
>implemented more registrar back ends than anyone else I'm speaking from
>experence.

Rick,

Personally I think the layer of abstractions that containers offers is 
quite excellent and that the added complexity is not that great.  So I was 
quite surprised at the resistance to it.  However I'd say that the working 
group rough consensus about NOT wanting in required (or, at least, not 
wanting it at the present time) was undeniable.

So I thought that the compromise of making it an option was exactly the 
right choice.

If we are not going to specify the details now, that leaves the requirement 
that we keep the future use in mind and try to make sure we do not 
unintentionally prevent the addition later.

d/

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

Date: Mon, 15 Apr 2002 09:15:52 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Edward Lewis <[email-masked]>, Robert Burbidge <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Re: Decision on containers - status?
Sender: [email-masked]

Dave,

I'd actually disagree as mainiaing the efficiencies of contains is not
very a complex task from a registrar point of view -- and since I've
implemented more registrar back ends than anyone else I'm speaking from
experence.

-rick

On Mon, 15 Apr 2002, Dave Crocker wrote:

> At 10:34 AM 4/15/2002 -0400, Edward Lewis wrote:
> >(dormantly) around.  The third possibility is there in case there are some
> >folks that feel it is good, "but not right now."
> >
> >As far as the PS - it might be that containers are left as an
> >implementation-specific option.
>
> Containers offers the benefit of freedom.  It decouples the details of
> interacting with the registrar's customer from the details of interacting
> with the registry on behalf of that customer.
>
> Without containers, the two are tied together.  For many registrar
> environments, this is not a problem.  For others -- particularly
> larger-scale ones -- the limitation requires many more registrary/registry
> interactions and more complicated bookkeeping.
>
> And bookkeeping is the word.  I don't know enough about bookkeeping to know
> the standard term, but I know that this sort of decoupling is quite common
> for accounting systems that have any sort of scale.
>
> So, folks, yes it is less work now.  And clearly many registrars will not
> reach the size that needs containers.  Others will grow into the
> need.  Will, not might.
>
> That says that containers needs to be an option.  Specification of options
> often can be deferred.  And given the knowledge about them, now, the
> requirement is to make sure that the current specification does not make
> adding containers difficult.
>
> d/
>
>
> ----------
> Dave Crocker  <mailto:[email-masked]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.850.1850
>

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: <domain:info> command and <host>
Date: Mon, 15 Apr 2002 16:48:42 +0100
Sender: [email-masked]

Can someone clarify the <host> return tag on the <domain:info> command? In
"draft-ietf-provreg-epp-domain-04.txt" page 11, it is stated that <host>
records contain "the fully qualified names of subordinate host objects that
exist under this superordinate domain object".  I can't see the point of
this or how it can be achieved.

Given the following hypothetical scenario:

* The registry is for the ".tld" top level domain
* A client has successfully created the domain "wibble.tld" along with valid
nameservers etc.
* The client performs a <domain:info> query on "wibble.tld".

How can the registry return any information at all that relates to
subordinate objects of "wibble.tld"? Presumably it has delegated management
of that domain to the domain's owner via the registrar, and presumably the
owners DNS system is the only place that holds the definitive subordinate
object listing. Or have I missed  something?

In contrast, I see no problems with returning <ns> objects, as it is clear
that the registry may well have name server information that relates to the
domain. In fact, given the way that <domain:create> works, it's very likely.

Thanks
Rob Burbidge

Date: Mon, 15 Apr 2002 08:00:55 -0700
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Decision on containers - status?
Cc: Robert Burbidge <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Sender: [email-masked]

At 10:34 AM 4/15/2002 -0400, Edward Lewis wrote:
>(dormantly) around.  The third possibility is there in case there are some
>folks that feel it is good, "but not right now."
>
>As far as the PS - it might be that containers are left as an
>implementation-specific option.

Containers offers the benefit of freedom.  It decouples the details of 
interacting with the registrar's customer from the details of interacting 
with the registry on behalf of that customer.

Without containers, the two are tied together.  For many registrar 
environments, this is not a problem.  For others -- particularly 
larger-scale ones -- the limitation requires many more registrary/registry 
interactions and more complicated bookkeeping.

And bookkeeping is the word.  I don't know enough about bookkeeping to know 
the standard term, but I know that this sort of decoupling is quite common 
for accounting systems that have any sort of scale.

So, folks, yes it is less work now.  And clearly many registrars will not 
reach the size that needs containers.  Others will grow into the 
need.  Will, not might.

That says that containers needs to be an option.  Specification of options 
often can be deferred.  And given the knowledge about them, now, the 
requirement is to make sure that the current specification does not make 
adding containers difficult.

d/

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

Date: Mon, 15 Apr 2002 07:41:20 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: Robert Burbidge <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Re: Decision on containers - status?
Sender: [email-masked]

my vote is to drop it, if there isn't interst amend the charter.

-rick

On Mon, 15 Apr 2002, Edward Lewis wrote:

> At the end of the month, Jaap and I will be able to talk at the RIPE
> meeting, so we (the chairs) will have something to say then.  There are
> three possible outcomes - dropping it, pushing on it, or letting it lie
> (dormantly) around.  The third possibility is there in case there are some
> folks that feel it is good, "but not right now."
>
> As far as the PS - it might be that containers are left as an
> implementation-specific option.
>
> At 9:05 AM -0400 4/15/02, Robert Burbidge wrote:
> >According to "Goals and Milestones" on
> >http://search.ietf.org/html.charters/provreg-charter.html, Apr02 is the
> >deadline for deciding whether to support containers. Has this decision been
> >made yet and if so what is it? If not, is there a more specific deadline for
> >the decision?
> >
> >Rob Burbidge, Poptel
> >
> >(PS: Hope we're dropping them, less work to implement :-))
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
>
> Last day is Wednesday, April 24, 2002...
>
> Opinions expressed are property of my evil twin, not my employer.
>
>

Date: Mon, 15 Apr 2002 10:34:59 -0400
To: Robert Burbidge <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Decision on containers - status?
Cc: "Ietf-Provreg (E-mail)" <[email-masked]>
Sender: [email-masked]

At the end of the month, Jaap and I will be able to talk at the RIPE
meeting, so we (the chairs) will have something to say then.  There are
three possible outcomes - dropping it, pushing on it, or letting it lie
(dormantly) around.  The third possibility is there in case there are some
folks that feel it is good, "but not right now."

As far as the PS - it might be that containers are left as an
implementation-specific option.

At 9:05 AM -0400 4/15/02, Robert Burbidge wrote:
>According to "Goals and Milestones" on
>http://search.ietf.org/html.charters/provreg-charter.html, Apr02 is the
>deadline for deciding whether to support containers. Has this decision been
>made yet and if so what is it? If not, is there a more specific deadline for
>the decision?
>
>Rob Burbidge, Poptel
>
>(PS: Hope we're dropping them, less work to implement :-))

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

Last day is Wednesday, April 24, 2002...

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

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Decision on containers - status?
Date: Mon, 15 Apr 2002 14:05:27 +0100
Sender: [email-masked]

According to "Goals and Milestones" on
http://search.ietf.org/html.charters/provreg-charter.html, Apr02 is the
deadline for deciding whether to support containers. Has this decision been
made yet and if so what is it? If not, is there a more specific deadline for
the decision?

Rob Burbidge, Poptel

(PS: Hope we're dropping them, less work to implement :-))

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: Session and session-less commands in EPP
Date: Mon, 8 Apr 2002 08:16:46 -0400 
Sender: [email-masked]

> -----Original Message-----
> From: Robert Burbidge [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 5:44 AM
> To: Ietf-Provreg (E-mail)
> Subject: Session and session-less commands in EPP
> 
> 
> draft-ietf-provreg-epp-06.txt, Section 2.8.1
> 
> Session and session-less operation
> ==================================
> 
> "Session-oriented and session-less operating modes MUST NOT be mixed".
> Intuitively I think you mean that the two modes cannot be 
> mixed within the
> same "session" (to use the term "session" in its most generic sense).
> However, consider the following outline sequence of EPP commands and
> responses
> 
> 1 C: <hello>....
>   S: <greeting>...
> 2 C: <command><creds>...</creds><check>...</check></command>
>   S: <response>...</response>
> 3 C: <command><creds>...</creds><login>...</login></command>
>   S: <response>...</response>
> 4 C: <command><check>...</check></command>
>   S: <response>...</response>
> 5 C: <command><logout></logout></command>
>   S: <response>...</response>
> 
> In this sequence, the <check> command [2] contains its own 
> credentials and
> it has not logged in, which seems fair. The <login> command [3] then
> provides credentials, and these are used by the second check 
> command [4]. As
> far as I can see, this is completely in accordance with the 
> specification.
> But as you can see it mixes "sessioned" and "session-free" 
> operations. We
> might stipulate that a <login> command MUST be the first command after
> <hello> if a client wants to use session operations. But I don't think
> that's particularly desirable.

I agree with your last sentence, and that's why the text currently reads the
way it does.  I don't see a problem with creds-containing commands preceding
a <login> if the server supports such behavior.  Perhaps changing the
"Session-oriented and session-less operating modes MUST NOT be mixed"
sentence to something like "Session-less operating mode MUST NOT be used
within the bounds of an established <login> ... <logout> session" would make
this more clear.

> <logout> command
> ================
> 
> "Commands other than the login command MUST NOT include 
> identity credentials
> when submitted after successfully processing a <login> 
> command". This is
> reasonable. However, what happens AFTER a <logout> command? 
> The presumably
> releases the credential set at the server end. Would it be 
> possible to send
> a <command> that includes <creds> after a successful <logout>? If the
> command sequence outlined above is valid, then a sense of 
> symmetry would
> suggest that the answer is "yes", but this would be in 
> conflict with the
> quoted statement above. 
> 
> According to draft-ietf-provreg-epp-tcp-04.txt, "an EPP 
> session is nominally
> ended by the client issuing an EPP <logout> command. A server 
> receiving an
> EPP <logout> command  MUST end the EPP session and close the TCP
> session...". This would seem to preclude <command> elements 
> with <creds>
> after a <logout> command. A similar comment is found in the 
> BEEP protocol
> mapping.

What happens after a <logout> is processed depends on the transport.  That's
why the base specs doesn't say anything specific, and the TCP and BEEP
documents specifically do address the topic.  It might be possible to add a
sentence to the base spec that says "what happens after logout is
transport-dependent", but I wouldn't want to say much more than that because
of the number of transport-related variables.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: EPP/TCP session layer
Date: Mon, 8 Apr 2002 07:58:06 -0400 
Sender: [email-masked]

> -----Original Message-----
> From: Robert Burbidge [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 5:44 AM
> To: Ietf-Provreg (E-mail)
> Subject: EPP/TCP session layer
> 
> 
> Meaning of the word "nominally"
> ===============================
> 
> draft-ietf-provreg-epp-tcp-04.txt, section 2, paragraph 3
> 
> "An EPP session is nominally ended by ..."
> 
> What does "nominally" mean in this context? If it means 
> "existing in name
> only" then does this mean the session is not really ended? 
> This needs to be
> clarified.

Hmm, I used the word here and in other parts of the specs assuming that
nominal was a synonym for words like standard, typical, common, and usual.
Looking at my dictionary and thesaurus now I see that's not the case.  As
this is an editorial fix I assume I can deal with it after we receive last
call feedback from the IESG.

> Datagrams
> =========
> 
> draft-ietf-provreg-epp-tcp-04.txt, section 4
> 
> Is it a requirement that a datagram contains exactly one EPP 
> XML instance?
> It seems reasonable to suppose that a datagram cannot contain 
> fragments of
> an XML document, but can it contain more than one complete 
> well-formed EPP
> XML instance? I suppose not, but can we clarify this.

The last paragraph of section 3 already addresses this.

Meta-comment: the documents have already been through WG and IETF last call,
so I don't have a lot of freedom to change anything until after we hear from
the IESG.  This feedback is good, but please don't expect new versions of
the documents until some time after IESG commentary is provided - and even
then I have to be careful about what gets changed.

-Scott-

To: Robert Burbidge <[email-masked]>
cc: "Ietf-Provreg (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: Session and session-less commands in EPP 
Date: Mon, 08 Apr 2002 07:44:21 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Morning Robert,

The session-less model we'd (or we've) in mind is epp/smtp.

draft-ietf-provreg-epp-06.txt is (nomially, pardon the abuse of language)
transport-independent, so it must contain guidance (manditory to implement)
on generic session-full and generic session-less transports.

Assume generic session-full transport
1 C: <hello>....
  S: <greeting>...
2 C: <command><creds>...</creds><check>...</check></command>
  ...

Assume generic session-less transport
1 C: <hello>....
2 C: <command><creds>...</creds><check>...</check></command>
...

The difference is in the <greeting> reply, which is manditory for the server
to return when prompted if the service is over a connection, and manditory to
prompt for (but not necessarily get) if the service is connection-less.

Since the client may request a <greeting> at any time by sending a <hello>,
making a requirement as to the next command, e.g., <login> if session is
desired, seems problematic.

1 C: <hello>
  S: <greeting>
2 C: <hello>
  S: <greeting>
3 C: <command><creds>...</creds><login>...</login></command>

Assuming one were implementing an error test case, then you've suggested
that at 3 an error is returned.

I thought the text in section 2.4, Command Format, at lines 539-544 were
clear, <login> and <logout> define server session, repeated in section
2.8.1, Session Management Commands, at lines 1055-1062, was clear.

> But as you can see it mixes "sessioned" and "session-free" operations.

I guess I don't see this. Maybe another cup of coffee would help.

> after a <logout> command. A similar comment is found in the BEEP protocol
> mapping.
>
> Does anyone have any thoughts on this?

The first thought that went through my mind was "Oh joy! A careful reader
of the BEEP draft!"

I think that what you are doing is (understandibly) missing the bits written
in invisible, or archived mailing list ink, that said anything over tcp is
session-full, epp/tcp or epp/beep/tcp, and that epp/smtp is session-less.

I'm really pleased to see implementor-esque comments from someone at Poptel,
my regards to Stu and Cazz.

Cheers,
Eric

To: Robert Burbidge <[email-masked]>
cc: "Ietf-Provreg (E-mail)" <[email-masked]>, [email-masked]
Subject: Re: EPP/TCP session layer
Date: Mon, 08 Apr 2002 06:56:30 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Moring Robert,

The usage in draft-ietf-provreg-epp-tcp-04.txt, section 2, paragraph 3, of
"monimally" is not "existing in name only". Please see the following:

draft-ietf-provreg-epp-06.txt, section 3, Result Codes (at line 2647)
  1000    "Command completed successfully"
  This is the nominal response code for a successfully completed
  command.

draft-ietf-provreg-epp-beep-01.txt, section 2, Session Management (at 147)
   An EPP session is nominally ended by the client issuing an EPP
   <logout> command which terminates the respective BEEP channel.  A  
   server receiving an EPP <logout> command MUST end the EPP session and
   release the BEEP channel.

draft-ietf-provreg-epp-contact-04.txt, section 2.2, Status Values (at 242)
  ok
      
  This is the nominal status value for an object that has no pending
  operations or prohibitions.

The same usages are also in:
draft-ietf-provreg-epp-container-01.txt, section 2.5, Status Values (at 638)
draft-ietf-provreg-epp-domain-04.txt, section 2.3, Status Values (at 260)
draft-ietf-provreg-epp-host-04.txt, section 2.3, Status Values (at 242)

See also:
draft-ietf-provreg-grrp-reqs-06.txt, at 744,

3.5 Domain Status Indicators

  [1] The protocol MUST provide status indicators that identify the
  operational state of a domain name.  Indicators MAY be provided to
  identify a newly created state (the domain has been registered but has
  not yet appeared in a zone), a nominal active state (the domain can be
  modified and is published in a zone), an inactive state (the domain
  can be modified but is not published in a zone because it has no
  authoritative name servers), a hold state (the domain can not be
  modified and is not published in a zone), a lock state (the domain can
  not be modified and is published in a zone), a pending transfer state,
  and a pending removal state.

and at 963, 

7.4 Maintainability
  
  [1] Maintainability is a measure of the extent to which a protocol can
  be adapted or modified to address unforeseen operational needs or
  defects.  The protocol SHOULD be developed under the nominal working  
  group processes of the IETF to provide a well-known mechanism for  
  ongoing maintenance.

I confess I hadn't given the datagram section any thought at all. From an
implementor point of view isn't this equivalent to doing one write to the
wire per command or response?

I'm interested in understanding the scenario where two wf epp xml instances
(not equivalent, due to idempotency) exist in one socket buffer, for the use
case of transport over tcp. 

Cheers,
Eric

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: Session and session-less commands in EPP
Date: Mon, 8 Apr 2002 10:44:07 +0100 
Sender: [email-masked]

draft-ietf-provreg-epp-06.txt, Section 2.8.1

Session and session-less operation
==================================

"Session-oriented and session-less operating modes MUST NOT be mixed".
Intuitively I think you mean that the two modes cannot be mixed within the
same "session" (to use the term "session" in its most generic sense).
However, consider the following outline sequence of EPP commands and
responses

1 C: <hello>....
  S: <greeting>...
2 C: <command><creds>...</creds><check>...</check></command>
  S: <response>...</response>
3 C: <command><creds>...</creds><login>...</login></command>
  S: <response>...</response>
4 C: <command><check>...</check></command>
  S: <response>...</response>
5 C: <command><logout></logout></command>
  S: <response>...</response>

In this sequence, the <check> command [2] contains its own credentials and
it has not logged in, which seems fair. The <login> command [3] then
provides credentials, and these are used by the second check command [4]. As
far as I can see, this is completely in accordance with the specification.
But as you can see it mixes "sessioned" and "session-free" operations. We
might stipulate that a <login> command MUST be the first command after
<hello> if a client wants to use session operations. But I don't think
that's particularly desirable.

<logout> command
================

"Commands other than the login command MUST NOT include identity credentials
when submitted after successfully processing a <login> command". This is
reasonable. However, what happens AFTER a <logout> command? The presumably
releases the credential set at the server end. Would it be possible to send
a <command> that includes <creds> after a successful <logout>? If the
command sequence outlined above is valid, then a sense of symmetry would
suggest that the answer is "yes", but this would be in conflict with the
quoted statement above. 

According to draft-ietf-provreg-epp-tcp-04.txt, "an EPP session is nominally
ended by the client issuing an EPP <logout> command. A server receiving an
EPP <logout> command  MUST end the EPP session and close the TCP
session...". This would seem to preclude <command> elements with <creds>
after a <logout> command. A similar comment is found in the BEEP protocol
mapping.

Does anyone have any thoughts on this?

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: EPP/TCP session layer
Date: Mon, 8 Apr 2002 10:43:49 +0100 
Sender: [email-masked]

Meaning of the word "nominally"
===============================

draft-ietf-provreg-epp-tcp-04.txt, section 2, paragraph 3

"An EPP session is nominally ended by ..."

What does "nominally" mean in this context? If it means "existing in name
only" then does this mean the session is not really ended? This needs to be
clarified.

Datagrams
=========

draft-ietf-provreg-epp-tcp-04.txt, section 4

Is it a requirement that a datagram contains exactly one EPP XML instance?
It seems reasonable to suppose that a datagram cannot contain fragments of
an XML document, but can it contain more than one complete well-formed EPP
XML instance? I suppose not, but can we clarify this.

From: Robert Burbidge <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Ambiguity: <value> and <data> tags belong inside <result> or  <response>?
Date: Thu, 4 Apr 2002 16:05:09 +0100 
Sender: [email-masked]

Thanks Scott. You are right about the page numbers; that was a silly mistake
on my part. I can see that the schema is controlling, but anything you can
do to clarify the prose description would be helpful. 

Rob Burbidge

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: 04 April 2002 15:12
To: 'Robert Burbidge'; [email-masked]'
Subject: RE: Ambiguity: <value> and <data> tags belong inside <result>
or <response>?

Robert,

I think the text you're referring to is actually on page 12 (my copy of -06
has a sample <greeting> and the start of the command description section on
page 9), but FWIW the indentation does indeed need to be fixed.  The schema
is controlling, and it clearly states that the <value> and <data> elements
are child elements of the <result> element, not the <response> element.

During the document last call someone suggested numbering the element
description paragraphs so that child relationships would be more clear, and
not potentially screwed up by indentation problems.  Assuming that the IESG
is OK with that idea I'll be adding numbers into the next version of the
documents.  If not, the indentation will be fixed.

-Scott-

> -----Original Message-----
> From: Robert Burbidge [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 7:46 AM
> To: [email-masked]'
> Subject: Ambiguity: <value> and <data> tags belong inside <result> or
> <res ponse>?
> 
> 
> Since this is my first posting to this list, I hope that (a) 
> it gets there
> and (b) it makes sense. Here goes...
> 
> Page 9 of draft-ietf-provreg-epp-06.txt, implies that the 
> <value> elements
> are contained within <response>. I say "implied" because the 
> only indication
> of containment at that point is the left paragraph indent. 
> However, the
> example on page 15 shows that value is contained inside 
> <result>. A quick
> cross-reference to the schema entry on page 60 shows that <value> is
> supposed to be in <result>, which implies that page 9 is in 
> error in this
> respect. 
> 
> I think the same comment applies for the <data> tag, judging 
> by the schema.
> 
> Would anyone like to comment on this?
> 
> Rob Burbidge
> 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Ambiguity: <value> and <data> tags belong inside <result> or  <response>?
Date: Thu, 4 Apr 2002 09:12:20 -0500 
Sender: [email-masked]

Robert,

I think the text you're referring to is actually on page 12 (my copy of -06
has a sample <greeting> and the start of the command description section on
page 9), but FWIW the indentation does indeed need to be fixed.  The schema
is controlling, and it clearly states that the <value> and <data> elements
are child elements of the <result> element, not the <response> element.

During the document last call someone suggested numbering the element
description paragraphs so that child relationships would be more clear, and
not potentially screwed up by indentation problems.  Assuming that the IESG
is OK with that idea I'll be adding numbers into the next version of the
documents.  If not, the indentation will be fixed.

-Scott-

> -----Original Message-----
> From: Robert Burbidge [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 7:46 AM
> To: [email-masked]'
> Subject: Ambiguity: <value> and <data> tags belong inside <result> or
> <res ponse>?
> 
> 
> Since this is my first posting to this list, I hope that (a) 
> it gets there
> and (b) it makes sense. Here goes...
> 
> Page 9 of draft-ietf-provreg-epp-06.txt, implies that the 
> <value> elements
> are contained within <response>. I say "implied" because the 
> only indication
> of containment at that point is the left paragraph indent. 
> However, the
> example on page 15 shows that value is contained inside 
> <result>. A quick
> cross-reference to the schema entry on page 60 shows that <value> is
> supposed to be in <result>, which implies that page 9 is in 
> error in this
> respect. 
> 
> I think the same comment applies for the <data> tag, judging 
> by the schema.
> 
> Would anyone like to comment on this?
> 
> Rob Burbidge
> 

From: Robert Burbidge <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Ambiguity: <value> and <data> tags belong inside <result> or <res ponse>?
Date: Thu, 4 Apr 2002 13:45:47 +0100 
Sender: [email-masked]

Since this is my first posting to this list, I hope that (a) it gets there
and (b) it makes sense. Here goes...

Page 9 of draft-ietf-provreg-epp-06.txt, implies that the <value> elements
are contained within <response>. I say "implied" because the only indication
of containment at that point is the left paragraph indent. However, the
example on page 15 shows that value is contained inside <result>. A quick
cross-reference to the schema entry on page 60 shows that <value> is
supposed to be in <result>, which implies that page 9 is in error in this
respect. 

I think the same comment applies for the <data> tag, judging by the schema.

Would anyone like to comment on this?

Rob Burbidge

From: "Liu, Hong" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Documents for the WG
Date: Wed, 3 Apr 2002 14:36:27 -0600 
Sender: [email-masked]

Ed,

We have a continuous interest in containers and beep transport. However,
they are not high on our priority right now. We hope that we would be able
to revisit them in the future.

We also think that the guideline document is very important. We would like
to participate in the effort when the time comes.

We will try to put out an I-D on "push" as an individual contribution to the
WG for the next IETF meeting in Yokohoma in July.

Cheers,

--Hong

-----Original Message-----
From: Edward Lewis [mailto:[email-masked]]
Sent: Tuesday, April 02, 2002 10:23 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Documents for the WG

This is mostly for the benefit of folks that were not at the provreg
meeting last month in Minneapolis.  If anyone feels to submit input on
these, go ahead, I'd prefer that we get comments into the archives.

There are four/five items to talk about under the subject of documents...

1) Containers - We've seen no discussion generated by the message I sent
nearly two weeks ago.  We'll soon be requesting that that document be
dropped from the WG list.

2) Transport via BEEP - During the meeting this document got a warm
reception, but not an overwhelming one.  Comments on this?  A few folks did
have an interest, but no one has stepped forward to volunteer to be an
editor/author.

3) Transport via SMTP - This also got a warm reception.  We are pursuing
volunteers to either edit or provide content for this.  One side comment:
there are a lot of ccTLD's that are currently relying on SMTP for
registration - of course without EPP.  Some of the TLDs plan to pick up EPP
when it is available, there is a question of whether the TLDs will also
switch from e-mail to TCP as a "transport".  If the switch is to TCP, then
perhaps transport over e-mail gets by-passed.

4) Guidelines for Extentions - This document arose from situations in which
proposed extensions to EPP might break EPP.  Over the next few months, as
implemenations begin and/or mature, there may be enough gathered wisdom to
document a reference on how to extend EPP.  The provreg group will not last
for the lifetime for EPP, and Scott may not be available to advise others
on how to extend EPP, so we should document some examples.  And I am not
implying that Scott should write this.  This document got some initial
support at the meeting, but it is probably too early to write this.

5) "Push" - There was to be a "push" document at one time.  It seems to
have been largely forgotten.

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

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

Date: Tue, 2 Apr 2002 10:22:53 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Documents for the WG
Cc: [email-masked], [email-masked]
Sender: [email-masked]

This is mostly for the benefit of folks that were not at the provreg
meeting last month in Minneapolis.  If anyone feels to submit input on
these, go ahead, I'd prefer that we get comments into the archives.

There are four/five items to talk about under the subject of documents...

1) Containers - We've seen no discussion generated by the message I sent
nearly two weeks ago.  We'll soon be requesting that that document be
dropped from the WG list.

2) Transport via BEEP - During the meeting this document got a warm
reception, but not an overwhelming one.  Comments on this?  A few folks did
have an interest, but no one has stepped forward to volunteer to be an
editor/author.

3) Transport via SMTP - This also got a warm reception.  We are pursuing
volunteers to either edit or provide content for this.  One side comment:
there are a lot of ccTLD's that are currently relying on SMTP for
registration - of course without EPP.  Some of the TLDs plan to pick up EPP
when it is available, there is a question of whether the TLDs will also
switch from e-mail to TCP as a "transport".  If the switch is to TCP, then
perhaps transport over e-mail gets by-passed.

4) Guidelines for Extentions - This document arose from situations in which
proposed extensions to EPP might break EPP.  Over the next few months, as
implemenations begin and/or mature, there may be enough gathered wisdom to
document a reference on how to extend EPP.  The provreg group will not last
for the lifetime for EPP, and Scott may not be available to advise others
on how to extend EPP, so we should document some examples.  And I am not
implying that Scott should write this.  This document got some initial
support at the meeting, but it is probably too early to write this.

5) "Push" - There was to be a "push" document at one time.  It seems to
have been largely forgotten.

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

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