Subject: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review

From: James Gould <[email-masked]>
Date: Wed, 10 Feb 2010 23:07:31 -0500

All,

I submitted 04 of the draft.  The official draft is available at the URL
below:

http://www.ietf.org/id/draft-gould-rfc4310bis-04.txt

There are many updates from 03 described in Appendix A based on the feedback
on the list and privately.  These changes are substantial, so please review
it and provide me with your feedback as soon as possible.

I did not include anything in 04 related to Eduardo¹s active flag request
based on the variety of feedback on the provreg list that shows that it¹s
not ready for inclusion in rfc4310bis.  I encourage that the discussions
continue on the list for possible inclusion in a future draft.

Thanks,

-- 

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: Bernie Hoeneisen <[email-masked]>
Date: Thu, 11 Feb 2010 10:23:50 +0100 (CET)

Hi James

Thanks for the update and your work behind this.

Here a first feedback after skimming through it:

* section 5 (page 24):
   s/Extensible Provisioning Protocol v1.0/Extensible Provisioning Protocol v1.1/

* I suggest to include implementation recommendations, in particular for
   servers, on how to deal with the transition from 1.0 to 1.1.
   I'll think about some decent text and might come back to the list.
   If anyone else has great ideas for suitable wording, feel free to
   suggest it independently to the list.

* You might want to add an RFC Editors' note to sections "Appendix A./B."
   e.g. [RFC Editor: This section is to be removed before publication]

* You might want to include a summary of the most important changes
   beween 4310 and the new RFC (no details), (and publish it in the new
   RFC) to help people better understand the differences between 4310
   and the new RFC.

That's all for now. More might come once I find the time to read it more 
thoroughly.

cheers,
  Bernie

On Wed, 10 Feb 2010, James Gould wrote:

> All,
> 
> I submitted 04 of the draft.  The official draft is available at the URL below:
> 
> There are many updates from 03 described in Appendix A based on the feedback on the list and privately.  These changes
> are substantial, so please review it and provide me with your feedback as soon as possible.  
> 
> I did not include anything in 04 related to Eduardo’s active flag request based on the variety of feedback on the
> provreg list that shows that it’s not ready for inclusion in rfc4310bis.  I encourage that the discussions continue on
> the list for possible inclusion in a future draft.
> 
> Thanks,
> 
> --
> 
> 
> JG
> 
> 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: James Gould <[email-masked]>
Date: Thu, 11 Feb 2010 16:55:28 -0500

Bernie,

>    s/Extensible Provisioning Protocol v1.0/Extensible Provisioning Protocol

I believe that this is correct as discussed on the list.

>    suggest it independently to the list.

Yes, I can see the need for this; although I don¹t believe it is all that
complex.  I would propose adding text like the following:

To support the transition from 1.0 and 1.1 a server implementing 1.0 SHOULD
support both 1.0 and 1.1 for a period of time to allow clients to migrate to
1.1.  While supporting both 1.0 and 1.1, the server SHOULD route 1.0
commands to 1.0 protocol handlers and 1.1 commands to 1.1 protocol handlers.
For the secDNS:infData included with the domain info response the server
SHOULD choose version 1.0 or version 1.1 of secDNS:infData based on the
secDNS extURI elements included in the EPP login.  If extURI
urn:ietf:params:xml:ns:secDNS-1.1 is included in the EPP login then version
1.1 of secDNS:infData SHOULD be returned and if only extURI
urn:ietf:params:xml:ns:secDNS-1.0 is included in the EPP login then version
1.0 of the secDNS:infData SHOULD be returned.  If neither extURI
urn:ietf:params:xml:ns:secDNS-1.0 or extURI
urn:ietf:params:xml:ns:secDNS-1.1 is included in the EPP login then
secDNS:infData SHOULD NOT be returned.

Does anyone else have thoughts related to implementation recommendations.

>    e.g. [RFC Editor: This section is to be removed before publication]

I¹ll work with the AD on this.

>    RFC) to help people better understand the differences between 4310

I¹ll consider this, but at this point I don¹t plan on creating a new RFC.

Let me know any additional feedback that you have after a detailed review.

Thanks,

-- 

JG 

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

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 11 Feb 2010 04:23:50 -0500
To: James Gould <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for
Review

Hi James

* section 5 (page 24):
   s/Extensible Provisioning Protocol v1.0/Extensible Provisioning Protocol
v1.1/

cheers,
  Bernie

