Subject: Yo, provreg-archive, get 81% OFF Today

From: "#1 VIAGRA Shop" <[email-masked]>
Date: Mon, 29 Mar 2010 05:02:11 -0700 (PDT)

Can't
see everything? Visit online version here.

About Us |

Unsubscribe | Privacy Policy |
Terms of Use

Copyright © 1998-2009
Tjpyx. 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 o2QIAe9T009906 for ; Fri, 26 Mar 2010 19:10:40 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o2QIAeqx013205 for ietf-provreg-outgoing; Fri, 26 Mar 2010 19:10: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 o2QIAdH2003131 for ; Fri, 26 Mar 2010 19:10:40 +0100 (MET)
Received: from dhcp-wireless-open-abg-25-107.meeting.ietf.org (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o2QIASRk060249; Fri, 26 Mar 2010 14:10:30 -0400 (EDT) (envelope-from [email-masked])
Received: from [130.129.25.107] by dhcp-wireless-open-abg-25-107.meeting.ietf.org (PGP Universal service); Fri, 26 Mar 2010 11:10:38 -0700
X-PGP-Universal: processed; by dhcp-wireless-open-abg-25-107.meeting.ietf.org on Fri, 26 Mar 2010 11:10:38 -0700
Mime-Version: 1.0
Message-Id:
Date: Fri, 26 Mar 2010 11:09:54 -0700
To: [email-masked]
From: Edward Lewis
Subject: [ietf-provreg] Registration Operations Mail List
Cc: [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

As an outcome of a meeting of approximately 40 registration operators
on March 24, 2010 (coincident with IETF 77) a new mail list has been
established for the discussion of Internet Registration Operations
activities.

The kinds of operators that may be interested in the discussions on
this list include:

Regional Internet Registries
Domain Name registries (such as gTLD , ccTLD)
Registrars
Resellers of domain names
National Internet Registries
Local Internet Registries (including Internet Service Providers)
Managed DNS service operators
and possibly others

Examples of acceptable topics for the list:

Transfer of DNSSEC (and DNS) parameters into registries
Determining means to measure registration-related performance
Issues with provisioning protocols, including EPP extensions
Directory Inspection (aka WhoIs) methods
Escrow policies (*)
Discussion of threats involving the registration system

Although these registration services involve the operations of DNS, this list
is not intended to be a primary discussion venue for the DNS even if DNS
is a common theme.

The discussion on the list is considered public and will encourage
the development of work efforts directed towards the IETF when
appropriate and/or other organizations.

Oh, the name of the list is [email-masked]
Subscription address: [email-masked]

Please allow some time for discussion to begin.

* - There is an active effort to establish IETF work on escrow on [email-masked].
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o2QGvGVH008076 for ; Fri, 26 Mar 2010 17:57:16 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o2QGvGOA008546 for ietf-provreg-outgoing; Fri, 26 Mar 2010 17:57:16 +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 o2QGvFHw013039 for ; Fri, 26 Mar 2010 17:57:15 +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 o2QGoXAE029204 for ; Fri, 26 Mar 2010 12:50:33 -0400
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, 26 Mar 2010 12:57:14 -0400
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] Extending EPP Response Codes
Date: Fri, 26 Mar 2010 12:57:12 -0400
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Extending EPP Response Codes
Thread-Index: AcrNApnunDxRX9KsQDujaPs9dPrcggAAo4ow
From: "Hollenbeck, Scott"
To: "EPP Provreg"
X-OriginalArrivalTime: 26 Mar 2010 16:57:14.0619 (UTC) FILETIME=[6298C4B0:01CACD05]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o2QGvFHw026349
Sender: [email-masked]
Precedence: bulk

(Sorry to anyone who gets this twice - I sent it to the IRE list first
by mistake.)

During the Wednesday bar BOF some folks mentioned challenges in
extending the set of EPP response codes. I said it could be done. Now
I'll describe how in more detail. Readers should first understand RFC
3735 (this is the RFC that describes guidelines for extending EPP) and
section 2.7 of RFC 3730, 4930, or 5730.

Once you understand the basic principles of EPP extension, there's a
question to be answered before we can select the appropriate extension
type: are you trying to add new codes for use *in addition to* the
existing set, or are you trying to add new codes for use *instead of*
the existing set? I'll describe both scenarios for completeness.

Given: response codes are a mandatory child element of the
element.

"In addition to" use case: this requires definition of a data structure
to be included in the optional element that exists within
the element. Here's an example:

Command completed successfully

Account has been billed.

ABC-12345
54321-XYZ

Note that the existing codes are still required.

"Instead of" use case: this requires definition of an extension data
structure to replace the existing element. A complete
example could get quite long, so instead I'll refer you to section 2.7.1
of the 3730/4930/5730 documents. Here's what it could look like at a
high level:

This is a completely new response
code.

This type of extension would require a lot more XML specification work
than changing the existing 1.0 schema and incrementing the version
number, but it's backward compatible and allows for opt-in processing.

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 o2PMhEHS022039 for ; Thu, 25 Mar 2010 23:43:14 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o2PMhEfx012111 for ietf-provreg-outgoing; Thu, 25 Mar 2010 23:43:14 +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 o2PMhD5W014581 for ; Thu, 25 Mar 2010 23:43:13 +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 o2PMMOEE027365; Thu, 25 Mar 2010 18:22:24 -0400
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 Mar 2010 18:43:11 -0400
Received: from 10.169.80.1 ([10.169.80.1]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 25 Mar 2010 22:43:11 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 25 Mar 2010 18:43:09 -0400
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
From: James Gould
To: , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
Thread-Index: AcrL3ESW6lNxkEw7SY+IfrkPO4cS4QAkEYt9
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3352387390_15811398"
X-OriginalArrivalTime: 25 Mar 2010 22:43:11.0769 (UTC) FILETIME=[8C68C090:01CACC6C]
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_3352387390_15811398
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Ray,

Thanks, we can take a look of the nits in AUTH48.

On the item of ignoring unsupported protocol options, I don=B9t believe that
it is reasonable to return a success unless the server did exactly what the
client requested. The protocol is not defined to support a single client=B9s
implementation, but to provide the required and optional features to satisf=
y
the needs of multiple clients. If a client wants to interface with all
registries with the least number of permutations than it should not include
the optional attributes. Including another protocol item that defines the
optional attributes that were ignored would require more work for the
clients that care about those options. If the servers should ignore
unsupported options than the 2102 error code should not exist, but I believ=
e
its inclusion covers this specific case. In summary, the 2102 error does
not make policy but clearly provides a response to the client that their
command could not be processed as requested. Having the server pick and
choose what it=B9s going to do with the command elements would cause more
confusion and does not make for a clean interface.

--=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: Thu, 25 Mar 2010 00:58:35 -0400
To: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for
Review

Having just discussed with Scott, I'd like to re-raise this point that I
made 26th February:
=20
> 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 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.

To my mind, requiring the 2102 error in effect makes policy - something we
just said in the meeting that EPP specs should not do. It _mandates_ a har=
d
fail condition when those values are not supported, when it would be
_perfectly_ reasonable for a registry to ignore the values, complete the
operation anyway but also send back a element indicating that th=
e
requested policy value was ignored.

Absent a "policy negotiation" feature in EPP, I still believe that hard
failing these options also puts too high an implementation cost on the
_client_ side of this specification. If the server announces support for
the secDNS 1.1 extension, the client shouldn't also need additional
coding/templating to handle the four possible variants of whether the
particular registry server it's talking to also supports "maxSigLife" and/o=
r
"urgent".=20

Unfortunately I don't know how to address this without requiring a larger
change than the AUTH48 window permits.

There's also a couple of nits relating to whic=
h
I think can be easily fixed in AUTH48.

Firstly, =A75.2.5 says "A server MUST return an EPP error result code of 2102
if the "urgent" attribute is specified and the server does not support it".
I believe this is incorrect - the "urgent" attribute is _always_ specified,
since it has a default value (i.e. "false"). Notwithstanding my comments
above about the suitability of the 2102 error in the first place, this
sentence needs to be qualified as "specified with a 'true' value".

Secondly (although it is permitted by XML Schema) the examples might look
better if they read <... urgent=3D"true"> rather than <... urgent=3D"1">, since
the draft and schema always use "false" rather than "0" to represent the
opposite value.=20

kind regards,=20

Ray=20

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

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

Ray,

Thanks, we can take a look of the nits in AUTH48.

On the item of ignoring unsupported protocol options, I don’t believe=
that it is reasonable to return a success unless the server did exactly wha=
t the client requested.  The protocol is not defined to support a singl=
e client’s implementation, but to provide the required and optional fe=
atures to satisfy the needs of multiple clients.  If a client wants to =
interface with all registries with the least number of permutations than it =
should not include the optional attributes.  Including another protocol=
item that defines the optional attributes that were ignored would require m=
ore work for the clients that care about those options.  If the servers=
should ignore unsupported options than the 2102 error code should not exist=
, but I believe its inclusion covers this specific case.  In summary, t=
he 2102 error does not make policy but clearly provides a response to the cl=
ient that their command could not be processed as requested.  Having th=
e server pick and choose what it’s going to do with the command elemen=
ts would cause more confusion and does not make for a clean interface.  =
;

--

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: Thu, 25 Mar 2010 00:58:35 -0400

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

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

Having just discussed with Scott, I'd like to re-raise this poin=
t that I made 26th February:

> 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&q=
uot;> or

> <secDNS:maxSigLife> ?

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

> registrar has to have advance knowledge of which registries support
> those elements and which don't, and alter their submitted XML

> accordingly.  I can't immediately see how any harm would come fro=
m

> simply ignoring those elements.

To my mind, requiring th=
e 2102 error in effect makes policy - something we just said in the meeting =
that EPP specs should not do.  It _mandates_ a hard fail condition when=
those values are not supported, when it would be _perfectly_ reasonable for=
a registry to ignore the values, complete the operation anyway but also sen=
d back a <message/> element indicating that the requested policy value=
was ignored.

Absent a "policy ne=
gotiation" feature in EPP, I still believe that hard failing these opti=
ons also puts too high an implementation cost on the _client_ side of this s=
pecification.  If the server announces support for the secDNS 1.1 exten=
sion, the client shouldn't also need additional coding/templating to handle =
the four possible variants of whether the particular registry server it's ta=
lking to also supports "maxSigLife" and/or "urgent".

Unfortunately I don't kn=
ow how to address this without requiring a larger change than the AUTH48 win=
dow permits.

There's also a couple of=
nits relating to <secDNS:update urgent=3D"..."> which I think=
can be easily fixed in AUTH48.

Firstly, §5.2.5 say=
s "A server MUST return an EPP error result code of 2102 if the "u=
rgent" attribute is specified and the server does not support it".=
I believe this is incorrect - the "urgent" attribute is _al=
ways_ specified, since it has a default value (i.e. "false"). &nbs=
p;Notwithstanding my comments above about the suitability of the 2102 error =
in the first place, this sentence needs to be qualified as "specified w=
ith a 'true' value".

Secondly (although it is=
permitted by XML Schema) the examples might look better if they read <..=
. urgent=3D"true"> rather than <... urgent=3D"1">, =
since the draft and schema always use "false" rather than "0&=
quot; to represent the opposite value.

kind regards,

Ray

--B_3352387390_15811398--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o2P4wdWj007466 for ; Thu, 25 Mar 2010 05:58:39 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o2P4wc6h023903 for ietf-provreg-outgoing; Thu, 25 Mar 2010 05:58:38 +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 o2P4wc09018856 for ; Thu, 25 Mar 2010 05:58:38 +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:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=Ucfo4qPy1TOUXnuMcCm+7Bd4YkmXGK0lpaDKxUUFkhshnLYGRVZlxPo9 imRjWeH1Iy7JunSeYMJ4YffbQJSEMV2kn9zv584sTyo5oGi8fZfiwKjmv vzjrUINYeS9Fd1R;
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=1269493118; x=1301029118; 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:=20Wed,=2024=20Mar=202010=2020:58:35=20- 0800|Message-ID:=20|To:=20EPP=20Provreg =20|MIME-Version:=201.0 |In-Reply-To:=20|References:=20=20=20; bh=O0W3LoMBFtwPZq54i3c4yzqWm1w7K/Vl5uycPNAiD8g=; b=ebVHS5d1G9RPMvQUdRvY27JkdJL01lZf9Kqqisj3nUp69WnQEO0noRqG to/IiI35hX3rEbav5SJ1Myaf2GxpGGGEbqh1xHRHyD4ops2regDvNPh78 eiaebKYlxLIOv2P;
X-IronPort-AV: E=Sophos;i="4.51,305,1267401600"; d="scan'208";a="22861342"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 25 Mar 2010 04:58:37 +0000
In-Reply-To:
References:
To: 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: Wed, 24 Mar 2010 20:58:35 -0800
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 25/03/2010 04:58:36 AM, Serialize complete at 25/03/2010 04:58:36 AM
Content-Type: multipart/alternative; boundary="=_alternative 001B56AF882576F1_="
Sender: [email-masked]
Precedence: bulk

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

Having just discussed with Scott, I'd like to re-raise this point that I=20
made 26th February:
=20
> Not being an EPP guru, what's the rationale for requiring a 2102=20
> error if the server doesn't support or=20
> ?=20
>=20
> I would have thought that Postel's law should apply, otherwise a=20
> registrar has to have advance knowledge of which registries support=20
> those elements and which don't, and alter their submitted XML=20
> accordingly. I can't immediately see how any harm would come from=20
> simply ignoring those elements.=20

To my mind, requiring the 2102 error in effect makes policy - something we =

just said in the meeting that EPP specs should not do. It =5Fmandates=5F a=
=20
hard fail condition when those values are not supported, when it would be=20
=5Fperfectly=5F reasonable for a registry to ignore the values, complete th=
e=20
operation anyway but also send back a element indicating that=20
the requested policy value was ignored.

Absent a "policy negotiation" feature in EPP, I still believe that hard=20
failing these options also puts too high an implementation cost on the=20
=5Fclient=5F side of this specification. If the server announces support f=
or=20
the secDNS 1.1 extension, the client shouldn't also need additional=20
coding/templating to handle the four possible variants of whether the=20
particular registry server it's talking to also supports "maxSigLife"=20
and/or "urgent".

Unfortunately I don't know how to address this without requiring a larger=20
change than the AUTH48 window permits.

There's also a couple of nits relating to =20
which I think can be easily fixed in AUTH48.

Firstly, =A75.2.5 says "A server MUST return an EPP error result code of=20
2102 if the "urgent" attribute is specified and the server does not=20
support it". I believe this is incorrect - the "urgent" attribute is=20
=5Falways=5F specified, since it has a default value (i.e. "false").=20
Notwithstanding my comments above about the suitability of the 2102 error=20
in the first place, this sentence needs to be qualified as "specified with =

a 'true' value".

Secondly (although it is permitted by XML Schema) the examples might look=20
better if they read <... urgent=3D"true"> rather than <... urgent=3D"1">,=20
since the draft and schema always use "false" rather than "0" to represent =

the opposite value.

kind regards,

Ray

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

Having just discussed with Scott, I'd like to re-raise
this point that I made 26th February:

> 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

> <secDNS:maxSigLife> ?

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

> registrar has to have advance knowledge of which registries support

> those elements and which don't, and alter their submitted XML

> accordingly.  I can't immediately see how any harm would come
from

> simply ignoring those elements.

To my mind, requiring the 2102 error in effect makes
policy - something we just said in the meeting that EPP specs should not
do.  It =5Fmandates=5F a hard fail condition when those values are not
supported, when it would be =5Fperfectly=5F reasonable for a registry to ig=
nore
the values, complete the operation anyway but also send back a <message/=
element indicating that the requested policy value was ignored.

Absent a "policy negotiation" feature in
EPP, I still believe that hard failing these options also puts too high
an implementation cost on the =5Fclient=5F side of this specification. &nbs=
p;If
the server announces support for the secDNS 1.1 extension, the client shoul=
dn't
also need additional coding/templating to handle the four possible variants
of whether the particular registry server it's talking to also supports
"maxSigLife" and/or "urgent".

Unfortunately I don't know how to address this witho=
ut
requiring a larger change than the AUTH48 window permits.

There's also a couple of nits relating to <secDNS=
:update
urgent=3D"..."> which I think can be easily fixed in AUTH48.

Firstly, =A75.2.5 says "A server MUST return an
EPP error result code of 2102 if the "urgent" attribute is specif=
ied
and the server does not support it".  I believe this is incorrect
- the "urgent" attribute is =5Falways=5F specified, since it has
a default value (i.e. "false").  Notwithstanding my comments
above about the suitability of the 2102 error in the first place, this
sentence needs to be qualified as "specified with a 'true' value"=
.

Secondly (although it is permitted by XML Schema)
the examples might look better if they read <... urgent=3D"true&quo=
t;>
rather than <... urgent=3D"1">, since the draft and schema
always use "false" rather than "0" to represent the
opposite value.

kind regards,

Ray

--=_alternative 001B56AF882576F1_=--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o2E3uom7014354 for ; Sun, 14 Mar 2010 04:56:50 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o2E3uoro001480 for ietf-provreg-outgoing; Sun, 14 Mar 2010 04:56: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 o2E3unnq015492 for ; Sun, 14 Mar 2010 04:56:50 +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 o2E3aP67002827 for ; Sat, 13 Mar 2010 22:36:25 -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); Sat, 13 Mar 2010 22:56:48 -0500
Received: from 10.169.80.2 ([10.169.80.2]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Sun, 14 Mar 2010 03:56:47 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Sat, 13 Mar 2010 22:56:46 -0500
Subject: [ietf-provreg] draft-gould-rfc4310bis Approved
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis Approved
Thread-Index: AcrDKl2blmLbVTHJ0kevbRQVBZaC9Q==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3351365807_17275979"
X-OriginalArrivalTime: 14 Mar 2010 03:56:48.0131 (UTC) FILETIME=[5EE0BD30:01CAC32A]
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_3351365807_17275979
Content-type: text/plain;
charset="US-ASCII"
Content-transfer-encoding: 7bit

I wanted to provide an update to draft-gould-rfc4310bis in that it was
approved on Thursday by the IESG. The announcement should be sent out early
next week. I want to thank everyone that contributed to this. I want to
especially thank Olafur in stepping forward to be the Document Sheppard.

--

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_3351365807_17275979
Content-type: text/html;
charset="US-ASCII"
Content-transfer-encoding: quoted-printable

draft-gould-rfc4310bis Approved

I wanted to provide an update to draft-gould-rfc4310bis in that it was app=
roved on Thursday by the IESG.  The announcement should be sent out ear=
ly next week.  I want to thank everyone that contributed to this.  =
;I want to especially thank Olafur in stepping forward to be the Document Sh=
eppard.

--

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

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o24Fe0Fd005353 for ; Thu, 4 Mar 2010 16:40:00 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o24Fe09u012952 for ietf-provreg-outgoing; Thu, 4 Mar 2010 16:40:00 +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 o24FdxCD012598 for ; Thu, 4 Mar 2010 16:39:59 +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 o24Fdn1I059503; Thu, 4 Mar 2010 10:39:49 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Thu, 04 Mar 2010 10:39:51 -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: James Gould
CC: "Hollenbeck, Scott" , Alexey Melnikov , [email-masked], EPP Provreg
Subject: Re: [ietf-provreg] Re: RFC4310bis document writeup
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

On 04/03/2010 10:18 AM, James Gould wrote:
> I concur with Scott. The main goal of referencing RFC 3757 was for the
> description of the SEP bit, where in RFC 4034 it references RFC 3757 for the
> same reason.
>

Lets cite both and there is no issue.

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 o24FIYOG023792 for ; Thu, 4 Mar 2010 16:18:34 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o24FIYwF010110 for ietf-provreg-outgoing; Thu, 4 Mar 2010 16:18:34 +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 o24FIXhk003845 for ; Thu, 4 Mar 2010 16:18:34 +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 o24FCVHv012889; Thu, 4 Mar 2010 10:12:31 -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); Thu, 4 Mar 2010 10:18:33 -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 ; Thu, 4 Mar 2010 15:18:32 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 04 Mar 2010 10:18:26 -0500
Subject: Re: [ietf-provreg] Re: RFC4310bis document writeup
From: James Gould
To: "Hollenbeck, Scott" , Olafur Gudmundsson , Alexey Melnikov
CC: , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Re: RFC4310bis document writeup
Thread-Index: Acq7pmATltoZr2+9Q4qlNiMJTyOpVgAAL2vAAAG0gZE=
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 04 Mar 2010 15:18:33.0000 (UTC) FILETIME=[F3F2EA80:01CABBAD]
Sender: [email-masked]
Precedence: bulk

I concur with Scott. The main goal of referencing RFC 3757 was for the
description of the SEP bit, where in RFC 4034 it references RFC 3757 for the
same reason.

--

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: "Hollenbeck, Scott"
> Date: Thu, 4 Mar 2010 09:30:44 -0500
> To: Olafur Gudmundsson , Alexey Melnikov
>
> Cc: , EPP Provreg
> Subject: RE: [ietf-provreg] Re: RFC4310bis document writeup
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Olafur Gudmundsson
>> Sent: Thursday, March 04, 2010 8:34 AM
>> To: Alexey Melnikov
>> Cc: [email-masked]; EPP Provreg
>> Subject: [ietf-provreg] Re: RFC4310bis document writeup
>>
>> On 04/03/2010 6:54 AM, Alexey Melnikov wrote:
>>> Hi Olafur,
>>>
>>> Olafur Gudmundsson wrote:
>>> [...]
>>>
>>>> (1.g) Has the Document Shepherd personally verified that
>> the document
>>>> satisfies all ID nits? (See the Internet-Drafts Checklist and
>>>> http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
>>>> enough; this check needs to be thorough. Has the document met all
>>>> formal review criteria it needs to, such as the MIB Doctor, media
>>>> type and URI type reviews?
>>>>
>>>> There are few nits due to the ever changing boilerplates and tools
>>>> not being available when BP changes :-(.
>>>>
>>>> I found one minor error in section 4.1. cites RFC3757 but
>> should use
>>>> the document that obsoleted it, RFC4034.
>>>
>>> If I remember correctly I've asked authors about this
>> before starting
>>> IETF LC and they said it was intentional.
>>>
>>>
>>>
>>
>> IMHO I do not understand why they want to treat RFC3757
>> differently from
>> RFC3658 as both are obsoleted by RFC403[345].
>>
>> If the RFC3757 reference stands then I need to change my
>> write-up to say there is a possible downref as Obsolete RFC
>> is used and editors will have to provide downref justification.
>> If there is particular text in RFC3757 that the editors want
>> to cite, an explicit informative reference can be added but
>> the main citation is changed to RFC403[45].
>
> Changing the reference would be fine, bit I'm not sure which of the new
> documents is an appropriate replacement. None of them seem to describe
> the function of the SEP bit in the same way that 3757 does.
>
> Scott
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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 o24EUkJK003010 for ; Thu, 4 Mar 2010 15:30:46 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o24EUkRK009037 for ietf-provreg-outgoing; Thu, 4 Mar 2010 15:30:46 +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 o24EUjec017103 for ; Thu, 4 Mar 2010 15:30:45 +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 o24EAeL4025181; Thu, 4 Mar 2010 09:10: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); Thu, 4 Mar 2010 09:30:44 -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: RE: [ietf-provreg] Re: RFC4310bis document writeup
Date: Thu, 4 Mar 2010 09:30:44 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] Re: RFC4310bis document writeup
Thread-Index: Acq7pmATltoZr2+9Q4qlNiMJTyOpVgAAL2vA
References: <[email-masked]> <[email-masked]> <[email-masked]>
From: "Hollenbeck, Scott"
To: "Olafur Gudmundsson" , "Alexey Melnikov"
Cc: , "EPP Provreg"
X-OriginalArrivalTime: 04 Mar 2010 14:30:44.0309 (UTC) FILETIME=[46136850:01CABBA7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id o24EUjec011598
Sender: [email-masked]
Precedence: bulk

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Olafur Gudmundsson
> Sent: Thursday, March 04, 2010 8:34 AM
> To: Alexey Melnikov
> Cc: [email-masked]; EPP Provreg
> Subject: [ietf-provreg] Re: RFC4310bis document writeup
>
> On 04/03/2010 6:54 AM, Alexey Melnikov wrote:
> > Hi Olafur,
> >
> > Olafur Gudmundsson wrote:
> > [...]
> >
> >> (1.g) Has the Document Shepherd personally verified that
> the document
> >> satisfies all ID nits? (See the Internet-Drafts Checklist and
> >> http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
> >> enough; this check needs to be thorough. Has the document met all
> >> formal review criteria it needs to, such as the MIB Doctor, media
> >> type and URI type reviews?
> >>
> >> There are few nits due to the ever changing boilerplates and tools
> >> not being available when BP changes :-(.
> >>
> >> I found one minor error in section 4.1. cites RFC3757 but
> should use
> >> the document that obsoleted it, RFC4034.
> >
> > If I remember correctly I've asked authors about this
> before starting
> > IETF LC and they said it was intentional.
> >
> >
> >
>
> IMHO I do not understand why they want to treat RFC3757
> differently from
> RFC3658 as both are obsoleted by RFC403[345].
>
> If the RFC3757 reference stands then I need to change my
> write-up to say there is a possible downref as Obsolete RFC
> is used and editors will have to provide downref justification.
> If there is particular text in RFC3757 that the editors want
> to cite, an explicit informative reference can be added but
> the main citation is changed to RFC403[45].

Changing the reference would be fine, bit I'm not sure which of the new
documents is an appropriate replacement. None of them seem to describe
the function of the SEP bit in the same way that 3757 does.

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 o24DXwOt024050 for ; Thu, 4 Mar 2010 14:33:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o24DXwl5004728 for ietf-provreg-outgoing; Thu, 4 Mar 2010 14:33:58 +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 o24DXvYw026979 for ; Thu, 4 Mar 2010 14:33:57 +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 o24DXmIx058465; Thu, 4 Mar 2010 08:33:48 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Thu, 04 Mar 2010 08:33:50 -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: Alexey Melnikov
CC: [email-masked], EPP Provreg
Subject: [ietf-provreg] Re: RFC4310bis document writeup
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

On 04/03/2010 6:54 AM, Alexey Melnikov wrote:
> Hi Olafur,
>
> Olafur Gudmundsson wrote:
> [...]
>
>> (1.g) Has the Document Shepherd personally verified that the
>> document satisfies all ID nits? (See the Internet-Drafts Checklist
>> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>> not enough; this check needs to be thorough. Has the document
>> met all formal review criteria it needs to, such as the MIB
>> Doctor, media type and URI type reviews?
>>
>> There are few nits due to the ever changing boilerplates and tools not
>> being available when BP changes :-(.
>>
>> I found one minor error in section 4.1. cites RFC3757 but should use the
>> document that obsoleted it, RFC4034.
>
> If I remember correctly I've asked authors about this before starting
> IETF LC and they said it was intentional.
>
>
>

IMHO I do not understand why they want to treat RFC3757 differently from
RFC3658 as both are obsoleted by RFC403[345].

If the RFC3757 reference stands then I need to change my write-up to say
there is a possible downref as Obsolete RFC is used and editors will
have to provide downref justification.
If there is particular text in RFC3757 that the editors want to cite,
an explicit informative reference can be added but the main citation is
changed to RFC403[45].

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 o24DFcWN011764 for ; Thu, 4 Mar 2010 14:15:38 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o24DFcgj029717 for ietf-provreg-outgoing; Thu, 4 Mar 2010 14:15:38 +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 o24DFbEe019905 for ; Thu, 4 Mar 2010 14:15:38 +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 o24CtX34022498; Thu, 4 Mar 2010 07:55:33 -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, 4 Mar 2010 08:15:37 -0500
Received: from 10.169.80.1 ([10.169.80.1]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Mar 2010 13:15:36 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 04 Mar 2010 08:15:36 -0500
Subject: Re: [ietf-provreg] RFC4310bis document writeup
From: James Gould
To:
CC: , EPP Provreg , Olafur Gudmundsson
Message-ID:
Thread-Topic: [ietf-provreg] RFC4310bis document writeup
Thread-Index: Acq7mh+3QHcms5QgRPuFhKB1DONREAAAqcy2
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3350535336_4251024"
X-OriginalArrivalTime: 04 Mar 2010 13:15:37.0527 (UTC) FILETIME=[C7D30C70:01CABB9C]
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_3350535336_4251024
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Ray,

> Was Alex's feedback on-list? I don't see a copy anywhere.

Yes, Alex=B9s Nit review feedback was on the list and is at the URL below:

http://www.cafax.se/ietf-provreg/maillist/2010-02/msg00050.html

My reply to Alex=B9s Nit review feedback was not on the list (my mistake). I
just forwarded it to the list.

--=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: Thu, 4 Mar 2010 07:56:25 -0500
To: James Gould
Cc: , EPP Provreg , Olafur Gudmundsso=
n

Subject: Re: [ietf-provreg] RFC4310bis document writeup

> The last sentence =B3The server MUST return an EPP error result code
> of 2306 if the server receives a command using an unsupported
> interface=B3 of section 4 was added to address your feedback below.

Thanks - that makes sense.

> The remainder of the updates in section 4 was made to address Alex=B9s
> Nit review feedback.

Was Alex's feedback on-list? I don't see a copy anywhere.

kind regards,=20

Ray=20

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

Re: [ietf-provreg] RFC4310bis document writeup

Ray,

> Was Alex's feedback on-list?   I don't see a copy=
anywhere.

Yes, Alex’s Nit review feedback was on the list and is at the URL bel=
ow:

h=
ttp://www.cafax.se/ietf-provreg/maillist/2010-02/msg00050.html

My reply to Alex’s Nit review feedback was not on the list (my mistak=
e).  I just forwarded it to the list.

--

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: Thu, 4 Mar 2010 07:56:25 -0500

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

Cc: <[email-masked]>, EPP Provreg &=
lt;[email-masked]>, Olafur Gud=
mundsson <[email-masked]>

Subject: Re: [ietf-provreg] RFC4310bis document writeup

> The last sentence “The server MUST return an EPP error result co=
de

> of 2306 if the server receives a command using an unsupported

> interface“ of section 4 was added to address your feedback below=
.

Thanks - that makes sens=
e.

> The remainder of the updates in section 4 was made to address AlexR=
17;s

> Nit review feedback.

Was Alex's feedback on-l=
ist?   I don't see a copy anywhere.

kind regards,

Ray

--B_3350535336_4251024--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o24CvkYw001826 for ; Thu, 4 Mar 2010 13:57:46 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o24Cvk8B017983 for ietf-provreg-outgoing; Thu, 4 Mar 2010 13:57:46 +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 o24Cvjwo004818 for ; Thu, 4 Mar 2010 13:57:45 +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 o24Cjo7C006790; Thu, 4 Mar 2010 07:45:50 -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, 4 Mar 2010 07:51:51 -0500
Received: from 10.169.80.1 ([10.169.80.1]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Mar 2010 12:51:50 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 04 Mar 2010 07:51:15 -0500
Subject: Re: [ietf-provreg] RFC4310bis document writeup
From: James Gould
To: , Olafur Gudmundsson
CC: , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] RFC4310bis document writeup
Thread-Index: Acq7fW1j0T7JVRjdQAqpnHgt8SA35QAG/K1e
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3350533910_4214494"
X-OriginalArrivalTime: 04 Mar 2010 12:51:51.0422 (UTC) FILETIME=[75CCB1E0:01CABB99]
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_3350533910_4214494
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Ray,

The last sentence =B3The server MUST return an EPP error result code of 2306
if the server receives a command using an unsupported interface=B3 of section
4 was added to address your feedback below. The remainder of the updates i=
n
section 4 was made to address Alex=B9s Nit review feedback.

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

> In particular the newly documented requirement that EPP clients have to
> "remove all" and then re-insert DNSSEC data in order to migrate from one
> format to the other on a _per_domain_ basis may have significant design a=
nd
> implementation overhead that was not previously anticipated.

The use of the =B3remove all=B2 was added as one option to migrate from one
interface to a new interface. This is defined as a MAY and not a MUST, so
it is not a requirement. There are certainly other options, but we don=B9t
want to get into a position where the server has both client specified DS
and server-generated DS for the same domain. The use of =B3remove all=B2 along
with adding using the new interface will ensure that there is no mixing on =
a
per-domain. The sentence =B3The server MUST support the use of only one for=
m
of interface except during a transition period during which time the serve=
r
MAY support both=B2 in section 4 of =AD06 was expanded to the second paragraph
in section 4 of =AD06 to clarify it based on Alex=B9s feedback.

--=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: Thu, 4 Mar 2010 04:08:16 -0500
To: Olafur Gudmundsson
Cc: , EPP Provreg
Subject: Re: [ietf-provreg] RFC4310bis document writeup

> Version 07 a nits pass

Olafur,=20

There's actually some substantial new text in =A74 introduced between the -06
and the -07 versions to address my comments about vs
.=20

In particular the newly documented requirement that EPP clients have to
"remove all" and then re-insert DNSSEC data in order to migrate from one
format to the other on a _per_domain_ basis may have significant design and
implementation overhead that was not previously anticipated.

I'm still trying to grok the implications of this new text, and am
consulting with our EPP implementors as to whether this is considered too
arduous a requirement to be written in stone in the draft.

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_3350533910_4214494
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] RFC4310bis document writeup

Ray,

The last sentence “The server MUST return an EPP error result code of=
2306 if the server receives a command using an unsupported interface“=
of section 4 was added to address your feedback below.  The remainder =
of the updates in section 4 was made to address Alex’s Nit review feed=
back.

> Also, I note that §4 says that a server MUST support e=
ither <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;

> In particular the n=
ewly documented requirement that EPP clients have to

> "remove all" and then re-insert DNSSEC data in order to migr=
ate from one

> format to the other on a _per_domain_ basis may have significant desig=
n and

> implementation overhead that was not previously anticipated.

The use of the “remove all” was added as one option to migrate =
from one interface to a new interface.  This is defined as a MAY and no=
t a MUST, so it is not a requirement.   There are certainly other =
options, but we don’t want to get into a position where the server has=
both client specified DS and server-generated DS for the same domain.  =
;The use of “remove all” along with adding using the new interfa=
ce will ensure that there is no mixing on a per-domain.   The sent=
ence “The server MUST support the use of only one form of interface ex=
cept  during a transition period during which time the server MAY suppo=
rt both” in section 4 of –06 was expanded to the second paragrap=
h in section 4 of –06 to clarify it based on Alex’s feedback. &n=
bsp;

--

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: Thu, 4 Mar 2010 04:08:16 -0500

To: Olafur Gudmundsson <[email-masked]=

Cc: <[email-masked]>, EPP Provreg &=
lt;[email-masked]>

Subject: Re: [ietf-provreg] RFC4310bis document writeup

> Version 07 a nits pass

Olafur,

There's actually some su=
bstantial new text in §4 introduced between the -06 and the -07  v=
ersions to address my comments about <secdns:dsData> vs <secdns:key=
Data>.

In particular the newly =
documented requirement that EPP clients have to "remove all" and t=
hen re-insert DNSSEC data in order to migrate from one format to the other o=
n a _per_domain_ basis may have significant design and implementation overhe=
ad that was not previously anticipated.

I'm still trying to grok=
the implications of this new text, and am consulting with our EPP implement=
ors as to whether this is considered too arduous a requirement to be written=
in stone in the draft.kind regards,

Ray

--

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

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

--B_3350533910_4214494--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o24CuVKb006241 for ; Thu, 4 Mar 2010 13:56:31 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o24CuU8H005804 for ietf-provreg-outgoing; Thu, 4 Mar 2010 13:56:30 +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 o24CuU2i009250 for ; Thu, 4 Mar 2010 13:56:30 +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=OsIoy/pWgDjMBgw6JiXw03xH9OeFnGu6dh37QjzKvylhe6lQxe0tR3kw My1IVPVewpVwTEnwZqaRbwC76d9qBI7oXia6sl3YVoBN16xMxrdLVECk6 QN7+HPw1rmq/Z8E;
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=1267707390; x=1299243390; 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=20document=20writeup|Date:=20Thu, =204=20Mar=202010=2012:56:25=20+0000|Message-ID:=20|To:=20James=20Gould=20 |Cc:=[email-masked],=0D=0A=09EPP=20Provreg=20,=0D=0A=09Olafur=20Gudmundsson=20|MIME-Version:=201.0|In-Reply-To:=20|References:=20=20; bh=3MH4DfBDmZz+oWaz5tkawX/Mh0XfrzEyS3oXcVOMBnU=; b=qbqGJeoMjN/hz7svsE5z6LLd6Rbe1hlJnucMtRLXiSR1/qruQ/2pIJ8H Z8kfck4+++IfL6gLbGT4TpEsBKQEmsMr9kQTZAUmCL5TVYPsBE+wHO+5V +1LBJbzJqSlgFkw;
X-IronPort-AV: E=Sophos;i="4.49,581,1262563200"; d="scan'208";a="22307886"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 04 Mar 2010 12:56:26 +0000
In-Reply-To:
References:
To: James Gould
Cc: [email-masked], EPP Provreg , Olafur Gudmundsson
Subject: Re: [ietf-provreg] RFC4310bis document writeup
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Thu, 4 Mar 2010 12:56:25 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/03/2010 12:56:26 PM, Serialize complete at 04/03/2010 12:56:26 PM
Content-Type: multipart/alternative; boundary="=_alternative 00471563802576DC_="
Sender: [email-masked]
Precedence: bulk

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

> The last sentence ?The server MUST return an EPP error result code=20
> of 2306 if the server receives a command using an unsupported=20
> interface? of section 4 was added to address your feedback below.

Thanks - that makes sense.

> The remainder of the updates in section 4 was made to address Alex?s
> Nit review feedback.=20

Was Alex's feedback on-list? I don't see a copy anywhere.

kind regards,

Ray

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

> The last sentence “The server MUST return an EPP error result co=
de

> of 2306 if the server receives a command using an unsupported

> interface“ of section 4 was added to address your feedback below=
.

Thanks - that makes sense.

> The remainder of the updates in section 4 was made to address AlexR=
17;s

> Nit review feedback.

Was Alex's feedback on-list?   I don't see a
copy anywhere.

kind regards,

Ray

--=_alternative 00471563802576DC_=--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o2498J76015683 for ; Thu, 4 Mar 2010 10:08:19 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o2498J3P002851 for ietf-provreg-outgoing; Thu, 4 Mar 2010 10:08:19 +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 o2498H49018488 for ; Thu, 4 Mar 2010 10:08:18 +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=IUANUbOB3e0GJIld2oO+B82Kvv8ORPyZCLP8rZEAJnEU368ByKISuOcI QZ3ZGSGllRkoqQwWvFHs6OnsrYqdkw+ALtjwYeiF8HYl/bKaLBYYptyJy gkz97w5K9oXkoab;
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=1267693698; x=1299229698; 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=20document=20writeup|Date:=20Thu, =204=20Mar=202010=2009:08:16=20+0000|Message-ID:=20|To:=20Olafur=20Gudmundsson=20 |Cc:=[email-masked],=0D=0A=09EPP=20Provreg=20|MIME-Version:=201.0|In-Reply-To:=20<4B8F235F [email-masked]>|References:=20<[email-masked] om>; bh=XHJ2uj1Wli3RZmJnmw7IJJKLADJ9kUECDgCiAkm+zcg=; b=lH2EHLEVelCBJWn4lFDi8cq/bGHZC080S4WpMZqZ1au42WGHeLWtvw/0 47fWHiZkVQJnHA8xSYBqWv1QYtIRYQHTuGTLJCDXJP5MdpVku9obKu0+f Xm3pJdojD11dvD7;
X-IronPort-AV: E=Sophos;i="4.49,580,1262563200"; d="scan'208";a="16728636"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 04 Mar 2010 09:08:17 +0000
In-Reply-To: <[email-masked]>
References: <[email-masked]>
To: Olafur Gudmundsson
Cc: [email-masked], EPP Provreg
Subject: Re: [ietf-provreg] RFC4310bis document writeup
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID:
From: [email-masked]
Date: Thu, 4 Mar 2010 09:08:16 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 04/03/2010 09:08:17 AM, Serialize complete at 04/03/2010 09:08:17 AM
Content-Type: multipart/alternative; boundary="=_alternative 00323205802576DC_="
Sender: [email-masked]
Precedence: bulk

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

> Version 07 a nits pass

Olafur,

There's actually some substantial new text in =A74 introduced between the=20
-06 and the -07 versions to address my comments about vs=20
.

In particular the newly documented requirement that EPP clients have to=20
"remove all" and then re-insert DNSSEC data in order to migrate from one=20
format to the other on a =5Fper=5Fdomain=5F basis may have significant desi=
gn=20
and implementation overhead that was not previously anticipated.

I'm still trying to grok the implications of this new text, and am=20
consulting with our EPP implementors as to whether this is considered too=20
arduous a requirement to be written in stone in the draft.

kind regards,

Ray

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

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

> Version 07 a nits pass

Olafur,

There's actually some substantial new text in =A74 i=
ntroduced
between the -06 and the -07  versions to address my comments about
<secdns:dsData> vs <secdns:keyData>.

In particular the newly documented requirement that
EPP clients have to "remove all" and then re-insert DNSSEC data
in order to migrate from one format to the other on a =5Fper=5Fdomain=5F ba=
sis
may have significant design and implementation overhead that was not previo=
usly
anticipated.

I'm still trying to grok the implications of this
new text, and am consulting with our EPP implementors as to whether this
is considered too arduous a requirement to be written in stone in the draft=
.

kind regards,

Ray

--

Ray Bellis, MA(Oxon) MIET

Senior Researcher in Advanced Projects, Nominet

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

--=_alternative 00323205802576DC_=--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o2435DB6001892 for ; Thu, 4 Mar 2010 04:05:13 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o2435CkG029607 for ietf-provreg-outgoing; Thu, 4 Mar 2010 04:05:13 +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 o2435BNt013695 for ; Thu, 4 Mar 2010 04:05:12 +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 o24351pY054096; Wed, 3 Mar 2010 22:05:01 -0500 (EST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Wed, 03 Mar 2010 22:05:03 -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: [email-masked]
CC: EPP Provreg
Subject: [ietf-provreg] RFC4310bis document writeup
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4
Sender: [email-masked]
Precedence: bulk

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Olafur Gudmndsson, agreed to take this on after the document entered
IETF last call.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

I have reviewed the document starting with the version LC 03
and tried to assert the disposition of the discussion on the document
on the provreg and ietf mailing lists. The document is now in version
07.

Note: I was active participant in discussion before becoming Document
Shepherd.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document has been extensively discussed and had been reviewed by
a number of knowledgeable people. From EPP and DNSSEC perspectives
thus I have no concerns about the depth or quality of the reviews.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

Overall comments on the document:
This is a high quality document, with excellent editors who have done
a great job of corresponding with commenter and integrating comments
into the final version.

NO IPR.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

This document is not a product of a working group, the people that
have participated in the discussions on the document seem to have
come to an agreement that this is a good specification.
As this was not a product of a working group some people that actually
work in this area did not know the discussion of updating RFC4310
was taking place. These same people once they joined the discussion
made significant contributions.
I have not been able to identify any "silent" group that may not
grasp the content of this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None,

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

There are few nits due to the ever changing boilerplates and tools not
being available when BP changes :-(.

I found one minor error in section 4.1. cites RFC3757 but should use the
document that obsoleted it, RFC4034.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References split.
No down refs once the RFC3757 reference is updated to RFC4034.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section is clear.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The XML code in the document passed my visual inspection and simple
XML syntax checker. I have confidence that the XML syntax is correct
but it would be useful if someone double checked.

Short history of Last call:

Version 03 posted
Last call issued:

Eduardo Duarte: Multiple DS and [in]active DS's
Mailing list praticipants is not clear if this is
needed and furthermore can not agree
on what the meaning of "active" is.
--> not reflected in document

Bernie Hoensisen Version numbers needs to change
-> accepted to reflect major changes in format

BH: Broken rem support should be dropped
-> included in 04

Andrew Sullivan: Setting TTL
-> not accepted not enough support

Multiple people: Multiple different MAXSIgLife statements
-> move outside each DS and have this apply to whole set. 04
(this forced the version number bump)

Version 04 posted

Version 05 added section on backwards compatibility and support of
both versions of the schema.

Version 06 number of clarity issues raised addressed no change in
content

Version 07 a nits pass

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o23GElGp005666 for ; Wed, 3 Mar 2010 17:14:47 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o23GElAF004080 for ietf-provreg-outgoing; Wed, 3 Mar 2010 17:14:47 +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 o23GEk6k006740 for ; Wed, 3 Mar 2010 17:14:46 +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 o23FsiJx002033 for ; Wed, 3 Mar 2010 10:54:44 -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, 3 Mar 2010 11:14:46 -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 Mar 2010 16:14:44 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 03 Mar 2010 11:14:41 -0500
Subject: [ietf-provreg] draft-gould-rfc4310bis-07.txt Submitted for Review
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis-07.txt Submitted for Review
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9gyuHd/LAEtXUTgDu+Ig5w==
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3350459681_2172248"
X-OriginalArrivalTime: 03 Mar 2010 16:14:46.0228 (UTC) FILETIME=[A422E940:01CABAEC]
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_3350459681_2172248
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

I submitted=20
http://www.ietf.org/internet-drafts/draft-gould-rfc4310bis-07.txt that
includes the feedback from Alex and Ray. This will be the basis for the
IESG review. Please let me know if you have any feedback to the latest
draft. The difference between =AD06 and =AD07 is at the URL below:

http://tools.ietf.org/rfcdiff?url2=3Ddraft-gould-rfc4310bis-07

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.

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

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

All,

I submitted http://www.ietf.org/internet-drafts/dr=
aft-gould-rfc4310bis-07.txt that includes the feedback from A=
lex and Ray.  This will be the basis for the IESG review.  Please =
let me know if you have any feedback to the latest draft.  The differen=
ce between –06 and –07 is at the URL below:

http://tools.ietf.org/rfcdiff?url2=3Ddraft-gould-rfc4310b=
is-07

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

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