Subject: For provreg-archive,we return to -80% prices

From: "SuperShop on-line" <[email-masked]>
Date: Sat, 27 Feb 2010 12:48:06 -0800 (PST)

Cannot see this email?
click here.

You are subscribed as [email-masked]

You can unsubscribe here.

Check our privacy policy.

Copyright c 2009 EBOLYETYLO. All rights reserved.

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QKdoYd003929 for ; Fri, 26 Feb 2010 21:39:50 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1QKdo8L007624 for ietf-provreg-outgoing; Fri, 26 Feb 2010 21:39:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QKdnDn008027 for ; Fri, 26 Feb 2010 21:39:49 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o1QKJuDm001172; Fri, 26 Feb 2010 15:19:57 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Feb 2010 15:39:48 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Feb 2010 20:39:47 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 26 Feb 2010 15:39:45 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
From: James Gould
To:
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
Thread-Index: Acq2zI6EnXWowCuaRYaqt1RVIj7GXAAV0X2U
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3350043586_12146589"
X-OriginalArrivalTime: 26 Feb 2010 20:39:48.0521 (UTC) FILETIME=[D6938190:01CAB723]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3350043586_12146589
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Ray,

> Not being an EPP guru, what's the rationale for requiring a 2102 error if=
the
> server doesn't support or =
?

The rationale is if a client passes an optional element or attribute that i=
s
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 attribut=
e
than how does the client know whether the optional element or attribute is
supported and applied? It=B9s best that the server return an error when
receiving optional elements and attributes that it does not support. The
2102 =B3Unimplemented option=B2 is the appropriate error result code for this
scenario.

> I would have thought that Postel's law should apply, otherwise a registra=
r 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 se=
e 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=B9t support otherwise clients would expect that it was applied.

> Also, I note that =A74 says that a server MUST support either or
> , but not both (unless in transition from one to the othe=
r).
> 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 =B3Parameter value policy error=B2 as the appropriate error
response in this case. This could be added to the end of the paragraph of
section 4 in =AD07.=20

> BTW, =A710 (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 431=
0. I
> don't believe it's permitted to both obsolete a document and refer to it =
at
> the same time.=20

I already read Bernie=B9s response to this one and I=B9ll defer to him on this
one since he made both recommendations.

--=20

JG=20

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

=20
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 writte=
n
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:
Date: Fri, 26 Feb 2010 05:14:55 -0500
To: James Gould
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

> 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 or
?=20

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

Also, I note that =A74 says that a server MUST support either
or , 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, =A710 (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.=20

kind regards,=20

Ray=20

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

--B_3350043586_12146589
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Ray,

> Not being an EPP guru, what's the rationale for requiring a=
2102 error if the

> server doesn't support <secDNS:update urgent=3D"1"> or &=
lt;secDNS:maxSigLife> ?

The rationale is if a client passes an optional element or attribute that i=
s not supported by the server the server should return an error instead of i=
gnoring it.  If the server were to ignore the optional element or attri=
bute than how does the client  know whether the optional element or att=
ribute is supported and applied?  It’s best that the server retur=
n an error when receiving optional elements and attributes that it does not =
support.  The 2102 “Unimplemented option” is the appropriat=
e error result code for this scenario.

> I would have though=
t that Postel's law should apply, otherwise a registrar has

> to have advance knowledge of which registries support those elements a=
nd which

> don't, and alter their submitted XML accordingly.  I can't immedi=
ately 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 i=
t doesn’t support otherwise clients would expect that it was applied. =

> Also, I note that &=
sect;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 sen=
ds 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. &n=
bsp;

I would see 2306 “Parameter value policy error” as the appropri=
ate error response in this case.  This could be added to the end of the=
paragraph of section 4 in –07.

> BTW, §10 (Ackn=
owledgements) 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 referenc=
e 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

-------------------------------------------------------

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: <[email-masked]>

Date: Fri, 26 Feb 2010 05:14:55 -0500

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

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-rfc4310bi=
s-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, w=
hat's the rationale for requiring a 2102 error if the server doesn't support=
<secDNS:update urgent=3D"1"> or <secDNS:maxSigLife> ?

I would have thought tha=
t Postel's law should apply, otherwise a registrar has to have advance knowl=
edge of which registries support those elements and which don't, and alter t=
heir submitted XML accordingly.  I can't immediately see how any harm w=
ould 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). &nb=
sp;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 a=
ffects individual messages, and doesn't reflect the server's capabilities. &=
nbsp;

BTW, §10 (Acknowled=
gements) says that this doc _updates_ 4310 and refers readers to that docume=
nt's acknowledgements section, whereas elsewhere it's clear that it obsolete=
s it.  There's also an informative reference to 4310.  I don't bel=
ieve 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<=
BR>

--B_3350043586_12146589--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QBOClQ008550 for ; Fri, 26 Feb 2010 12:24:12 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1QBOCbl021814 for ietf-provreg-outgoing; Fri, 26 Feb 2010 12:24:12 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QBOBV2028722 for ; Fri, 26 Feb 2010 12:24:11 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o1QB4Is4013045; Fri, 26 Feb 2010 06:04:19 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Feb 2010 06:24:10 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB6D6.36CE1EF0"
Subject: RE: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
Date: Fri, 26 Feb 2010 06:24:07 -0500
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
Thread-Index: Acq2z+KN16Kv9nliRkGACsUIBTq26wABhAsg
References:
From: "Hollenbeck, Scott"
To: , "Gould, James"
Cc: "EPP Provreg"
X-OriginalArrivalTime: 26 Feb 2010 11:24:10.0110 (UTC) FILETIME=[3755B1E0:01CAB6D6]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAB6D6.36CE1EF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The informative reference to 4310 is perfectly appropriate, but yes, any =
mention of "updates" should be changed.
=20
I'll let Jim take care of your other comments since he's holding the =
editing pen.
=20
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
=09
=09
=09
> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt =
=20
> which includes the feedback that I received so far and will be the=20
> basis for the IESG review. Please let me know if you have any=20
> feedback to the latest draft.=20
=09
Not being an EPP guru, what's the rationale for requiring a 2102 error =
if the server doesn't support or =
?=20
=09
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.=20
=09
Also, I note that =A74 says that a server MUST support either =
or , 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. =20
=09
BTW, =A710 (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.=20
=09
kind regards,=20
=09
Ray=20
=09
--=20
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211
=09
=09
=09
=09

------_=_NextPart_001_01CAB6D6.36CE1EF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The informative reference to 4310 is =
perfectly=20
appropriate, but yes, any mention of "updates" should be=20
changed.

I'll let Jim take care of your other comments =
since=20
he's holding the editing pen.

Scott

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

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

> which includes the feedback that I received so far =
and will=20
be the
> basis for the IESG review.  Please let me know if =
you=20
have any
> feedback to the latest draft. =

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

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

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

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

kind regards,

Ray

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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QB5ThE008081 for ; Fri, 26 Feb 2010 12:05:29 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1QB5TmI017303 for ietf-provreg-outgoing; Fri, 26 Feb 2010 12:05:29 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QB5Skw001553 for ; Fri, 26 Feb 2010 12:05:29 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nky0e-0005zX-3g; Fri, 26 Feb 2010 12:05:28 +0100
Date: Fri, 26 Feb 2010 12:05:27 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: [email-masked]
cc: EPP Provreg
Subject: Re: [ietf-provreg] NITS review of draft-gould-rfc4310bis (pre-6 version)
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

Hi Alex

Great review!

On Fri, 26 Feb 2010, Alexander Mayrhofer wrote:

> - Copyright: Since this document does very likely include Material that
> was published before November 2008, which means that another copyright
> boiler plate is likely required. I haven't checked that recently, but is
> suppose there's a different "ipr" tag required for that.
>
> Bernie, are you aware of what the latest "good" ipr tag is?

Hmmmm...this has been a moving target for a long time...

According to

http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#attribute-ipr

it should be "pre5378Trust200902".

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QB1eZq019329 for ; Fri, 26 Feb 2010 12:01:40 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1QB1ets026344 for ietf-provreg-outgoing; Fri, 26 Feb 2010 12:01:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QB1c7V018590 for ; Fri, 26 Feb 2010 12:01:38 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nkxwt-0005yg-1g; Fri, 26 Feb 2010 12:01:35 +0100
Date: Fri, 26 Feb 2010 12:01:35 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: Ray Bellis
cc: James Gould , EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
In-Reply-To:
Message-ID:
References:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-237347771-1267182095=:21578"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--37663318-237347771-1267182095=:21578
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi Ray, James et al.

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

> BTW, =A710 (Acknowledgements) says that this doc _updates_ 4310 and refer=
s=20
> readers to that document's acknowledgements section, whereas elsewhere=20
> it's clear that it obsoletes it. =A0

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

> There's also an informative reference to 4310. =A0I don't believe it's=20
> 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=
=20
this should not be permitted. There are many examples which include a=20
reference to the document they obsolete, e.g.

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

cheers,
Bernie
--37663318-237347771-1267182095=:21578--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QAgwRE016435 for ; Fri, 26 Feb 2010 11:42:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1QAgwvd029019 for ietf-provreg-outgoing; Fri, 26 Feb 2010 11:42:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from na.nona.net (engine01.malakii.net [188.40.65.119]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QAgwcs022537 for ; Fri, 26 Feb 2010 11:42:58 +0100 (MET)
Received: from [10.10.0.134] ([::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by kahua with esmtp; Fri, 26 Feb 2010 11:42:55 +0100 id 00000000001548A1.000000004B87A5B0.00007BAB
Message-ID: <[email-masked]>
Date: Fri, 26 Feb 2010 11:42:16 +0100
From: [email-masked]
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: [email-masked]
Subject: [ietf-provreg] NITS review of draft-gould-rfc4310bis (pre-6 version)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

FYI, i sent the following to the Author and document shepherd:

---

Hello,

Here's my NIT review for the draft (note that you might receive
contradicting comments from other IETF reviewers, and i deliberately
haven't compared the bis-Draft to the original RFC 4310):

Generally, i think there are a still a few open issues in the document.
Some might be nitpicking, some of them are major, and could create
interopability issues:

The major issues from my perspective are:
=========================================

- What's the motivation behind replacing 4310? This is not explained in
the document.
- What's the relation between the OPTIONAL keyData in the DS interface,
and pre-existing DS records in the registry?
- It's unclear whether servers can "mix" the DS and the key Data
interface, and what the implications are.
- I would appreciate if the relation between provisioning interface and
the DNS interface is described in greater detail (if that is in scope!)
- What is expected to happen on the DNS interface for a certain
provisioning request, for example a maxSigLifetime change? This could be
part of a non-normative "examples" or "use cases" section.

I think it's also worthwhile to resolve the nitpicking issues,
particularly because it's a -bis document that tries to resolve issues
in the original RFC, and hence should have very little "bugs" left.

Details in sequential order by section:
=======================================

- There's no need to extend abbreviations in the Abstract (although it's
not disallowed, either).

- The abstract should say "This document obsoletes RFC 4310" instead of
"is intended to"...

- Copyright: Since this document does very likely include Material that
was published before November 2008, which means that another copyright
boiler plate is likely required. I haven't checked that recently, but is
suppose there's a different "ipr" tag required for that.

Bernie, are you aware of what the latest "good" ipr tag is?

- Section 1:

In the introduction it might be unclear to the reader what "secDNS-1.1"
and "secDNS-1.0" refer to. Is that a name of a protocol, or some
identifier of the XML schema described? Ok, i see now it's defined in
1.1, so that is a "chicken and egg" problem - not sure how to resolve
that.. (but also not really serious)

I am missing in the introduction (or somewhere else, maybe?) what the
motivation for changing RFC 4310 is. Adding such a section might help
readers and implementors to understand the issues and reasoning behind
that update.

- Section 2:

it might not be necessary to mention again that "secDNS-1.0" is defined
in RFC 4310, and "secDNS-1.1" defined in this document. It's already in
the introduction - i would remove it. "in magrating from secDNS-1.0 to
secDNS-1.1" is enough.

The sentence that a client SHOULD only use 1.1 in the migration is
slightly misleading. In a situation where the server announces *both*
versions, it makes sense. However, in a situation where a server only
announces 1.1, there's an implicit MUST already from the EPP base
specification. Therefore, i suggest something simpler like: "If a server
announces support for both secDNS-1.0 and secDNS-1.1 in a greeting,
clients supporting both versions SHOULD prefer secDNS-1.1".

- bullet 1 is "self-fulfilling". Better would be "A server migrating
from secDNS-1.0 SHOULD support both secDNS-1.0 and secDNS-1.1 for a
reasonable migration period" (the "period of time" should be specified
somehow, because 0.56 seconds is clearly not enough ;-)

- i don't understand the reasoning for bullet 2 - Why is it important to
seperate the handlers? If i create a single handler that complies
perfectly to both the old and new version, why would that be a problem?
Also, the term "protocol handler" is somehow vague...

- bullet 3: I would add "element" and "command" behind the XML tags -
makes it clear what they refer to. Also, maybe amend "(indicating the
secDNS extension _version_)" for clarity. The sentence is also a bit
longish and confusing (at least to a non-native speaker like me ;)

Nit: You're having "was included" twice, and "is included" once in the
list below bullet 3 - is that intentional?

Section 3:

- "Only those new elements are described here" would be better than
"descriptions are described", i think..

Section 4:

- Is it intended that a server MUST supports just *one* of those two
interfaces, or *at least* one of them, but MAY support both? This is not
entirely clear from the text..

Section 4.1:

- "relies uses" - typo? What are "creates, adds, removes, replaces"? Are
those EPP commands, or abstract operations? If they are operations,
where are they defined? What's the relation of those operations to EPP
commands?

- Generally, it might make sense to keep a consistent style when
refering to EPP commands. For example, section 2 uses ""
for identifying a response to an EPP command, while this section uses
the plain word "info".

- The bullet describing the OPTIONAL keyData element is a bit confusing
to me, particularly because it's not clear to which "server" the
fragment "use in server validation" refers to - the DNS or the EPP
server? Maybe something like "describes the key data that the EPP server
uses as input for validating the DS records provided in the command"?

- MAJOR issue: Is that keyData only used for validating the DS records
provided in the same command only, or could there be cases where this
keyData is also used for validating DS records that have been
provisioned to the registry before? An example for example when
performing "add" and "remove" updates, what's the relation between
keyData and pre-existing DS records?

Section 4.3:

- The example snippets should at least use proper XML namespace
definitions for "secDNS", to make clear what the schema is... Is it -1.1
or is it -1.0, for example?

Section 5.1.2:

- The second bullet describing the contents of the "dsData" element
confuses me slighty, particularly the "that describe .... That
describes" indirection (if that's not a leftover from some copy & paste
operations). Maybe this sentence could be split up for clarity?

Section 5.1.3:

I understand that the "transfer" command mentioned here are the
"transfer query" commands. However, that's not explained in that
section, which makes it look as if it overlaps the following Section
where the transform type transfer commands are described. It would be
good to clarify that 5.1.3 is about the query sub-types of the transfer
command. The relation between 5.2.4 and 5.1.3 is unclear...

Section 5.2.5:

- Typo "An OPTIONAL The " ...

(Note: i have not reviewed the XML schema for validity, nor have i
validated the examples against the schema. I assume that this has
already been done as part of previous reviews)

Tia,

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QAEwxe024376 for ; Fri, 26 Feb 2010 11:14:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1QAEwI7002987 for ietf-provreg-outgoing; Fri, 26 Feb 2010 11:14:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1QAEvWl029622 for ; Fri, 26 Feb 2010 11:14:57 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=Z2J1K267LllFC/PYJBM3mYfofnZeqBZXg6ZB0LsnS65ydYLoBeDzBh78 sMbcg0SO/1kNjc56u+Ac8oKkxphU73h+X8/O5poUSC+y+V3Zz59IK36s0 jHjDBDtUsf+IlOp;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1267179297; x=1298715297; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20[ietf -provreg]=20draft-gould-rfc4310bis-06.txt=20Submitted=20f or=20Review|Date:=20Fri,=2026=20Feb=202010=2010:14:55=20+ 0000|Message-ID:=20|To:=20James=20Gould =20|Cc:=20EPP=20Provreg=20|MIME-Version:=201.0|In-Reply-To:=20|References:=20=20; bh=uKruY112f7KPN35H/A+0cKkURQ3sATNVg4E/3gHBcsc=; b=C3Tw9Z5Qg36sVXs+gnp3rbuB9N+gVUDaWzYcp9JOb0+3VLRaTR89nDmm O1uxFJH2aeTjyj7Ri5VuDHjZTYAZPUq1Ch40wsu0ofkKIZdmNToFgZrOU VJXMAydHDB/nkgq;
X-IronPort-AV: E=Sophos;i="4.49,545,1262563200"; d="scan'208";a="22081943"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 26 Feb 2010 10:14:56 +0000
In-Reply-To:
References:
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Fri, 26 Feb 2010 10:14:55 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 26/02/2010 10:14:56 AM, Serialize complete at 26/02/2010 10:14:56 AM
Content-Type: multipart/alternative; boundary="=_alternative 00384C62802576D6_="
Sender: [email-masked]
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 00384C62802576D6_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

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

Not being an EPP guru, what's the rationale for requiring a 2102 error if=20
the server doesn't support or=20
?

I would have thought that Postel's law should apply, otherwise a registrar =

has to have advance knowledge of which registries support those elements=20
and which don't, and alter their submitted XML accordingly. I can't=20
immediately see how any harm would come from simply ignoring those=20
elements.

Also, I note that =A74 says that a server MUST support either=20
or , but not both (unless in transition=20
from one to the other). However I can find no guidance on what should=20
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.=20

BTW, =A710 (Acknowledgements) says that this doc =5Fupdates=5F 4310 and ref=
ers=20
readers to that document's acknowledgements section, whereas elsewhere=20
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=20
refer to it at the same time.

kind regards,

Ray

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

--=_alternative 00384C62802576D6_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

> I submitted http://www.ietf.org/id/draft-gould-rf=
c4310bis-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 requ=
iring
a 2102 error if the server doesn't support <secDNS:update urgent=3D"=
;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 accor=
dingly.
I can't immediately see how any harm would come from simply ignoring
those elements.

Also, I note that =A74 says that a server MUST suppo=
rt
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, =A710 (Acknowledgements) says that this doc =5F=
updates=5F
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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1Q0ADp5016357 for ; Fri, 26 Feb 2010 01:10:13 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1Q0ADej021772 for ietf-provreg-outgoing; Fri, 26 Feb 2010 01:10:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1Q0ACXw004871 for ; Fri, 26 Feb 2010 01:10:12 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1Q04LeL003639 for ; Thu, 25 Feb 2010 19:04:22 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 19:10:11 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 26 Feb 2010 00:10:10 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 25 Feb 2010 19:10:00 -0500
Subject: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis-06.txt Submitted for Review
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9gyuHd/LAEtXUTgCnrwrxQ==
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349969800_10733679"
X-OriginalArrivalTime: 26 Feb 2010 00:10:11.0206 (UTC) FILETIME=[0FDEA260:01CAB678]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3349969800_10733679
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

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

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

--B_3349969800_10733679
Content-type: text/html;
charset="US-ASCII"
Content-transfer-encoding: quoted-printable

draft-gould-rfc4310bis-06.txt Submitted for Review

All,

I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.tx=
t 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

-------------------------------------------------------

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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.

--B_3349969800_10733679--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1ODcKtf028832 for ; Wed, 24 Feb 2010 14:38:20 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1ODcKkY001084 for ietf-provreg-outgoing; Wed, 24 Feb 2010 14:38:20 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1ODcJB6019912 for ; Wed, 24 Feb 2010 14:38:20 +0100 (MET)
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Howard Eland
In-Reply-To: <[email-masked]>
Date: Wed, 24 Feb 2010 07:38:17 -0600
Cc: EPP Provreg
Message-Id:
References: <[email-masked]> <[email-masked]>
To: Ulrich Wisser
X-Mailer: Apple Mail (2.1077)
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o1ODcKB6002061
Sender: [email-masked]
Precedence: bulk

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 they sent in.

I am fine with leaving this out as well.

-Howard

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

> Hi,
>
>> Section 5.1.2. EPP Command, Example Response for a Secure
>> Delegation using the Key Data Interface:
>> I believe the server should also return the server generated
>> 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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1ODa6h2024691 for ; Wed, 24 Feb 2010 14:36:06 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1ODa62S008607 for ietf-provreg-outgoing; Wed, 24 Feb 2010 14:36:06 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1ODa5df027893 for ; Wed, 24 Feb 2010 14:36:05 +0100 (MET)
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Howard Eland
In-Reply-To: <[email-masked]>
Date: Wed, 24 Feb 2010 07:36:02 -0600
Cc: EPP Provreg
Message-Id:
References: <[email-masked]> <[email-masked]>
To: Andrew Sullivan
X-Mailer: Apple Mail (2.1077)
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o1ODa5df017590
Sender: [email-masked]
Precedence: bulk

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:

>
>
> On 2010-02-23, at 16:17, Howard Eland wrote:
>
>> 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.".
>>
>
> 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
>

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1O8oiKJ016422 for ; Wed, 24 Feb 2010 09:50:44 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1O8oiFL011216 for ietf-provreg-outgoing; Wed, 24 Feb 2010 09:50:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1O8oh6j027913 for ; Wed, 24 Feb 2010 09:50:43 +0100 (MET)
Received: (qmail 14198 invoked from network); 24 Feb 2010 08:50:42 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Feb 2010 08:50:42 +0000
Message-ID: <[email-masked]>
Date: Wed, 24 Feb 2010 09:50:42 +0100
From: Ulrich Wisser
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
MIME-Version: 1.0
To: Howard Eland
CC: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hi,

> Section 5.1.2. EPP Command, Example Response for a Secure
> Delegation using the Key Data Interface:
> I believe the server should also return the server generated
> 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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1O1mDKd007668 for ; Wed, 24 Feb 2010 02:48:13 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1O1mDR9007724 for ietf-provreg-outgoing; Wed, 24 Feb 2010 02:48:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1O1mCNO003403 for ; Wed, 24 Feb 2010 02:48:13 +0100 (MET)
Received: from [172.16.33.104] (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 731241ECB4E8; Wed, 24 Feb 2010 01:48:11 +0000 (UTC)
From: Andrew Sullivan
To: Howard Eland
In-Reply-To: <[email-masked]>
X-Mailer: iPhone Mail (7E18)
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
References: <[email-masked]>
Message-Id: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 7E18)
Date: Tue, 23 Feb 2010 20:48:08 -0500
Cc: EPP Provreg
Sender: [email-masked]
Precedence: bulk

On 2010-02-23, at 16:17, Howard Eland wrote:

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

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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1NMVOlo000772 for ; Tue, 23 Feb 2010 23:31:24 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1NMVNAK014303 for ietf-provreg-outgoing; Tue, 23 Feb 2010 23:31:23 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1NMVMQW004919 for ; Tue, 23 Feb 2010 23:31:23 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o1NMBYt4022738; Tue, 23 Feb 2010 17:11:35 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 17:31:21 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Feb 2010 22:31:19 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 23 Feb 2010 17:31:19 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
From: James Gould
To: Howard Eland , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
Thread-Index: Acq00RdT0wK0AOWjQwGEj9DniTvd6gABtPa9
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349791079_3968681"
X-OriginalArrivalTime: 23 Feb 2010 22:31:21.0110 (UTC) FILETIME=[EC6E4B60:01CAB4D7]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3349791079_3968681
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Howard,

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

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

No problem I can add this to the =AD06 draft.

> Section 5.1.2. EPP Command, Example Response for a Secure
> Delegation using the Key Data Interface:
> I believe the server should also return the server generated
> 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=B9t explicitly set it or manage it. We don=B9t return the RRSIG
resource records with the DS Data Interface, so why would another generated
set of resource records be returned back?

> Section 5.2.1. EPP Command, second bullet set plus examples
> It is not clear in this section of the document that and
> elements, when used to create DS records on the server,
> cannot be intermixed. The text seems to imply that under a single
> , one could specify multiple elements, mul=
tiple
> elements, or a mixture of both, as a method for creating
> multiple DS records in the server. Using this interpretation, the exampl=
e is
> actually ambiguous, as it is not sure if the is part of =
the
> optional "validation" element for the previous , or if it =
is
> implying the creation of another DS record by using only the
> 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 =B3DS Data Interface
and Key Data Interface=B2 is meant to more fully define the two supported
interfaces of using either elements or ,
where only one is used. It is hard for me to believe that it can be
interpreted to use the optional =B3validation=B2 element of the
in the sentence =B3Zero or more elements or
elements=B2. Based on your proposal 0, would it be clearer to say =B3Zero or
more elements or elements, but not both as
defined in section 4=B2? 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.

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

No problem I can add this to the =AD06 draft.

--=20

JG=20

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

=20
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 writte=
n
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
Date: Tue, 23 Feb 2010 16:17:01 -0500
To: EPP Provreg
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 th=
e
sentence "The maxSigLife value applies to the RRSIG resource record (RR)
over the DS RRset.".

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

Section 5.2.1. EPP Command, second bullet set plus examples
It is not clear in this section of the document that and
elements, when used to create DS records on the server,
cannot be intermixed. The text seems to imply that under a single
, one could specify multiple elements,
multiple 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 is
part of the optional "validation" element for the previous ,
or if it is implying the creation of another DS record by using only the
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 or
can be specified.
1) Change the "Zero or more" statement to "Zero or one", forcing a
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 element that would be used as
a wrapper for the when it is used as the optional element
under . This would avoid confusion as to when the client wa=
s
specifying for validation purposes, or when it's used to
specify another DS. In fact, couldn't doing this eliminate the need for
and to be mutually exclusive?

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