> There are many updates from 03 described in Appendix A based on the feedback
on the list and privately.  These changes
> I did not include anything in 04 related to Eduardo?s active flag request
based on the variety of feedback on the
> provreg list that shows that it?s not ready for inclusion in rfc4310bis.  I
encourage that the discussions continue on
> the list for possible inclusion in a future draft.
Registry  Sensitive information intended
> solely for the recipient and, thus may not be  retransmitted, reproduced or
disclosed without the prior written consent
> sender immediately by  telephone or reply e-mail and destroy the original
message without making a  copy.  Thank you.

---

From: James Gould <[email-masked]>
Date: Fri, 12 Feb 2010 11:04:46 -0500

All,

I forgot about one item brought up by Klaus in a prior posting related to
inclusion of ttl in rfc4310bis.  What does the list feel about the need for
adding support for an optional client specified ttl value and an optional
server ttl returned in the info response used in a similar fashion as the
maxSigLife, meaning directly under the secDNS:create, secDNS:infData, and
under the secDNS:chg of the secDNS:update?  From my perspective this might
be useful in the handling of DNS hosting transfers, where the Registrant can
request for a reduced ttl for the DS RRset and the RRSIG resource record
when moving the DNSSEC enabled domain to another DNS hosting provider.  The
DNS hosting provider could obviously be another Registrar as part of a
sponsorship transfer.

Any thoughts to this is greatly appreciated.

According to the AD the last call review period will be extended and should
be on the IESG telechat agenda for March 4th, so I would like to incorporate
as much feedback as possible to the 04 draft in a soon to follow 05 draft.

Thanks,

-- 

JG 

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

From: James Gould <[email-masked]>
Date: Wed, 10 Feb 2010 23:07:31 -0500
To: EPP Provreg <[email-masked]>
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: draft-gould-rfc4310bis-04.txt Submitted for Review

All,

Thanks,

-- 

JG 

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

---

From: [email-masked]
Date: Fri, 12 Feb 2010 16:35:31 +0000

[email-masked] wrote on 11/02/2010 04:07:31:
> James Gould <[email-masked]>
> I submitted 04 of the draft.  The official draft is available at theURL
> http://www.ietf.org/id/draft-gould-rfc4310bis-04.txt

