Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

From: Ulrich Wisser <[email-masked]>
Date: Mon, 02 Nov 2009 11:08:03 +0100

Andrew Sullivan wrote:
> On Wed, Oct 28, 2009 at 12:45:54PM +0100, Ulrich Wisser wrote:
> 
>> The add command (as well as update) uses the secDNS:dsDataType. Which  
>> makes keytag, alg, digestType and digest mandatory. I know that .SE and  
>> other registries considered to become a "fat" registry and take in the  
>> public keys instead of the ds records. The DS records would be computed  
>> from the public keys according to registry policies.
>> This case is not covered by 4310.
> 
> While this is true, 4310 does provide an OPTIONAL <secDNS:keyData>
> element.  Registry policy could require this.  Then you could get the
> DS and the DNSKEY at the same time, and you could even check to be
> sure the DS they're providing actually matches the DNSKEY they're
> providing (and use that as a first-line test to make sure their plan
> is sane.  If they can't generate the right DS, they are as likely to
> have other problems as not, and it could well be that you want to stop
> doing anything until it's sorted).  No?

I agree and this is not a big issue. I just thought that while we are 
changing the XML schema anyway, this change wouldn't be to troublesome 
either. I believe

      <complexType name="dsDataType">
        <sequence>
<group minOccurs="0">
          <element name="keyTag"     type="unsignedShort"/>
          <element name="alg"        type="unsignedByte"/>
          <element name="digestType" type="unsignedByte"/>
          <element name="digest"     type="hexBinary"/>
          <element name="maxSigLife" type="secDNS:maxSigLifeType"
           minOccurs="0"/>
</group>
          <element name="keyData" type="secDNS:keyDataType"
           minOccurs="0"/>
        </sequence>
      </complexType>

would do the trick and still be backward compatible, wouldn't it?

/Ulrich

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: James Gould <[email-masked]>
Date: Mon, 02 Nov 2009 10:03:45 -0400

Ulrich,

So there are registries out there looking to support a keyData interface for
DNSSEC, where the client would pass just the keyData on an add/rem/chg?
Would the DS data be returned in the info response?  Was providing a keyData
interface for DNSSEC requested by the Registrars to ease in the
implementation?  I¹m not sure if having the registries supporting two
different models like the hostAttr and hostObj models of the domain
specification adds value or causes more complexity for the Registrars.  I'm
assuming that the Registry should support one model or the other and not
both.  If there is a compelling reason for supporting two different models,
then I believe that a combination of Klaus¹s and Ulrich¹s schema changes
makes sense, but I would like to hear from others related to the advantage
of supporting two DNSSEC models (dsData and keyData).

In summary, below is the XML schema snippet from Klaus:

    <complexType name="updateType">

        <choice>
  
            <element name="chg" type="secDNS:dsType"/>

                <sequence>

                    <element name="add" type="secDNS:dsType"
minOccurs="0"/>
   
                    <element name="rem" type="secDNS:remType"
minOccurs="0"/>
   
                </sequence>

           </choice>

            <attribute name="urgent" type="boolean" default="false"/>

    </complexType>

    <complexType name="remType">

        <choice maxOccurs="unbounded">

            <element name="dsData" type="secDNS:dsDataType"/>

        </choice>
 
    </complexType>

Below is the XML schema snippet that includes both Klaus¹s and Ulrich¹s
proposals:

    <complexType name="updateType">

        <choice>
  
            <element name="chg" type="secDNS:dsType"/>

                <sequence>

                    <element name="add" type="secDNS:dsType"
minOccurs="0"/>
   
                    <element name="rem" type="secDNS:remType"
minOccurs="0"/>
   
                </sequence>

           </choice>

            <attribute name="urgent" type="boolean" default="false"/>

    </complexType>

    <complexType name="remType">

        <choice maxOccurs="unbounded">

            <element name="dsData" type="secDNS:dsDataType"/>

        </choice>
 
    </complexType>

I agree that if we're not concerned about backward compatibility that the
chg can be removed since supporting add and rem of multiple DS records is
consistent with the other EPP specifications and removes the need for chg.
I'm on the fence about this since I like backward compatibility but I also
like removing confusion around the use of chg if add and rem can be used in
its place.  

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

From: Ulrich Wisser <[email-masked]>
Date: Mon, 2 Nov 2009 05:08:03 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

/Ulrich

---

From: Howard Eland <[email-masked]>
Date: Mon, 2 Nov 2009 09:45:03 -0600

All,

I am in favor of "going to the well once".  I know there's been  
reluctance to change some things because of backwards compatibility  
and current implementation issues.  However, I feel that if the  
current document is broken enough to effect these changes, then we  
should do everything we can to make it right.  It is in exactly this  
spirit that I conceded to requiring the entire dsData set on remove,  
rather than just the digest.

On the two different DNS models: I am in favor of this, on one  
condition: the text has got to make sure that we preserve the  
authority of the data elements.  By this I mean that while it's  
permissible to send in the DNSKEY data, the registry itself MUST NOT  
publish and / or sign this record in the DNS, if they are not  
authoritative for it.

Interestingly enough, this is one reason why I like this option -  
because the parent _is_ authoritative for the DS record.  The same  
comment should be made to the owner of the child zone as well (that  
they are not authoritative for the DS record) - although I don't think  
it can be as strong.

Another reason I like this option is that it gives the registry the  
ability to maintain some consistency in not only the DS record RDATA,  
but also the DS record TTL.

-Howard

On Nov 2, 2009, at 8:03 AM, James Gould wrote:

> implementation?  I’m not sure if having the registries supporting two
> then I believe that a combination of Klaus’s and Ulrich’s schema  
> changes
> Below is the XML schema snippet that includes both Klaus’s and  
> Ulrich’s
> proposals:
>

---

From: James Gould <[email-masked]>
Date: Mon, 02 Nov 2009 11:46:00 -0400

Howard,

So if we ³go to the well once² without backward compatibility support, the
schema would do the following:

1. Remove support for the chg
2. Remove support for rem with just keyTag
3. Support for the combination of add and rem
4. Specify all of the DS information (keyTag, alg, digestType, and digest)
on an add and rem. 

As far as supporting a keyData interface and dsData interface to the clients
, I believe that client-side software (SDK¹s and utilities) should be
available for the client to generate the DS instead of pushing it to the
server-side.  With the dsData interface, the client has maximum flexibility,
the load is distributed to the client-side, and the registries can provide
one consistent interface.  It would be good to hear from the Registrars
related to supporting two different models across the DNSSEC registries.

I updated the options for the schema updates below:

Option 1 - Proposal from Klaus that is backward compatible, supports
combined add and rem, and supports rem with the four ds attributes as
elements:

        <choice>

                <sequence>

   
                </sequence>

           </choice>

    </complexType>

        </choice>
 
    </complexType>

Option 2 - Combination of Klaus¹s and Ulrich¹s proposals, where the dsData
information is made optional to support the keyData interface:

        <choice>

                <sequence>

   
                </sequence>

           </choice>

    </complexType>

        </choice>
 
    </complexType>

Option 3 - Simplified interface that is not backward compatible but is
consistent with the rest of the EPP specs.  Updates consist of just add and
rem of dsType data:

        <sequence>

            <element name="add" type="secDNS:dsType" minOccurs="0"/>

            <element name="rem" type="secDNS:dsType" minOccurs="0"/>

        </sequence>

    </complexType>

Option 4 - Simplified interface that is not backward compatible but is
consistent with the rest of the EPP specs but with support for a keyData
interface, which makes the daData optional.

        <sequence>

            <element name="add" type="secDNS:dsType" minOccurs="0"/>

            <element name="rem" type="secDNS:dsType" minOccurs="0"/>

        </sequence>

    </complexType>

I personally like the simplicity of option 3 if we don't have to worry about
backward compatibility.  Option 4 would be needed if there is a set of
registries that have a compelling reason to support the keyData interface.
For our registries we should be able to deal with a non-backward compatible
change as long as we move quickly to an agreement.  Our registries will most
likely support only the dsData interface.  I propose that the version number
of the namespace and schema be changed to reflect the non-backward
compatible change.  I would see this as a urn:ietf:params:xml:ns:secDNS-2.0
and secDNS-2.0.xsd.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Howard Eland <[email-masked]>
Date: Mon, 2 Nov 2009 10:45:03 -0500
To: James Gould <[email-masked]>
Cc: Ulrich Wisser <[email-masked]>, EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

All,

-Howard

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Nov 2009 09:54:15 -0500

> but also the DS record TTL.

What is the value in having similar TTLs on the DS in the parent and
the DNSKEY in the child?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Nov 2009 10:04:22 -0500

> 2. Remove support for rem with just keyTag

I see no reason whatever to make those changes in the protocol.  That
is a conflation of policy and protocol.  There might be good reasons
for server operators not to allow such combinations, and therefore I
think we should make it possible for a server operator to refuse such
operations.  But we shouldn't remove them from the protocol.

> 3. Support for the combination of add and rem

This seems fine to me, and when I update the draft the next time I'll
make the change so that this is possible.  Now that I understand how
sequence works, this is an obvious improvement.

> 4. Specify all of the DS information (keyTag, alg, digestType, and digest)

I am willing to make this change.  Obviously, using all of them is
redundant (if we start having hash collisions, there's going to be
bigger problems with DNSSEC than getting the DS record into the parent
via EPP), but the symmetry might make the coding easier, and it's not
that much more data.  That said, I don't think we need to require this
(see above).

> related to supporting two different models across the DNSSEC registries.

Well, there's nothing wrong with adding the feature to the protocol as
such.  The question is really whether anybody really wants this.

A

---

From: James Gould <[email-masked]>
Date: Tue, 03 Nov 2009 11:03:20 -0500

Andrew,

I understand that it can be made up to registry policy, but I want to ensure
that we don’t make it more difficult for the clients to interface with
servers applying different interface policies (support for chg, support for
just keyTag, support for add and rem, and support for keyData interface)
with potentially little extra value.  Supporting add and rem in a single
command pretty much deprecates chg and supporting rem with all DS attributes
pretty much deprecates the use of just the keyTag.  I don’t have heartburn
to leaving the deprecated elements in the specification for backward
compatibility, but that would be the only reason they should be left in.
Support for both the dsData and keyData interfaces is a fundamental
different interface similar to the difference between hostAttr and hostObj
in the domain specification, so I don’t support adding extra options to the
specification that can lead to confusion if there is not a compelling reason
to do so.  For our registries the dsData interface is sufficient, so I would
like to understand the real driver behind the keyData interface and whether
this is being driven by Registrars.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Nov 2009 10:04:22 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

> related to supporting two different models across tkeyhe DNSSEC registries.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Nov 2009 11:23:07 -0500

On Tue, Nov 03, 2009 at 11:03:20AM -0500, James Gould wrote:
> pretty much deprecates the use of just the keyTag.

The latter is certainly not true: by policy one could decide to allow
simple keyTag uses, since in just about every case the keyTag is
actually going to be enough.  There is a problem when one is changing
algorithms, for instance, but that doesn't happen very often.

The key thing in preparing the protocol is not to make it as simple as
possible, but to make it as simple as possible without excluding any
reasonable operational model.  Competent experts in the field can
legitimately disagree about what is a "reasonable operational model",
and I'm particularly keen not to change anything that just breaks
deployed and running code in the interests of simplicity.

> this is being driven by Registrars.

I agree it's different, but there is a strong data-source argument
that the registry is the correct generator of the DS record, because
the DS is authoritative in the parent side.  This is different from
the usual NS case, where the record is identical on both sides of the
zone cut.

A

---

From: Howard Eland <[email-masked]>
Date: Tue, 3 Nov 2009 15:32:37 -0600

Sorry, I did not answer this yesterday.

On Nov 2, 2009, at 9:46 AM, James Gould wrote:

> Howard,
>
> So if we “go to the well once” without backward compatibility  
> support, the

So I did some sleuthing to try and figure out the logic of how and why  
chg was implemented in the first place, and I _think_ I've got it.  I  
believe that chg was used when attributes should always have a value  
of some sort.  I went  back through 4931, then back to 3731, looking  
specifically at AuthInfo.  While all of these say that a <domain:null>  
can be used in :chg, I note that in the XML there's a comment about  
adding the null value, which makes me think that at some point a null  
was not allowed, thus requiring a chg command.  I also note that in  
5733, the chg requires at least one child element to update contacts.

I think an argument can be made that :chg is an atomic method for  
replacing all DS records with new ones, without ever having a (albeit  
temporary) state in the DNS where a DS doesn't exist.  This however is  
solving the wrong problem: while there's always a DS in the zone, what  
we ultimately care about is client validation.  The most extreme case  
I can come up with is an emergency KSK rollover.  Should this occur,  
one can easily argue that removing the old DS records (rendering the  
zone invalid for a neg TTL potentially) and immediately (even within  
the same update) adding is as good as an replace (where, while the  
replace is processing, a validator could query and receive the bad DS  
record for a full TTL).

 From this perspective, the only reason to continue to support :chg  
would be because others are currently using it.
Because of this, I support the deprecation of :chg for DS records.

> 2. Remove support for rem with just keyTag

Not sure how this is different from (4), but I'm OK with this.

I've read Andrew's argument about keeping only the keyTag as part of  
the rem, but I'm concerned about making the text and XML correct with  
supporting only a keyTag IFF it removes one DS record, ELSE returns an  
error that specifies the problem, and possibly suggests adding all  
other parameters.

I do think we'll see quite a few registrants that send in the same  
keyTag w/ different digest types.  I am seeing a _lot_ of interest for  
this, from both test registrants as well as registrars, and it'll be  
more prevalent with the uptake of SHA-256.

> 3. Support for the combination of add and rem

Yes, provided the text clearly states that only one outcome can  
occur.  This can mean doing all adds first, or all removes first.  Of  
course, all adds can occur in any order, as can all removes.  Allowing  
policy to dictate how this works would be mean that registrars would  
have to support both.

> 4. Specify all of the DS information (keyTag, alg, digestType, and  

Yes - this needs to happen to ensure only a single DS is affected.

> , I believe that client-side software (SDK’s and utilities) should be

While registrar input is certainly important, I think it's really up  
to the registries that are authoritative for the DS record.  While I  
may not use this out of the gate, it's certainly an interesting idea,  
and it seems like something others said they would like to see.

-Howard

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Nov 2009 17:20:47 -0500

On Tue, Nov 03, 2009 at 03:32:37PM -0600, Howard Eland wrote:
>
> From this perspective, the only reason to continue to support :chg would 
> be because others are currently using it.

The conclusion seems not to follow from the premise.  We do not know
whether anyone is using chg.  If we remove support, then we might
break someone who doesn't know to follow the list of a long-closed WG.
What benefit is there in removing support?

> I've read Andrew's argument about keeping only the keyTag as part of the 
> rem, but I'm concerned about making the text and XML correct with  
> error that specifies the problem, and possibly suggests adding all other 
> parameters.

Why do we need to do this?  If registries want to make a policy that
they won't accept changes with only the keyTag, I think we ought to
make it possible to do that.  I don't see any reason at all that the
protocol should require one behaviour or another, however.  And again,
without allowing keyTag-only operation, we're forcing on anyone who
has already implemented 4310 a flag day cutover: on that day, all the
old clients need to stop.  No?

> Yes, provided the text clearly states that only one outcome can occur.  
> This can mean doing all adds first, or all removes first.  Of course, all 
> adds can occur in any order, as can all removes.  Allowing policy to 
> dictate how this works would be mean that registrars would have to 
> support both.

I don't think I understand your remark here.  I thought the idea was
that we make this a sequence, such that the outcome is whatever that
sequence of operations would be.  No?

A

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 04 Nov 2009 14:31:39 +0100

> sequence of operations would be.  No?

But the sequence in the schema does allow only one kind of sequence. It
will always be add/rem or rem/add. The schema doesn't allow you to
choose which one to put first. And therefor the order of execution will
be fixed.

But if we go for the new dsData/keydata changes for the rem command I
can't see that we would need rem/add and add/rem. Either scheme allows
all reasonable updates. As dsData identifies exactly on ds record and
keydata exactly one key adding and removing the same ds record/key in
one epp command could be considered unreasonable, couldn't it?

/Ulrich

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 04 Nov 2009 14:31:53 +0100

> Would the DS data be returned in the info response? 

James, I've heard from several registries considering it. But I have no
input about this from registrars. From a registry standpoint dealing
with keys instead of ds records makes operations much simpler.

We would not return DS data. .SE would put two DS records for each key
in the zone file. So returning DS records would mean to return the key
twice. With the proposed change we would return the key data in the info
command.

/Ulrich

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 04 Nov 2009 14:30:39 +0100

After going through our epp server code I believe we should go for the
*not* backward compatible changes. In my opinion supporting another
extension on the server side is if not trivial at least very easy.
Server operators are always free to support the old namespace as long as
necessary but anybody doing a new implementation would get it right from
the beginning.

Andrew, if we change the namespace version number servers can support
the old way without any changes to the clients and the new (proper) way
at the same time.

In that light I propose we drop backward compatibility.

/Ulrich

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Nov 2009 08:52:53 -0500

> In that light I propose we drop backward compatibility.

This sounds like what we are proposing is a completely new extension.
Is that right?

A

---

From: James Gould <[email-masked]>
Date: Wed, 04 Nov 2009 09:43:23 -0500

All,

Before we continue to go around in circles, can I propose an option that
addresses most of everyone¹s concerns, where the following would be met?

1. XML schema is backward compatible
2. Support for add and rem in the same command
3. Support for passing all four dsData attributes on a rem
4. Support for a dsData and keyData primary interface.  Only one primary
interface should be supported by the server.
5. Remove support for the wildcard delete of dsData in the rem by just using
the keyTag with a clear statement (i.e. Server must return error if the
keyTag matches multiple DS records) in the specification.  From my
perspective and I believe a couple others this is a key issue that must be
addressed.    
6. Clarity in the specification on the use of the chg as a replace or a
³change all².   
7. Clarity around the corner case of a client attempting to add and remove
the same dsData or keyData in a single command.  This must result in an
error from the server.  Additionally an error must be returned if the client
tries to remove dsData or keyData that does not exist or tries to add dsData
or keyData that already exists.

Option 2 from my prior e-mail should satisfy all of these along with some
additional text clarity in the specification.

        <choice>

                <sequence>

   
                </sequence>

           </choice>

    </complexType>

        </choice>
 
    </complexType>

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Nov 2009 08:52:53 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Nov 2009 10:21:19 -0500

> 1. XML schema is backward compatible

What do you mean by this exactly?  It seems that you are proposing
changing the schema in such a way that the schema is not actually
backward compatible, because you want to make it protocol-impossible
for someone to delete all DS data just by using the keyTag.  I think
that requires that the schemas are formally incompatible.  Doesn't it?

> interface should be supported by the server.

I think I don't know what "primary interface" means in the above.  If
you mean that the I-D should say something like "A server MUST accept
either dsData or keyData, and SHOULD NOT accept both," it makes sense
to me.

> perspective and I believe a couple others this is a key issue that must be

Nobody has yet responded to my contention that this is a policy
matter, and shouldn't be required by the protocol.  You don't happen
to have a deployed system using 4310 yet, so it isn't a concern to
you, but it seems to me that there are people who do have such
deployed systems, and the above requirement effectively requires them
to have a flag day.  Why does that need to be a protocol mandate, when
we can do it with registry policy?

> 6. Clarity in the specification on the use of the chg as a replace or a

I think the I-D I circulated already contains such language.

> error from the server. 

Why?  In the mainline EPP specification, if you remove and add the
same name servers in a single command, it doesn't cause an error.  (I
know this because misguided registrars used to do it all the time in
an effort to get the "primary" name server "listed first".)  It's a
waste of bandwidth, but since EPP is idempotent it should have no
effect, right?

> Additionally an error must be returned if the client

These are already errors, I think, no?

A

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 04 Nov 2009 20:26:40 +0100

> one epp command could be considered unreasonable, couldn't it?

Hi all,

just an attempt to clarify:

The XML Schema <sequence> *only* defines the order of the elements in the XML 
file. It *does not* impose any implicit processing order. A protocol can define 
any processing order it likes.

Also, there is one <add> and/or <rem> element at most in a request. However, 
within each of them, multiple elements may occur to represent multiple DS 
records (or keys, if you will).

Personally, I really don't care about the order in the XML document, but I 
prefer the perform the removals first and then the additions. Ulrich's way to 
reject a request if a DS record appears both in <add> and <rem> would be also 
acceptable to me, but it makes the implementation a little bit more complex if 
the <keyTag> in the <rem> section is retained -- in this case, the DS data has 
to be checked against these <keyTag> elements as well.

Regards,
Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 04 Nov 2009 20:36:17 +0100

> waste of bandwidth, but since EPP is idempotent it should have no

Hi Andrew,

I am quite sure that RFC 5731 and its predecessors do not define how to handle 
this case and that the problem is left as an exercise to the implementor. As I 
regard this as a flaw in the protocol, I would appreciate a statement in 4310bis 
regarding such a state.

Klaus

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 4 Nov 2009 15:05:34 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Klaus Malorny
> Sent: Wednesday, November 04, 2009 2:36 PM
> To: Andrew Sullivan; EPP Provreg
> >> 7. Clarity around the corner case of a client attempting 
> to add and 
> >> remove the same dsData or keyData in a single command.  This must 
> >> result in an error from the server.
> >
> I am quite sure that RFC 5731 and its predecessors do not 
> define how to handle this case and that the problem is left 
> as an exercise to the implementor. As I regard this as a flaw 
> in the protocol, I would appreciate a statement in 4310bis 
> regarding such a state.

Section 2 of 5730 very clearly states that "Commands are processed by a
server in the order they are received from a client."  If an <add> is
received before a <rem> it should be processed first.

Scott

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 04 Nov 2009 21:06:57 +0100

Hi all,

sorry for flooding the list, but I prefer to keep issues separated.

I'd like to dig a little bit deeper on this dsData/keyData issue:

So we would allow either to

  * [DS]: specify only the DS data

  * [KEY]: specify only the DNSKEY data; the registry would be responsible to
    generate DS record(s) from it

  * [DS/KEY]: specify both DS and DNSKEY data; the registry would either
    silently ignore the DS data and use the key data as in [KEY], or use
    the DNSKEY to verify the correctness of the DS data. I wouldn't
    recommend the first case, though.

in <create> and <update> requests?

It would be upon the registry policy which of the three (including any 
combination of them) would be accepted.

In the <rem> section of an <update>, how can a user remove an existing entry?

* a [DS] entry could remove an existing [DS] or [DS/KEY] entry,
   but it probably should not be able to remove a [KEY] entry
* a [KEY] entry could remove an existing [KEY], [DS/KEY] entry
   or multiple [DS] entries (e.g. with different digest types),
   but the latter is probably not recommended
* a [DS/KEY] entry could remove all three types

Again, it would probably be the best to define the acceptable ways as a registry 
policy, wouldn't it?

For the <info> request, I would like propose that the answer returns exactly the 
data that has been specified in the <create>/<update> requests.

However, different answers could be imaginable:

* a [KEY] could be returned either as the respective [DS] entries
   (maybe even in addition).
* [DS/KEY] could be returned as [DS] only.

One final thing:

I believe that the <maxSigLife> element should be removed from the group 
definition and put directly into the sequence, so that it may be also specified 
in a key data only solution. Or shall it not be applicable in this case? I.e.:

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 04 Nov 2009 21:33:30 +0100

On 04/11/09 21:05, Hollenbeck, Scott wrote:

> server in the order they are received from a client."  If an<add>  is
> received before a<rem>  it should be processed first.
>
> Scott
>

Hi Scott,

up to now I interpreted the term "command" in this sentence in respect to the 
"epp:commandType" in the "urn:ietf:params:xml:ns:epp-1.0" name space as an 
atomic piece of work. The definition as low level sequences of characters 
forming text contents, attributes, elements, comments, processing instructions 
and so on, representing individual tiny commands within the big one, is a fairly 
new and dubious concept to me, especially as the XML infoset[1] does not regard 
the order of attributes in the document as relevant and parsers and generators 
are free to change it.

But thanks for clarification.

Regards,

Klaus

[1] http://www.w3.org/TR/xml-infoset Appendix D, 10.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: James Gould <[email-masked]>
Date: Wed, 04 Nov 2009 16:44:17 -0500

Andrew,

I answer your questions below.  I believe the only contention point that we
have is the handling the wildcard rem keyTag which I've responded to below.
Is there any objections to the proposed XML schema updates, since this is
the key to me?  We can work out the details of the text changes made to the
specification.  

“What do you mean by this exactly?  It seems that you are proposing
changing the schema in such a way that the schema is not actually
backward compatible, because you want to make it protocol-impossible
for someone to delete all DS data just by using the keyTag.  I think
that requires that the schemas are formally incompatible.  Doesn't it?”

A client that implements the existing version of the specification will not
fail due to XML schema validation if interfacing with a server that supports
the new specification.  It will be up to the server to decide when to apply
the dsKey wildcard policy to comply with the latest specification, but from
a client interface perspective the proposed XML schema is fully backward
compatible.  Clients should be notified with an error message if they were
not specific enough to remove an individual DS record.  If the client does
not have an issue with multiple DS with the same keyTag for a domain, then
the new specification will work for them even if they provide just the
keyTag on a remove.

“I think I don't know what "primary interface" means in the above.  If
you mean that the I-D should say something like "A server MUST accept
either dsData or keyData, and SHOULD NOT accept both," it makes sense
to me.”

I mean “primary interface” to indicate the significant (primary) fields used
for transform commands.  The current specification uses dsData as the
primary interface with keyData as optional to support additional server-side
validation, which should continue to be supported.  To support keyData as
the primary interface I’m assuming that the dsData SHOULD NOT be provided.
If the client specifies dsData or dsData and keyData then they are
implementing the dsData primary interface, and if the client just specifies
the keyData then they are implementing the keyData primary interface.   The
server MUST NOT mix both dsData as the primary interface as well as keyData
as the primary interface.  Of course the server could decide to not fully
follow the new specification during a migration period just like with the
dsKey wildcard policy.

“Nobody has yet responded to my contention that this is a policy
matter, and shouldn't be required by the protocol.  You don't happen
to have a deployed system using 4310 yet, so it isn't a concern to
you, but it seems to me that there are people who do have such
deployed systems, and the above requirement effectively requires them
to have a flag day.  Why does that need to be a protocol mandate, when
we can do it with registry policy?”

I believe that this is one of the issues with the current specification that
requires a remedy.  We could have a system deployed prior to agreement and
implementation of the updated specification, so we could be impacted by
this.  It can be up to the server when to fully support the latest
specification (the flag day), but I foresee confusion with the Registrars if
some servers by Registry policy support the keyTag rem without returning an
error when more then one DS record is impacted.  Our current plan is to
remove all matching DS records on a keyTag rem using the current
specification, so we will have a flag day if we plan on deploying with the
current specification prior to supporting the new specification.  Maybe it
makes sense to define an either or option in the specification in support
the keyTag rem or the dsData rem, where there is a period of time the server
will support both for migration.   Either that or we can weaken the text of
the specification to SHOULD instead of MUST, but I really believe it is bad
behavior for the server to support the wildcard keyTag rem if the dsData rem
is supported.  
 
“I think the I-D I circulated already contains such language.”

I don’t believe that “The <secDNS:chg> element is used to replace existing
DS information with new DS information” is clear enough since it could mean
replace the attributes associated with the existing matching DS information
by keyTag with the new attributes.  It would be clearer to state something
like "The <secDNS:chg> element is used to replace all existing DS
information with new DS information.  For example, if three DS records exist
and the <secDNS:chg> includes two <secDNS:dsData> elements that the three DS
records will be replaced with the two <secDNS:dsData> elements.".  We
debated the interpretation of the sentence in implementing 4310, so it would
help to add a little bit more clarity.

"Why?  In the mainline EPP specification, if you remove and add the
effect, right?"

I just want to put to rest the thread on how the add and rem is processed on
the server side.  I really don't believe this should be an issue, but if a
few lines of text will help clear any concerns around supporting add and rem
together I'm fine with it.  Our server will return an error if the client
attempts to add and remove the same name server.  I don't want anything in
the specification stating something like "the removes need to be processed
prior to the adds" to address this corner case.

"These are already errors, I think, no?"

Yes, it might be overkill to state the obvious, but just to make sure it's
clear how the add and rem are used together.  If everyone is fine with
adding support for using the add and rem together without any additional
explanatory text, I'm fine with it.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Nov 2009 10:21:19 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

A

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 5 Nov 2009 07:16:55 -0500

> From: Klaus Malorny [mailto:[email-masked]] 
> Sent: Wednesday, November 04, 2009 3:34 PM
> To: Hollenbeck, Scott
> Cc: Andrew Sullivan; EPP Provreg
> > Section 2 of 5730 very clearly states that "Commands are 
> processed by 
> > a server in the order they are received from a client."  If 
> an<add>  
> > is received before a<rem>  it should be processed first.
> >
> > Scott
> >
> 
> Hi Scott,
> 
> up to now I interpreted the term "command" in this sentence 
> in respect to the "epp:commandType" in the 
> "urn:ietf:params:xml:ns:epp-1.0" name space as an atomic 
> piece of work. The definition as low level sequences of 
> characters forming text contents, attributes, elements, 
> comments, processing instructions and so on, representing 
> individual tiny commands within the big one, is a fairly new 
> and dubious concept to me, especially as the XML infoset[1] 
> does not regard the order of attributes in the document as 
> relevant and parsers and generators are free to change it.
> 

I'm referring to XML command structures for which an order can be
explicitly specified, such as elements within a sequence.  It's
certainly not a new concept because the specifications have been this
way since the very beginning (the same quote can be found in RFC 3730
from 2004). If the order wasn't intended to be significant I wouldn't
have used sequences.

Scott

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 05 Nov 2009 14:07:15 +0100

> from 2004). If the order wasn't intended to be significant I wouldn't