-Howard

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

> All,
>=20
> 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 questio=
n on
> the inclusion of the ttl element to the AD for guidance. Please let me k=
now
> if you have any feedback to the latest draft.
>=20
> Thanks, =20
>=20
> --=20
>=20
>=20
> JG=20
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =20
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> Notice to Recipient: This e-mail contains confidential, proprietary and/=
or
> Registry Sensitive information intended solely for the recipient and, th=
us
> may not be retransmitted, reproduced or disclosed without the prior writ=
ten
> 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.
>=20

--B_3349791079_3968681
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Revie=
w

Howard,

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

> Section 3.3.  Maximum Signature LIfetime

> Nit: for clarity, you may want to add "in the parent zone" t=
o the end of the

> sentence "The maxSigLife value applies to the RRSIG resource reco=
rd (RR) over

> the DS RRset.".

No problem I can add this to the –06 draft.

> 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 <secDN=
S: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 c=
lient 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?

> Section 5.2.1. EPP <create> Command, second bullet set plus exam=
ples

> 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 singl=
e

> <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, th=
e example is

> actually ambiguous, as it is not sure if the <secDNS:keyData> is=
part of the

> optional "validation" element for the previous <secDNS:ds=
Data>, or if it is

> implying the creation of another DS record by using only the <secDN=
S:keyData>

> for the second DS.  I understand it's specified in the XML explic=
itly as

> "dsOrKeyType", but the text under create should reflect this=
as well.

This text is used throughout the draft, since section 4 “DS Data Inte=
rface and Key Data Interface” is meant to more fully define the two su=
pported interfaces of using either <secDNS:dsData> elements or <sec=
DNS:keyData>, where only one is used.  It is hard for me to believe =
that it can be interpreted to use the optional “validation” elem=
ent of the <secDNS:dsData> in the sentence “Zero or more <sec=
DNS:dsData> elements or <secDNS:keyData> elements”.  Bas=
ed on your proposal 0, would it be clearer to say “Zero or more <se=
cDNS:dsData> elements or <secDNS:keyData> elements, but not both as=
defined in section 4”?  I view this as being redundant, but mayb=
e because I wrote it.  Please let me know if this sentence is really am=
biguous and whether the extra verbiage for the one sentence helps.

> 9. Security Considerations, 2nd to last paragraph

> After "Data validity checking", add "and Delegation Sig=
ner record creation".

No problem I can add this to the –06 draft.

--

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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 16:17:01 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

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 commen=
ts:

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 resourc=
e 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:dsD=
ata> when the client only sends in the Key Data interface.

Section 5.2.1. EPP <create> Command, second bullet set plus examples<=
BR>
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 s=
erver, cannot be intermixed.  The text seems to imply that under a sing=
le <secDNS:create>, one could specify multiple <secDNS:dsData> e=
lements, multiple <secDNS:keyData> elements, or a mixture of both, as =
a method for creating multiple DS records in the server.  Using this in=
terpretation, the example is actually ambiguous, as it is not sure if the &l=
t;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 D=
S.  I understand it's specified in the XML explicitly as "dsOrKeyT=
ype", 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 u=
sed as a wrapper for the <secDNS:keyData> when it is used as the optio=
nal element under <secDNS:dsData>.  This would avoid confusion as=
to when the client was specifying <secDNS:keyData> for validation pur=
poses, or when it's used to specify another DS.  In fact, couldn't doin=
g this eliminate the need for <secDNS:dsData> and <secDNS:keyData&g=
t; to be mutually exclusive?

9. Security Considerations, 2nd to last paragraph

After "Data validity checking", add "and Delegation Signer r=
ecord creation".

-Howard

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

<=
SPAN STYLE=3D'font-size:11pt'>All,

I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.tx=
t 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 d=
raft.

Thanks,

--

JG

-------------------------------------------------------

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked] <x-msg:<=
a href=3D"//170/[email-masked]">//170/[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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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.

=

--B_3349791079_3968681--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1NLH7qu007118 for ; Tue, 23 Feb 2010 22:17:07 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1NLH6QS026239 for ietf-provreg-outgoing; Tue, 23 Feb 2010 22:17:06 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1NLH5fv014171 for ; Tue, 23 Feb 2010 22:17:06 +0100 (MET)
From: Howard Eland
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary=Apple-Mail-17-889812584
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
Date: Tue, 23 Feb 2010 15:17:01 -0600
In-Reply-To:
To: EPP Provreg
References:
Message-Id: <[email-masked]>
X-Mailer: Apple Mail (2.1077)
X-Authenticated: True
Sender: [email-masked]
Precedence: bulk

--Apple-Mail-17-889812584
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

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 Command, Example Response for a Secure =
Delegation using the Key Data Interface:
I believe the server should also return the server generated =
when the client only sends in the Key Data interface.

Section 5.2.1. EPP Command, second bullet set plus examples
It is not clear in this section of the document that and =
elements, when used to create DS records on the server, =
cannot be intermixed. The text seems to imply that under a single =
, one could specify multiple elements, =
multiple 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 is part of the optional "validation" element for =
the previous , or if it is implying the creation of =
another DS record by using only the 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 or =
can be specified.
1) Change the "Zero or more" statement to "Zero or one", forcing a =
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 element that would be used =
as a wrapper for the when it is used as the optional =
element under . This would avoid confusion as to when =
the client was specifying for validation purposes, or =
when it's used to specify another DS. In fact, couldn't doing this =
eliminate the need for and to be =
mutually exclusive?

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

-Howard

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

> All,
>=20
> 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.=20
>=20
> Thanks, =20
>=20
> --=20
>=20
>=20
> JG=20
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =20
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> 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.
>=20

--Apple-Mail-17-889812584
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii

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

<=
/div>

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

All,

I submitted http://www.i=
etf.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

--------------------------------------------------=
-----

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.

=

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1NJ9KoY016832 for ; Tue, 23 Feb 2010 20:09:20 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1NJ9K2D002750 for ietf-provreg-outgoing; Tue, 23 Feb 2010 20:09:20 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1NJ9IGP026682 for ; Tue, 23 Feb 2010 20:09:18 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1NJ3VCF013467 for ; Tue, 23 Feb 2010 14:03:31 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 14:09:16 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Feb 2010 19:09:15 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 23 Feb 2010 14:09:14 -0500
Subject: Re: [ietf-provreg] Looking for a Document Shepherd for rfc4310bis
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Looking for a Document Shepherd for rfc4310bis
Thread-Index: Acq0KQe9L0nhzq0Ry0yBo8e+2TR/oQAkqhf/
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349778955_3243064"
X-OriginalArrivalTime: 23 Feb 2010 19:09:16.0755 (UTC) FILETIME=[B1C08A30:01CAB4BB]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3349778955_3243064
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

I wanted to let you know that Olafur Gudmundsson volunteered to be the
document shepherd for rfc4310bis. Thanks Olafur for stepping forward for
this! Based on feedback from Alexey I intend to incorporate Bernie=B9s
editorial changes into an 06 draft later today that will be used as the
basis for the IESG review.

--=20

JG=20

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

=20
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 writte=
n
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
Date: Mon, 22 Feb 2010 20:39:25 -0500
To: EPP Provreg
Subject: [ietf-provreg] Looking for a Document Shepherd for rfc4310bis

All,

I=B9m looking for a volunteer who can serve as the document shepherd for
rfc4310bis. We=B9re trying to get draft-gould-rfc4310bis-05.txt on the next
IESG telechat on March 4th. To do so I need a document shepherd by the end
of Thursday who will also need to fill in the shepherding write-up:

http://www.ietf.org/iesg/template/doc-writeup.html

We have come a long way in addressing the issues with RFC 4310. I
appreciate someone from the list stepping forward to help this document
progress.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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.

--B_3349778955_3243064
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] Looking for a Document Shepherd for rfc4310bis</T=
ITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>All,<BR>
<BR>
I wanted to let you know that Olafur Gudmundsson volunteered to be the docu=
ment shepherd for rfc4310bis.  Thanks Olafur for stepping forward for t=
his!  Based on feedback from Alexey I intend to incorporate Bernie̵=
7;s editorial changes into an 06 draft later today that will be used as the =
basis for the IESG review.  <BR>
</SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN S=
TYLE=3D'font-size:9pt'><BR>
-- <BR>
<BR>
<BR>
JG <BR>
<BR>
</SPAN></FONT><FONT COLOR=3D"#800000"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-si=
ze:7.5pt'>-------------------------------------------------------<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Arial"><FONT COLOR=3D"#7F0000"><FONT =
SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>James F. Gould<BR>
</B></SPAN></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B><FO=
NT COLOR=3D"#4C4C4C">Principal Software Engineer<BR>
</FONT></B><FONT COLOR=3D"#4C4C4C">VeriSign Naming Services<BR>
</FONT></SPAN></FONT><FONT COLOR=3D"#1100EF"><FONT SIZE=3D"1"><SPAN STYLE=3D'font=
-size:9pt'><a href=3D"[email-masked]">[email-masked]</a><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"1"><FONT COLOR=3D"#4C4C4C"><SPAN STYLE=3D'font=
-size:7.5pt'><B>Direct:</B> 703.948.3271<BR>
<B>Mobile:</B> 703.628.7063<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:7.5pt'><BR>
<BR>
<FONT COLOR=3D"#4C4C4C">21345 Ridgetop Circle<BR>
LS2-2-1<BR>
Dulles, VA 20166<BR>
</FONT><BR>
<FONT COLOR=3D"#7F0000"><B><I>Notice to Recipient:  </I></B></FONT></SPA=
N><I><SPAN STYLE=3D'font-size:9pt'>This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  <B>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.</B>  Thank you.<BR>
</SPAN></I></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><S=
PAN STYLE=3D'font-size:11pt'><BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"><B>From: </B>James Gould <<a href=3D=
"[email-masked]">[email-masked]</a>><BR>
<B>Date: </B>Mon, 22 Feb 2010 20:39:25 -0500<BR>
<B>To: </B>EPP Provreg <<a href=3D"[email-masked]">ietf-provreg@caf=
ax.se</a>><BR>
<B>Subject: </B>[ietf-provreg] Looking for a Document Shepherd for rfc4310b=
is<BR>
<BR>
All,<BR>
<BR>
I’m looking for a volunteer who can serve as the document shepherd fo=
r rfc4310bis.  We’re trying to get </SPAN></FONT><FONT SIZE=3D"1"><=
FONT FACE=3D"Geneva, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:9pt'>dr=
aft-gould-rfc4310bis-05.txt on the next </SPAN></FONT></FONT><FONT FACE=3D"Cal=
ibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt'>IESG telechat =
on March 4th.  To do so I need a document shepherd by the end of Thursd=
ay who will also need to fill in the shepherding write-up:<BR>
<BR>
<a href=3D"http://www.ietf.org/iesg/template/doc-writeup.html">http://www.iet=
f.org/iesg/template/doc-writeup.html</a><BR>
<BR>
We have come a long way in addressing the issues with RFC 4310.  I app=
reciate someone from the list stepping forward to help this document progres=
s.<BR>
<BR>
Thanks,<BR>
</SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN S=
TYLE=3D'font-size:9pt'><BR>
-- <BR>
<BR>
<BR>
JG <BR>
<BR>
</SPAN></FONT><FONT COLOR=3D"#800000"><FONT FACE=3D"Arial"><SPAN STYLE=3D'font-si=
ze:7pt'>-------------------------------------------------------<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Arial"><FONT COLOR=3D"#7F0000"><FONT =
SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>James F. Gould<BR>
</B></SPAN></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B><FO=
NT COLOR=3D"#4C4C4C">Principal Software Engineer<BR>
</FONT></B><FONT COLOR=3D"#4C4C4C">VeriSign Naming Services<BR>
</FONT></SPAN></FONT><FONT COLOR=3D"#1100EF"><FONT SIZE=3D"1"><SPAN STYLE=3D'font=
-size:9pt'><a href=3D"[email-masked]">[email-masked]</a><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"1"><FONT COLOR=3D"#4C4C4C"><SPAN STYLE=3D'font=
-size:7pt'><B>Direct:</B> 703.948.3271<BR>
<B>Mobile:</B> 703.628.7063<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:7pt'><BR>
<BR>
<FONT COLOR=3D"#4C4C4C">21345 Ridgetop Circle<BR>
LS2-2-1<BR>
Dulles, VA 20166<BR>
</FONT><BR>
<FONT COLOR=3D"#7F0000"><B><I>Notice to Recipient:  </I></B></FONT></SPA=
N><I><SPAN STYLE=3D'font-size:9pt'>This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  <B>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.</B>  Thank you.<BR>
</SPAN></I></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><S=
PAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT>
</BODY>
</HTML>

--B_3349778955_3243064--

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