thanks, James
just a picky detail; ISTM that the minOccurs="0" for maxSigLife in chgType
is redundant, because chgType is already optional in updateType (it was
required when it was a member of dsDataType but isn't any more).  Come to
think of it, maxSigLife could just be an element in updateType.
kind regards,
Anthony

e.g.
<!-- Child elements of the <update> element. -->
<complexType name="updateType">
  <sequence>
    <element name="rem" type="secDNS:remType" minOccurs="0"/>
    <element name="add" type="secDNS:dsOrKeyType" minOccurs="0"/>
    <element name="maxSigLife" type="secDNS:maxSigLifeType" minOccurs="0"/>
  </sequence>
  <attribute name="urgent" type="boolean" default="false"/>
</complexType>

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

---

From: James Gould <[email-masked]>
Date: Fri, 12 Feb 2010 11:41:57 -0500

Anthony,

Thanks for the feedback.  I originally had maxSigLife under the
secDNS:update but it was pointed out in a private message that it should be
under secDNS:chg to be consistent with the other EPP RFC¹s.  The secDNS:chg
follows the other EPP RFC¹s by having minOccurs=²0² and subsequently any
attributes that can be changed have minOccurs=²0² which in this case is only
the single attribute maxSigLife.  With this structure additional attributes
can be more easily added that are consistent with the other EPP RFC¹s.  I
sent a question out to the list about the option of adding the ttl
attribute, which would add a second optional element under secDNS:chg.

Thanks, 

-- 

JG 

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

From: <[email-masked]>
Date: Fri, 12 Feb 2010 11:35:31 -0500
To: James Gould <[email-masked]>
Cc: EPP Provreg <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for
Review

thanks, James

e.g.

---

From: James Gould <[email-masked]>
Date: Mon, 15 Feb 2010 19:26:01 -0500

All,

I haven¹t heard any feedback on the idea of adding a client specified ttl
value and an optional server ttl returned in the info response used in a
similar fashion as the maxSigLife element.  The use case I see for this is
allowing the client to determine what the ttl is for the DS RRset and the
RRSIG resource record and for the client to have the option of decreasing
the ttl in support of a DNS hosting transfer, which could be part of a
sponsorship transfer.  To enable the DNS hosting transfer of a DNSSEC
enabled domain without going insecure by removing the DS records, the losing
DNS hosting provider needs to be capable of accepting the gaining DNS
hosting provider¹s public keys and the gaining DNS hosting provider¹s DS
needs to be added to the parent zone.   The switching of the name servers
has to wait for the longest of the ttl¹s (child and parent zone) to account
for DNS caching, so having visibility of the ttl of the DNSSEC resource
records of the server and to have the capability to adjust the ttl (down
during the transfer) could help with the DNS hosting transfer process.  If
such a feature needs to be added to rfc4310bis, I need to receive feedback
early this week to be included in the rfc4310bis 05 draft.  I plan on
publishing the rfc4310bis 05 draft on Wednesday that includes all of the
feedback received so far.

Thanks,  

-- 

JG 

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

From: James Gould <[email-masked]>
Date: Fri, 12 Feb 2010 11:04:46 -0500
To: EPP Provreg <[email-masked]>
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: Re: draft-gould-rfc4310bis-04.txt Submitted for Review

All,

Thanks,

-- 

JG 

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

All,

Thanks,

-- 

JG 

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

---

From: Howard Eland <[email-masked]>
Date: Tue, 16 Feb 2010 12:00:40 -0600

Hi James,

Thanks for the ping about this issue.

Transfers (specifically, those that involve changes to a DNS provider) are a complex issue, and are of a much bigger scope than what we can accomplish in 4310-bis.  For a transfer involving glue (in which the IP address of the glue record would change), there is the issue of TTL on the glue record.  Regardless of how well a registrant turns down the TTL for the RS and RRSIG records, it will still be subject to glue TTL, which, as I mentioned, is out of scope for us.  Thus, the ability to set the TTL on DS and RRSIGs is not sufficient to ensure a smooth transfer.  

There is also the ability for registrars (or registrants, through their registrar GUI) to misuse theTTL value.  I would not want to see a TTL of 0, nor would I want to see $HUGE_VAL.  In fact, short DS and RRSIG TTLs could cause an inordinate amount of queries to hit the parent name server, resulting in amplification attacks.  This could, of course, be controlled by server policy, but that policy may hinder the ability of the registrant to turn down the TTL, which defeats the purpose.

Disclaimer: I have not gone back through the provreg archive to see the rationale for not providing TTLs in EPP proper, so I do not know if that reasoning extends to this issue, or if it was an oversight.

I'm interested in a counter argument to this, but for now, I am not in favor of adding TTL.

-Howard

On Feb 15, 2010, at 6:26 PM, James Gould wrote:

> All,
> 
> I haven’t heard any feedback on the idea of adding a client specified ttl value and an optional server ttl returned in the info response used in a similar fashion as the maxSigLife element.  The use case I see for this is allowing the client to determine what the ttl is for the DS RRset and the RRSIG resource record and for the client to have the option of decreasing the ttl in support of a DNS hosting transfer, which could be part of a sponsorship transfer.  To enable the DNS hosting transfer of a DNSSEC enabled domain without going insecure by removing the DS records, the losing DNS hosting provider needs to be capable of accepting the gaining DNS hosting provider’s public keys and the gaining DNS hosting provider’s DS needs to be added to the parent zone.   The switching of the name servers has to wait for the longest of the ttl’s (child and parent zone) to account for DNS caching, so having visibility of the ttl of the DNSSEC resource records of the server and to have the capability to adjust the ttl (down during the transfer) could help with the DNS hosting transfer process.  If such a feature needs to be added to rfc4310bis, I need to receive feedback early this week to be included in the rfc4310bis 05 draft.  I plan on publishing the rfc4310bis 05 draft on Wednesday that includes all of the feedback received so far. 
> 
> Thanks,  
> 
> -- 
> 
> 
> JG 
> 
> 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.
> 
> 
> I forgot about one item brought up by Klaus in a prior posting related to inclusion of ttl in rfc4310bis.  What does the list feel about the need for adding support for an optional client specified ttl value and an optional server ttl returned in the info response used in a similar fashion as the maxSigLife, meaning directly under the secDNS:create, secDNS:infData, and under the secDNS:chg of the secDNS:update?  From my perspective this might be useful in the handling of DNS hosting transfers, where the Registrant can request for a reduced ttl for the DS RRset and the RRSIG resource record when moving the DNSSEC enabled domain to another DNS hosting provider.  The DNS hosting provider could obviously be another Registrar as part of a sponsorship transfer.  
> 
> According to the AD the last call review period will be extended and should be on the IESG telechat agenda for March 4th, so I would like to incorporate as much feedback as possible to the 04 draft in a soon to follow 05 draft.  
> 
> Thanks,
> 
> -- 
> 
> 
> JG 
> 
> 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.
> 
> 
> There are many updates from 03 described in Appendix A based on the feedback on the list and privately.  These changes are substantial, so please review it and provide me with your feedback as soon as possible.  
> 
> I did not include anything in 04 related to Eduardo’s active flag request based on the variety of feedback on the provreg list that shows that it’s not ready for inclusion in rfc4310bis.  I encourage that the discussions continue on the list for possible inclusion in a future draft. 
> 
> Thanks,
> 
> -- 
> 
> 
> JG 
> 
> 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: Olafur Gudmundsson <[email-masked]>
Date: Tue, 16 Feb 2010 14:53:13 -0500

On 16/02/2010 1:00 PM, Howard Eland wrote:
> Transfers (specifically, those that involve changes to a DNS provider)
> are a complex issue, and are of a much bigger scope than what we can
> accomplish in 4310-bis. For a transfer involving glue (in which the IP
> address of the glue record would change), there is the issue of TTL on
> the glue record. Regardless of how well a registrant turns down the TTL
> for the RS and RRSIG records, it will still be subject to glue TTL,
> which, as I mentioned, is out of scope for us. Thus, the ability to set
> the TTL on DS and RRSIGs is not sufficient to ensure a smooth transfer.
>
> There is also the ability for registrars (or registrants, through their
> registrar GUI) to misuse theTTL value. I would not want to see a TTL of
> 0, nor would I want to see $HUGE_VAL. In fact, short DS and RRSIG TTLs
> could cause an inordinate amount of queries to hit the parent name
> server, resulting in amplification attacks. This could, of course, be
> controlled by server policy, but that policy may hinder the ability of
> the registrant to turn down the TTL, which defeats the purpose.

Howard,
as you mention above this is big issue.
While I'm sympathetic to your concerns on possible flood of DS 
questions, that would only take place if the DNSKEY in the child also
had a small TTL and the child was a popular domain :-)