Well, XML is not a not a command structure but a hierarchical syntax for 
documents, with XML Schema being one of multiple choices of overlaying it with 
rules. Anyway, for my taste tying the logic of a high level protocol that 
tightly to its transport representation is a design weakness, more abstraction 
would be a boon. But it is wasted time to argue -- it is nothing new that we 
have diametric opinions on certain topics...

Regards,

Klaus

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 5 Nov 2009 08:30:19 -0500

> Sent: Thursday, November 05, 2009 8:07 AM
> To: Hollenbeck, Scott
> Cc: EPP Provreg
> Well, XML is not a not a command structure but a hierarchical 
> syntax for documents, with XML Schema being one of multiple 
> choices of overlaying it with rules. Anyway, for my taste 
> tying the logic of a high level protocol that tightly to its 
> transport representation is a design weakness, more 
> abstraction would be a boon. But it is wasted time to argue 
> -- it is nothing new that we have diametric opinions on 
> certain topics...

"XML command structures" should be interpreted as "XML Schema used to
specify EPP commands".  Sorry for not being more specific, but given
what we're talking about I didn't think my meaning was unclear.

In this context, more abstraction makes for just the kind of uncertainty
("what happens if you do a <rem> before an <add> or vice-versa?") that
we're seeing on the list right now.  You're certainly correct in
suggesting that there are situations where more abstraction is
beneficial, but a lack of specificity in this particular situation
(add/rem processing order) can lead to non-deterministic behavior.
*That's* a weakness.