Return-Path: <[email-masked]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1N1dUNR024824 for <[email-masked]>; Tue, 23 Feb 2010 02:39:30 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1N1dUHs014417 for ietf-provreg-outgoing; Tue, 23 Feb 2010 02:39:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1N1dTO8016521 for <[email-masked]>; Tue, 23 Feb 2010 02:39:30 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1N1XjZT018776 for <[email-masked]>; Mon, 22 Feb 2010 20:33:45 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 20:39:29 -0500
Received: from 10.169.80.5 ([10.169.80.5]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Feb 2010 01:39:27 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 22 Feb 2010 20:39:25 -0500
Subject: [ietf-provreg] Looking for a Document Shepherd for rfc4310bis
From: James Gould <[email-masked]>
To: EPP Provreg <[email-masked]>
Message-ID: <[email-masked]>
Thread-Topic: Looking for a Document Shepherd for rfc4310bis
Thread-Index: Acq0KQe9L0nhzq0Ry0yBo8e+2TR/oQ==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349715966_58106875"
X-OriginalArrivalTime: 23 Feb 2010 01:39:29.0001 (UTC) FILETIME=[0A200590:01CAB429]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3349715966_58106875
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

I=B9m looking for a volunteer who can serve as the document shepherd for
rfc4310bis. We=B9re trying to get draft-gould-rfc4310bis-05.txt on the next
IESG telechat on March 4th. To do so I need a document shepherd by the end
of Thursday who will also need to fill in the shepherding write-up:

http://www.ietf.org/iesg/template/doc-writeup.html

We have come a long way in addressing the issues with RFC 4310. I
appreciate someone from the list stepping forward to help this document
progress.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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.

--B_3349715966_58106875
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Looking for a Document Shepherd for rfc4310bis

All,

I’m looking for a volunteer who can serve as the document shepherd fo=
r rfc4310bis.  We’re trying to get <=
FONT FACE=3D"Geneva, Verdana, Helvetica, Arial">d=
raft-gould-rfc4310bis-05.txt on the next IESG telechat=
on March 4th.  To do so I need a document shepherd by the end of Thurs=
day who will also need to fill in the shepherding write-up:

http://www.iet=
f.org/iesg/template/doc-writeup.html

We have come a long way in addressing the issues with RFC 4310.  I app=
reciate someone from the list stepping forward to help this document progres=
s.

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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.

--B_3349715966_58106875--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LKhZAw018344 for ; Sun, 21 Feb 2010 21:43:35 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1LKhYLq005116 for ietf-provreg-outgoing; Sun, 21 Feb 2010 21:43:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LKhYlT023469 for ; Sun, 21 Feb 2010 21:43:34 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NjIeJ-0003kd-DT; Sun, 21 Feb 2010 21:43:31 +0100
Date: Sun, 21 Feb 2010 21:43:31 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: James Gould
cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
In-Reply-To:
Message-ID:
References:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-1523882370-1266785011=:12860"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--37663318-1523882370-1266785011=:12860
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi James,

Thanks for your clarifications!

I guess I now understand, what you intend to accomplish with the 3rd=20
bullet point that I misunderstood. It looks like this can easily be=20
resolved on editorial level. How about to clear out the 3rd bullet point=20
as follows (proposal):

3. Response to EPP Command

The version of to be returned by the server in the
response to a command SHOULD depend on the
elements (indicating the secDNS extension) the client
included in the EPP command using the following mapping:

- Return secDNS-1.1 if
urn:ietf:params:xml:ns:secDNS-1.1 was included as an in
the EPP command.

- Return secDNS-1.0 if
urn:ietf:params:xml:ns:secDNS-1.0 but not
urn:ietf:params:xml:ns:secDNS-1.1 was included as an
in the EPP command.

- Don't return any element if neither
urn:ietf:params:xml:ns:secDNS-1.0 nor
urn:ietf:params:xml:ns:secDNS-1.1 was included as an in
the EPP command.

----

Abd some more editorial feedback (not directly related to our recent=20
discussion):

* I suggest to add an explicit statement about deprecation (somewhere in=20
the Introduction, e.g. shortly before section 1.1). It could be something=
=20
along the lines of:

This document obsoletes RFC 4310; thus secDNS-1.1 as defined in this
document deprecates secDNS-1.0 [RFC 4310].

* The introduction of Section "2. Migrating from RFC 4310" could be=20
rewritten as follows (proposal):

This section includes implementation recommendations that a server
SHOULD follow to help clients migrate from secDNS-1.0 [RFC 4310] to
secDNS-1.1 as defined in this document

* I suggest to add a recommendation for EPP clients e.g. (proposal):

As this document deprecates RFC 4310, clients supporting both version
secDNS-1.0 [RFC 4310] and secDNS-1.1 (as defined in this document)
SHOULD only use secDNS-1.1, if the server announced support for
secDNS-1.1 in the greeting.

* Maybe define secDNS-1.0 and secDNS-1.1 in section 1.1 as an abbreviation=
=20
for urn:ietf:params:xml:ns:secDNS-1.(0|1)

---

Have a nice evening!

cheers,
Bernie

On Sun, 21 Feb 2010, James Gould wrote:

> Bernie,
>=20
> >> The implementation note did not state anything about the contents of t=
he
> >> greeting of the server
> >
> > That's what I said. Therefore the greeting might be different from logi=
n
> > response (s. below in my original email).
>=20
> Ok, let=E2=80=99s try to walk through a use case, where the server does s=
upport both 1.0 and 1.1 per item #1 in section 2 =E2=80=9CMigrating from RF=
C 4310=E2=80=9D.
> =C2=A0The server should include both urn:ietf:params:xml:ns:secDNS-1.0 an=
d urn:ietf:params:xml:ns:secDNS-1.1 in the greeting per RFC 5730. =C2=A0The
> client can submit the same or a subset of the services presented by the s=
erver greeting in the login. =C2=A0Item #3 of section 2 =E2=80=9CMigrating =
from
> RFC 4310=E2=80=9D addresses the secDNS:infData that should be returned ba=
sed on what the client presents in the EPP login. =C2=A0Let=E2=80=99s go th=
rough the
> items within #3 of section 2 =E2=80=9CMigrating from RFC 4310=E2=80=9D on=
e-by-one:
>
> 1. Client includes urn:ietf:params:xml:ns:secDNS-1.1 in the EPP login. I=
f urn:ietf:params:xml:ns:secDNS-1.0 in the EPP login is also
> included it doesn=E2=80=99t matter since the server should return urn=
:ietf:params:xml:ns:secDNS-1.1 of the secDNS:infData.
> 2. Client only includes =C2=A0urn:ietf:params:xml:ns:secDNS-1.0 in the E=
PP login, which means that the client does not support
> urn:ietf:params:xml:ns:secDNS-1.1 and therefore the server should ret=
urn urn:ietf:params:xml:ns:secDNS-1.0 of the secDNS:infData.
> 3. Client does not include either urn:ietf:params:xml:ns:secDNS-1.0 or u=
rn:ietf:params:xml:ns:secDNS-1.1 in the EPP login, which means that
> the client doesn=E2=80=99t support secDNS at all. =C2=A0In this case =
the server should not include secDNS:infData. =C2=A0Nothing is being hidden=
here,
> since secDNS is optional and the server is complying with the service=
s that the client included in the EPP login. =C2=A0=C2=A0
>=20
> >> doing any kind of hiding of supported extensions.=C2=A0
> >
> > As I understand the hiding happens at login response (as it is defined =
now
> > in draft-gould-rfc4310bis-05).
>=20
> I=E2=80=99m not sure what hiding that you=E2=80=99re referring to with th=
e EPP login. =C2=A0There is nothing new here and there should be no hiding =
of anything
> in either the EPP greeting or login.
>=20
>=20
> >> It is assumed without having to restate it that the server MUST suppor=
t
> >> RFC 5730.
> >
> > As I said, the proposal is compliant with RFC 5730, however it might
> > cause pain to implementors.
>=20
> This is the case where the clients and servers are properly following the=
greeting and EPP login semantics defined in RFC 5730 so this
> should not be new or complicated. =C2=A0The EPP greeting should include a=
ll of the services supported by the server, which still holds. =C2=A0The EP=
P
> login should include all of the services that are supported by the client=
, which still holds. =C2=A0Section 2 =E2=80=9CMigrating from RFC 4310=E2=80=
=9D simply
> provides a recommended approach to dealing with a mix of client and serve=
r support for secDNS. =C2=A0There is certainly more work on the server
> side to support both urn:ietf:params:xml:ns:secDNS-1.0 and urn:ietf:param=
s:xml:ns:secDNS-1.1 in parallel, but the added work should be
> expected. =C2=A0
>=20
> --
>=20
>=20
> JG
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =C2=A0
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> Notice to Recipient: =C2=A0This e-mail contains confidential, proprietary=
and/or Registry =C2=A0Sensitive information intended solely for the
> recipient and, thus may not be =C2=A0retransmitted, reproduced or disclos=
ed without the prior written consent of =C2=A0VeriSign Naming and Directory
> Services. =C2=A0If you have received =C2=A0this e-mail message in error, =
please notify the sender immediately by =C2=A0telephone or reply e-mail and
> destroy the original message without making a =C2=A0copy. =C2=A0Thank you=
=2E
>=20
>
> ______________________________________________________________________=
_______________________________________________________________
> From:
> Date: Sun, 21 Feb 2010 13:03:31 -0500
> To: James Gould
> Cc: EPP Provreg
> Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for R=
eview
>=20
> Hi James,
>=20
> On Sun, 21 Feb 2010, Gould, James wrote:
>=20
> > The implementation note did not state anything about the contents of th=
e
> > greeting of the server
>=20
> That's what I said. Therefore the greeting might be different from login
> response (s. below in my original email).
>=20
> > doing any kind of hiding of supported extensions.=C2=A0
>=20
> As I understand the hiding happens at login response (as it is defined no=
w
> in draft-gould-rfc4310bis-05).
>=20
> > The point of the note was to address how the server will handle clients
> > that support 1.0, 1.1, or both.=C2=A0
>=20
> I understand this, and it's good to have this section about transition
> considerations.
>=20
> > It is assumed without having to restate it that the server MUST support
> > RFC 5730.
>=20
> As I said, the proposal is compliant with RFC 5730, however it might
> cause pain to implementors.
>=20
> cheers,
> =C2=A0=C2=A0Bernie
>=20
> >
> > ----- Original Message -----
> > From: Bernie Hoeneisen
> > To: Gould, James
> > Cc: EPP Provreg
> > Sent: Sun Feb 21 12:14:38 2010
> > Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for=
Review
> >
> > Hi James
> >
> > Thanks for the update!
> >
> > Concerning the transition considerations:
> >
> > =C2=A0=C2=A0=C2=A0 3.=C2=A0 The version of to return f=
or a domain info
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 command SHOULD be defined by=
the secDNS extURI's included in the
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EPP login services using the=
following mapping:
> > =C2=A0=C2=A0=C2=A0 [...]
> >
> > - 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 proce=
ss.
> >
> > - 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,
> > =C2=A0 Bernie
> >
> >
> > On Wed, 17 Feb 2010, James Gould wrote:
> >
> > > All,
> > >
> > > I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt whic=
h includes the feedback that I received so far. =C2=A0I included an open
> > > question on the inclusion of the ttl element to the AD for guidance. =
=C2=A0Please let me know if you have any feedback to the latest draft.
> > >
> > > Thanks, =C2=A0
> > >
> > > --
> > >
> > >
> > > JG
> > >
> > > -------------------------------------------------------
> > > James F. Gould
> > > Principal Software Engineer
> > > VeriSign Naming Services
> > > [email-masked]
> > > Direct: 703.948.3271
> > > Mobile: 703.628.7063
> > >
> > > =C2=A0
> > > 21345 Ridgetop Circle
> > > LS2-2-1
> > > Dulles, VA 20166
> > >
> > > Notice to Recipient: =C2=A0This e-mail contains confidential, proprie=
tary and/or Registry =C2=A0Sensitive information intended solely for the
> > > recipient and, thus may not be =C2=A0retransmitted, reproduced or dis=
closed without the prior written consent of =C2=A0VeriSign Naming and
> Directory
> > > Services. =C2=A0If you have received =C2=A0this e-mail message in err=
or, please notify the sender immediately by =C2=A0telephone or reply e-mail=
and
> > > destroy the original message without making a =C2=A0copy. =C2=A0Thank=
you.
>=20
>=20
--37663318-1523882370-1266785011=:12860--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LIq6nt016160 for ; Sun, 21 Feb 2010 19:52:06 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1LIq6q5013231 for ietf-provreg-outgoing; Sun, 21 Feb 2010 19:52:06 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LIq5hx019549 for ; Sun, 21 Feb 2010 19:52:06 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1LIkNn9006584; Sun, 21 Feb 2010 13:46:23 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Feb 2010 13:52:04 -0500
Received: from 10.169.80.10 ([10.169.80.10]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Sun, 21 Feb 2010 18:52:02 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Sun, 21 Feb 2010 13:51:55 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
From: James Gould
To:
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
Thread-Index: AcqzIDGz/af76v+eR6K2cA39OBYg6gABr5IS
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349605117_52106470"
X-OriginalArrivalTime: 21 Feb 2010 18:52:04.0667 (UTC) FILETIME=[F5C0E8B0:01CAB326]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3349605117_52106470
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Bernie,=20

>> The implementation note did not state anything about the contents of the
>> greeting of the server
>=20
> That's what I said. Therefore the greeting might be different from login
> response (s. below in my original email).

Ok, let=B9s try to walk through a use case, where the server does support bot=
h
1.0 and 1.1 per item #1 in section 2 =B3Migrating from RFC 4310=B2. The server
should include both urn:ietf:params:xml:ns:secDNS-1.0 and
urn:ietf:params:xml:ns:secDNS-1.1 in the greeting per RFC 5730. The client
can submit the same or a subset of the services presented by the server
greeting in the login. Item #3 of section 2 =B3Migrating from RFC 4310=B2
addresses the secDNS:infData that should be returned based on what the
client presents in the EPP login. Let=B9s go through the items within #3 of
section 2 =B3Migrating from RFC 4310=B2 one-by-one:

1. Client includes urn:ietf:params:xml:ns:secDNS-1.1 in the EPP login. If
urn:ietf:params:xml:ns:secDNS-1.0 in the EPP login is also included it
doesn=B9t matter since the server should return
urn:ietf:params:xml:ns:secDNS-1.1 of the secDNS:infData.
2. Client only includes urn:ietf:params:xml:ns:secDNS-1.0 in the EPP login=
,
which means that the client does not support
urn:ietf:params:xml:ns:secDNS-1.1 and therefore the server should return
urn:ietf:params:xml:ns:secDNS-1.0 of the secDNS:infData.
3. Client does not include either urn:ietf:params:xml:ns:secDNS-1.0 or
urn:ietf:params:xml:ns:secDNS-1.1 in the EPP login, which means that the
client doesn=B9t support secDNS at all. In this case the server should not
include secDNS:infData. Nothing is being hidden here, since secDNS is
optional and the server is complying with the services that the client
included in the EPP login.

>> doing any kind of hiding of supported extensions.=A0
>=20
> As I understand the hiding happens at login response (as it is defined no=
w
> in draft-gould-rfc4310bis-05).

I=B9m not sure what hiding that you=B9re referring to with the EPP login. Ther=
e
is nothing new here and there should be no hiding of anything in either the
EPP greeting or login.

>> It is assumed without having to restate it that the server MUST support
>> RFC 5730.
>=20
> As I said, the proposal is compliant with RFC 5730, however it might
> cause pain to implementors.

This is the case where the clients and servers are properly following the
greeting and EPP login semantics defined in RFC 5730 so this should not be
new or complicated. The EPP greeting should include all of the services
supported by the server, which still holds. The EPP login should include
all of the services that are supported by the client, which still holds.
Section 2 =B3Migrating from RFC 4310=B2 simply provides a recommended approach
to dealing with a mix of client and server support for secDNS. There is
certainly more work on the server side to support both
urn:ietf:params:xml:ns:secDNS-1.0 and urn:ietf:params:xml:ns:secDNS-1.1 in
parallel, but the added work should be expected.

--=20

JG=20

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

=20
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 writte=
n
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:
Date: Sun, 21 Feb 2010 13:03:31 -0500
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for
Review

Hi James,

On Sun, 21 Feb 2010, Gould, James wrote:

> The implementation note did not state anything about the contents of the
> greeting of the server

That's what I said. Therefore the greeting might be different from login
response (s. below in my original email).

> doing any kind of hiding of supported extensions.=A0

As I understand the hiding happens at login response (as it is defined now
in draft-gould-rfc4310bis-05).

> The point of the note was to address how the server will handle clients
> that support 1.0, 1.1, or both.=A0

I understand this, and it's good to have this section about transition
considerations.

> It is assumed without having to restate it that the server MUST support
> RFC 5730.

As I said, the proposal is compliant with RFC 5730, however it might
cause pain to implementors.

cheers,
Bernie

>
> ----- Original Message -----
> From: Bernie Hoeneisen
> To: Gould, James
> Cc: EPP Provreg
> Sent: Sun Feb 21 12:14:38 2010
> Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for R=
eview
>
> Hi James
>
> Thanks for the update!
>
> Concerning the transition considerations:
>
> =A0=A0=A0 3.=A0 The version of to return for a domain info
> =A0=A0=A0=A0=A0=A0=A0 command SHOULD be defined by the secDNS extURI's included in the
> =A0=A0=A0=A0=A0=A0=A0 EPP login services using the following mapping:
> =A0=A0=A0 [...]
>
> - 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,
> =A0 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. =A0I included an open
> > question on the inclusion of the ttl element to the AD for guidance. =A0P=
lease
let me know if you have any feedback to the latest draft.
> >
> > Thanks, =A0
> >
> > --
> >
> >
> > JG
> >
> > -------------------------------------------------------
> > James F. Gould
> > Principal Software Engineer
> > VeriSign Naming Services
> > [email-masked]
> > Direct: 703.948.3271
> > Mobile: 703.628.7063
> >
> > =A0
> > 21345 Ridgetop Circle
> > LS2-2-1
> > Dulles, VA 20166
> >
> > Notice to Recipient: =A0This e-mail contains confidential, proprietary an=
d/or
Registry =A0Sensitive information intended solely for the
> > recipient and, thus may not be =A0retransmitted, reproduced or disclosed
without the prior written consent of =A0VeriSign Naming and Directory
> > Services. =A0If you have received =A0this e-mail message in error, please n=
otify
the sender immediately by =A0telephone or reply e-mail and
> > destroy the original message without making a =A0copy. =A0Thank you.
> >
> >
> >
>
>
>

--B_3349605117_52106470
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Revie=
w

Bernie,

>> The implementation note did not state anything about the contents =
of the

>> greeting of the server

> That's what I said. Therefore the greeting might be different from log=
in

> response (s. below in my original email).

Ok, let’s try to walk through a use case, where the server does suppo=
rt both 1.0 and 1.1 per item #1 in section 2 “Migrating from RFC 4310&=
#8221;.  The server should include both urn:ietf:params:xml:ns:secDNS-1=
.0 and urn:ietf:params:xml:ns:secDNS-1.1 in the greeting per RFC 5730.  =
;The client can submit the same or a subset of the services presented by the=
server greeting in the login.  Item #3 of section 2 “Migrating f=
rom RFC 4310” addresses the secDNS:infData that should be returned bas=
ed on what the client presents in the EPP login.  Let’s go throug=
h the items within #3 of section 2 “Migrating from RFC 4310” one=
-by-one:

Client includes urn:ietf:params:xml:ns:secDNS-1.1 in=
the EPP login. If urn:ietf:params:xml:ns:secDNS-1.0 in the EPP login is als=
o included it doesn’t matter since the server should return urn:ietf:p=
arams:xml:ns:secDNS-1.1 of the secDNS:infData.

Client only includes  urn:ietf:params:xml:ns:secDNS=
-1.0 in the EPP login, which means that the client does not support urn:ietf=
:params:xml:ns:secDNS-1.1 and therefore the server should return urn:ietf:pa=
rams:xml:ns:secDNS-1.0 of the secDNS:infData.

Client does not include either urn:ietf:params:xml:ns:se=
cDNS-1.0 or urn:ietf:params:xml:ns:secDNS-1.1 in the EPP login, which means =
that the client doesn’t support secDNS at all.  In this case the =
server should not include secDNS:infData.  Nothing is being hidden here=
, since secDNS is optional and the server is complying with the services tha=
t the client included in the EPP login.

>> doing any kind of hiding of supported extensions.=A0

> As I understand the hiding happens at login response (as it is defined=
now

> in draft-gould-rfc4310bis-05).

I’m not sure what hiding that you’re referring to with the EPP =
login.  There is nothing new here and there should be no hiding of anyt=
hing in either the EPP greeting or login.

>> It is assumed without having to restate it that the server MUST su=
pport

>> RFC 5730.

> As I said, the proposal is compliant with RFC 5730, however it might
> cause pain to implementors.

This is the case where the clients and servers are properly following the g=
reeting and EPP login semantics defined in RFC 5730 so this should not be ne=
w or complicated.  The EPP greeting should include all of the services =
supported by the server, which still holds.  The EPP login should inclu=
de all of the services that are supported by the client, which still holds. =
Section 2 “Migrating from RFC 4310” simply provides a reco=
mmended approach to dealing with a mix of client and server support for secD=
NS.  There is certainly more work on the server side to support both ur=
n:ietf:params:xml:ns:secDNS-1.0 and urn:ietf:params:xml:ns:secDNS-1.1 in par=
allel, but the added work should be expected.

--

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: <[email-masked]>

Date: Sun, 21 Feb 2010 13:03:31 -0500

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted =
for Review

Hi James,

On Sun, 21 Feb 2010, Gould, James wrote:

> The implementation note did not state anything about the contents of t=
he

> greeting of the server

That's what I said. Therefore the greeting might be different from login
response (s. below in my original email).

> doing any kind of hiding of supported extensions.=A0

As I understand the hiding happens at login response (as it is defined now<=
BR>
in draft-gould-rfc4310bis-05).

> The point of the note was to address how the server will handle client=
s

> that support 1.0, 1.1, or both.=A0

I understand this, and it's good to have this section about transition

considerations.

> It is assumed without having to restate it that the server MUST suppor=
t

> RFC 5730.

As I said, the proposal is compliant with RFC 5730, however it might

cause pain to implementors.

cheers,

Bernie

> ----- Original Message -----

> From: Bernie Hoeneisen <bernie@i=
etf.hoeneisen.ch>

> To: Gould, James

> Cc: EPP Provreg <ietf-provreg@cafax=
.se>

> Sent: Sun Feb 21 12:14:38 2010

> Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted fo=
r Review

> Hi James

> Thanks for the update!

> Concerning the transition considerations:

> =A0=A0=A0 3.=A0 The version of <secDNS:infData> to return for a domain i=
nfo

> =A0=A0=A0=A0=A0=A0=A0 command SHOULD be defined by the secDNS extURI's included in t=
he

> =A0=A0=A0=A0=A0=A0=A0 EPP login services using the following mapping:

> =A0=A0=A0 [...]

> - 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, i=
t

> potentially introduces inconsistencies in the feature negotiation proc=
ess.

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

> =A0 Bernie

> On Wed, 17 Feb 2010, James Gould wrote:

> > All,

> > I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which inc=
ludes the feedback that I received so far. =A0I included an open

> > question on the inclusion of the ttl element to the AD for guidan=
ce. =A0Please let me know if you have any feedback to the latest draft.

> > Thanks, =A0

> > --

> > JG

> > -------------------------------------------------------

> > James F. Gould

> > Principal Software Engineer

> > VeriSign Naming Services

> > [email-masked]

> > Direct: 703.948.3271

> > Mobile: 703.628.7063

> > =A0

> > 21345 Ridgetop Circle

> > LS2-2-1

> > Dulles, VA 20166

> > Notice to Recipient: =A0This e-mail contains confidential, propriet=
ary and/or Registry =A0Sensitive information intended solely for the

> > recipient and, thus may not be =A0retransmitted, reproduced or disc=
losed without the prior written consent of =A0VeriSign Naming and Directory
> > Services. =A0If you have received =A0this e-mail message in error, pl=
ease notify the sender immediately by =A0telephone or reply e-mail and

> > destroy the original message without making a =A0copy. =A0Thank you.<=
BR>

--B_3349605117_52106470--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LI3Z7l026011 for ; Sun, 21 Feb 2010 19:03:35 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1LI3ZLR011766 for ietf-provreg-outgoing; Sun, 21 Feb 2010 19:03:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LI3YUl010036 for ; Sun, 21 Feb 2010 19:03:34 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NjG9T-0003XH-KN; Sun, 21 Feb 2010 19:03:31 +0100
Date: Sun, 21 Feb 2010 19:03:31 +0100 (CET)
From: [email-masked]
X-X-Sender: [email-masked]
To: "Gould, James"
cc: [email-masked]
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-1434258587-1266775411=:12860"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--37663318-1434258587-1266775411=:12860
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi James,

On Sun, 21 Feb 2010, Gould, James wrote:

> The implementation note did not state anything about the contents of the=
=20
> greeting of the server

That's what I said. Therefore the greeting might be different from login=20
response (s. below in my original email).

> doing any kind of hiding of supported extensions.=A0

As I understand the hiding happens at login response (as it is defined now=
=20
in draft-gould-rfc4310bis-05).

> The point of the note was to address how the server will handle clients=
=20
> that support 1.0, 1.1, or both.=A0

I understand this, and it's good to have this section about transition=20
considerations.

> It is assumed without having to restate it that the server MUST support=
=20
> RFC 5730.

As I said, the proposal is compliant with RFC 5730, however it might=20
cause pain to implementors.

cheers,
Bernie

>=20
> ----- Original Message -----
> From: Bernie Hoeneisen
> To: Gould, James
> Cc: EPP Provreg
> Sent: Sun Feb 21 12:14:38 2010
> Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for R=
eview
>=20
> Hi James
>=20
> Thanks for the update!
>=20
> Concerning the transition considerations:
>=20
> =A0=A0=A0 3.=A0 The version of to return for a domain in=
fo
> =A0=A0=A0=A0=A0=A0=A0 command SHOULD be defined by the secDNS extURI's in=
cluded in the
> =A0=A0=A0=A0=A0=A0=A0 EPP login services using the following mapping:
> =A0=A0=A0 [...]
>=20
> - 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.
>=20
> - 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=
=2E
>=20
> - The text (as it is) leads to confusion among implementors.
>=20
> 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.)
>=20
> cheers,
> =A0 Bernie
>=20
>=20
> On Wed, 17 Feb 2010, James Gould wrote:
>=20
> > All,
> >
> > I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which =
includes the feedback that I received so far. =A0I included an open
> > question on the inclusion of the ttl element to the AD for guidance. =
=A0Please let me know if you have any feedback to the latest draft.
> >
> > Thanks, =A0
> >
> > --
> >
> >
> > JG
> >
> > -------------------------------------------------------
> > James F. Gould
> > Principal Software Engineer
> > VeriSign Naming Services
> > [email-masked]
> > Direct: 703.948.3271
> > Mobile: 703.628.7063
> >
> > =A0
> > 21345 Ridgetop Circle
> > LS2-2-1
> > Dulles, VA 20166
> >
> > Notice to Recipient: =A0This e-mail contains confidential, proprietary =
and/or Registry =A0Sensitive information intended solely for the
> > recipient and, thus may not be =A0retransmitted, reproduced or disclose=
d without the prior written consent of =A0VeriSign Naming and Directory
> > Services. =A0If you have received =A0this e-mail message in error, plea=
se notify the sender immediately by =A0telephone or reply e-mail and
> > destroy the original message without making a =A0copy. =A0Thank you.
> >
> >
> >
>=20
>=20
>
--37663318-1434258587-1266775411=:12860--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LHJuua021594 for ; Sun, 21 Feb 2010 18:19:56 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1LHJuih013882 for ietf-provreg-outgoing; Sun, 21 Feb 2010 18:19:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LHJtJK014046 for ; Sun, 21 Feb 2010 18:19:55 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1LHECQP003848; Sun, 21 Feb 2010 12:14:12 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Feb 2010 12:19:54 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB31A.140A008C"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
Date: Sun, 21 Feb 2010 12:19:51 -0500
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
Thread-Index: AcqzGVzkOTatc6/STDetRn9Kd7aDhgAALc3Y
From: "Gould, James"
To:
Cc:
X-OriginalArrivalTime: 21 Feb 2010 17:19:54.0022 (UTC) FILETIME=[153B7460:01CAB31A]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAB31A.140A008C
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bernie,

The implementation note did not state anything about the contents of the =
greeting of the server doing any kind of hiding of supported extensions. =
The point of the note was to address how the server will handle clients =
that support 1.0, 1.1, or both. It is assumed without having to restate =
it that the server MUST support RFC 5730.

----- Original Message -----
From: Bernie Hoeneisen
To: Gould, James
Cc: EPP Provreg
Sent: Sun Feb 21 12:14:38 2010
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for =
Review

Hi James

Thanks for the update!

Concerning the transition considerations:

3. The version of 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,=20
2.3/2.4), where extensions are queried too. This might lead to=20
inconsistencies in the extension announcements of an EPP server.