My suggestion is suggest that each parent set a resonable default and
a floor on how low the TTL can be set, the child would be allowed to
seletct at TTL between these two numbers.
	
	Olafur

---

From: Howard Eland <[email-masked]>
Date: Tue, 16 Feb 2010 15:33:42 -0600

On Feb 16, 2010, at 1:53 PM, Olafur Gudmundsson wrote:

> While I'm sympathetic to your concerns on possible flood of DS questions, that would only take place if the DNSKEY in the child also

If they're in the middle of a transfer, and they are turning down the TTL of the DS record, I'm assuming they're also turning down the corresponding DNSKEYs, so I think that scenario is still very plausible.  WIthin the TLD namespace, there are many popular domains (I realize that this may not be the case for all implementors, though).

> seletct at TTL between these two numbers.

Possibly, if a reasonable tradeoff can be made here.  Of course, if we have wording about server policy being able to define the floor and ceiling, then technically operators could force it to be a single value, if they so desired.

-Howard

---

From: James Gould <[email-masked]>
Date: Tue, 16 Feb 2010 16:51:22 -0500

>> 
>> My suggestion is suggest that each parent set a reasonable default and
> Possibly, if a reasonable tradeoff can be made here.  Of course, if we have
> wording about server policy being able to define the floor and ceiling, then
> technically operators could force it to be a single value, if they so desired.

I would view this as an optional server feature, so if a server does not
want to support a client-specified value they don¹t have to and should
return a 2102 to the client in a similar fashion to the maxSigLife.  If they
did support a client-specified value the floor and ceiling values is a
server policy decision.  It would be nice if the server did return the
server-side default TTL for the DNSSEC resource records to help define the
maximum wait period, but again that would be optional.  If the visibility
and setting of the ttl will assist in the transfers, than it would be good
if the protocol did provide support for it.  I guess I want to understand if
others see the benefit of this.

-- 

JG 

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

From: Howard Eland <[email-masked]>
Date: Tue, 16 Feb 2010 16:33:42 -0500
To: Olafur Gudmundsson <[email-masked]>
Cc: James Gould <[email-masked]>, EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for
Review

> seletct at TTL between these two numbers.

Possibly, if a reasonable tradeoff can be made here.  Of course, if we have
wording about server policy being able to define the floor and ceiling, then
technically operators could force it to be a single value, if they so
desired.

---

From: James Gould <[email-masked]>
Date: Wed, 17 Feb 2010 17:06:54 -0500

All,