Scott

---

From: James Gould <[email-masked]>
Date: Mon, 16 Nov 2009 09:35:03 -0500

Klaus,

Sorry for the late reply to your post, since you raise some good questions.
I believe that the clients should specify the dsData with the keyData for
optional validation for maximum flexibility to the client, but if there is
the need to support a keyData interface then the specification can support
it.   

³So we would allow either to

  * [KEY]: specify only the DNSKEY data; the registry would be responsible
to
    generate DS record(s) from it

³

The [DS] and [DS/KEY] models make sense, and the ladder interpretation of
[DS/KEY] seems like the better one, where it is really [DS] with the
optional use of the key data for validation.  The server should support
either the [DS] / [DS/KEY] model or the [KEY] model and not both.

³In the <rem> section of an <update>, how can a user remove an existing
entry?

³

The [DS] entry should remove a single DS data record.  If there are multiple
DS data records with the same [KEY] the <rem> SHOULD not more then one DS
data records as a side effect.  This is the wildcard scenario.  I would
imagine with the [KEY] interface that the server is responsible for the
generation of the associated DS records, so a removal of a [KEY] entry
should remove all DS records for that [KEY] entry.  [DS/KEY] doesn¹t make
much sense on a <rem> since I view [DS/KEY] as [DS] with optional keyData
validation, which is not needed on a remove.  It would be good if the server
returned an error if both the dsData and the keyData is passed on a <rem> to
reduce confusion.  