- Furthermore I consider it a bad idea, if EPP servers hide extensions=20
from EPP clients. While such behavior is not prohibited by RFC 5730, it=20
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=20
recommendation, that the EPP client SHOULD always use 1.1, if mutually=20
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,
>=20
> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which =
includes the feedback that I received so far. =A0I included an open
> question on the inclusion of the ttl element to the AD for guidance. =
=A0Please let me know if you have any feedback to the latest draft.
>=20
> Thanks, =A0
>=20
> --
>=20
>=20
> JG
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =A0
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> Notice to Recipient: =A0This e-mail contains confidential, proprietary =
and/or Registry =A0Sensitive information intended solely for the
> recipient and, thus may not be =A0retransmitted, reproduced or =
disclosed without the prior written consent of =A0VeriSign Naming and =
Directory
> Services. =A0If you have received =A0this e-mail message in error, =
please notify the sender immediately by =A0telephone or reply e-mail and
> destroy the original message without making a =A0copy. =A0Thank you.
>=20
>=20
>

------_=_NextPart_001_01CAB31A.140A008C
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for =
Review

Bernie,

The implementation note did not state anything about the contents of the =
greeting of the server doing any kind of hiding of supported =
extensions.  The point of the note was to address how the server =
will handle clients that support 1.0, 1.1, or both.  It is assumed =
without having to restate it that the server MUST support RFC 5730.

----- Original Message -----

From: Bernie Hoeneisen <[email-masked]>

To: Gould, James

Cc: EPP Provreg <[email-masked]>

Sent: Sun Feb 21 12:14:38 2010

Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for =
Review

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. =A0I included an open

> question on the inclusion of the ttl element to the AD for =
guidance. =A0Please let me know if you have any feedback to the latest =
draft.

> Thanks, =A0

> --

> JG

> -------------------------------------------------------

> James F. Gould

> Principal Software Engineer

> VeriSign Naming Services

> [email-masked]

> Direct: 703.948.3271

> Mobile: 703.628.7063

> =A0

> 21345 Ridgetop Circle

> LS2-2-1

> Dulles, VA 20166

> Notice to Recipient: =A0This e-mail contains confidential, =
proprietary and/or Registry =A0Sensitive information intended solely for =
the

> recipient and, thus may not be =A0retransmitted, reproduced or =
disclosed without the prior written consent of =A0VeriSign Naming and =
Directory

> Services. =A0If you have received =A0this e-mail message in error, =
please notify the sender immediately by =A0telephone or reply e-mail =
and

> destroy the original message without making a =A0copy. =A0Thank =
you.

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LHEfFH025499 for ; Sun, 21 Feb 2010 18:14:41 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1LHEfgA020251 for ietf-provreg-outgoing; Sun, 21 Feb 2010 18:14:41 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LHEfBA011278 for ; Sun, 21 Feb 2010 18:14:41 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NjFOA-0003QM-FV; Sun, 21 Feb 2010 18:14:38 +0100
Date: Sun, 21 Feb 2010 18:14:38 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: James Gould
cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
In-Reply-To:
Message-ID:
References:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-20501796-1266772478=:12860"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--37663318-20501796-1266772478=:12860
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi James

Thanks for the update!

Concerning the transition considerations:

3. The version of 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,=20
2.3/2.4), where extensions are queried too. This might lead to=20
inconsistencies in the extension announcements of an EPP server.

- Furthermore I consider it a bad idea, if EPP servers hide extensions=20
from EPP clients. While such behavior is not prohibited by RFC 5730, it=20
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=20
recommendation, that the EPP client SHOULD always use 1.1, if mutually=20
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,
>=20
> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which in=
cludes the feedback that I received so far. =A0I included an open
> question on the inclusion of the ttl element to the AD for guidance. =A0P=
lease let me know if you have any feedback to the latest draft.
>=20
> Thanks, =A0
>=20
> --
>=20
>=20
> JG
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =A0
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> Notice to Recipient: =A0This e-mail contains confidential, proprietary an=
d/or Registry =A0Sensitive information intended solely for the
> recipient and, thus may not be =A0retransmitted, reproduced or disclosed =
without the prior written consent of =A0VeriSign Naming and Directory
> Services. =A0If you have received =A0this e-mail message in error, please=
notify the sender immediately by =A0telephone or reply e-mail and
> destroy the original message without making a =A0copy. =A0Thank you.
>=20
>=20
>
--37663318-20501796-1266772478=:12860--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LGcmh4015247 for ; Sun, 21 Feb 2010 17:38:48 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1LGcmqn003912 for ietf-provreg-outgoing; Sun, 21 Feb 2010 17:38:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1LGclj9014872 for ; Sun, 21 Feb 2010 17:38:48 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NjEpT-0003N2-4Q for [email-masked]; Sun, 21 Feb 2010 17:38:47 +0100
Date: Sun, 21 Feb 2010 17:38:47 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: EPP Provreg
Subject: [ietf-provreg] Fwd: Re: [DNSOP] Roll Over and Die ?
Message-ID:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

Hi,

I am just wondering whether or not these findings (links see below) have
an impact on rfc4310bis, as we have some open issues touching this
problem space.

Any thoughts?

cheers,
Bernie

-------- Original Message --------
Subject: Re: [DNSOP] Roll Over and Die ?
Date: Thu, 18 Feb 2010 13:35:59 +0000

On Thu, 18 Feb 2010, George Barwood wrote:

> Any reaction to this CircleID article ?
>
> http://www.circleid.com/posts/dns_resolvers_and_dnssec_roll_over_and_die/

https://www.isc.org/announcement/response-to-concerns10Feb
http://unbound.net/pipermail/unbound-users/2010-February/001031.html

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1HM77Ha015964 for ; Wed, 17 Feb 2010 23:07:07 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1HM77cw007807 for ietf-provreg-outgoing; Wed, 17 Feb 2010 23:07:07 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1HM75b9019438 for ; Wed, 17 Feb 2010 23:07:05 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1HM1T9c009324 for ; Wed, 17 Feb 2010 17:01:30 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 17:07:04 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Feb 2010 22:07:03 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 17 Feb 2010 17:06:54 -0500
Subject: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis-05.txt Submitted for Review
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9gyuHd/LAEtXUTgBCBq+fg==
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349271221_47610896"
X-OriginalArrivalTime: 17 Feb 2010 22:07:04.0699 (UTC) FILETIME=[89DD1CB0:01CAB01D]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3349271221_47610896
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

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

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

--B_3349271221_47610896
Content-type: text/html;
charset="US-ASCII"
Content-transfer-encoding: quoted-printable

draft-gould-rfc4310bis-05.txt Submitted for Review

All,

I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.tx=
t 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 d=
raft.

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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.

--B_3349271221_47610896--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1GLppLR011184 for ; Tue, 16 Feb 2010 22:51:51 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1GLpp4f013156 for ietf-provreg-outgoing; Tue, 16 Feb 2010 22:51:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1GLpoSS017259 for ; Tue, 16 Feb 2010 22:51:51 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1GLjuoa003998; Tue, 16 Feb 2010 16:45:56 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 16:51:29 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Feb 2010 21:51:28 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Tue, 16 Feb 2010 16:51:22 -0500
Subject: Re: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for Review
From: James Gould
To: Howard Eland , Olafur Gudmundsson
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for Review
Thread-Index: AcqvT7pqNd7cVBD5Qgy3FqzjYaXVFAAAnMm3
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349183885_45536054"
X-OriginalArrivalTime: 16 Feb 2010 21:51:29.0295 (UTC) FILETIME=[31E809F0:01CAAF52]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3349183885_45536054
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

>>=20
>> My suggestion is suggest that each parent set a reasonable 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.
>=20
> Possibly, if a reasonable tradeoff can be made here. Of course, if we ha=
ve
> wording about server policy being able to define the floor and ceiling, t=
hen
> technically operators could force it to be a single value, if they so des=
ired.

I would view this as an optional server feature, so if a server does not
want to support a client-specified value they don=B9t have to and should
return a 2102 to the client in a similar fashion to the maxSigLife. If the=
y
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 i=
f
others see the benefit of this.

--=20

JG=20

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

=20
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 writte=
n
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
Date: Tue, 16 Feb 2010 16:33:42 -0500
To: Olafur Gudmundsson
Cc: James Gould , EPP Provreg
Subject: Re: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for
Review

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

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, the=
n
technically operators could force it to be a single value, if they so
desired.

--B_3349183885_45536054
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for R=
eview

>> My suggestion is suggest that each parent set a reasonable 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.

> 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 wa=
nt to support a client-specified value they don’t have to and should r=
eturn 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 m=
aximum wait period, but again that would be optional.  If the visibilit=
y 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 underst=
and if others see the benefit of this.

--

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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 <heland@afilias.=
info>

Date: Tue, 16 Feb 2010 16:33:42 -0500

To: Olafur Gudmundsson <[email-masked]=

Cc: James Gould <[email-masked]=
m>, EPP Provreg <ietf-provreg@cafa=
x.se>

Subject: Re: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submit=
ted for Review

> My suggestion is suggest that each parent set a resonable default and<=
BR>
> a floor on how low the TTL can be set, the child would be allowed to
> 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.

--B_3349183885_45536054--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1GLXp3f006027 for ; Tue, 16 Feb 2010 22:33:51 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1GLXpli015411 for ietf-provreg-outgoing; Tue, 16 Feb 2010 22:33:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1GLXoR5013222 for ; Tue, 16 Feb 2010 22:33:50 +0100 (MET)
Subject: Re: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for Review
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Howard Eland
In-Reply-To: <[email-masked]>
Date: Tue, 16 Feb 2010 15:33:42 -0600
Cc: James Gould , EPP Provreg
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]>
To: Olafur Gudmundsson
X-Mailer: Apple Mail (2.1077)
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o1GLXoR5017628
Sender: [email-masked]
Precedence: bulk

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

> On 16/02/2010 1:00 PM, Howard Eland wrote:
>> 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.
>
> 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 :-)

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

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

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

> Olafur

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1GJreoY018322 for ; Tue, 16 Feb 2010 20:53:40 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1GJrePt028392 for ietf-provreg-outgoing; Tue, 16 Feb 2010 20:53:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1GJrdpE027152 for ; Tue, 16 Feb 2010 20:53:40 +0100 (MET)
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o1GJrDSJ005406; Tue, 16 Feb 2010 14:53:14 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Tue, 16 Feb 2010 14:53:13 -0500
From: Olafur Gudmundsson
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Howard Eland
CC: James Gould , EPP Provreg
Subject: Re: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for Review
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

On 16/02/2010 1:00 PM, Howard Eland wrote:
> 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.

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

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1GI0uol023929 for ; Tue, 16 Feb 2010 19:00:56 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1GI0ueq024941 for ietf-provreg-outgoing; Tue, 16 Feb 2010 19:00:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1GI0tm0022543 for ; Tue, 16 Feb 2010 19:00:55 +0100 (MET)
Subject: Re: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for Review
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary=Apple-Mail-46-273231618
From: Howard Eland
In-Reply-To:
Date: Tue, 16 Feb 2010 12:00:40 -0600
Cc: EPP Provreg
Message-Id: <[email-masked]>
References:
To: James Gould
X-Mailer: Apple Mail (2.1077)
X-Authenticated: True
Sender: [email-masked]
Precedence: bulk