I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which
includes the feedback that I received so far.  I included an open question
on the inclusion of the ttl element to the AD for guidance.  Please let me
know if you have any feedback to the latest draft.

Thanks,  

-- 

JG 

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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sun, 21 Feb 2010 18:14:38 +0100 (CET)

Hi James

Thanks for the update!

Concerning the transition considerations:

    3.  The version of <secDNS:infData> to return for a domain info
        command SHOULD be defined by the secDNS extURI's included in the
        EPP login services using the following mapping:
    [...]

- This does not specify the behavior of Hello & Greeting (RFC 5730, 
2.3/2.4), where extensions are queried too. This might lead to 
inconsistencies in the extension announcements of an EPP server.

- Furthermore I consider it a bad idea, if EPP servers hide extensions 
from EPP clients. While such behavior is not prohibited by RFC 5730, it 
potentially introduces inconsistencies in the feature negotiation process.

- The text (as it is) leads to confusion among implementors.

For these reasons, I suggest to replace the 3rd bullet point by a 
recommendation, that the EPP client SHOULD always use 1.1, if mutually 
supported by EPP server and client (or sth similar).
(The EPP server should always be honest about his supported extensions.)

cheers,
  Bernie

On Wed, 17 Feb 2010, James Gould wrote:

> All,
> 
> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which includes the feedback that I received so far.  I included an open
> question on the inclusion of the ttl element to the AD for guidance.  Please let me know if you have any feedback to the latest draft.
> 
> Thanks,  
> 
> --
> 
> 
> JG
> 
> 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: Howard Eland <[email-masked]>
Date: Tue, 23 Feb 2010 15:17:01 -0600

In addition to that already posted to the list, I have the following comments:

Section 3.3.  Maximum Signature LIfetime
Nit: for clarity, you may want to add "in the parent zone" to the end of the sentence "The maxSigLife value applies to the RRSIG resource record (RR) over the DS RRset.".

Section 5.1.2. EPP <info> Command, Example <info> Response for a Secure Delegation using the Key Data Interface:
I believe the server should also return the server generated <secDNS:dsData> when the client only sends in the Key Data interface.

Section 5.2.1. EPP <create> Command, second bullet set plus examples
It is not clear in this section of the document that <secDNS:dsData> and <secDNS:keyData> elements, when used to create DS records on the server, cannot be intermixed.  The text seems to imply that under a single <secDNS:create>, one could specify multiple <secDNS:dsData> elements, multiple <secDNS:keyData> elements, or a mixture of both, as a method for creating multiple DS records in the server.  Using this interpretation, the example is actually ambiguous, as it is not sure if the <secDNS:keyData> is part of the optional "validation" element for the previous <secDNS:dsData>, or if it is implying the creation of another DS record by using only the <secDNS:keyData> for the second DS.  I understand it's specified in the XML explicitly as "dsOrKeyType", but the text under create should reflect this as well.

The text could do one of the following:
0) Add text that explicitly states that only one of <secDNSdsData> or <secDNS:keyData> can be specified.
1) Change the "Zero or more" statement to "Zero or one", forcing a <secDNS:create> for each DS record desired (although this hoses up maxSigLife, so there's a bit more to this than just that).
2) Add something akin to a <secDNS:dsKeyData> element that would be used as a wrapper for the <secDNS:keyData> when it is used as the optional element under <secDNS:dsData>.  This would avoid confusion as to when the client was specifying <secDNS:keyData> for validation purposes, or when it's used to specify another DS.  In fact, couldn't doing this eliminate the need for <secDNS:dsData> and <secDNS:keyData> to be mutually exclusive?

9. Security Considerations, 2nd to last paragraph
After "Data validity checking", add "and Delegation Signer record creation".

-Howard

On Feb 17, 2010, at 4:06 PM, James Gould wrote:

> All,
> 
> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which includes the feedback that I received so far.  I included an open question on the inclusion of the ttl element to the AD for guidance.  Please let me know if you have any feedback to the latest draft. 
> 
> Thanks,  
> 
> -- 
> 
> 
> JG 
>

---

From: James Gould <[email-masked]>
Date: Tue, 23 Feb 2010 17:31:19 -0500

Howard,

Thanks for the feedback.  Below is my reply to your feedback:

> Nit: for clarity, you may want to add "in the parent zone" to the end of the
> sentence "The maxSigLife value applies to the RRSIG resource record (RR) over
> the DS RRset.".

No problem I can add this to the 06 draft.

> I believe the server should also return the server generated <secDNS:dsData>
> when the client only sends in the Key Data interface.