³I believe that the <maxSigLife> element should be removed from the group
definition and put directly into the sequence, so that it may be also
specified
in a key data only solution. Or shall it not be applicable in this case?
I.e.:
³

I¹m not sure if the client specified maxSigLife makes much sense for the
[KEY] interface since the DS data becomes the responsibility of the server.
Do any of the registries looking to support the [KEY] interface have an
opinion on this one?

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Klaus Malorny <[email-masked]>
Date: Wed, 4 Nov 2009 15:06:57 -0500
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Hi all,

  * [KEY]: specify only the DNSKEY data; the registry would be responsible
to
    generate DS record(s) from it

In the <rem> section of an <update>, how can a user remove an existing
entry?

Again, it would probably be the best to define the acceptable ways as a
registry
policy, wouldn't it?

For the <info> request, I would like propose that the answer returns exactly
the
data that has been specified in the <create>/<update> requests.

One final thing:

I believe that the <maxSigLife> element should be removed from the group
definition and put directly into the sequence, so that it may be also
specified
in a key data only solution. Or shall it not be applicable in this case?
I.e.:

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 19 Nov 2009 17:51:48 +0100

Hi all,

I don't want to broaden the discussion even more, but I'd like to have your 
comments on another question in the context of 4310-bis.

If a registrar issues a domain:update request which changes the DS data, then 
this is usually a part of the KSK rollover process. The rollover process depends 
on various timeouts, which rely on the TTLs of the DS records in the parent zone 
and the time of update of the DS records.