--Apple-Mail-46-273231618
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252

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

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,
>=20
> I haven=92t 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=92s public keys =
and the gaining DNS hosting provider=92s DS needs to be added to the =
parent zone. The switching of the name servers has to wait for the =
longest of the ttl=92s (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.=20
>=20
> Thanks, =20
>=20
> --=20
>=20
>=20
> JG=20
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =20
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> 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.
>=20
>=20
> From: James Gould
> Date: Fri, 12 Feb 2010 11:04:46 -0500
> To: EPP Provreg
> Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
> Subject: Re: draft-gould-rfc4310bis-04.txt Submitted for Review
>=20
> All,
>=20
> 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? =46rom =
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. =20
>=20
> Any thoughts to this is greatly appreciated. =20
>=20
> 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. =20
>=20
> Thanks,
>=20
> --=20
>=20
>=20
> JG=20
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =20
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> 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.
>=20
>=20
> From: James Gould
> Date: Wed, 10 Feb 2010 23:07:31 -0500
> To: EPP Provreg
> Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
> Subject: draft-gould-rfc4310bis-04.txt Submitted for Review
>=20
> All,
>=20
> I submitted 04 of the draft. The official draft is available at the =
URL below:
>=20
> http://www.ietf.org/id/draft-gould-rfc4310bis-04.txt
>=20
> 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. =20=

>=20
> I did not include anything in 04 related to Eduardo=92s active flag =
request based on the variety of feedback on the provreg list that shows =
that it=92s not ready for inclusion in rfc4310bis. I encourage that the =
discussions continue on the list for possible inclusion in a future =
draft.=20
>=20
> Thanks,
>=20
> --=20
>=20
>=20
> JG=20
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =20
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> 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.

--Apple-Mail-46-273231618
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252

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

O=
n Feb 15, 2010, at 6:26 PM, James Gould wrote:

All,

I haven=92t 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=92s public keys and the =
gaining DNS hosting provider=92s DS needs to be added to the parent =
zone.   The switching of the name servers has to wait for the =
longest of the ttl=92s (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

------------------------------------------------=
-------

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: 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,

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?  =46rom 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

--------------------------------------------------=
-----

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: 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,

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

http://www.i=
etf.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=92s active flag =
request based on the variety of feedback on the provreg list that shows =
that it=92s 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.

=

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1G0Q5p5004203 for ; Tue, 16 Feb 2010 01:26:05 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1G0Q557021466 for ietf-provreg-outgoing; Tue, 16 Feb 2010 01:26:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1G0Q4kV018794 for ; Tue, 16 Feb 2010 01:26:05 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1G0KWcS007609 for ; Mon, 15 Feb 2010 19:20:32 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 19:26:03 -0500
Received: from 10.169.80.3 ([10.169.80.3]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Feb 2010 00:26:02 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 15 Feb 2010 19:26:01 -0500
Subject: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for Review
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis-04.txt Submitted for Review
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9gyuHd/LAEtXUTgAqGFWHw==
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3349106762_43428898"
X-OriginalArrivalTime: 16 Feb 2010 00:26:03.0634 (UTC) FILETIME=[9F6E1D20:01CAAE9E]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3349106762_43428898
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

I haven=B9t 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 losin=
g
DNS hosting provider needs to be capable of accepting the gaining DNS
hosting provider=B9s public keys and the gaining DNS hosting provider=B9s DS
needs to be added to the parent zone. The switching of the name servers
has to wait for the longest of the ttl=B9s (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, =20

--=20

JG=20

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

=20
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 writte=
n
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
Date: Fri, 12 Feb 2010 11:04:46 -0500
To: EPP Provreg
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: Re: draft-gould-rfc4310bis-04.txt Submitted for Review

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 ca=
n
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 incorporat=
e
as much feedback as possible to the 04 draft in a soon to follow 05 draft.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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
Date: Wed, 10 Feb 2010 23:07:31 -0500
To: EPP Provreg
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: draft-gould-rfc4310bis-04.txt Submitted for Review

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 feedbac=
k
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=B9s active flag request
based on the variety of feedback on the provreg list that shows that it=B9s
not ready for inclusion in rfc4310bis. I encourage that the discussions
continue on the list for possible inclusion in a future draft.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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.

--B_3349106762_43428898
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: draft-gould-rfc4310bis-04.txt Submitted for Review

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 th=
is 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 decreasin=
g the ttl in support of a DNS hosting transfer, which could be part of a spo=
nsorship transfer.  To enable the DNS hosting transfer of a DNSSEC enab=
led domain without going insecure by removing the DS records, the losing DNS=
hosting provider needs to be capable of accepting the gaining DNS hosting p=
rovider’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 zon=
e) 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 o=
f the feedback received so far.

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: Fri, 12 Feb 2010 11:04:46 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review

Subject: Re: draft-gould-rfc4310bis-04.txt Submitted for Review

All,

I forgot about one item brought up by Klaus in a prior posting related to i=
nclusion of ttl in rfc4310bis.  What does the list feel about the need =
for adding support for an optional client specified ttl value and an optiona=
l server ttl returned in the info response used in a similar fashion as the =
maxSigLife, meaning directly under the secDNS:create, secDNS:infData, and un=
der the secDNS:chg of the secDNS:update?  From my perspective this migh=
t be useful in the handling of DNS hosting transfers, where the Registrant c=
an 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 incorporat=
e as much feedback as possible to the 04 draft in a soon to follow 05 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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: Wed, 10 Feb 2010 23:07:31 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review

Subject: draft-gould-rfc4310bis-04.txt Submitted for Review

All,

I submitted 04 of the draft.  The official draft is available at the U=
RL below:

http://www.i=
etf.org/id/draft-gould-rfc4310bis-04.txt

There are many updates from 03 described in Appendix A based on the feedbac=
k 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 req=
uest 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 d=
iscussions 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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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.

--B_3349106762_43428898--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1CGgFhC002774 for ; Fri, 12 Feb 2010 17:42:15 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1CGgFNN007433 for ietf-provreg-outgoing; Fri, 12 Feb 2010 17:42:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1CGg38G013632; Fri, 12 Feb 2010 17:42:04 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o1CGMd65024952; Fri, 12 Feb 2010 11:22:40 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 11:42:03 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Feb 2010 16:42:02 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 12 Feb 2010 11:41:57 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review
From: James Gould
To:
CC: EPP Provreg , "[email-masked]"
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review
Thread-Index: AcqsAWecM2/JoU90QLaVT3tuuybjIAAAOKz9
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3348819720_37004518"
X-OriginalArrivalTime: 12 Feb 2010 16:42:03.0010 (UTC) FILETIME=[4DE2C620:01CAAC02]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3348819720_37004518
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

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=B9s. The secDNS:chg
follows the other EPP RFC=B9s by having minOccurs=3D=B20=B2 and subsequently any
attributes that can be changed have minOccurs=3D=B20=B2 which in this case is onl=
y
the single attribute maxSigLife. With this structure additional attributes
can be more easily added that are consistent with the other EPP RFC=B9s. 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,=20

--=20

JG=20

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

=20
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 writte=
n
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:
Date: Fri, 12 Feb 2010 11:35:31 -0500
To: James Gould
Cc: EPP Provreg , "[email-masked]"

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

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

thanks, James
just a picky detail; ISTM that the minOccurs=3D"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.

--B_3348819720_37004518
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Revie=
w

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=3D”0” a=
nd subsequently any attributes that can be changed have minOccurs=3D”0&#=
8221; which in this case is only the single attribute maxSigLife.  With=
this structure additional attributes can be more easily added that are cons=
istent with the other EPP RFC’s.  I sent a question out to the li=
st about the option of adding the ttl attribute, which would add a second op=
tional element under secDNS:chg.

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: <[email-masked]>

Date: Fri, 12 Feb 2010 11:35:31 -0500

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>, "owner-ietf-provre=
[email-masked]" <owner-ietf-pr=
[email-masked]>

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

[email-masked] wrote=
on 11/02/2010 04:07:31:

> James Gould <[email-masked]&=
gt;

> I submitted 04 of the draft.  The official draft is available at =
theURL

below:

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

thanks, James

just a picky detail; ISTM that the minOccurs=3D"0" for maxSigLife i=
n 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=3D"updateType">

<sequence>

<element name=3D"rem" type=3D"secDNS:=
remType" minOccurs=3D"0"/>

<element name=3D"add" type=3D"secDNS:=
dsOrKeyType" minOccurs=3D"0"/>

<element name=3D"maxSigLife" type=3D"=
secDNS:maxSigLifeType" minOccurs=3D"0"/>

</sequence>

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

</complexType>

--B_3348819720_37004518--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1CGZjSx013395 for ; Fri, 12 Feb 2010 17:35:45 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1CGZjdL022377 for ietf-provreg-outgoing; Fri, 12 Feb 2010 17:35:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1CGZXNg027988; Fri, 12 Feb 2010 17:35:33 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:Subject:To: Cc:X-Mailer:Message-ID:From:Date:X-MIMETrack:MIME-Version: Content-type; b=bwfUmIXhWMD9P6S6EuFtTavv+YOmJwj7K16X+BKI1IwR88xeNX0gOq9X MTUeCbYzi/JwFuHyLRB8/9kT2gF81Mnkysnl2qj2sUXQG9juuTMc3zpdA KldicsuiRR/92po;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1265992533; x=1297528533; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20[i etf-provreg]=20draft-gould-rfc4310bis-04.txt=20Submitted =20for=20Review|Date:=20Fri,=2012=20Feb=202010=2016:35:31 =20+0000|Message-ID:=20|To:=20James=20Go uld=20|Cc:=20EPP=20Provreg=20,=0D=0A=[email-masked] |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20; bh=SiUcA75d29Ozo7U4N4kfftAG6fkWA2+OVsc/6wTSq9A=; b=YNxCPnXV5HXUKf3VS7Y4uR+bE4c53yRf4ezFXyn5yXv3V9zYjs7V2qy7 m4l1peeAgAFNA0vTjV5PrU+JgLvV+Qp0v87CticedlIuyk+YKIRzpjS7X qp0nH4CpscH872h;
X-IronPort-AV: E=Sophos;i="4.49,461,1262563200"; d="scan'208";a="21658252"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 12 Feb 2010 16:35:32 +0000
In-Reply-To:
References:
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review
To: James Gould
Cc: EPP Provreg , [email-masked]
X-Mailer: Lotus Notes Release 8.0.1 February 07, 2008
Message-ID:
From: [email-masked]
Date: Fri, 12 Feb 2010 16:35:31 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 12/02/2010 04:35:32 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk

[email-masked] wrote on 11/02/2010 04:07:31:
> James Gould
> I submitted 04 of the draft. The official draft is available at theURL
below:
>
> 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.

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1CG4u4Z015748 for ; Fri, 12 Feb 2010 17:04:56 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1CG4up2002021 for ietf-provreg-outgoing; Fri, 12 Feb 2010 17:04:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1CG4tno020738 for ; Fri, 12 Feb 2010 17:04:55 +0100 (MET)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1CFxTDH010847 for ; Fri, 12 Feb 2010 10:59:29 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 11:04:54 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Feb 2010 16:04:54 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 12 Feb 2010 11:04:46 -0500
Subject: [ietf-provreg] Re: draft-gould-rfc4310bis-04.txt Submitted for Review
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis-04.txt Submitted for Review
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9gyuHd/LAEtXUTg=
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3348817491_36867755"
X-OriginalArrivalTime: 12 Feb 2010 16:04:54.0692 (UTC) FILETIME=[1DB46E40:01CAABFD]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3348817491_36867755
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

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 ca=
n
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 incorporat=
e
as much feedback as possible to the 04 draft in a soon to follow 05 draft.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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
Date: Wed, 10 Feb 2010 23:07:31 -0500
To: EPP Provreg
Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review
Subject: draft-gould-rfc4310bis-04.txt Submitted for Review

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 feedbac=
k
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=B9s active flag request
based on the variety of feedback on the provreg list that shows that it=B9s
not ready for inclusion in rfc4310bis. I encourage that the discussions
continue on the list for possible inclusion in a future draft.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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.

--B_3348817491_36867755
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: draft-gould-rfc4310bis-04.txt Submitted for Review

All,

I forgot about one item brought up by Klaus in a prior posting related to i=
nclusion of ttl in rfc4310bis.  What does the list feel about the need =
for adding support for an optional client specified ttl value and an optiona=
l server ttl returned in the info response used in a similar fashion as the =
maxSigLife, meaning directly under the secDNS:create, secDNS:infData, and un=
der the secDNS:chg of the secDNS:update?  From my perspective this migh=
t be useful in the handling of DNS hosting transfers, where the Registrant c=
an 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 incorporat=
e as much feedback as possible to the 04 draft in a soon to follow 05 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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: Wed, 10 Feb 2010 23:07:31 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Conversation: draft-gould-rfc4310bis-04.txt Submitted for Review

Subject: draft-gould-rfc4310bis-04.txt Submitted for Review

All,

I submitted 04 of the draft.  The official draft is available at the U=
RL below:

http://www.i=
etf.org/id/draft-gould-rfc4310bis-04.txt

There are many updates from 03 described in Appendix A based on the feedbac=
k 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 req=
uest 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 d=
iscussions 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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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.

--B_3348817491_36867755--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1BLtb1U015006 for ; Thu, 11 Feb 2010 22:55:37 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1BLtbFQ018537 for ietf-provreg-outgoing; Thu, 11 Feb 2010 22:55:37 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1BLtaKj016631 for ; Thu, 11 Feb 2010 22:55:37 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1BLoBOu027288; Thu, 11 Feb 2010 16:50:11 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 16:55:34 -0500
Received: from 10.169.80.4 ([10.169.80.4]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Feb 2010 21:55:34 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 11 Feb 2010 16:55:28 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review
From: James Gould
To: Bernie Hoeneisen
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review
Thread-Index: Acqq++/QX/0JH/vbTCSxXbw7oeVRuwAaPxNw
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3348752129_33116925"
X-OriginalArrivalTime: 11 Feb 2010 21:55:34.0868 (UTC) FILETIME=[F036C140:01CAAB64]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3348752129_33116925
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Bernie,

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

> s/Extensible Provisioning Protocol v1.0/Extensible Provisioning Protoc=
ol
> v1.1/

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

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

Yes, I can see the need for this; although I don=B9t 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 t=
o
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.

> * 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]

I=B9ll work with the AD on this.

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

I=B9ll consider this, but at this point I don=B9t plan on creating a new RFC.

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

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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
Date: Thu, 11 Feb 2010 04:23:50 -0500
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for
Review

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. =A0The 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 feedb=
ack
on the list and privately. =A0These changes
> are substantial, so please review it and provide me with your feedback as=
soon
as possible. =A0
>
> 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. =
=A0I
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
>
> =A0
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> Notice to Recipient: =A0This e-mail contains confidential, proprietary and/=
or
Registry =A0Sensitive information intended
> solely for the recipient and, thus may not be =A0retransmitted, reproduced =
or
disclosed without the prior written consent
> of =A0VeriSign Naming and Directory Services. =A0If you have received =A0this e=
-mail
message in error, please notify the
> sender immediately by =A0telephone or reply e-mail and destroy the original
message without making a =A0copy. =A0Thank you.

--B_3348752129_33116925
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Revie=
w

Bernie,

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

>    s/Extensible Provisioning Protocol v1.0/Extensible P=
rovisioning Protocol

> v1.1/

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

> * I suggest to include implementation recommendations, in particular f=
or

>    servers, on how to deal with the transition from 1.0=
to 1.1.

>    I'll think about some decent text and might come bac=
k to the list.

>    If anyone else has great ideas for suitable wording,=
feel free to

>    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 t=
o 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 ser=
ver 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:p=
arams:xml:ns:secDNS-1.1 is included in the EPP login then version 1.1 of sec=
DNS:infData SHOULD be returned and if only extURI urn:ietf:params:xml:ns:sec=
DNS-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 t=
hen secDNS:infData SHOULD NOT be returned.

Does anyone else have thoughts related to implementation recommendations.

> * You might want to add an RFC Editors' note to sections "Appendi=
x A./B."

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

I’ll work with the AD on this.

> * You might want to include a summary of the most important changes
>    beween 4310 and the new RFC (no details), (and publi=
sh it in the new

>    RFC) to help people better understand the difference=
s between 4310

>    and the new RFC.

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

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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 04:23:50 -0500

To: James Gould <[email-masked]=
m>

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

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

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 Provis=
ioning 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 pu=
blication]

* 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 bet=
ween 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. =A0The official draft is available at the U=
RL below:

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

> There are many updates from 03 described in Appendix A based on the fe=
edback on the list and privately. =A0These changes

> are substantial, so please review it and provide me with your feedback=
as soon as possible. =A0

> I did not include anything in 04 related to Eduardo?s active flag requ=
est based on the variety of feedback on the

> provreg list that shows that it?s not ready for inclusion in rfc4310bi=
s. =A0I 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

> =A0

> 21345 Ridgetop Circle

> LS2-2-1

> Dulles, VA 20166

> Notice to Recipient: =A0This e-mail contains confidential, proprietary a=
nd/or Registry =A0Sensitive information intended

> solely for the recipient and, thus may not be =A0retransmitted, reproduc=
ed or disclosed without the prior written consent

> of =A0VeriSign Naming and Directory Services. =A0If you have received =A0thi=
s e-mail message in error, please notify the

> sender immediately by =A0telephone or reply e-mail and destroy the origi=
nal message without making a =A0copy. =A0Thank you.

--B_3348752129_33116925--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1B9Nsvi016103 for ; Thu, 11 Feb 2010 10:23:54 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1B9Ns7E019451 for ietf-provreg-outgoing; Thu, 11 Feb 2010 10:23:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1B9NrfJ023134 for ; Thu, 11 Feb 2010 10:23:53 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NfVH4-0003JI-Ap; Thu, 11 Feb 2010 10:23:50 +0100
Date: Thu, 11 Feb 2010 10:23:50 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: James Gould
cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review
In-Reply-To:
Message-ID:
References:
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-20530750-1265880230=:12441"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--37663318-20530750-1265880230=:12441
Content-Type: TEXT/PLAIN; charset=ISO-8859-7; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

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=20
thoroughly.

cheers,
Bernie

On Wed, 10 Feb 2010, James Gould wrote:

> All,
>=20
> I submitted 04 of the draft. =A0The official draft is available at the UR=
L below:
>=20
> http://www.ietf.org/id/draft-gould-rfc4310bis-04.txt
>=20
> There are many updates from 03 described in Appendix A based on the feedb=
ack on the list and privately. =A0These changes
> are substantial, so please review it and provide me with your feedback as=
soon as possible. =A0
>=20
> I did not include anything in 04 related to Eduardo=A2s active flag reque=
st based on the variety of feedback on the
> provreg list that shows that it=A2s not ready for inclusion in rfc4310bis=
=2E =A0I encourage that the discussions continue on
> the list for possible inclusion in a future draft.
>=20
> Thanks,
>=20
> --
>=20
>=20
> JG
>=20
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email-masked]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>=20
> =A0
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>=20
> Notice to Recipient: =A0This e-mail contains confidential, proprietary an=
d/or Registry =A0Sensitive information intended
> solely for the recipient and, thus may not be =A0retransmitted, reproduce=
d or disclosed without the prior written consent
> of =A0VeriSign Naming and Directory Services. =A0If you have received =A0=
this e-mail message in error, please notify the
> sender immediately by =A0telephone or reply e-mail and destroy the origin=
al message without making a =A0copy. =A0Thank you.
>=20
--37663318-20530750-1265880230=:12441--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1B47ZKC029949 for ; Thu, 11 Feb 2010 05:07:35 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1B47ZhT013665 for ietf-provreg-outgoing; Thu, 11 Feb 2010 05:07:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1B47YQi015141 for ; Thu, 11 Feb 2010 05:07:34 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o1B42AIT005159 for ; Wed, 10 Feb 2010 23:02:10 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 23:07:33 -0500
Received: from 10.169.80.4 ([10.169.80.4]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Feb 2010 04:07:32 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 10 Feb 2010 23:07:31 -0500
Subject: [ietf-provreg] draft-gould-rfc4310bis-04.txt Submitted for Review
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis-04.txt Submitted for Review
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9gyuHd/L
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3348688052_31341521"
X-OriginalArrivalTime: 11 Feb 2010 04:07:33.0074 (UTC) FILETIME=[BC7CFB20:01CAAACF]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3348688052_31341521
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

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 feedbac=
k
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=B9s active flag request
based on the variety of feedback on the provreg list that shows that it=B9s
not ready for inclusion in rfc4310bis. I encourage that the discussions
continue on the list for possible inclusion in a future draft.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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.

--B_3348688052_31341521
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

draft-gould-rfc4310bis-04.txt Submitted for Review

All,

I submitted 04 of the draft.  The official draft is available at the U=
RL below:

http://www.i=
etf.org/id/draft-gould-rfc4310bis-04.txt

There are many updates from 03 described in Appendix A based on the feedbac=
k 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 req=
uest 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 d=
iscussions 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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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.

--B_3348688052_31341521--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1AEeTkP011753 for ; Wed, 10 Feb 2010 15:40:29 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1AEeT7u006082 for ietf-provreg-outgoing; Wed, 10 Feb 2010 15:40:29 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1AEeSpM014251 for ; Wed, 10 Feb 2010 15:40:28 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o1AEL8FS021626; Wed, 10 Feb 2010 09:21:08 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Feb 2010 09:40:27 -0500
Received: from 10.169.80.4 ([10.169.80.4]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Feb 2010 14:40:26 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 10 Feb 2010 09:40:24 -0500
Subject: Re: [ietf-provreg] 4310-bis progress
From: James Gould
To: , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] 4310-bis progress
Thread-Index: AcqqRthi3zUPlEXrTAKCMv09+mPQLwAGCIiK
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3348639624_28406451"
X-OriginalArrivalTime: 10 Feb 2010 14:40:27.0109 (UTC) FILETIME=[FC5D2150:01CAAA5E]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3348639624_28406451
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Ray,

Excellent question. I sent an update to the AD almost a week ago and I
haven=B9t received a response yet. I=B9m working from the following assumption=
s
related to the discussed items on the list:

1. schema versions =AD 4310-bis will use a new URI secDNS-1.1. By changing
the URI is breaks backward compatibility, but this will allow us to address
other issues more cleanly.
2. maxSigLife =AD The maxSigLife will be moved out of the dsData and directly
under secDNS:create, secDNS:update, and secDNS:infData since it applies
across all of the DS for a domain.
3. Ulrich=B9s request to remove the backward compatibility inconsistent or
undesirable features. These include removing support of secDNS:rem with
secDNS:keyTag and to change secDNS:chg to work as a true change instead of =
a
replace or to remove secDNS:chg altogether. I=B9m in favor of addressing thi=
s
request after we broke backward compatibility with #1, where removing
support for secDNS:rem with secDNS:keyTag and removing support for
secDNS:chg is straightforward. Since maxSigLife was moved outside the the
dsData in #2, use of secDNS:chg for DS is not needed. The only purpose for
secDNS:chg is if there is the need to change an attribute in secDNS:dsData
or secDNS:keyData based on #4 below.
4. Eduardo=B9s request for an =B3active=B2 flag based on asynchronous server-side
validation. This particular item has not been resolved. I posted a messag=
e
with a list of options that I came up with to address this request. If a
secDNS:dsData or secDNS:keyData attribute needs to be added for the client
to provide a hint to the server, than secDNS:chg is needed.

I highly suggest that you have =B3the right people=B2 take the time to look at
the details of the changes as soon as possible to help drive 4310-bis along=
.
I=B9ve have many changes from the feedback and based on #1, #2, #3 above
included in a 04 draft that has not been posted yet. I really want to come
to some sort of conclusion on #4 and I want to ensure that the list is fine
with #3 prior to posting 04. Any feedback you have on these items or any
other elements of 4310-bis is greatly appreciated.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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:
Date: Wed, 10 Feb 2010 06:19:47 -0500
To: EPP Provreg
Subject: [ietf-provreg] 4310-bis progress

James,=20

What are the current plans for 4310-bis? The IESG last call is due to
expire next week, but there's been significant on-list debate around some
aspects (e.g. schema versions for backwards compatibility, maxSigLife, etc)=
.

I'm really just trying to get an idea of the potential future timeline for
this document so that we can make sure the right people have time to look a=
t
the details of the changes.

Ray=20

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

--B_3348639624_28406451
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] 4310-bis progress

Ray,

Excellent question.  I sent an update to the AD almost a week ago and =
I haven’t received a response yet.  I’m working from the fo=
llowing assumptions related to the discussed items on the list:

schema versions – 4310-bis will use a new URI =
secDNS-1.1.  By changing the URI is breaks backward compatibility, but =
this will allow us to address other issues more cleanly.

maxSigLife – The maxSigLife will be moved out of t=
he dsData and directly under secDNS:create, secDNS:update, and secDNS:infDat=
a since it applies across all of the DS for a domain.=20

Ulrich’s request to remove the backward compatibil=
ity inconsistent or undesirable features.  These include removing suppo=
rt of secDNS:rem with secDNS:keyTag and to change secDNS:chg to work as a tr=
ue change instead of a replace or to remove secDNS:chg altogether.  I&#=
8217;m in favor of addressing this request after we broke backward compatibi=
lity with #1, where removing support for secDNS:rem with secDNS:keyTag and r=
emoving support for secDNS:chg is straightforward.  Since maxSigLife wa=
s moved outside the the dsData in #2, use of secDNS:chg for DS is not needed=
.  The only purpose for secDNS:chg is if there is the need to change an=
attribute in secDNS:dsData or secDNS:keyData based on #4 below.

Eduardo’s request for an “active” flag=
based on asynchronous server-side validation.  This particular item ha=
s not been resolved.  I posted a message with a list of options that I =
came up with to address this request.  If a secDNS:dsData or secDNS:key=
Data attribute needs to be added for the client to provide a hint to the ser=
ver, than secDNS:chg is needed.

I highly suggest that you have “the right people” take the time=
to look at the details of the changes as soon as possible to help drive 431=
0-bis along.  I’ve have many changes from the feedback and based =
on #1, #2, #3 above included in a 04 draft that has not been posted yet. &nb=
sp;I really want to come to some sort of conclusion on #4 and I want to ensu=
re that the list is fine with #3 prior to posting 04.  Any feedback you=
have on these items or any other elements of 4310-bis is greatly appreciate=
d.

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: <[email-masked]>

Date: Wed, 10 Feb 2010 06:19:47 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: [ietf-provreg] 4310-bis progress

James,

What are the current plans for 4310-bis?  The IESG last call is due to=
expire next week, but there's been significant on-list debate around some a=
spects (e.g. schema versions for backwards compatibility, maxSigLife, etc). =

I'm really just trying to get an idea of the potential future timeline for =
this document so that we can make sure the right people have time to look at=
the details of the changes.

Ray

--

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

e: [email-masked], t: +44 1865 332211<=
BR>

--B_3348639624_28406451--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1ADF3Sn015684 for ; Wed, 10 Feb 2010 14:15:03 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1ADF36m002089 for ietf-provreg-outgoing; Wed, 10 Feb 2010 14:15:03 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1ADF3FI006629 for ; Wed, 10 Feb 2010 14:15:03 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 34643DC; Wed, 10 Feb 2010 14:15:03 +0100 (MEZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id uxZr1EXoWQTN; Wed, 10 Feb 2010 14:14:58 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 9F5C8E2; Wed, 10 Feb 2010 14:14:58 +0100 (MEZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id o1ADEw8m026291; Wed, 10 Feb 2010 14:14:58 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 10 Feb 2010 14:14:58 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.8) Gecko/20100209 Shredder/3.0.2pre
MIME-Version: 1.0
To: EPP Provreg
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o1ADF3FI020184
Sender: [email-masked]
Precedence: bulk

On 05/02/10 14:18, Ulrich Wisser wrote:
> Hi,
>
>> 1. Don’t include any additional elements. This means that the server
>> would either validate the passed DS inline with the EPP
>> transaction or would publish all DS that is passed.
>
> This would be my favorite option. Sorry Eduardo!
>
>> 2. Add a new optional element in the secDNS:dsData (DS Interface) and
>> secDNS:keyData (Key Interface) elements of secDNS:infData. I
>> propose the use of the secDNS:published element.
>

Hi all,

I have to admit that I have not yet fully understood the purpose of the
element for each key/DS entry in the domain:info response.

Shall it reflect the outcome of an asynchronous verification of the specified
key data against the actual data in the child zone? Or shall it simply denote
that the respective DS record is now visible on all name servers of the parent zone?

In both cases, I see the problem that the registrar needs to periodically check
the domain in order to detect a "magical" change of the value from "false" to
"true". Being responsible for thousands to millions of domains, a registrar
might create a considerable extra load on his and the registry's servers for the
periodical submission of requests. Wouldn't it be better to create
a poll message for that state change which can be retrieved via the request?

In the first case, I wonder whether this would match the general processing
model of EPP. If an asynchronous check is performed, wouldn't the respective
and requests be required to return a
1001/"Command completed successfully; action pending" response, enter the
"pendingCreate"/"pendingUpdate" state until completion, with the respective poll
message at the end?

In the second case, I would like to also refer to a posting of myself to the
list last November[1].

Regards

Klaus

[1] http://www.cafax.se/ietf-provreg/maillist/2009-11/msg00028.html

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1ABJnE2018475 for ; Wed, 10 Feb 2010 12:19:49 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o1ABJn5d019604 for ietf-provreg-outgoing; Wed, 10 Feb 2010 12:19:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o1ABJn3P029149 for ; Wed, 10 Feb 2010 12:19:49 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type; b=KbEp9/QKKudqIGzvxOF/Lo04w+xD384OLARg7izJiz9v1x56jqyP4etE Ot/sFp4mKe7cwRleXRcm4DgfGhMKPy+V/jWQNiJ9xj9BoaDgM8kExR588 Q4K+6CeBuxsgf1Q;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1265800789; x=1297336789; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=204310-bis=20 progress|Date:=20Wed,=2010=20Feb=202010=2011:19:47=20+000 0|Message-ID:=20|To:=20EPP=20Provreg=20< [email-masked]>|MIME-Version:=201.0; bh=1v6uG9nD3UYN4psVvTtpQwa51R2gzfyP6OuX2mhlw/c=; b=MN1hxMZdT0+FyHU8boeNb+TbqSfKeVKtLvNOiODCRGcXB1H9j3Mm4HuI ycL541nOGrzw7dUiLi6NzgfdEOTFdH/ATJ7pufnJmEVBQtgSZuOyzeOEi vcnOeeC+7DRPVy+;
X-IronPort-AV: E=Sophos;i="4.49,443,1262563200"; d="scan'208";a="16187859"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 10 Feb 2010 11:19:48 +0000
To: EPP Provreg
Subject: [ietf-provreg] 4310-bis progress
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Wed, 10 Feb 2010 11:19:47 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 10/02/2010 11:19:48 AM, Serialize complete at 10/02/2010 11:19:48 AM
Content-Type: multipart/alternative; boundary="=_alternative 003E3C4A802576C6_="
Sender: [email-masked]
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 003E3C4A802576C6_=
Content-Type: text/plain; charset="US-ASCII"

James,

What are the current plans for 4310-bis? The IESG last call is due to
expire next week, but there's been significant on-list debate around some
aspects (e.g. schema versions for backwards compatibility, maxSigLife,
etc).

I'm really just trying to get an idea of the potential future timeline for
this document so that we can make sure the right people have time to look
at the details of the changes.

Ray

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

--=_alternative 003E3C4A802576C6_=
Content-Type: text/html; charset="US-ASCII"

James,

What are the current plans for 4310-bis?
The IESG last call is due to expire next week, but there's been significant
on-list debate around some aspects (e.g. schema versions for backwards
compatibility, maxSigLife, etc).

I'm really just trying to get an idea
of the potential future timeline for this document so that we can make
sure the right people have time to look at the details of the changes.

Ray

--

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

e: [email-masked], t: +44 1865 332211

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o15ExmDN028195 for ; Fri, 5 Feb 2010 15:59:48 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o15ExmT1020870 for ietf-provreg-outgoing; Fri, 5 Feb 2010 15:59:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o15ExlVL007360 for ; Fri, 5 Feb 2010 15:59:48 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o15EsY9q025698; Fri, 5 Feb 2010 09:54:34 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 09:59:46 -0500
Received: from 10.169.80.15 ([10.169.80.15]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Feb 2010 14:59:45 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 05 Feb 2010 09:59:44 -0500
Subject: Re: [ietf-provreg] Pandoras box - or not!? you decide
From: James Gould
To: Ulrich Wisser , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Pandoras box - or not!? you decide
Thread-Index: AcqmZyx3Zr062cwPRxC26EniaOhmFAADK1lI
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3348208785_8166376"
X-OriginalArrivalTime: 05 Feb 2010 14:59:46.0676 (UTC) FILETIME=[DB744340:01CAA673]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3348208785_8166376
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Ulrich,

Thanks for stepping forward with your proposal. We=B9ve come a long way whic=
h
is one reason to stay the course, but I would like to hear from the list
feedback to Ulrich=B9s proposal. I don=B9t believe the changes being requested
are all that large, but they are a significant shift from backward
compatibility which was broken with the URI change. I provide feedback to
your proposals below. I certainly don=B9t want to entertain truly opening up
Pandora's Box with a laundry list of new features and extend the time
getting this update out for servers to implement to.

> 1. Drop old style
> There is no need to support a broken specification in the new version.
> Servers looking for backward compatibility can use version 1.0.

All we=B9re talking about here is removing support for the with
the . The issue with use of the and
(wildcard delete) is mitigated in the text, but if no one
intends to support the old model than it can be removed.

> 2. Redefine the to match the semantics used in all other
> EPP documents.
> The usual definition of add/rem/chg for EPP is that add will add things,
> rem will remove things and chg will update things that can't be added or
> removed. E.g. the registrant for a domain can only be changed, ns
> records can only be added or removed not changed.
> That would mean could no longer be used to add or remove
> ds records. But chg could be used to update maxSigLife.
> This would also mean to drop maxSigLife from dsData and keyData
> interface. And of course maxSigLife can't be added or removed.

I already moved the secDNS:maxSigLife element out of the secDNS:dsData and
secDNS:keyData elements based on feedback from the list and since I agree
that maxSigLife is not an attribute of the secDNS:dsData or secDNS:keyData
but an attribute of the RRSIG which is at the domain level. If we don=B9t ad=
d
the secDNS:childKeyPublished element to secDNS:dsData and secDNS:keyData as
described in option #3 of my =B3off-list was Re: [ietf-provreg] Revision of
4310=B2 posting on the list there are no attributes to update under
secDNS:dsData and secDNS:keyData. Based on this the secDNS:chg could be
removed all together since it really is just an alternative for the
secDNS:add and secDNS:rem. If there is an client updatable attribute under
secDNS:dsData and secDNS:keyData then secDNS:chg would be needed. The only
case right now that I=B9m aware of is the secDNS:childKeyPublished element
that is being discussed on the list.

Removing is a lot easier than adding to the draft, but if there are any
servers intending to use the old features than they will have to stay. Our
servers will most likely have to support 1.0 and 1.1, but I=B9m assuming that
the bulk of the clients would opt to use 1.1. Since our business logic
would have to support both models, including the old model in 1.1 is not
hard to support but is certainly not a hard requirement. I generally agree
that your proposals would make the draft simpler and more consistent with
the other EPP RFC=B9s. I really want to hear from the list on this to
determine if we keep the draft as is or if we remove one or both
( with and use of the ) of the old
models. Send feedback to the list or to me privately.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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
Date: Fri, 5 Feb 2010 08:06:07 -0500
To: EPP Provreg
Subject: [ietf-provreg] Pandoras box - or not!? you decide

Hi,

may proposal maybe not the most popular, but anyway ...

Now that we will change the URN we could make this extension actually
reflect the behavior of EPP in general. We already have found an
inconsistency in the extension for maxSigLife. I propose the following
changes.

1. Drop old style
There is no need to support a broken specification in the new version.
Servers looking for backward compatibility can use version 1.0.

2. Redefine the to match the semantics used in all other
EPP documents.
The usual definition of add/rem/chg for EPP is that add will add things,
rem will remove things and chg will update things that can't be added or
removed. E.g. the registrant for a domain can only be changed, ns
records can only be added or removed not changed.
That would mean could no longer be used to add or remove
ds records. But chg could be used to update maxSigLife.
This would also mean to drop maxSigLife from dsData and keyData
interface. And of course maxSigLife can't be added or removed.

I know that these are no minor changes. And they most probably go beyond
the initial scope of the intended update to 4310. But I would like to
ask you to consider my proposal anyway. We have the chance to fix this
extension and I would like us to at least try to aim for the same
quality as the other EPP documents.

/Ulrich

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

--B_3348208785_8166376
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] Pandoras box - or not!? you decide

Ulrich,

Thanks for stepping forward with your proposal.  We’ve come a lo=
ng way which is one reason to stay the course, but I would like to hear from=
the list feedback to Ulrich’s proposal.  I don’t believe t=
he changes being requested are all that large, but they are a significant sh=
ift from backward compatibility which was broken with the URI change.  =
I provide feedback to your proposals below.  I certainly don’t wa=
nt to entertain truly opening up Pandora's Box with a laundry list of new fe=
atures and extend the time getting this update out for servers to implement =
to.

> 1. Drop old style <secDNS:rem/>

> There is no need to support a broken specification in the new version.=

> Servers looking for backward compatibility can use version 1.0.

All we’re talking about here is removing support for the <secDNS:r=
em> with the <secDNS:keyTag>.  The issue with use of the <s=
ecDNS:rem> and <secDNS:keyTag> (wildcard delete) is mitigated in th=
e text, but if no one intends to support the old model than it can be remove=
d.

> 2. Redefine the <secDNS:chg/> to match the semantics used in all=
other

> EPP documents.

> The usual definition of add/rem/chg for EPP is that add will add thing=
s,

> rem will remove things and chg will update things that can't be added =
or

> removed. E.g. the registrant for a domain can only be changed, ns

> records can only be added or removed not changed.

> That would mean <secDNS:chg/> could no longer be used to add or =
remove

> ds records. But chg could be used to update maxSigLife.

> This would also mean to drop maxSigLife from dsData and keyData

> interface. And of course maxSigLife can't be added or removed.

I already moved the secDNS:maxSigLife element out of the secDNS:dsData and =
secDNS:keyData elements based on feedback from the list and since I agree th=
at maxSigLife is not an attribute of the secDNS:dsData or secDNS:keyData but=
an attribute of the RRSIG which is at the domain level.  If we donR=
17;t add the secDNS:childKeyPublished element to secDNS:dsData and secDNS:ke=
yData as described in option #3 of my “of=
f-list was Re: [ietf-provreg] Revision of 4310” <=
/SPAN>posting on the list there are no attributes to update under se=
cDNS:dsData and secDNS:keyData.  Based on this the secDNS:chg could be =
removed all together since it really is just an alternative for the secDNS:a=
dd and secDNS:rem.  If there is an client updatable attribute under sec=
DNS:dsData and secDNS:keyData then secDNS:chg would be needed.  The onl=
y case right now that I’m aware of is the secDNS:childKeyPublished ele=
ment that is being discussed on the list.

Removing is a lot easier than adding to the draft, but if there are any ser=
vers intending to use the old features than they will have to stay.  Ou=
r servers will most likely have to support 1.0 and 1.1, but I’m assumi=
ng that the bulk of the clients would opt to use 1.1.  Since our busine=
ss logic would have to support both models, including the old model in 1.1 i=
s not hard to support but is certainly not a hard requirement.  I gener=
ally agree that your proposals would make the draft simpler and more consist=
ent with the other EPP RFC’s.  I really want to hear from the lis=
t on this to determine if we keep the draft as is or if we remove one or bot=
h (<secDNS:rem> with <secDNS:keyTag> and use of the <secDNS:c=
hg>) of the old models.  Send feedback to the list or to me privatel=
y.

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: Fri, 5 Feb 2010 08:06:07 -0500

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: [ietf-provreg] Pandoras box - or not!? you decide

Hi,

may proposal maybe not the most popular, but anyway ...

Now that we will change the URN we could make this extension actually

reflect the behavior of EPP in general. We already have found an

inconsistency in the extension for maxSigLife. I propose the following

changes.

1. Drop old style <secDNS:rem/>

There is no need to support a broken specification in the new version.

Servers looking for backward compatibility can use version 1.0.

2. Redefine the <secDNS:chg/> to match the semantics used in all othe=
r

EPP documents.

The usual definition of add/rem/chg for EPP is that add will add things,
rem will remove things and chg will update things that can't be added or
removed. E.g. the registrant for a domain can only be changed, ns

records can only be added or removed not changed.

That would mean <secDNS:chg/> could no longer be used to add or remov=
e

ds records. But chg could be used to update maxSigLife.

This would also mean to drop maxSigLife from dsData and keyData

interface. And of course maxSigLife can't be added or removed.

I know that these are no minor changes. And they most probably go beyond
the initial scope of the intended update to 4310. But I would like to

ask you to consider my proposal anyway. We have the chance to fix this

extension and I would like us to at least try to aim for the same

quality as the other EPP documents.

/Ulrich

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3348208785_8166376--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o15EmPns029207 for ; Fri, 5 Feb 2010 15:48:25 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o15EmPMF024780 for ietf-provreg-outgoing; Fri, 5 Feb 2010 15:48:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o15EmMfR029484 for ; Fri, 5 Feb 2010 15:48:24 +0100 (MET)
Received: from Work-Laptop-2.local (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o15EmHbe039855; Fri, 5 Feb 2010 09:48:18 -0500 (EST) (envelope-from [email-masked])
Received: from [192.168.1.103] by Work-Laptop-2.local (PGP Universal service); Fri, 05 Feb 2010 09:48:18 -0500
X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 05 Feb 2010 09:48:18 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Fri, 5 Feb 2010 09:44:34 -0500
To: EPP Provreg
From: Edward Lewis
Subject: [ietf-provreg] My verision of MaxSigLife's history was Re: ... 03 AD Feedback
Cc: [email-masked]
Content-Type: multipart/alternative; boundary="============_-946741198==_ma============"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

--============_-946741198==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

The MaxSigLife was intended to limit the span of time an attacker
could replay the DS record after acquiring (through stealing or
cryptanalysis) the private key.

If (for example) this sequence of events happens:

on the 1st day of the month you put a key pair into service (meaning
the parent publishes a DS record and signs from the 1st to the 31st)
on the 3rd day someone hacks in and copies the key pair out
on the 4th day you detect this and place a new keypair into service
(meaning the parent deletes the old DS and puts in a new one, and
generates a new signature)

The attacker can replay the parent's RRSIG of the DS set with your
broken key until the 31st and verifiers will still consider the the
key good. This is because there was no revocation in DNSSEC (prior
to RFC 5011).

When 4310 was written, some in the DNSOP WG felt that the child
should be able to curtail the window of abuse opportunity by letting
the child request a shorter (or longer) signature duration than the
parent's default.

That's the motivation.

But, of the folks with the most experience with this at the time of
4310's development, no one wanted to add this. It was added at the
insistence of folks in the DNSOP WG. So it was added and made
optional.

I would recommend against using it. A signature's duration ought to
be a function of the strength and reliability of the key generating
it, making it a parent's internal matter. I really haven't thought
much about this wrinkle, but with RFC 5011, it's probably no longer
needed for any reason.

At 13:45 +0000 2/1/10, [email-masked] wrote:

I also can't see how it relates to rollovers - as later messages
point out, the signature lifetime in the DS RRSIG applies to _every_
DS record, and is not on a per-DS basis. Hence you can't have a
different life time on different keys as they're introduced - all you
_might_ do is reduce the lifetime on _all_ keys.

Our initial assessment is that we can see no need to expose this
parameter to child zones. The signature on the DS RRset in the
parent zone is created by the parent, and is the way that the parent
guarantees to anyone who retrieves the DS RRs that the information is
from the parent and has not been altered in transit. All the child
should be concerned about is data in the DS record; proving the
authenticity of that data is the parent's responsibility.

Ray

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.
--============_-946741198==_ma============
Content-Type: text/html; charset="us-ascii"

My verision of MaxSigLife's history was Re: ... 03
AD Feed

The MaxSigLife was intended to limit the span of time an attacker
could replay the DS record after acquiring (through stealing or
cryptanalysis) the private key.

If (for example) this sequence of events happens:

on the 1st day of the month you put a key pair into service
(meaning the parent publishes a DS record and signs from the 1st to
the 31st)

on the 3rd day someone hacks in and copies the key pair out

on the 4th day you detect this and place a new keypair into
service (meaning the parent deletes the old DS and puts in a new one,
and generates a new signature)

The attacker can replay the parent's RRSIG of the DS set with
your broken key until the 31st and verifiers will still consider the
the key good.  This is because there was no revocation in DNSSEC
(prior to RFC 5011).

When 4310 was written, some in the DNSOP WG felt that the child
should be able to curtail the window of abuse opportunity by letting
the child request a shorter (or longer) signature duration than the
parent's default.

That's the motivation.

But, of the folks with the most experience with this at the time
of 4310's development, no one wanted to add this.  It was added
at the insistence of folks in the DNSOP WG.  So it was added and
made optional.

I would recommend against using it.  A signature's duration
ought to be a function of the strength and reliability of the key
generating it, making it a parent's internal matter.  I really
haven't thought much about this wrinkle, but with RFC 5011, it's
probably no longer needed for any reason.

At 13:45 +0000 2/1/10, [email-masked] wrote:

I also can't see how it relates to rollovers - as later
messages point out, the signature lifetime in the DS RRSIG applies to
_every_ DS record, and is not on a per-DS basis.  Hence you can't
have a different life time on different keys as they're introduced -
all you _might_ do is reduce the lifetime on _all_ keys.

Our initial assessment is that we can see no need to expose this
parameter to child zones.  The signature on the DS RRset in the
parent zone is created by the parent, and is the way that the parent
guarantees to anyone who retrieves the DS RRs that the information is
from the parent and has not been altered in transit.  All the
child should be concerned about is data in the DS record; proving the
authenticity of that data is the parent's responsibility.

Ray

--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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.

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o15DIExq005054 for ; Fri, 5 Feb 2010 14:18:14 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o15DIDX2004530 for ietf-provreg-outgoing; Fri, 5 Feb 2010 14:18:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o15DIDg9014109 for ; Fri, 5 Feb 2010 14:18:13 +0100 (MET)
Received: (qmail 13563 invoked from network); 5 Feb 2010 13:18:12 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Feb 2010 13:18:12 +0000
Message-ID: <[email-masked]>
Date: Fri, 05 Feb 2010 14:18:09 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: EPP Provreg
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
References:
In-Reply-To:
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o15DIDg9027671
Sender: [email-masked]
Precedence: bulk

Hi,

> 1. Don’t include any additional elements. This means that the server
> would either validate the passed DS inline with the EPP
> transaction or would publish all DS that is passed.

This would be my favorite option. Sorry Eduardo!

> 2. Add a new optional element in the secDNS:dsData (DS Interface) and
> secDNS:keyData (Key Interface) elements of secDNS:infData. I
> propose the use of the secDNS:published element.

At least I can see a use case here, but even if you know when the ds
record is published there is still so much guessing about cache updates
that the option doesn't really help.

> 3. Add a new optional secDNS:childKeyPublished element in the
> secDNS:dsData (DS Interface) and secDNS:keyData (Key Interface)
> elements of secDNS:create, secDNS:update, and secDNS:infData.
> This element would be specified by the client to inform the
> server which DS has a corresponding DNSKEY published in the child
> zone. It would be up to the server to decide the validation and
> publishing scheme based on this flag. Option #2 might have to go
> along with this as well in the event that the server will publish
> a different set of DS based on offline / asynchronous processing.

In that case I see a major clash with EPP semantics. The
childKeyPublished flag should be update able. The current extension
doesn't allow for this. So the ds record in question would have to be
removed and added again. If the registry doesn't publish ds records of
unpublished keys it seems that you shouldn't send the ds record to the
registry in the first place. If the registry does publish ds records of
unpublished keys the flag has no function. If the registry checks if the
key is published before putting it in the zone file, the flag has no
function either.

Given my above assessment I would prefer to not put in such a flag.

/Ulrich

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o15D6GJe029152 for ; Fri, 5 Feb 2010 14:06:16 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o15D6GrX023373 for ietf-provreg-outgoing; Fri, 5 Feb 2010 14:06:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o15D6Fis021528 for ; Fri, 5 Feb 2010 14:06:15 +0100 (MET)
Received: (qmail 9297 invoked from network); 5 Feb 2010 13:06:14 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Feb 2010 13:06:14 +0000
Message-ID: <[email-masked]>
Date: Fri, 05 Feb 2010 14:06:07 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: EPP Provreg
Subject: [ietf-provreg] Pandoras box - or not!? you decide
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hi,

may proposal maybe not the most popular, but anyway ...

Now that we will change the URN we could make this extension actually
reflect the behavior of EPP in general. We already have found an
inconsistency in the extension for maxSigLife. I propose the following
changes.

1. Drop old style
There is no need to support a broken specification in the new version.
Servers looking for backward compatibility can use version 1.0.

2. Redefine the to match the semantics used in all other
EPP documents.
The usual definition of add/rem/chg for EPP is that add will add things,
rem will remove things and chg will update things that can't be added or
removed. E.g. the registrant for a domain can only be changed, ns
records can only be added or removed not changed.
That would mean could no longer be used to add or remove
ds records. But chg could be used to update maxSigLife.
This would also mean to drop maxSigLife from dsData and keyData
interface. And of course maxSigLife can't be added or removed.

I know that these are no minor changes. And they most probably go beyond
the initial scope of the intended update to 4310. But I would like to
ask you to consider my proposal anyway. We have the chance to fix this
extension and I would like us to at least try to aim for the same
quality as the other EPP documents.

/Ulrich

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o14BKELG022705 for ; Thu, 4 Feb 2010 12:20:14 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o14BKEci003157 for ietf-provreg-outgoing; Thu, 4 Feb 2010 12:20:14 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from app02.fccn.pt (app02.fccn.pt [193.137.198.37]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o14BKDZW002799 for ; Thu, 4 Feb 2010 12:20:13 +0100 (MET)
Received: from mx.anubis.local (ste [10.1.2.2]) by outbound.anubis.local (Postfix) with ESMTP id 16E87C2E26 for ; Thu, 4 Feb 2010 11:20:12 +0000 (WET)
Received: from [193.136.44.92] (gaea.corp.fccn.pt [193.136.44.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: [email-masked]) by mx.anubis.local (Postfix) with ESMTP id D78B4C2E22; Thu, 4 Feb 2010 11:20:11 +0000 (WET)
Message-ID: <[email-masked]>
Date: Thu, 04 Feb 2010 11:20:56 +0000
From: Eduardo Duarte
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: James Gould
CC: [email-masked], EPP Provreg , "'WG-DNS'"
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
References:
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------020604000406060002000901"
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.
--------------020604000406060002000901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

Well I think you know here I stand here. For me the hypothesis number 3
will be the best option. But I think number 2 will also be a good
approximation where I can make some adjustments to work with it. But the
number 1, for me, will be a bad choice. :(
So depending on what the list chose I will follow it.

Best regards,

Eduardo Duarte

James Gould wrote, On 03-02-2010 23:18:
> Pre-publishing the DS is a valid use case, but I guess it boils down
> to how the servers are going to handle the pre-published DS. I know
> for our registries that we'll publish what is given to us or do the
> validation inline with the EPP transaction. Validation could be done
> inline with the EPP transaction so that DS is not stored in the
> database unless it has the corresponding DNSKEY in the child zone or
> in the case of .PT it could be done asynchronously which leads to
> accepting DS that might not be published based on server policy. So
> the real question is whether the rfc4310-bis needs to add an
> additional flag element to support the ladder? I personally don't
> like the term "active" for this, since "active" does not effectively
> reflect the purpose. I believe that published is more accurate, since
> the server is making a decision related to what is published and what
> is not published. This should be an optional attribute to support
> servers that publish everything, where the default is true. I would
> like to pose the following options to the list for consideration in
> rfc4310-bis:
>
> 1. Don't include any additional elements. This means that the
> server would either validate the passed DS inline with the EPP
> transaction or would publish all DS that is passed.
> 2. Add a new optional element in the secDNS:dsData (DS Interface)
> and secDNS:keyData (Key Interface) elements of secDNS:infData.
> I propose the use of the secDNS:published element.
> 3. Add a new optional secDNS:childKeyPublished element in the
> secDNS:dsData (DS Interface) and secDNS:keyData (Key Interface)
> elements of secDNS:create, secDNS:update, and secDNS:infData.
> This element would be specified by the client to inform the
> server which DS has a corresponding DNSKEY published in the
> child zone. It would be up to the server to decide the
> validation and publishing scheme based on this flag. Option #2
> might have to go along with this as well in the event that the
> server will publish a different set of DS based on offline /
> asynchronous processing.
>
>
> I would like to hear from those interested in this topic either from
> messages to the list or to me privately.
>
> 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: *
> *Date: *Mon, 1 Feb 2010 11:51:55 -0500
> *To: *
> *Cc: *EPP Provreg
> *Subject: *Re: off-list was Re: [ietf-provreg] Revision of 4310
>
> Eduardo Duarte wrote:
>
> > ... we are thinking of adding a
> > DS validator in order to publish only the correct DS's. Also we
> always have
> > our data in the database and there we keep the multiple keys
> associated with
> > the domain some in publish state and other in a unpublished state. So
> when a
> > user adds a DS to our system he is adding it to the database and not
> to the
> > zone itself and after, when generating the zone the script, will only
> pick-up
> > and add to the zone the "actives" DS's.
>
> As has been pointed out elsewhere, there are valid reasons for
> publishing a DS record in the parent without a corresponding DNSKEY in
> the child (e.g. key rollover). If you are going to validate the
> DS/DNSKEY correspondences, then a better check would be that at least
> one of the DS records being published in the parent corresponds to a
> DNSKEY currently in the child.
>
> Stephen

--------------020604000406060002000901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hello,

Well I think you know here I stand here. For me the hypothesis number 3
will be the best option. But I think number 2 will also be a good
approximation where I can make some adjustments to work with it. But
the number 1, for me, will be a bad choice. :(

So depending on what the list chose I will follow it.

Best regards,

Eduardo Duarte

James Gould wrote, On 03-02-2010 23:18:

Re: off-list was Re: [ietf-provreg] Revision of 4310

Pre-publishing the DS is a valid use case,
but I guess it boils down to how the servers are going to handle the
pre-published DS.  I know for our registries that we’ll publish what is
given to us or do the validation inline with the EPP transaction.
Validation could be done inline with the EPP transaction so that DS is
not stored in the database unless it has the corresponding DNSKEY in
the child zone or in the case of .PT it could be done asynchronously
which leads to accepting DS that might not be published based on server
policy.  So the real question is whether the rfc4310-bis needs to add
an additional flag element to support the ladder?  I personally don’t
like the term “active” for this, since “active” does not effectively
reflect the purpose.  I believe that published is more accurate, since
the server is making a decision related to what is published and what
is not published.  This should be an optional attribute to support
servers that publish everything, where the default is true.  I would
like to pose the following options to the list for consideration in
rfc4310-bis:

Don’t include any additional elements.  This
means that the server would either validate the passed DS inline with
the EPP transaction or would publish all DS that is passed.

Add a new optional element in the
secDNS:dsData (DS Interface) and secDNS:keyData (Key Interface)
elements of secDNS:infData.  I propose the use of the secDNS:published
element.

Add a new optional secDNS:childKeyPublished
element in the secDNS:dsData (DS Interface) and secDNS:keyData (Key
Interface) elements of secDNS:create, secDNS:update, and
secDNS:infData.  This element would be specified by the client to
inform the server which DS has a corresponding DNSKEY published in the
child zone.  It would be up to the server to decide the validation and
publishing scheme based on this flag.  Option #2 might have to go along
with this as well in the event that the server will publish a different
set of DS based on offline / asynchronous processing.

I would like to hear from those interested in this topic either from
messages to the list or to me privately.

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: <[email-masked]>

Date: Mon, 1 Feb 2010 11:51:55 -0500

To: <[email-masked]>

Cc: EPP Provreg <[email-masked]>

Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo Duarte <[email-masked]>
wrote:

> ... we are thinking of adding a

> DS validator in order to publish only the correct DS's. Also we
always have

> our data in the database and there we keep the multiple keys
associated with

> the domain some in publish state and other in a unpublished state.
So when a

> user adds a DS to our system he is adding it to the database and
not to the

> zone itself and after, when generating the zone the script, will
only pick-up

> and add to the zone the "actives" DS's.

As has been
pointed out elsewhere, there are valid reasons for publishing a DS
record in the parent without a corresponding DNSKEY in the child (e.g.
key rollover). If you are going to validate the DS/DNSKEY
correspondences, then a better check would be that at least one of the
DS records being published in the parent corresponds to a DNSKEY
currently in the child.

Stephen

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o13NJD4Y014259 for ; Thu, 4 Feb 2010 00:19:13 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o13NJDY3019827 for ietf-provreg-outgoing; Thu, 4 Feb 2010 00:19:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o13NJBMv001800 for ; Thu, 4 Feb 2010 00:19:12 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o13NE12r006375; Wed, 3 Feb 2010 18:14:01 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 18:19:10 -0500
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Feb 2010 23:19:09 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 03 Feb 2010 18:18:55 -0500
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
From: James Gould
To: ,
CC: EPP Provreg
Message-ID:
Thread-Topic: off-list was Re: [ietf-provreg] Revision of 4310
Thread-Index: AcqjYpkMdgWdrxrwThqJpQd1QdgiKwBxKgui
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3348065943_6101027"
X-OriginalArrivalTime: 03 Feb 2010 23:19:10.0364 (UTC) FILETIME=[4A60B5C0:01CAA527]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3348065943_6101027
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Pre-publishing the DS is a valid use case, but I guess it boils down to how
the servers are going to handle the pre-published DS. I know for our
registries that we=B9ll publish what is given to us or do the validation
inline with the EPP transaction. Validation could be done inline with the
EPP transaction so that DS is not stored in the database unless it has the
corresponding DNSKEY in the child zone or in the case of .PT it could be
done asynchronously which leads to accepting DS that might not be published
based on server policy. So the real question is whether the rfc4310-bis
needs to add an additional flag element to support the ladder? I personall=
y
don=B9t like the term =B3active=B2 for this, since =B3active=B2 does not effectively
reflect the purpose. I believe that published is more accurate, since the
server is making a decision related to what is published and what is not
published. This should be an optional attribute to support servers that
publish everything, where the default is true. I would like to pose the
following options to the list for consideration in rfc4310-bis:

1. Don=B9t include any additional elements. This means that the server would
either validate the passed DS inline with the EPP transaction or would
publish all DS that is passed.
2. Add a new optional element in the secDNS:dsData (DS Interface) and
secDNS:keyData (Key Interface) elements of secDNS:infData. I propose the
use of the secDNS:published element.
3. Add a new optional secDNS:childKeyPublished element in the secDNS:dsData
(DS Interface) and secDNS:keyData (Key Interface) elements of secDNS:create=
,
secDNS:update, and secDNS:infData. This element would be specified by the
client to inform the server which DS has a corresponding DNSKEY published i=
n
the child zone. It would be up to the server to decide the validation and
publishing scheme based on this flag. Option #2 might have to go along wit=
h
this as well in the event that the server will publish a different set of D=
S
based on offline / asynchronous processing.

I would like to hear from those interested in this topic either from
messages to the list or to me privately.

Thanks,

--=20

JG=20

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

=20
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 writte=
n
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:
Date: Mon, 1 Feb 2010 11:51:55 -0500
To:
Cc: EPP Provreg
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo Duarte wrote:

> ... we are thinking of adding a
> DS validator in order to publish only the correct DS's. Also we always ha=
ve
> our data in the database and there we keep the multiple keys associated w=
ith
> the domain some in publish state and other in a unpublished state. So whe=
n a
> user adds a DS to our system he is adding it to the database and not to t=
he
> zone itself and after, when generating the zone the script, will only pic=
k-up
> and add to the zone the "actives" DS's.

As has been pointed out elsewhere, there are valid reasons for publishing a
DS record in the parent without a corresponding DNSKEY in the child (e.g.
key rollover). If you are going to validate the DS/DNSKEY correspondences,
then a better check would be that at least one of the DS records being
published in the parent corresponds to a DNSKEY currently in the child.

Stephen

--B_3348065943_6101027
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: off-list was Re: [ietf-provreg] Revision of 4310

Pre-publishing the DS is a valid use case, but I guess it boils down to ho=
w the servers are going to handle the pre-published DS.  I know for our=
registries that we’ll publish what is given to us or do the validatio=
n inline with the EPP transaction.  Validation could be done inline wit=
h the EPP transaction so that DS is not stored in the database unless it has=
the corresponding DNSKEY in the child zone or in the case of .PT it could b=
e done asynchronously which leads to accepting DS that might not be publishe=
d based on server policy.  So the real question is whether the rfc4310-=
bis needs to add an additional flag element to support the ladder?  I p=
ersonally don’t like the term “active” for this, since =
220;active” does not effectively reflect the purpose.  I believe =
that published is more accurate, since the server is making a decision relat=
ed to what is published and what is not published.  This should be an o=
ptional attribute to support servers that publish everything, where the defa=
ult is true.  I would like to pose the following options to the list fo=
r consideration in rfc4310-bis:

Don’t include any additional elements.  T=
his means that the server would either validate the passed DS inline with th=
e EPP transaction or would publish all DS that is passed.

Add a new optional element in the secDNS:dsData (DS Inte=
rface) and secDNS:keyData (Key Interface) elements of secDNS:infData.  =
I propose the use of the secDNS:published element.

Add a new optional secDNS:childKeyPublished element in t=
he secDNS:dsData (DS Interface) and secDNS:keyData (Key Interface) elements =
of secDNS:create, secDNS:update, and secDNS:infData.  This element woul=
d be specified by the client to inform the server which DS has a correspondi=
ng DNSKEY published in the child zone.  It would be up to the server to=
decide the validation and publishing scheme based on this flag.  Optio=
n #2 might have to go along with this as well in the event that the server w=
ill publish a different set of DS based on offline / asynchronous processing=
.

I would like to hear from those interested in this topic either from messag=
es to the list or to me privately.

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, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  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: <[email-masked]>

Date: Mon, 1 Feb 2010 11:51:55 -0500

To: <[email-masked]&=
gt;

Cc: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo Duarte <eduardo.duar=
[email-masked]> wrote:

> ... we are thinking of adding a

> DS validator in order to publish only the correct DS's. Also we always=
have

> our data in the database and there we keep the multiple keys associate=
d with

> the domain some in publish state and other in a unpublished state. So =
when a

> user adds a DS to our system he is adding it to the database and not t=
o the

> zone itself and after, when generating the zone the script, will only =
pick-up

> and add to the zone the "actives" DS's.

As has been pointed out =
elsewhere, there are valid reasons for publishing a DS record in the parent =
without a corresponding DNSKEY in the child (e.g. key rollover). If you are =
going to validate the DS/DNSKEY correspondences, then a better check would b=
e that at least one of the DS records being published in the parent correspo=
nds to a DNSKEY currently in the child.

Stephen

--B_3348065943_6101027--

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o13BMYjr005590 for ; Wed, 3 Feb 2010 12:22:34 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o13BMYq5012714 for ietf-provreg-outgoing; Wed, 3 Feb 2010 12:22:34 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o13BMXvn008464 for ; Wed, 3 Feb 2010 12:22:33 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NcdJK-0001Nr-I4; Wed, 03 Feb 2010 12:22:18 +0100
Date: Wed, 3 Feb 2010 12:22:18 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: Edward Lewis
cc: Alexey Melnikov , "Hollenbeck, Scott" , Jaap Akkerhuis , [email-masked], EPP Provreg
Subject: Re: [ietf-provreg] RE: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
In-Reply-To:
Message-ID:
References: <4B6413D8.108 [email-masked]> <[email-masked]>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

Hi Scott, Ed, Jaap et al.

Thank you all for your views and feedback on this discussion.

Concerning the observation I brought to attention, Ed's email hits the
nail on the head (copied right below):

On Mon, 1 Feb 2010, Edward Lewis wrote:

> Since the closing of the WG the documents defining EPP have been advanced to
> Full Standard using the mailing list as the basis for communication. While
> this meets with IETF processes standards, the registration industry/community
> grew both in population[0] and in scope[1] at the same time and this did not
> feed into the IETF process. Members of this growth had no formal way to know
> of the mailing list as it had no WG to "cover" it, had no chairs or advocates
> to promote it in appropriate venues (like CENTR Tech).

Have a nice day!

cheers,
Bernie

--

http://ucom.ch/
Tech Consulting for Internet Standardization
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o13At17X009874 for ; Wed, 3 Feb 2010 11:55:01 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o13At1Mb027244 for ietf-provreg-outgoing; Wed, 3 Feb 2010 11:55:01 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o13At0nU020946 for ; Wed, 3 Feb 2010 11:55:01 +0100 (MET)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nccsr-0001AN-Kq; Wed, 03 Feb 2010 11:54:57 +0100
Date: Wed, 3 Feb 2010 11:54:57 +0100 (CET)
From: Bernie Hoeneisen
X-X-Sender: [email-masked]
To: Jaap Akkerhuis
cc: EPP Provreg
Subject: Re: [ietf-provreg] DBSSEC in CH & LI
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: [email-masked]
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Sender: [email-masked]
Precedence: bulk

For those of you who want to watch the official ceremony and some
presentations about DNSsec in .ch/.li land, the streams can be found on:

http://www.domainpulse.org/en/dp_video/index.html

However, most of the talks are in German. At least, the talk from Kim
Davies about Root zone signing is in English.

Enjoy!

cheers,
Bernie

On Wed, 3 Feb 2010, Jaap Akkerhuis wrote:

> The next message mentions EPP in productin use. It might be relevant to discussions on this list.
>
> jaap
>
> ________
>
> From: Alexander Gall
> Date: Wed, 3 Feb 2010 09:28:32 +0100
> To: [email-masked]
>
> We're happy to announce that our DNSSEC service for the CH and LI TLDs
> has become fully operational as of February 2nd. After running a
> "pioneer phase" for about 5 months, during which we added DS records
> manually to the zones for people who took part in the trial, our
> registry now fully supports DNSSEC for all direct customers via
> as well as for registrars (we call them
> "partners", in case you look for information on our website) via the
> standard EPP extensions.
>
> We currently have 9 signed delegations (out of about 1.1 million :)
>
> --
> Alex
>
> --
> SWITCH
> Serving Swiss Universities
> --------------------------
> Alexander Gall, Network Engineer
> P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 22, fax +41 44 268 15 68
> [email-masked], http://www.switch.ch
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o13ARoCX012920 for ; Wed, 3 Feb 2010 11:27:50 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o13ARoqb006171 for ietf-provreg-outgoing; Wed, 3 Feb 2010 11:27:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o13ARnGd017225 for ; Wed, 3 Feb 2010 11:27:49 +0100 (MET)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id o13ARjlM038588 for ; Wed, 3 Feb 2010 11:27:45 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] DBSSEC in CH & LI
Date: Wed, 03 Feb 2010 11:27:45 +0100
From: Jaap Akkerhuis
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Wed, 03 Feb 2010 11:27:45 +0100 (CET)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

The next message mentions EPP in productin use. It might be relevant to discussions on this list.

jaap

________

From: Alexander Gall
Date: Wed, 3 Feb 2010 09:28:32 +0100
To: [email-masked]

We're happy to announce that our DNSSEC service for the CH and LI TLDs
has become fully operational as of February 2nd. After running a
"pioneer phase" for about 5 months, during which we added DS records
manually to the zones for people who took part in the trial, our
registry now fully supports DNSSEC for all direct customers via
as well as for registrars (we call them
"partners", in case you look for information on our website) via the
standard EPP extensions.

We currently have 9 signed delegations (out of about 1.1 million :)

--
Alex

--
SWITCH
Serving Swiss Universities
--------------------------
Alexander Gall, Network Engineer
P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 22, fax +41 44 268 15 68
[email-masked], http://www.switch.ch
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o12ABFCv027718 for ; Tue, 2 Feb 2010 11:11:15 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o12ABFtV020074 for ietf-provreg-outgoing; Tue, 2 Feb 2010 11:11:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o12ABEcH003438 for ; Tue, 2 Feb 2010 11:11:15 +0100 (MET)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id o12ABBRY034807; Tue, 2 Feb 2010 11:11:11 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: Edward Lewis
cc: "Bernie Hoeneisen" , "Alexey Melnikov" , "Hollenbeck, Scott" , EPP Provreg , [email-masked]
Subject: Re: [ietf-provreg] RE: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
In-reply-to:
References: <4B6413D8.108 [email-masked]> <[email-masked]>
Comments: In-reply-to Edward Lewis message dated "Mon, 01 Feb 2010 10:11:26 -0500."
Date: Tue, 02 Feb 2010 11:11:11 +0100
From: Jaap Akkerhuis
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Tue, 02 Feb 2010 11:11:12 +0100 (CET)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bartok.nlnetlabs.nl
Sender: [email-masked]
Precedence: bulk

>Even when provreg was a working group the same mailing list, hosted in
>the same place, was used for group discussion. An explicit decision was
>made to keep the list open for ongoing discussion after the working
>group was closed. Nothing has changed in terms of the agreed-upon place
>for ongoing work discussion.
>
>All individual submission work that happened after the group closed was
>done in complete accordance with IETF procedures, with appropriate
>public announcements, using the agreed-upon mailing list. Responsible
>"stakeholders" have a responsibility to stay involved, Bernie. I know I
>can't have done any more to let people know what's been going on.

Having once been one of the co-chairs of Provreg I want to try to
explain the situation. Both Bernie and Scott are right, but that
doesn't mean there isn't a gap.

As the other ex-co-chair I don't have a lot to add to Ed's comments.
I too do see some momentum growing to revive work on EPP in the
IETF.

The ietf-provreg mail list itself is as official as non-WG lists
come. It is listed on the non-WG ietf mail lists pages and I have
maintained it since the closing of the WG, occasionally adapting
it to requests of the secretariat. Currently there are 242 subscribers
to the list (and several hundred spam messages a day).

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11L5sXY003127 for ; Mon, 1 Feb 2010 22:05:54 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o11L5sIK008730 for ietf-provreg-outgoing; Mon, 1 Feb 2010 22:05:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11L5rXY003510 for ; Mon, 1 Feb 2010 22:05:53 +0100 (MET)
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=windows-1252
From: Howard Eland
In-Reply-To:
Date: Mon, 1 Feb 2010 15:05:47 -0600
Cc: Michael Young , EPP Provreg , Andrew Sullivan
Message-Id:
References:
To: James Gould
X-Mailer: Apple Mail (2.1077)
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o11L5rXY025301
Sender: [email-masked]
Precedence: bulk

Hi James,

We bantered this about internally for a bit now, but came to the conclusion that in order to use maxSigLife at all we would have to limit the range of accepted values for maxSigLife to be very small, and (more importantly) change registrar behavior whenever signing policy was modified. For registrars, they must be in synch with our signing policy, which made this another invitation for pedal removal via firearm.

Our current implementation supports maxSigLife, but an upcoming build of ours will indeed ignore it.

I agree that multiple maxSigLife elements should return an error. Not specifying maxSigLife should default to server policy. As stated, we are moving towards having any MaxSigLife also default to default server policy.

But, not everyone will agree with our choice here, so let me evaluate the options you suggest:

(1) I'm not sure that either error code you suggest provides a good indication of the problem back to the client. 2004 is really misleading, and not indicative of the problem. Perhaps 2308 "Data management Policy Violation" may be closer (although if this is required via this specification, then it's hardly server policy)?

I like the use of the word MUST (be see my option (4) below) for multiple maxSigLife elements in a single domain object, since one RRSIG will be used across the DS RRset anyway.

(2) I'm not crazy about this at all. maxSigLife is "metadata" for a DS record, so it belongs there. If you do (1) or (4), then it's much cleaner.

(3) No. This reduces functionality, and although I'm not going to use it, others may. (I'm sure others on the list will do better than I at recalling the rationale for maxSigLife, but it escapes me for now).

Option 4: If multiple maxSigLife values are requested, the server MAY use the smallest maxSigLife value received. This could, of course, be setup as server policy, leaving it open in this specification, but at least this gives guidance for server implementors.

-Howard

On Jan 31, 2010, at 9:23 AM, James Gould wrote:

> Michael & Howard,
>
> Do either you have thoughts related to the maxSigLife attribute in RFC 4310?
> In review, the AD had the following comment to the draft:
>
>>> An OPTIONAL element that indicates a child's
>>> preference for the number of seconds after signature generation
>>> when the parent's signature on the DS information provided by the
>>> child will expire. A client SHOULD specify the same >> maxSigLife> value for all elements associated with
>>> a domain. If the is not present, or if
>>> multiple values are requested, the default
>>> signature expiration policy of the server operator (as determined
>>> using an out-of-band mechanism) applies.
>>
>> I am slightly surprised that the latter is not an error condition.
>> But if this what people have implemented, then Ok.
>
>
> I agree that at a minimum the server should return an error instead of
> applying the server default when multiple maxSigLife values are requested.
> To address this I have the following options. I would like to hear from
> anyone using the maxSigLife attribute or planning on using the maxSigLife
> attribute.
>
> 1. Keep the maxSigLife as an element of secDNS:dsData or secDNS:keyData.
> Update the text to require the server to return an 2305 “Object association
> prohibits operation” or 2004 “Parameter value range error” error when
> multiple maxSigLife values are requested. I’m leaning towards the 2004
> error. I would also recommend that we change “A client SHOULD specify the
> same value” to “A client MUST specify the same
> value”, since I don’t know the use case where the value
> could be different per DS.
> 2. Move the maxSigLife element out of the secDNS:dsData and secDNS:keyData,
> so that it can be set as a single value for a domain. The maxSigLife
> applies to the RRSIG, so it doesn’t make much sense to set it at the DS
> level. This would mean that maxSigLife would be an optional element
> directly under secDNS:create, secDNS:update, and secDNS:infData. This
> breaks backward compatibility, but backward compatibility is already broken
> by changing the URI.
> 3. Remove the maxSigLife element all together. This doesn’t sound like much
> of an option if there are servers using it. This breaks backward
> compatibility, but backward compatibility is already broken by changing the
> URI.
> 4. Update the text to allow for different maxSigLife values without the
> server applying the default. If we allow for multiple maxSigLife values I
> don’t believe it is correct for the server to return a successful response
> and then pretty much ignore the requested values.
>
> If there are any other options for this or if there are preferences to the
> options I proposed above, please respond to the list or to me privately.
>
> 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: Andrew Sullivan
> Date: Sun, 31 Jan 2010 03:59:29 -0500
> To: EPP Provreg
> Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
>
> On Fri, Jan 29, 2010 at 10:15:13AM -0500, James Gould wrote:
>> Is there anyone out there supporting or planning on supporting the client
>> specified maxSigLife. In looking into this in more detail if this attribute
>
> Afilias supports it now, IIRC.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>
>
>

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11GpvPV018695 for ; Mon, 1 Feb 2010 17:51:57 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o11GpvuM003462 for ietf-provreg-outgoing; Mon, 1 Feb 2010 17:51:57 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11Gpu1D000892 for ; Mon, 1 Feb 2010 17:51:56 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: MIME-Version:Subject:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=OUyJc9CQcx7y5brlOb3yb+8XR7c3QDy/ZhG1a1CAI2ggZSxTzS1kgyBC XJv/0qDPXSMlVmFmbZnhcv6E/X/qENMRRUdT/yrx9GuqQW4gm2ua/TK5X LFtVmk8SUJTdzMq;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1265043116; x=1296579116; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20o ff-list=20was=20Re:=20[ietf-provreg]=20Revision=20of=2043 10|Date:=20Mon,=201=20Feb=202010=2016:51:55=20+0000 |Message-ID:=20|To:=20eduardo.duarte@fcc n.pt|Cc:=[email-masked]|MIME-Version:=201.0 |In-Reply-To:=20 |References:=20<[email-masked]>=20; bh=HAdHjBcjclvjzxUTqyaQLo7lx4UKUlTCdYoQlv2wYRA=; b=uCOAJtD1vmvdfIDG8cjOXEoAveGzjpv4WmGJ8KFa6HOSGB67roltnC1h PavIO6ZUICpZ6XpO5781rSuBLfl0lV7dGahEmCIzmZ81JaSqiSHeSBZms FUIKu3dLbtoyT8O;
X-IronPort-AV: E=Sophos;i="4.49,384,1262563200"; d="scan'208";a="21345419"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 01 Feb 2010 16:51:56 +0000
In-Reply-To:
References: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
MIME-Version: 1.0
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Mon, 1 Feb 2010 16:51:55 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 01/02/2010 04:51:56 PM, Serialize complete at 01/02/2010 04:51:56 PM
Content-Type: multipart/alternative; boundary="=_alternative 005CA4F8802576BD_="
Sender: [email-masked]
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 005CA4F8802576BD_=
Content-Type: text/plain; charset="US-ASCII"

Eduardo Duarte wrote:

> ... we are thinking of adding a
> DS validator in order to publish only the correct DS's. Also we always
have
> our data in the database and there we keep the multiple keys associated
with
> the domain some in publish state and other in a unpublished state. So
when a
> user adds a DS to our system he is adding it to the database and not to
the
> zone itself and after, when generating the zone the script, will only
pick-up
> and add to the zone the "actives" DS's.

As has been pointed out elsewhere, there are valid reasons for publishing
a DS record in the parent without a corresponding DNSKEY in the child
(e.g. key rollover). If you are going to validate the DS/DNSKEY
correspondences, then a better check would be that at least one of the DS
records being published in the parent corresponds to a DNSKEY currently in
the child.

Stephen
--=_alternative 005CA4F8802576BD_=
Content-Type: text/html; charset="US-ASCII"

Eduardo Duarte <[email-masked]> wrote:

> ... we are thinking of adding a

> DS validator in order to publish only the correct DS's. Also we always
have

> our data in the database and there we keep the multiple keys associated
with

> the domain some in publish state and other in a unpublished state.
So when a

> user adds a DS to our system he is adding it to the database and not
to the

> zone itself and after, when generating the zone the script, will only
pick-up

> and add to the zone the "actives" DS's.

As has been pointed out elsewhere, there are valid
reasons for publishing a DS record in the parent without a corresponding
DNSKEY in the child (e.g. key rollover). If you are going to validate the
DS/DNSKEY correspondences, then a better check would be that at least one
of the DS records being published in the parent corresponds to a DNSKEY
currently in the child.

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11FZLiV001124 for ; Mon, 1 Feb 2010 16:35:21 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o11FZLYf016238 for ietf-provreg-outgoing; Mon, 1 Feb 2010 16:35:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11FZIME003602 for ; Mon, 1 Feb 2010 16:35:20 +0100 (MET)
Received: from [10.31.200.145] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o11FZCg3031738; Mon, 1 Feb 2010 10:35:13 -0500 (EST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <4B6413D8.108 [email-masked]> <[email-masked]>
Date: Mon, 1 Feb 2010 10:11:26 -0500
To: "Bernie Hoeneisen" , "Alexey Melnikov" , "Hollenbeck, Scott"
From: Edward Lewis
Subject: [ietf-provreg] RE: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
Cc: EPP Provreg , [email-masked]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

(Left off the ietf general list)

At 7:24 -0500 2/1/10, Hollenbeck, Scott wrote:

>Even when provreg was a working group the same mailing list, hosted in
>the same place, was used for group discussion. An explicit decision was
>made to keep the list open for ongoing discussion after the working
>group was closed. Nothing has changed in terms of the agreed-upon place
>for ongoing work discussion.
>
>All individual submission work that happened after the group closed was
>done in complete accordance with IETF procedures, with appropriate
>public announcements, using the agreed-upon mailing list. Responsible
>"stakeholders" have a responsibility to stay involved, Bernie. I know I
>can't have done any more to let people know what's been going on.

Having once been one of the co-chairs of Provreg I want to try to
explain the situation. Both Bernie and Scott are right, but that
doesn't mean there isn't a gap.

What happened is that the PROVREG WG operated during a time when the
domain name registration function, as well as all other registration
functions, were understood by just a small community and within a
constrained framework. The WG achieved its goal, in 2003 or so
stopped meeting (it was closed officially once the RFCs were
published, months later). The mailing list has remained open since
then, with little or no publicity beyond those active on it. I
wouldn't expect that a responsible party would even know of the list
if they hadn't been there to participate in the WG.

Since the closing of the WG the documents defining EPP have been
advanced to Full Standard using the mailing list as the basis for
communication. While this meets with IETF processes standards, the
registration industry/community grew both in population[0] and in
scope[1] at the same time and this did not feed into the IETF
process. Members of this growth had no formal way to know of the
mailing list as it had no WG to "cover" it, had no chairs or
advocates to promote it in appropriate venues (like CENTR Tech).

>I know I can't have done any more to let people know what's been going on.

And that's certainly true, but that doesn't mean the message got out
far enough.

In the past few weeks, recognizing this and a backlog of technical
issues[2] facing registries, registrars, and all others involved in
Internet Registration, there has been discussion on the mailing list
to apply for a new WG (well, first a BoF, etc.). From the messages
posted, it appears that an effort to apply for a BoF will proceed,
hopefully in time for IETF 78 "Maastricht" (as the deadline for IETF
77 "Disneyland" has passed).

[0] Back then there were 3 or 4 registries and a few registrars;
according to a stat uttered at .ORG's Public Forum last week, there
are 14 "major" registry operators now, hundreds of registrars just
within the ICANN definition, and many other entities involved in
domain name registration.

[1] The role of registries are better understood today, more
realization of the differences and similarities of domain name
registration and RIR's for example. While RIR's did not actively
participate in the PROVREG WG, then did participate in CRISP, as one
sign of growing awareness.

[2] Such as submission of DNSSEC keys (SEP/KSK) into registries not
using EPP's DNSSEC extension (4310) now defined at PS; and how
non-EPP client DNS operators send the keys.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11DjSRx009822 for ; Mon, 1 Feb 2010 14:45:28 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o11DjSNl029796 for ietf-provreg-outgoing; Mon, 1 Feb 2010 14:45:28 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11DjRSu002902 for ; Mon, 1 Feb 2010 14:45:27 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=LVkjFt8I2t884zGArEI89l1kPdpefBPXwxXorNIqW2O/WkMiWf2UFcpd xnR2RccP/5QL8rtJhQXaq30iSyrLfSav17hxX/8XHjxIRMyHo9edIpJBM Bj2upj/TnzJdIER;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1265031927; x=1296567927; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20[ietf -provreg]=20rfc4310bis=2003=20AD=20Feedback|Date:=20Mon, =201=20Feb=202010=2013:45:15=20+0000|Message-ID:=20|To:=20Andrew=20Sullivan=20 |Cc:=20EPP=20Provreg=20 |MIME-Version:=201.0|In-Reply-To:=20<20100128164249.GE513 [email-masked]>|References:=20=20=20<20100128164249.GE5133@sh inkuro.com>; bh=64RMSStL9ogbKJRhlfe2XVeOZPpG8k6jOgBTDNX8u8I=; b=HS/Knv0YBPrYgi/LJ9ZlfqzP0MwCl+M0eDpfK+GPupRbniQLGF//fH2M AtyYm7dtBN6GJKx9Li3NN1B9awnuUWvZPkldqqpiWS6QauVh4VkJGTNtb 2z4lDw/ymzGyxwa;
X-IronPort-AV: E=Sophos;i="4.49,383,1262563200"; d="scan'208";a="21335303"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 01 Feb 2010 13:45:27 +0000
In-Reply-To: <[email-masked]>
References: <[email-masked]>
To: Andrew Sullivan
Cc: EPP Provreg
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Mon, 1 Feb 2010 13:45:15 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 01/02/2010 01:45:27 PM, Serialize complete at 01/02/2010 01:45:27 PM
Content-Type: multipart/alternative; boundary="=_alternative 004B8E53802576BD_="
Sender: [email-masked]
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 004B8E53802576BD_=
Content-Type: text/plain; charset="US-ASCII"

> The idea is that the child might want to have some maximum above which
> it doesn't go, so that the child can roll keys in a predictable way.
> This unfortunately ignores the effects of the RR TTL on the whole
> issue, and IMO is a foot-gun loaded for bear, because it makes it
> trivially easy to set the RRSIG short enough that an RRSIG expires
> while in cache. Without a knob to control TTLs, I don't know why
> you'd allow this to be adjusted.

I also can't see how it relates to rollovers - as later messages point
out, the signature lifetime in the DS RRSIG applies to _every_ DS record,
and is not on a per-DS basis. Hence you can't have a different life time
on different keys as they're introduced - all you _might_ do is reduce the
lifetime on _all_ keys.

Our initial assessment is that we can see no need to expose this parameter
to child zones. The signature on the DS RRset in the parent zone is
created by the parent, and is the way that the parent guarantees to anyone
who retrieves the DS RRs that the information is from the parent and has
not been altered in transit. All the child should be concerned about is
data in the DS record; proving the authenticity of that data is the
parent's responsibility.

Ray

--=_alternative 004B8E53802576BD_=
Content-Type: text/html; charset="US-ASCII"

> The idea is that the child might want to have some maximum above which

> it doesn't go, so that the child can roll keys in a predictable way.

> This unfortunately ignores the effects of the RR TTL on the whole

> issue, and IMO is a foot-gun loaded for bear, because it makes it

> trivially easy to set the RRSIG short enough that an RRSIG expires

> while in cache.  Without a knob to control TTLs, I don't know
why

> you'd allow this to be adjusted.

I also can't see how it relates to rollovers - as
later messages point out, the signature lifetime in the DS RRSIG applies
to _every_ DS record, and is not on a per-DS basis.  Hence you can't
have a different life time on different keys as they're introduced - all
you _might_ do is reduce the lifetime on _all_ keys.

Our initial assessment is that we can see no need
to expose this parameter to child zones.  The signature on the DS
RRset in the parent zone is created by the parent, and is the way that
the parent guarantees to anyone who retrieves the DS RRs that the information
is from the parent and has not been altered in transit.  All the child
should be concerned about is data in the DS record; proving the authenticity
of that data is the parent's responsibility.

Ray

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11DY3K2018285 for ; Mon, 1 Feb 2010 14:34:03 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o11DY368023038 for ietf-provreg-outgoing; Mon, 1 Feb 2010 14:34:03 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11DY2M6021821 for ; Mon, 1 Feb 2010 14:34:03 +0100 (MET)
Received: from limpet.local (cpe-67-241-43-7.twcny.res.rr.com [67.241.43.7]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id o11DNnL3066557; Mon, 1 Feb 2010 08:23:50 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Mon, 01 Feb 2010 08:33:55 -0500
From: Eric Brunner-Williams
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: [email-masked]
CC: "Hollenbeck, Scott" , Alexey Melnikov , EPP Provreg
Subject: Re: [ietf-provreg] RE: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

OK. So we need to:

(a) remind the lawyers who clutter up the Registry Stakeholder Group
(RySG) that they need to know to tell the technical people (who should
form the registry operator sharpened stakes and pitchforks group) that
technical work (on EPP) takes place on ietf-provreg, please bring your
extensions and other brain-damage or stay home,

(b) remind the lawyers who clutter up the Registrar Stakeholder Group
(RSG) that technical work (on EPP) takes place on ietf-provreg, and if
they intend to sell anything other than VGRS inventory, or stay afloat
in a sea of registry-specific extensions and other brain-damage, its
come or stay home,

(c) inform the civil administrators who clutter up the CNSO similar to
(a), above, rinse and repeat for the sharpened stakes and pitchforks
group, unencumbered by the "contract" problem,

and

(d) inform the ccTLD tech people who attend occasionally, or
regularly, the Monday ccTLD Tech Day at ICANN meetings that technical
work (on EPP) takes place on ietf-provreg, again, rinse and repeat for
the sharpened stakes and pitchforks group.

That covers the ICANN g&c space. Informing the CNNIC c&g's would be
useful as it is a bother that .cn-ascii and .cn-idn are at different
pre-1.0 revs. It is their choice, but spec-sync could benefit them as
well as everyone else benefited by spec-sync.

Are there other registrars, and other registries, which use, or plan
to use, EPP? Possibly. This gets more real when we look at another XML
syntax specified data transport issue, the escrow, as escrow is a
general interest to zone operators, not merely TLD zone operators.

The reason for techies to have "sharpened stakes and pitchforks" is
that the really important technical and operational issues do not fall
into the mutually exclusive "have a contract or have a MoU (or less)
with ICANN" baskets, and specification and/or implementation drift
caused by differences in legal regimes has no technical necessity
justification.

Eric

On 2/1/10 7:52 AM, [email-masked] wrote:
>
> > All individual submission work that happened after the group closed was
> > done in complete accordance with IETF procedures, with appropriate
> > public announcements, using the agreed-upon mailing list. Responsible
> > "stakeholders" have a responsibility to stay involved, Bernie.
>
> New stakeholders also have to find out how to _get_ involved.
>
> As a relative newbie to the IETF world (and only being employed in the
> registry business since late 2007) I only found out about this group by
> accident when I spotted the earlier EPPbis documents in the "new drafts"
> RSS feed.
>
> kind regards,
>
> Ray
>
>

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11D4sAC014541 for ; Mon, 1 Feb 2010 14:04:54 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o11D4s3P025402 for ietf-provreg-outgoing; Mon, 1 Feb 2010 14:04:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11D4rUA025050 for ; Mon, 1 Feb 2010 14:04:53 +0100 (MET)
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o11Cjqfk001109; Mon, 1 Feb 2010 07:45:52 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 08:04:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA33F.242963C9"
Subject: RE: [ietf-provreg] RE: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
Date: Mon, 1 Feb 2010 08:04:51 -0500
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] RE: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
Thread-Index: AcqjPYCotdHj5TaRQaSHxuIbyBUNFQAACeWA
References: <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To:
Cc: "Alexey Melnikov" , "EPP Provreg"
X-OriginalArrivalTime: 01 Feb 2010 13:04:52.0506 (UTC) FILETIME=[248E67A0:01CAA33F]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAA33F.242963C9
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

True, but it doesn't take much work to find out that there is work in
progress. New draft announcements are part of the process. There are
also multiple links to both current and old work on the IETF web site
for anyone who takes the time to look:
=20
Concluded working groups:
http://www.ietf.org/wg/concluded/
=20
Working group mailing lists:
http://datatracker.ietf.org/list/wg/
=20
Even a google search on "Extensible Provisioning Protocol" will turn up
links to new work done since the working group closed.
=20
Scott

________________________________

From: [email-masked]
[mailto:[email-masked]]=20
Sent: Monday, February 01, 2010 7:53 AM
To: Hollenbeck, Scott
Cc: Alexey Melnikov; EPP Provreg
Subject: Re: [ietf-provreg] RE: Last Call:
draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions
Mapping for the Extensible ProvisioningProtocol
=09
=09
=20
> All individual submission work that happened after the group
closed was
> done in complete accordance with IETF procedures, with
appropriate
> public announcements, using the agreed-upon mailing list.
Responsible
> "stakeholders" have a responsibility to stay involved, Bernie.

=09
New stakeholders also have to find out how to _get_ involved.=20
=09
As a relative newbie to the IETF world (and only being employed
in the registry business since late 2007) I only found out about this
group by accident when I spotted the earlier EPPbis documents in the
"new drafts" RSS feed.=20
=09
kind regards,=20
=09
Ray=20
=09
=09
=09

------_=_NextPart_001_01CAA33F.242963C9
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

True, but it doesn't take much work to find out that =
there is work=20
in progress.  New draft announcements are part of the =
process. =20
There are also multiple links to both current =
and old=20
work on the IETF web site for anyone who takes the time to=20
look:

Concluded working groups:

http://www.ietf.org/wg/conclud=
ed/

Working group mailing lists:

http://datatracker.ietf.org=
/list/wg/

Even a google search on "Extensible Provisioning =
Protocol" will=20
turn up links to new work done since the working group=20
closed.

Scott

From: [email-masked]=20
[mailto:[email-masked]]
Sent: Monday, February =
01, 2010=20
7:53 AM
To: Hollenbeck, Scott
Cc: Alexey Melnikov; =
EPP=20
Provreg
Subject: Re: [ietf-provreg] RE: Last Call:=20
draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions =
Mapping=20
for the Extensible ProvisioningProtocol

> All individual submission =
work that=20
happened after the group closed was
> done in complete =
accordance with=20
IETF procedures, with appropriate
> public announcements, using =
the=20
agreed-upon mailing list.  Responsible
> "stakeholders" =
have a=20
responsibility to stay involved, Bernie.

New stakeholders also have to find out how to _get_=20
involved.

As a relative newbie =
to the=20
IETF world (and only being employed in the registry business since =
late 2007)=20
I only found out about this group by accident when I spotted the =
earlier=20
EPPbis documents in the "new drafts" RSS feed. =

kind regards,

Ray=20

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11Cr4bp014034 for ; Mon, 1 Feb 2010 13:53:04 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o11Cr45b011325 for ietf-provreg-outgoing; Mon, 1 Feb 2010 13:53:04 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11Cr3T7013464 for ; Mon, 1 Feb 2010 13:53:03 +0100 (MET)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=rcOO9kI89gm9TxzclUqPcbhUOfoQn/I4e0V6CJx22dzxLMZdW/9K7sFo LKByApDgCN5npk6CebXdcysUdzDA1lLCpKd68oM7yuMhnI+eQbXzAHL1m pnwIGZk4eeMDba+;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=[email-masked]; q=dns/txt; s=main.dkim.nominet.selector; t=1265028783; x=1296564783; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=[email-masked]|Subject:=20Re:=20[ietf -provreg]=20RE:=20Last=20Call:=20draft-gould-rfc4310bis =20=20=20=20=20=20=20=20=20=20(Domain=0D=0A=20Name=20Syst em(DNS)=20Security=20Extensions=20Mapping=20for=20the=20E xtensible=0D=0A=20ProvisioningProtocol|Date:=20Mon,=201 =20Feb=202010=2012:52:52=20+0000|Message-ID:=20|To:=20"Hollenbeck,=20Scott"=20|Cc:=20"Alexey=20Melnikov"=20,=0D=0A=09"EPP=20Provreg"=20 |MIME-Version:=201.0|In-Reply-To:=20<046F43A8D79C794FA473 [email-masked]> |References:=20<[email-masked]>=20=20 <[email-masked] orp.ad.vrsn.com>; bh=IqxmSZgYTag0/1jOStn4F7rEIzJm4DCOiJvusfu4+o0=; b=dE7fLQtFWA6xW6q+BGxNFArDhDcL3PyAEv1bzSI+2jI55X5Zm9KP9Kdh gX50QrSAzTguUDmUYUnuaTidLSI0eO7YpzD1BlyPh31N3/8Y+4pVooIAW iA7Je0XHyOv+FH2;
X-IronPort-AV: E=Sophos;i="4.49,383,1262563200"; d="scan'208";a="15930034"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 01 Feb 2010 12:53:03 +0000
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
To: "Hollenbeck, Scott"
Cc: "Alexey Melnikov" , "EPP Provreg"
Subject: Re: [ietf-provreg] RE: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Mon, 1 Feb 2010 12:52:52 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 01/02/2010 12:53:03 PM, Serialize complete at 01/02/2010 12:53:03 PM
Content-Type: multipart/alternative; boundary="=_alternative 0046C247802576BD_="
Sender: [email-masked]
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 0046C247802576BD_=
Content-Type: text/plain; charset="US-ASCII"

> All individual submission work that happened after the group closed was
> done in complete accordance with IETF procedures, with appropriate
> public announcements, using the agreed-upon mailing list. Responsible
> "stakeholders" have a responsibility to stay involved, Bernie.

New stakeholders also have to find out how to _get_ involved.

As a relative newbie to the IETF world (and only being employed in the
registry business since late 2007) I only found out about this group by
accident when I spotted the earlier EPPbis documents in the "new drafts"
RSS feed.

kind regards,

Ray

--=_alternative 0046C247802576BD_=
Content-Type: text/html; charset="US-ASCII"

> All individual submission work that happened after the group closed
was

> done in complete accordance with IETF procedures, with appropriate

> public announcements, using the agreed-upon mailing list.  Responsible

> "stakeholders" have a responsibility to stay involved, Bernie.

New stakeholders also have to find out how to _get_
involved.

As a relative newbie to the IETF world (and only being
employed in the registry business since late 2007) I only found out about
this group by accident when I spotted the earlier EPPbis documents in the
"new drafts" RSS feed.

kind regards,

Ray

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11COg4n007395 for ; Mon, 1 Feb 2010 13:24:42 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o11COgqZ000230 for ietf-provreg-outgoing; Mon, 1 Feb 2010 13:24:42 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o11COfhf004819 for ; Mon, 1 Feb 2010 13:24:41 +0100 (MET)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o11C5dmj032191; Mon, 1 Feb 2010 07:05:39 -0500
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 07:24:39 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [ietf-provreg] RE: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
Date: Mon, 1 Feb 2010 07:24:39 -0500
Message-ID: <[email-masked]>
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Last Call: draft-gould-rfc4310bis (Domain Name System(DNS) Security Extensions Mapping for the Extensible ProvisioningProtocol
Thread-Index: Acqh1UQNayRiG1DcQoadGa5L+Ap9ywBYaYYg
References: <[email-masked]>
From: "Hollenbeck, Scott"
To: "Bernie Hoeneisen" , "Alexey Melnikov"
Cc: "EPP Provreg" , ,
X-OriginalArrivalTime: 01 Feb 2010 12:24:39.0846 (UTC) FILETIME=[867FB460:01CAA339]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o11COfhf016169
Sender: [email-masked]
Precedence: bulk

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bernie Hoeneisen
> Sent: Saturday, January 30, 2010 12:54 PM
> To: Alexey Melnikov
> Cc: EPP Provreg; [email-masked]; [email-masked]
> Subject: Re: Last Call: draft-gould-rfc4310bis (Domain Name
> System(DNS) Security Extensions Mapping for the Extensible
> ProvisioningProtocol

[snip]

> > Can you please explain your concerns about lack of an official IETF
> > mailing list?
>
> I care about the following:
>
> 1) Quality of the Standards
> 2) Openness / transparency of the Standards process
> 3) Checks and balance in the system
>
> I am not sure whether the EPP standardization has always
> addressed these points adequately in the past.
>
> Since the provreg WG has been closed (approx. 7 years ago),
> quite some standardization work has been done on EPP. The
> proposals were discussed on the provreg list (hosted outside
> IETF for historical reasons) and went through the IESG as AD
> sponsored. I am not sure whether all the relevant
> stakeholders have been involved in this process adequately.

Even when provreg was a working group the same mailing list, hosted in
the same place, was used for group discussion. An explicit decision was
made to keep the list open for ongoing discussion after the working
group was closed. Nothing has changed in terms of the agreed-upon place
for ongoing work discussion.

All individual submission work that happened after the group closed was
done in complete accordance with IETF procedures, with appropriate
public announcements, using the agreed-upon mailing list. Responsible
"stakeholders" have a responsibility to stay involved, Bernie. I know I
can't have done any more to let people know what's been going on.

Scott

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

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o118bL0m013764 for ; Mon, 1 Feb 2010 09:37:21 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o118bKKT021120 for ietf-provreg-outgoing; Mon, 1 Feb 2010 09:37:20 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from kmx10a.knipp.de (clust3a-eth0-0.bbone.knipp.de [195.253.6.83]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o118bKv0006841 for ; Mon, 1 Feb 2010 09:37:20 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id D94BDD2; Mon, 1 Feb 2010 09:37:19 +0100 (MEZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id gg8Ft2-DbRXW; Mon, 1 Feb 2010 09:37:14 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 57D39B5; Mon, 1 Feb 2010 09:37:14 +0100 (MEZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id o118bDff005474; Mon, 1 Feb 2010 09:37:14 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Mon, 01 Feb 2010 09:37:13 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.7) Gecko/20100128 Shredder/3.0.2pre
MIME-Version: 1.0
To: EPP Provreg
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
References:
In-Reply-To:
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o118bKv0010394
Sender: [email-masked]
Precedence: bulk

On 29/01/10 16:15, James Gould wrote:
> Is there anyone out there supporting or planning on supporting the
> client specified maxSigLife. In looking into this in more detail if this
> attribute were supported, doesn’t it make more sense for it to be an
> attribute outside the dsData or keyData, since it applies to the
> domain’s RRSIG and not to an individual DS? This means that it’s an
> attribute of the domain and not of the DS. Since we’re not worried about
> backward compatibility any longer with the change in the URI we’re open
> to remove or move this element. Any thoughts to this?
>
> --
>
>
> JG
>

Hi James,

we have implemented this for the puntCAT registry, however I share the concerns
around this value, so I wouldn't be too unhappy if it would go or would be
reworked (e.g. adding TTL suggestions as well if it then makes more sense).

Regarding the separation from the key/DS data: I think I had noted earlier
(probably in a private e-mail exchange) that I support this idea, as it is not
directly an attribute of key or DS data.

Regards,

Klaus

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