What is the purpose for doing this, since with the Key Data Interface the
client is managing the keys and the server is managing the DS associated
with the keys?  What would the client really do with the DS returned since
they don¹t explicitly set it or manage it.  We don¹t return the RRSIG
resource records with the DS Data Interface, so why would another generated
set of resource records be returned back?

> It is not clear in this section of the document that <secDNS:dsData> and
> <secDNS:keyData> elements, when used to create DS records on the server,
> cannot be intermixed.  The text seems to imply that under a single
> <secDNS:create>, one could specify multiple <secDNS:dsData> elements, multiple
> <secDNS:keyData> elements, or a mixture of both, as a method for creating
> multiple DS records in the server.  Using this interpretation, the example is
> actually ambiguous, as it is not sure if the <secDNS:keyData> is part of the
> optional "validation" element for the previous <secDNS:dsData>, or if it is
> implying the creation of another DS record by using only the <secDNS:keyData>
> for the second DS.  I understand it's specified in the XML explicitly as
> "dsOrKeyType", but the text under create should reflect this as well.

This text is used throughout the draft, since section 4 ³DS Data Interface
and Key Data Interface² is meant to more fully define the two supported
interfaces of using either <secDNS:dsData> elements or <secDNS:keyData>,
where only one is used.  It is hard for me to believe that it can be
interpreted to use the optional ³validation² element of the <secDNS:dsData>
in the sentence ³Zero or more <secDNS:dsData> elements or <secDNS:keyData>
elements².  Based on your proposal 0, would it be clearer to say ³Zero or
more <secDNS:dsData> elements or <secDNS:keyData> elements, but not both as
defined in section 4²?  I view this as being redundant, but maybe because I
wrote it.  Please let me know if this sentence is really ambiguous and
whether the extra verbiage for the one sentence helps.

> After "Data validity checking", add "and Delegation Signer record creation".

No problem I can add this to the 06 draft.

-- 

JG 

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

From: Howard Eland <[email-masked]>
Date: Tue, 23 Feb 2010 16:17:01 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for
Review

In addition to that already posted to the list, I have the following
comments:

Section 3.3.  Maximum Signature LIfetime
Nit: for clarity, you may want to add "in the parent zone" to the end of the
sentence "The maxSigLife value applies to the RRSIG resource record (RR)
over the DS RRset.".

Section 5.1.2. EPP <info> Command, Example <info> Response for a Secure
Delegation using the Key Data Interface:
I believe the server should also return the server generated <secDNS:dsData>
when the client only sends in the Key Data interface.

Section 5.2.1. EPP <create> Command, second bullet set plus examples
It is not clear in this section of the document that <secDNS:dsData> and
<secDNS:keyData> elements, when used to create DS records on the server,
cannot be intermixed.  The text seems to imply that under a single
<secDNS:create>, one could specify multiple <secDNS:dsData> elements,
multiple <secDNS:keyData> elements, or a mixture of both, as a method for
creating multiple DS records in the server.  Using this interpretation, the
example is actually ambiguous, as it is not sure if the <secDNS:keyData> is
part of the optional "validation" element for the previous <secDNS:dsData>,
or if it is implying the creation of another DS record by using only the
<secDNS:keyData> for the second DS.  I understand it's specified in the XML
explicitly as "dsOrKeyType", but the text under create should reflect this
as well.

The text could do one of the following:
0) Add text that explicitly states that only one of <secDNSdsData> or
<secDNS:keyData> can be specified.
1) Change the "Zero or more" statement to "Zero or one", forcing a
<secDNS:create> for each DS record desired (although this hoses up
maxSigLife, so there's a bit more to this than just that).
2) Add something akin to a <secDNS:dsKeyData> element that would be used as
a wrapper for the <secDNS:keyData> when it is used as the optional element
under <secDNS:dsData>.  This would avoid confusion as to when the client was
specifying <secDNS:keyData> for validation purposes, or when it's used to
specify another DS.  In fact, couldn't doing this eliminate the need for
<secDNS:dsData> and <secDNS:keyData> to be mutually exclusive?

-Howard

On Feb 17, 2010, at 4:06 PM, James Gould wrote:

> includes the feedback that I received so far.  I included an open question on
> the inclusion of the ttl element to the AD for guidance.  Please let me know
> if you have any feedback to the latest draft.
> 
> Thanks,  
> 
> -- 
> 
> 
> JG 
> 
> [email-masked] <x-msg://170/[email-masked]>
> Direct: 703.948.3271
> Mobile: 703.628.7063
> 
>  
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Feb 2010 20:48:08 -0500