Both values -- the TTL of the DS records and the update time of the name servers 
-- are subject to the registry and are unavailable from the EPP point of view. 
Of course, one can simply poll the name servers of the parent zones and check 
whether the performed changes have become visible, or, even simpler, blindly 
rely that it has happened after an ample amount of time.

On the other hand, if requested by the registrar, the EPP server *could* send a 
notification via the poll mechanism to the registrar, that the name servers of 
the registry now reflect the changes of a specific update that had been 
processed successfully earlier. TTLs could be reported at the same time.

This could not only make sense in the context of DNSSEC, but also for name 
server changes as well, and could also include create and delete requests, if 
need be.

Now, would you consider such a feature as useful, as a complete nonsense, maybe 
as something in-between? Would such a feature be worth the effort? If so, should 
it be included in 4310-bis?

Regards,

Klaus

---

From: James Gould <[email-masked]>
Date: Fri, 20 Nov 2009 13:00:17 -0500

Klaus,

Interesting idea, but I believe that the client implementing a preset timer
is the simplest approach for both Registrar and Registry.  The registry
could publish the global TTL set or allow for the TTL to be set
independently for each domain and publish the DNS latency SLA out-of-band.
Setting the TTL for a domain would be a good idea for a different EPP
extension.  Creating a poll message for each update would be difficult for
the client to match up, since the poll messages are usually consumed
asynchronously using a single threaded session.  Creating a poll message
would also be a challenge for the Registry since metrics would have to be
consolidated on a per domain basis across the DNS constellation.  I would go
with the KISS approach on this one by using a preset timer on the client
side with reasonable and conservative estimates and optionally allow the
client to explicitly set the TTL for a domain in a separate EPP extension.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Klaus Malorny <[email-masked]>
Date: Thu, 19 Nov 2009 11:51:48 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Hi all,

If a registrar issues a domain:update request which changes the DS data,
then
this is usually a part of the KSK rollover process. The rollover process
depends
on various timeouts, which rely on the TTLs of the DS records in the parent
zone
and the time of update of the DS records.

Both values -- the TTL of the DS records and the update time of the name
servers
-- are subject to the registry and are unavailable from the EPP point of
view.
Of course, one can simply poll the name servers of the parent zones and
check
whether the performed changes have become visible, or, even simpler, blindly
rely that it has happened after an ample amount of time.

On the other hand, if requested by the registrar, the EPP server *could*
send a
notification via the poll mechanism to the registrar, that the name servers
of
the registry now reflect the changes of a specific update that had been
processed successfully earlier. TTLs could be reported at the same time.

This could not only make sense in the context of DNSSEC, but also for name
server changes as well, and could also include create and delete requests,
if
need be.

Now, would you consider such a feature as useful, as a complete nonsense,
maybe
as something in-between? Would such a feature be worth the effort? If so,
should
it be included in 4310-bis?

Regards,

Klaus

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Nov 2009 10:18:15 -0500

I'm curious...is anyone preparing a document?

I confess that I read the thread more or less ten days ago and have 
forgotten the nuances.  The first question is on backwards 
compatibility.  We have already implemented 4310, but, we aren't in 
production with it.  Although we would not want to redo this (As in 
"how do you *want* to pay" want), if we had to for better stability 
we could (consider it).  Considering others are in production, is it 
a given that there will be backwards compatibility?