On 2010-02-23, at 16:17, Howard Eland <[email-masked]> wrote:

> Nit: for clarity, you may want to add "in the parent zone" to the  
> end of the sentence "The maxSigLife value applies to the RRSIG  
> resource record (RR) over the DS RRset.".
>

That actually seems confusing to me. The DS is only ever in the parent  
or an effective parent (e.g. Lookaside zone, where this could also be  
used). What's the benefit of adding this?

-- 
Andrew Sullivan
<[email-masked]>

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 24 Feb 2010 09:50:42 +0100

Hi,

> I believe the server should also return the server generated
> <secDNS:dsData> when the client only sends in the Key Data interface.

the registry could decide to put two ds records for each key in the 
zone. Should both ds records be returned and hence the key be returned 
twice? I believe that if the registry policy is to store key data it 
should return key data. In my eyes it is much easier for the client if 
the data sent and returned match.

/Ulrich

---

From: Howard Eland <[email-masked]>
Date: Wed, 24 Feb 2010 07:36:02 -0600

If it seems more confusing, then never mind (note the "may" in my original comment).  It seems we have a couple of folks on the list that didn't care for this.

-Howard

On Feb 23, 2010, at 7:48 PM, Andrew Sullivan wrote:

> That actually seems confusing to me. The DS is only ever in the parent or an effective parent (e.g. Lookaside zone, where this could also be used). What's the benefit of adding this?
> 
> 
> -- 
> Andrew Sullivan
> <[email-masked]>

---

From: Howard Eland <[email-masked]>
Date: Wed, 24 Feb 2010 07:38:17 -0600

I was adding this to aid the registrar in checking for problems w/ DS records once they sent in the key data, but in hindsight I don't think it adds any real value, either, since what they will most likely want to check is the <secDNS:keyData> they sent in.

I am fine with leaving this out as well.

-Howard

On Feb 24, 2010, at 2:50 AM, Ulrich Wisser wrote:

> the registry could decide to put two ds records for each key in the zone. Should both ds records be returned and hence the key be returned twice? I believe that if the registry policy is to store key data it should return key data. In my eyes it is much easier for the client if the data sent and returned match.
> 
> /Ulrich

---

From: James Gould <[email-masked]>
Date: Thu, 25 Feb 2010 19:10:00 -0500

All,

I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt which
includes the feedback that I received so far and will be the basis for the
IESG review.  Please let me know if you have any feedback to the latest
draft. 

Thanks,  

-- 

JG 

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

---

From: [email-masked]
Date: Fri, 26 Feb 2010 10:14:55 +0000

> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt 
> which includes the feedback that I received so far and will be the 
> basis for the IESG review.  Please let me know if you have any 
> feedback to the latest draft. 

Not being an EPP guru, what's the rationale for requiring a 2102 error if 
the server doesn't support <secDNS:update urgent="1"> or 
<secDNS:maxSigLife> ?

I would have thought that Postel's law should apply, otherwise a registrar 
has to have advance knowledge of which registries support those elements 
and which don't, and alter their submitted XML accordingly.  I can't 
immediately see how any harm would come from simply ignoring those 
elements.

Also, I note that §4 says that a server MUST support either 
<secDNS:dsData> or <secDNS:keyData>, but not both (unless in transition 
from one to the other).  However I can find no guidance on what should 
happen if the client sends the wrong one.  The schema is clear that it's a 
choice, but that only affects individual messages, and doesn't reflect the 
server's capabilities. 

BTW, §10 (Acknowledgements) says that this doc _updates_ 4310 and refers 
readers to that document's acknowledgements section, whereas elsewhere 
it's clear that it obsoletes it.  There's also an informative reference to 
4310.  I don't believe it's permitted to both obsolete a document and 
refer to it at the same time.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 26 Feb 2010 12:01:35 +0100 (CET)

Hi Ray, James et al.

On Fri, 26 Feb 2010, [email-masked] wrote:

> it's clear that it obsoletes it.  

Yep, "updates" is inaccurate here:  --> s/updates/obsoletes/
(I just notified an author of 3761bis about this inaccuracy as I "stole" 
that sentence from 3761bis before suggesting it to James...)

> There's also an informative reference to 4310.  I don't believe it's 
> permitted to both obsolete a document and refer to it at the same time.

To obsolete a document one needs to refer to it. I don't see a reason why 
this should not be permitted. There are many examples which include a 
reference to the document they obsolete, e.g.

   http://tools.ietf.org/html/rfc5226