Are the outstanding issues only related to being able to identify the 
records needed to be changed?  Or is there an issue that the client 
needs to get feedback that the change has been 
regsitered/made/propagated/served?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Nov 2009 12:48:33 -0500

> I'm curious...is anyone preparing a document?

I have a -00 draft (I mailed it at least once to the list), but it
didn't meet several people's needs.  My conclusion was that the draft
needed almost a complete rewrite, and this is no longer just an update
but a complete new specification.  I haven't had a chance to go back
to it.  If someone is dying to take over, I have XML that can be used.
I'm happy to have my name dropped from the list in that case.

> (consider it).  Considering others are in production, is it a given that 
> there will be backwards compatibility?

There will not be schema compatibility if we go the way currently
proposed.  If we go that way, it might be that old clients will work
fine with new servers.  James seemed to suggest at one point that
during a transition period, the way to get there would just be for
servers or clients or both to ignore parts of the new protocol.  This
answer makes my teeth hurt, but maybe we can get something cleaner.

A

---

From: James Gould <[email-masked]>
Date: Mon, 23 Nov 2009 13:46:15 -0500

Andrew,

I can take the task of creating a draft update based on a compromise
discussed on this list that meets the following points.  Can you forward me
the draft XML that you created?

1. Maintains XML schema backward compatibility
2. Support the ability to add and remove in the same command
3. Support the ability to specify either keyTag or all of the dsData
attributes for a remove.
4. Add clarity around the chg functioning as a replace.
5. Add support for a keyData or a dsData interface for Registries that
intend to manage the DS data generation.  I intend to have the XML schema
support both, but to specify that the server MUST support only one or the
other.  
6. Add a SHOULD statement around the server returning an error for wildcard
deletes to address one of the main concerns around unexpected side effects
of the rem matching multiple DS records with the same keyTag.

I believe the best route is to keep the interface as close as possible to
RFC 4310, but with updates to address the main interface issues.  There are
systems in Production and will be in Production shortly that should have a
smooth migration path to the updated draft.

Any suggestions that the list has with any of these items, please let me
know.  Once I have the draft created I¹ll send it out the list for review.

Thanks,

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Nov 2009 12:48:33 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Is there a 4310-bis document?

A

---

From: James Gould <[email-masked]>
Date: Wed, 25 Nov 2009 10:25:50 -0500

All,

I¹ve attached a proposed XML schema based on hitting on points 1, 2, 3, and
5  from the list below.  Points 4 and 6 will be addressed in the draft.
Please review the XML schema and let me know if there are any issues.

Are there any other points that need to be addressed?

I made the dsData (DS Data Interface) and keyData (Key Data Interface)
mutually exclusive, so by the XML schema there is no mixing of the two
interfaces while maintaining backward compatibility with RFC 4310.  I'm
really looking for feedback from the registries planning to support the Key
Data Interface.  I'm assuming that with the Key Data Interface that no DS
data is passed (command or response) since it's being completely managed by
the server.  Adding DS data to the Key Data Interface adds complexities
since the server could create multiple DS records for an individual key.  I
also assume that the server must choose either the DS Data Interface or the
Key Data Interface to make the protocol clear to the clients.  Supporting
the Key Data Interface is a significant change to the draft so I want to
ensure that it is meeting the requirements for those who plan on using it.

Thanks,          

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: James Gould <[email-masked]>
Date: Mon, 23 Nov 2009 13:46:15 -0500
To: Andrew Sullivan <[email-masked]>, EPP Provreg <[email-masked]>
Conversation: [ietf-provreg] Is there a 4310-bis document?
Subject: Re: [ietf-provreg] Is there a 4310-bis document?

Andrew,

Thanks,

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

A

---

From: Howard Eland <[email-masked]>
Date: Wed, 25 Nov 2009 13:26:36 -0600

Thanks for this, JG.  I'll not have a chance to review before the US  
holiday, but I will next week.

-Howard

On Nov 25, 2009, at 9:25 AM, James Gould wrote:

> All,
>
> I’ve attached a proposed XML schema based on hitting on points 1, 2,  
> 3, and
> To: Andrew Sullivan <[email-masked]>, EPP Provreg <[email-masked] 
> >
> know.  Once I have the draft created I’ll send it out the list for  
> review.
>
> Thanks,
>
> -- 
>
>
> JG
>
> <secDNS-1.0.xsd>