cheers,
  Bernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 26 Feb 2010 06:24:07 -0500

The informative reference to 4310 is perfectly appropriate, but yes, any mention of "updates" should be changed.
 
I'll let Jim take care of your other comments since he's holding the editing pen.
 
Scott

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Friday, February 26, 2010 5:15 AM
	To: Gould, James
	Cc: EPP Provreg
	Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review

	> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt <http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt>  
	
	Not being an EPP guru, what's the rationale for requiring a 2102 error if the server doesn't support <secDNS:update urgent="1"> or <secDNS:maxSigLife> ? 
	
	I would have thought that Postel's law should apply, otherwise a registrar has to have advance knowledge of which registries support those elements and which don't, and alter their submitted XML accordingly.  I can't immediately see how any harm would come from simply ignoring those elements. 
	
	Also, I note that §4 says that a server MUST support either <secDNS:dsData> or <secDNS:keyData>, but not both (unless in transition from one to the other).  However I can find no guidance on what should happen if the client sends the wrong one.  The schema is clear that it's a choice, but that only affects individual messages, and doesn't reflect the server's capabilities.   
	
	BTW, §10 (Acknowledgements) says that this doc _updates_ 4310 and refers readers to that document's acknowledgements section, whereas elsewhere it's clear that it obsoletes it.  There's also an informative reference to 4310.  I don't believe it's permitted to both obsolete a document and refer to it at the same time. 
	
	kind regards, 
	
	Ray

---

From: James Gould <[email-masked]>
Date: Fri, 26 Feb 2010 15:39:45 -0500

Ray,

> Not being an EPP guru, what's the rationale for requiring a 2102 error if the
> server doesn't support <secDNS:update urgent="1"> or <secDNS:maxSigLife> ?

The rationale is if a client passes an optional element or attribute that is
not supported by the server the server should return an error instead of
ignoring it.  If the server were to ignore the optional element or attribute
than how does the client  know whether the optional element or attribute is
supported and applied?  It¹s best that the server return an error when
receiving optional elements and attributes that it does not support.  The
2102 ³Unimplemented option² is the appropriate error result code for this
scenario.

> I would have thought that Postel's law should apply, otherwise a registrar has
> to have advance knowledge of which registries support those elements and which
> don't, and alter their submitted XML accordingly.  I can't immediately see how
> any harm would come from simply ignoring those elements.

The harm is for clients that do desire the optional elements or attributes
to be applied.  The server should not ignore optional attributes that it
doesn¹t support otherwise clients would expect that it was applied.

> Also, I note that §4 says that a server MUST support either <secDNS:dsData> or
> <secDNS:keyData>, but not both (unless in transition from one to the other).
> However I can find no guidance on what should happen if the client sends the
> wrong one.  The schema is clear that it's a choice, but that only affects
> individual messages, and doesn't reflect the server's capabilities.

I would see 2306 ³Parameter value policy error² as the appropriate error
response in this case.  This could be added to the end of the paragraph of
section 4 in 07. 

> readers to that document's acknowledgements section, whereas elsewhere it's
> clear that it obsoletes it.  There's also an informative reference to 4310.  I
> don't believe it's permitted to both obsolete a document and refer to it at
> the same time. 

I already read Bernie¹s response to this one and I¹ll defer to him on this
one since he made both recommendations.

-- 

JG 

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

From: <[email-masked]>
Date: Fri, 26 Feb 2010 05:14:55 -0500
To: James Gould <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for
Review

> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt
<http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt>

Not being an EPP guru, what's the rationale for requiring a 2102 error if
the server doesn't support <secDNS:update urgent="1"> or <secDNS:maxSigLife>
? 

I would have thought that Postel's law should apply, otherwise a registrar
has to have advance knowledge of which registries support those elements and
which don't, and alter their submitted XML accordingly.  I can't immediately
see how any harm would come from simply ignoring those elements.

Also, I note that §4 says that a server MUST support either <secDNS:dsData>
or <secDNS:keyData>, but not both (unless in transition from one to the
other).  However I can find no guidance on what should happen if the client
sends the wrong one.  The schema is clear that it's a choice, but that only
affects individual messages, and doesn't reflect the server's capabilities.

BTW, §10 (Acknowledgements) says that this doc _updates_ 4310 and refers
readers to that document's acknowledgements section, whereas elsewhere it's
clear that it obsoletes it.  There's also an informative reference to 4310.
I don't believe it's permitted to both obsolete a document and refer to it
at the same time. 

kind regards, 

Ray