Subject: Valued customer [email-masked] 80% OFF on Pfizer.

From: VIAGRA R Online Shop <[email-masked]>
Date: Thu, 31 Dec 2009 18:34:19 -0800 (PST)

If you cannot see this email,
click here.

Sign up for other emails.

You are subscribed to this email as [email-masked],
provreg-archive

You can unsubscribe from this email by
updating your preferences.

View our
privacy policy.

Copyright c 2009 UYWATIAX. 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 nBNN4jfi003096 for ; Thu, 24 Dec 2009 00:04:45 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBNN4j1H015740 for ietf-provreg-outgoing; Thu, 24 Dec 2009 00:04:45 +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 nBNN4irB029244 for ; Thu, 24 Dec 2009 00:04:44 +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 nBNN0nbW011139; Wed, 23 Dec 2009 18:00:49 -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, 23 Dec 2009 18:04:42 -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, 23 Dec 2009 23:04:45 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 23 Dec 2009 18:04:36 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review
From: James Gould
To: Klaus Malorny
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review
Thread-Index: AcqD7rEbvC/B/8etS/63jSASCGf4vQANZrCk
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3344436281_33439192"
X-OriginalArrivalTime: 23 Dec 2009 23:04:42.0892 (UTC) FILETIME=[4FF97CC0:01CA8424]
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_3344436281_33439192
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Klaus,

I incorporated your feedback in 02 of the draft at the URL below. Please
review for feedback.

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

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: Klaus Malorny
Date: Wed, 23 Dec 2009 11:40:35 -0500
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for
Review

On 21/12/09 19:13, James Gould wrote:
> Klaus,
> [...]

>> While a standard should be concise, it should avoid implicit
> assumptions in my
>> humble opinion. Maybe I am wrong, but I can't remember that RFC 5730
> or RFC
>> 3735
>> say anything about the semantics of not including a certain extension.
> Also,
>> giving the existence of an extension element any meaning limits the
> forward
>> compatibility of the extension itself. For example, if someone thinks t=
o
>> extend
>> RFC 3915 to report something in addition to the , then t=
he
>> semantics of the infData element would have to be changed regarding the
>> existence.
>
> I=B9m really not sure if there is any defined extension points for an
> extension. I can add some global statement to the draft around the
> meaning of the inclusion or exclusion of the extension, where the
> remainder of the draft assumes that the extension is only included for
> commands or responses when there is data relevant to the extension to
> pass along with one or two examples. Does this meet your request?
>

Yes, this would be IMHO sufficient.

>> I cannot agree. RFC 2119 says regarding "MUST":
>>
>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
>> definition is an absolute requirement of the specification.
>>
>> Although I am not a native English speaker, this seems to be pretty
> clear to
>> me
>> that there may not exist any hidden assumptions. There is no
> comparative to
>> "absolute". And it is no excuse for me that other EPP related RFCs do t=
he
>> same.
>> Their wording has been the source for confusion more than once ;-)
>>
>
> I personally have not been confused, but does a global statement in the
> draft meet this request as well? I can=B9t change other RFC=B9s, so I will
> look to add some clarity in a global statement.

Yes, I think so.

>[...]
> JG

Regards,

Klaus

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

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

Klaus,

I incorporated your feedback in 02 of the  draft at the URL below. &nb=
sp;Please review for feedback.

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

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

Date: Wed, 23 Dec 2009 11:40:35 -0500

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

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

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

On 21/12/09 19:13, James Gould wrote:

> Klaus,

> [...]

>>  While a standard should be concise, it should avoid implicit=

> assumptions in my

>>  humble opinion. Maybe I am wrong, but I can't remember that =
RFC 5730

> or RFC

>>  3735

>>  say anything about the semantics of not including a certain =
extension.

> Also,

>>  giving the existence of an extension element any meaning lim=
its the

> forward

>>  compatibility of the extension itself. For example, if someo=
ne thinks to

>>  extend

>>  RFC 3915 to report something in addition to the <rgp:rgpS=
tatus>, then the

>>  semantics of the infData element would have to be changed re=
garding the

>>  existence.

> I’m really not sure if there is any defined extension points for=
an

> extension. I can add some global statement to the draft around the

> meaning of the inclusion or exclusion of the extension, where the

> remainder of the draft assumes that the extension is only included for=

> commands or responses when there is data relevant to the extension to<=
BR>
> pass along with one or two examples. Does this meet your request?

Yes, this would be IMHO sufficient.

>>  I cannot agree. RFC 2119 says regarding "MUST":
>>

>>  1. MUST This word, or the terms "REQUIRED" or &quo=
t;SHALL", mean that the

>>  definition is an absolute requirement of the specification.<=
BR>

>>  Although I am not a native English speaker, this seems to be=
pretty

> clear to

>>  me

>>  that there may not exist any hidden assumptions. There is no=

> comparative to

>>  "absolute". And it is no excuse for me that other =
EPP related RFCs do the

>>  same.

>>  Their wording has been the source for confusion more than on=
ce ;-)

> I personally have not been confused, but does a global statement in th=
e

> draft meet this request as well? I can’t change other RFC’=
s, so I will

> look to add some clarity in a global statement.

Yes, I think so.

>[...]

> JG

Regards,

Klaus

--B_3344436281_33439192--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBNGenOO022754 for ; Wed, 23 Dec 2009 17:40:49 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBNGenXb023294 for ietf-provreg-outgoing; Wed, 23 Dec 2009 17:40:49 +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 nBNGen67000680 for ; Wed, 23 Dec 2009 17:40:49 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id AB172150; Wed, 23 Dec 2009 17:40:46 +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 qL0V3TtcV5m9; Wed, 23 Dec 2009 17:40:41 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 184B3151; Wed, 23 Dec 2009 17:40:41 +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 nBNGeeWb001879; Wed, 23 Dec 2009 17:40:40 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Wed, 23 Dec 2009 17:40:35 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091222 Shredder/3.0.1pre
MIME-Version: 1.0
To: James Gould
CC: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review
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 nBNGen67005976
Sender: [email-masked]
Precedence: bulk

On 21/12/09 19:13, James Gould wrote:
> Klaus,
> [...]

>> While a standard should be concise, it should avoid implicit
> assumptions in my
>> humble opinion. Maybe I am wrong, but I can't remember that RFC 5730
> or RFC
>> 3735
>> say anything about the semantics of not including a certain extension.
> Also,
>> giving the existence of an extension element any meaning limits the
> forward
>> compatibility of the extension itself. For example, if someone thinks to
>> extend
>> RFC 3915 to report something in addition to the , then the
>> semantics of the infData element would have to be changed regarding the
>> existence.
>
> I’m really not sure if there is any defined extension points for an
> extension. I can add some global statement to the draft around the
> meaning of the inclusion or exclusion of the extension, where the
> remainder of the draft assumes that the extension is only included for
> commands or responses when there is data relevant to the extension to
> pass along with one or two examples. Does this meet your request?
>

Yes, this would be IMHO sufficient.

>> I cannot agree. RFC 2119 says regarding "MUST":
>>
>> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
>> definition is an absolute requirement of the specification.
>>
>> Although I am not a native English speaker, this seems to be pretty
> clear to
>> me
>> that there may not exist any hidden assumptions. There is no
> comparative to
>> "absolute". And it is no excuse for me that other EPP related RFCs do the
>> same.
>> Their wording has been the source for confusion more than once ;-)
>>
>
> I personally have not been confused, but does a global statement in the
> draft meet this request as well? I can’t change other RFC’s, so I will
> look to add some clarity in a global statement.

Yes, I think so.

>[...]
> JG

Regards,

Klaus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBLFakP1029417 for ; Mon, 21 Dec 2009 16:36:46 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBLFak4c000571 for ietf-provreg-outgoing; Mon, 21 Dec 2009 16:36:46 +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 nBLFakee022354 for ; Mon, 21 Dec 2009 16:36:46 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id A2264125; Mon, 21 Dec 2009 16:36:39 +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 vbgXWpI34Ax6; Mon, 21 Dec 2009 16:36:34 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id EA824123; Mon, 21 Dec 2009 16:36:33 +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 nBLFaXs0019358; Mon, 21 Dec 2009 16:36:33 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Mon, 21 Dec 2009 16:36:27 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091217 Shredder/3.0.1pre
MIME-Version: 1.0
To: James Gould
CC: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review
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 nBLFakee006839
Sender: [email-masked]
Precedence: bulk

On 18/12/09 18:55, James Gould wrote:
> Klaus,

Hi James,

> Thanks for the feedback. My answers are below:
>
>> section 3.
>>
>> The server MUST support use of one specification form consistently.
>>
>> What does "consistency" mean in this context? This is a bit too vague
> for me.
>> Shall it be possible to use one form for one domain, and the other
> form for
>> another domain at the same instance?
>
> My intent was for the server to support either the DS Data Interface or
> the Key Data Interface and not both. This is similar to the hostObj and
> hostAttr models in the RFC 5731. If the server supports different
> interfaces at the object level, it will not be straight forward to the
> client what interface to implement to. Do you see a need for the server
> to support both models at the same time and if so can you describe why?
> Should more be added to the draft to make it clear that the server
> should support either the DS Data Interface or the Key Data Interface
> and not both?
>

Well, technically, this is feasible to support both at the same time. But I
agree that this would be rather confusing and thus should be avoided. I would
appreciate a sentence with a SHOULD NOT according to RFC 2119.

>> section 4.1.2.
>> While the XML schema and the wording "one or more
> ...dsData...|...keyData...
>> elements" implies the following, maybe it is worth to mention that if
> a domain
>> does not have and DS or key data at all, the element
> MUST not
>> be included.
>
> Yes, this is good feedback, but I believe that the exclusion of the
> extension when there is no relevant data is pretty standard across the
> EPP extensions and is assumed in the original RFC. For example in the
> RGP EPP RFC 3915 it doesn’t state that the should not be
> included if none of the rgp statuses apply. The secDNS:infData can not
> be empty based on the XML schema, so the server has no choice but to not
> include the extension. I’m not sure if explicit text is warranted here
> or for the other commands (secDNS:create and secDNS:update) around not
> including the extension when there is no relevant data associated to
> secDNS.
>

While a standard should be concise, it should avoid implicit assumptions in my
humble opinion. Maybe I am wrong, but I can't remember that RFC 5730 or RFC 3735
say anything about the semantics of not including a certain extension. Also,
giving the existence of an extension element any meaning limits the forward
compatibility of the extension itself. For example, if someone thinks to extend
RFC 3915 to report something in addition to the , then the
semantics of the infData element would have to be changed regarding the existence.

>> section 4.2.5.
>>
>> The EPP command provides a transform operation that allows a
>> client to modify the attributes of a domain object. In addition to
>> the EPP command elements described in the EPP domain mapping, the
>> command MUST contain an element. The element
>> MUST contain a child element that identifies the
>> extension namespace and the location of the extension schema.
>>
>> This implies that the extension element would have to be provided even
> in the
>> case that the client does not intend to update the DNSSEC related data
> at all.
>> In my humble opinion, this should not be the case, although the schema
> does
>> allow an empty transformation regarding DNSSEC data.
>
> This is pretty standard text in the original RFC and other EPP
> extensions. The global assumption is that the extension should not be
> included in the secDNS:create, secDNS:update, secDNS:infData if there is
> no data or updates associated with secDNS.

I cannot agree. RFC 2119 says regarding "MUST":

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.

Although I am not a native English speaker, this seems to be pretty clear to me
that there may not exist any hidden assumptions. There is no comparative to
"absolute". And it is no excuse for me that other EPP related RFCs do the same.
Their wording has been the source for confusion more than once ;-)

> [...]

>
>> As Scott Hollenbeck recently clarified that the order in the XML document
>> implies the execution order of the various changes contained in a
> request, I
>> suggest to change the order of the and element so that the
>
>> element comes first. This would allow a client to change the
>> value
>> for a single entry using the / scheme.
>
> I prefer to keep the order of and consistent with the other
> EPP RFC’s ( RFC 5731 and RFC 5732 ). RFC 4310 is somewhat unique in the
> sense that the is an attribute that might need to be
> changed in the act of an and , so some text might be needed
> to clarify this in the draft. So really the only reason for and
> of the same DS or Key Data would be to change the value?

There is probably no other reason. But I can live with your decision since there
is an alternative way to achieve the same. It would be worse if the client would
have to issue two commands to the server in order get the maxSigLife changed. If
just between the two commands the server would take a snapshot for the zone
generation, it would render the domain inoperable.

> JG

Klaus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBI9crk4022669 for ; Fri, 18 Dec 2009 10:38:53 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBI9crDw014184 for ietf-provreg-outgoing; Fri, 18 Dec 2009 10:38:53 +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 nBI9cqgQ010499 for ; Fri, 18 Dec 2009 10:38:52 +0100 (MET)
Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 4EAFC146; Fri, 18 Dec 2009 10:38:46 +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 BaFhhZYos+4F; Fri, 18 Dec 2009 10:38:42 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 3349F145; Fri, 18 Dec 2009 10:38:42 +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 nBI9cfhT026370; Fri, 18 Dec 2009 10:38:41 +0100 (MEZ)
Message-ID: <[email-masked]>
Date: Fri, 18 Dec 2009 10:38:42 +0100
From: Klaus Malorny
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.5) Gecko/20091216 Shredder/3.0.1pre
MIME-Version: 1.0
To: James Gould
CC: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

On 14/12/09 23:56, James Gould wrote:
> All,
>
> I submitted 01 of the draft. The official draft is available at the URL
> below:
>
> http://www.ietf.org/id/draft-gould-rfc4310bis-01.txt
>
> [...]
>
> Please provide me with any feedback that you have via the list or
> privately.
>
> Thanks,
>

Hi James,

thank you for your work. Unfortunately, I did not find time earlier to review
the -00/-01 drafts, but here are my comments on the -01 draft (minor issues mostly):

- - 8< - -

section 3.

The server MUST support use of one specification form consistently.

What does "consistency" mean in this context? This is a bit too vague for me.
Shall it be possible to use one form for one domain, and the other form for
another domain at the same instance?

section 4.1.2.

While the XML schema and the wording "one or more ...dsData...|...keyData...
elements" implies the following, maybe it is worth to mention that if a domain
does not have and DS or key data at all, the element MUST not
be included.

section 4.2.1.

same issue as 4.1.2. regarding the inclusion of .

section 4.2.5.

The EPP command provides a transform operation that allows a
client to modify the attributes of a domain object. In addition to
the EPP command elements described in the EPP domain mapping, the
command MUST contain an element. The element
MUST contain a child element that identifies the
extension namespace and the location of the extension schema.

This implies that the extension element would have to be provided even in the
case that the client does not intend to update the DNSSEC related data at all.
In my humble opinion, this should not be the case, although the schema does
allow an empty transformation regarding DNSSEC data.

( section)

element is used to uniquely define the DS record to
remove by using all four elements , ,
, and that is guaranteed to be
unique.

element is used to uniquely define the key data to
remove along with the associated DS data. There can be more then one
DS record created for each key, so removing a key could remove more
then one DS record.

I would prefer if -- similar as for the dsData element -- the elements would be
mentioned that are relevant for the identification, i.e. , ,
, (excluding )

As Scott Hollenbeck recently clarified that the order in the XML document
implies the execution order of the various changes contained in a request, I
suggest to change the order of the and element so that the
element comes first. This would allow a client to change the value
for a single entry using the / scheme.

section 5/section 7:

I discovered that the schema uses the same XML namespace as RFC 4310. I am not
familiar with the policies of XML namespaces at the IETF, but I wonder whether
there is a need to use a different XML namespace, since we considerably changed
the schema (despite the fact that it should be backward compatible).

- - 8< - -

Regards,

Klaus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBFCsRLt015577 for ; Tue, 15 Dec 2009 13:54:27 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBFCsRpM005289 for ietf-provreg-outgoing; Tue, 15 Dec 2009 13:54:27 +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 nBFCsQBN018863 for ; Tue, 15 Dec 2009 13:54:26 +0100 (MET)
From: "Michael Young"
To: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , "'Ulrich Wisser'"
Cc: "'EPP Provreg'"
References: <[email-masked]>
In-Reply-To:
Subject: RE: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
Date: Tue, 15 Dec 2009 07:54:31 -0500
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acp9buZ4d7KupsA8QNOQJE879ROV7QAFsZfw
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
X-Authenticated: True
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nBFCsQBN022828
Sender: [email-masked]
Precedence: bulk

Makes sense to me.

Michael Young

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Tuesday, December 15, 2009 2:32 AM
To: Ulrich Wisser
Cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted
forReview

On 14 dec 2009, at 21.20, Ulrich Wisser wrote:

>> I propose adding the zero or more case to the draft for secDNS:chg.
Please respond to the list or to me privately if you support this or don’t
support this along with any reasons.
>
> It does make life easier for many web application programmers. So I would
like to second that change.

I also think this is needed, or as I said earlier, any mechanism that make
it easy for someone that do _not_ support 4310 to at least remove the DS
data in the registry.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBF7WE8N029020 for ; Tue, 15 Dec 2009 08:32:14 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBF7WEn3000022 for ietf-provreg-outgoing; Tue, 15 Dec 2009 08:32:14 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id nBF7WDWQ025912 for ; Tue, 15 Dec 2009 08:32:13 +0100 (MET)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAIHKJktAZnwM/2dsb2JhbADAe5cPhCsE
X-IronPort-AV: E=Sophos;i="4.47,399,1257120000"; d="scan'208";a="74306368"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Dec 2009 07:32:10 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBF7WARi004917; Tue, 15 Dec 2009 07:32:10 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 08:32:09 +0100
Received: from [192.165.72.14] ([10.61.79.43]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 08:32:08 +0100
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=windows-1252
From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Tue, 15 Dec 2009 08:32:08 +0100
Cc: EPP Provreg
Message-Id:
References: <[email-masked]>
To: Ulrich Wisser
X-Mailer: Apple Mail (2.1077)
X-OriginalArrivalTime: 15 Dec 2009 07:32:09.0050 (UTC) FILETIME=[B594C3A0:01CA7D58]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nBF7WDWQ011391
Sender: [email-masked]
Precedence: bulk

On 14 dec 2009, at 21.20, Ulrich Wisser wrote:

>> I propose adding the zero or more case to the draft for secDNS:chg. Please respond to the list or to me privately if you support this or don’t support this along with any reasons.
>
> It does make life easier for many web application programmers. So I would like to second that change.

I also think this is needed, or as I said earlier, any mechanism that make it easy for someone that do _not_ support 4310 to at least remove the DS data in the registry.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBEMuj5c000918 for ; Mon, 14 Dec 2009 23:56:45 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBEMujkd029859 for ietf-provreg-outgoing; Mon, 14 Dec 2009 23:56:45 +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 nBEMuiek005459 for ; Mon, 14 Dec 2009 23:56:45 +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 nBEMdLfq002791 for ; Mon, 14 Dec 2009 17:39:22 -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, 14 Dec 2009 17:56:45 -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 ; Mon, 14 Dec 2009 22:56:43 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 14 Dec 2009 17:56:41 -0500
Subject: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis-01.txt Submitted for Review
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9gE+W9Ae
In-Reply-To:
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3343658202_19665603"
X-OriginalArrivalTime: 14 Dec 2009 22:56:45.0645 (UTC) FILETIME=[B5CB9FD0:01CA7D10]
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_3343658202_19665603
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

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

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

The following is a summary of the changes from 00:

1. Added =B3Appendix A. Changes from RFC 4310=B2 section
2. Added Scott Hollenbeck as a co-author since much of the text comes from
the original RFC=20
3. Added support for zero or more DS or Key Data with the secDNS:chg

Please provide me with any feedback that you have via the list or 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.

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

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

All,

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

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

The following is a summary of the changes from 00:

Added “Appendix A. Changes from RFC 4310”=
; section

Added Scott Hollenbeck as a co-author since much of the =
text comes from the original RFC

Added support for zero or more DS or Key Data with the s=
ecDNS:chg

Please provide me with any feedback that you have via the list or 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.

--B_3343658202_19665603--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBEKKxLj019319 for ; Mon, 14 Dec 2009 21:20:59 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBEKKxQn028788 for ietf-provreg-outgoing; Mon, 14 Dec 2009 21:20:59 +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 nBEKKwC3025031 for ; Mon, 14 Dec 2009 21:20:58 +0100 (MET)
Received: (qmail 27863 invoked from network); 14 Dec 2009 20:20:58 +0000
Received: from h149n1c1o1110.bredband.skanova.com (HELO ulrich-wissers-macbook-pro.local) (81.230.70.149) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Dec 2009 20:20:58 +0000
Message-ID: <[email-masked]>
Date: Mon, 14 Dec 2009 21:20:54 +0100
From: Ulrich Wisser
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
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 nBEKKxC3006549
Sender: [email-masked]
Precedence: bulk

> I propose adding the zero or more case to the draft for secDNS:chg.
> Please respond to the list or to me privately if you support this or
> don’t support this along with any reasons.

It does make life easier for many web application programmers. So I
would like to second that change.

/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 nBEGJwtt029457 for ; Mon, 14 Dec 2009 17:19:58 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBEGJwqg020112 for ietf-provreg-outgoing; Mon, 14 Dec 2009 17:19:58 +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 nBEGJvcO005241 for ; Mon, 14 Dec 2009 17:19:57 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8ACD62FE8CB8 for ; Mon, 14 Dec 2009 16:19:56 +0000 (UTC)
Date: Mon, 14 Dec 2009 11:19:54 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Mon, Dec 14, 2009 at 11:13:10AM -0500, James Gould wrote:
> Andrew,
>
> I thought about the concept of replace a little bit more, and I generally
> agree that itÂ¹s better to use the secDNS:rem for removals. I believe that
> to fully support the concept of a set / replace with secDNS:chg that the
> zero or more case should be supported. Limiting it to the one or more case
> is kind of like creating a list that must have at least one element, which
> doesnÂ¹t sound like a very useful list.

Well, my _real_ complaint is a data cleanliness/modelling issue. I
hate having "no data" mean "null". Only SQL geeks really get excited
about this sort of thing, however, and if others really want this I'm
not really going to object, since I don't have to run any systems that
use it.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBEGDEfv021499 for ; Mon, 14 Dec 2009 17:13:14 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBEGDE3Z026190 for ietf-provreg-outgoing; Mon, 14 Dec 2009 17:13: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 nBEGDDDM004244 for ; Mon, 14 Dec 2009 17:13:14 +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 nBEFtp5o014589; Mon, 14 Dec 2009 10:55:51 -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); Mon, 14 Dec 2009 11:13:12 -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 ; Mon, 14 Dec 2009 16:13:11 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 14 Dec 2009 11:13:10 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
Thread-Index: Acp6sUItrq7MgwNyQuOAM7Hxt5UzpACJxH6k
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3343633991_18339221"
X-OriginalArrivalTime: 14 Dec 2009 16:13:12.0735 (UTC) FILETIME=[55C6C2F0:01CA7CD8]
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_3343633991_18339221
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Andrew,

I thought about the concept of replace a little bit more, and I generally
agree that it=B9s better to use the secDNS:rem for removals. I believe that
to fully support the concept of a set / replace with secDNS:chg that the
zero or more case should be supported. Limiting it to the one or more case
is kind of like creating a list that must have at least one element, which
doesn=B9t sound like a very useful list. The risk of removing all data holds
from the Registrar web site independent of what is supported by the
protocol, since the Registrar web site could translate an empty web form to
mean remove all. Remove all could be done as well via secDNS:rem.

I propose adding the zero or more case to the draft for secDNS:chg. Please
respond to the list or to me privately if you support this or don=B9t support
this along with any reasons.

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: Andrew Sullivan
Date: Fri, 11 Dec 2009 17:07:09 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted
forReview

On Fri, Dec 11, 2009 at 03:51:42PM -0500, James Gould wrote:

> corner case that is not covered in the current schema is replacing all DS=
or
> Key Data with nothing, meaning remove all. I prefer that the client
> explicitly specify what should be added or removed via the secDNS:add and
> secDNS:rem, but the secDNS:chg could be updated to allow an empty
> secDNS:chg.

That sounds to me like a foot-gun loaded for bear. I think what will
happen is that someone will have some nasty bug that fails to get the
new data into place (think "empty webform gets submitted by
fat-fingered iphone user" or even worse, "webform bug doesn't get POST
data properly from client") and submits a syntactically-legal empty
"new state" dataset. Poof! Instant DS deletion.

Now, normally I'd argue that the above is policy, not protocol, except
that I dislike very much the habit of overloading "no data" to also
mean "replace data with NULL" (we recovering database geeks just see
this sort of thing everywhere). So I'd say if you want to remove
something, you have to remove it, not change it to "empty".

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=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_3343633991_18339221
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview=

Andrew,

I thought about the concept of replace a little bit more, and I generally a=
gree that it’s better to use the secDNS:rem for removals.  I beli=
eve that to fully support the concept of a set / replace with secDNS:chg tha=
t the zero or more case should be supported.  Limiting it to the one or=
more case is kind of like creating a list that must have at least one eleme=
nt, which doesn’t sound like a very useful list.  The risk of rem=
oving all data holds from the Registrar web site independent of what is supp=
orted by the protocol, since the Registrar web site could translate an empty=
web form to mean remove all.  Remove all could be done as well via sec=
DNS:rem.

I propose adding the zero or more case to the draft for secDNS:chg.  P=
lease respond to the list or to me privately if you support this or don̵=
7;t support this along with any reasons.

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

Date: Fri, 11 Dec 2009 17:07:09 -0500

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

Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted =
forReview

On Fri, Dec 11, 2009 at 03:51:42PM -0500, James Gould wrote:

> corner case that is not covered in the current schema is replacing all=
DS or

> Key Data with nothing, meaning remove all.  I prefer that the cli=
ent

> explicitly specify what should be added or removed via the secDNS:add =
and

> secDNS:rem, but the secDNS:chg could be updated to allow an empty

> secDNS:chg.

That sounds to me like a foot-gun loaded for bear.  I think what will<=
BR>
happen is that someone will have some nasty bug that fails to get the

new data into place (think "empty webform gets submitted by

fat-fingered iphone user" or even worse, "webform bug doesn't get=
POST

data properly from client") and submits a syntactically-legal empty
"new state" dataset.  Poof!  Instant DS deletion.

Now, normally I'd argue that the above is policy, not protocol, except

that I dislike very much the habit of overloading "no data" to al=
so

mean "replace data with NULL" (we recovering database geeks just =
see

this sort of thing everywhere).  So I'd say if you want to remove

something, you have to remove it, not change it to "empty".

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

-=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_3343633991_18339221--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBBMZU2E023134 for ; Fri, 11 Dec 2009 23:35:30 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBBMZUW4018704 for ietf-provreg-outgoing; Fri, 11 Dec 2009 23:35:30 +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 nBBMZTl0004814 for ; Fri, 11 Dec 2009 23:35:29 +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 nBBMIC9i016539; Fri, 11 Dec 2009 17:18:12 -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, 11 Dec 2009 17:35:28 -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, 11 Dec 2009 22:35:27 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 11 Dec 2009 17:35:22 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
From: James Gould
To: Andrew Sullivan , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
Thread-Index: Acp6sUItrq7MgwNyQuOAM7Hxt5UzpAAAPdGx
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3343397724_13212590"
X-OriginalArrivalTime: 11 Dec 2009 22:35:28.0165 (UTC) FILETIME=[3D1E6550:01CA7AB2]
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_3343397724_13212590
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Andrew,

Thanks, that is my feeling as well. I want to bring this up as an option,
but I believe that it=B9s better to make updates explicit. The gaining
Registrar can easily do an info to get the existing DS (or key data) and
then remove all of the DS (or key data) in a subsequent update explicitly
via secDNS:rem. Any other thoughts to 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: Andrew Sullivan
Date: Fri, 11 Dec 2009 17:07:09 -0500
To: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted
forReview

On Fri, Dec 11, 2009 at 03:51:42PM -0500, James Gould wrote:

> corner case that is not covered in the current schema is replacing all DS=
or
> Key Data with nothing, meaning remove all. I prefer that the client
> explicitly specify what should be added or removed via the secDNS:add and
> secDNS:rem, but the secDNS:chg could be updated to allow an empty
> secDNS:chg.

That sounds to me like a foot-gun loaded for bear. I think what will
happen is that someone will have some nasty bug that fails to get the
new data into place (think "empty webform gets submitted by
fat-fingered iphone user" or even worse, "webform bug doesn't get POST
data properly from client") and submits a syntactically-legal empty
"new state" dataset. Poof! Instant DS deletion.

Now, normally I'd argue that the above is policy, not protocol, except
that I dislike very much the habit of overloading "no data" to also
mean "replace data with NULL" (we recovering database geeks just see
this sort of thing everywhere). So I'd say if you want to remove
something, you have to remove it, not change it to "empty".

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=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_3343397724_13212590
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview=

Andrew,

Thanks, that is my feeling as well.  I want to bring this up as an opt=
ion, but I believe that it’s better to make updates explicit.  Th=
e gaining Registrar can easily do an info to get the existing DS (or key dat=
a) and then remove all of the DS (or key data) in a subsequent update explic=
itly via secDNS:rem.  Any other thoughts to 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: Andrew Sullivan <[email-masked]>

Date: Fri, 11 Dec 2009 17:07:09 -0500

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

Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted =
forReview

On Fri, Dec 11, 2009 at 03:51:42PM -0500, James Gould wrote:

> corner case that is not covered in the current schema is replacing all=
DS or

> Key Data with nothing, meaning remove all.  I prefer that the cli=
ent

> explicitly specify what should be added or removed via the secDNS:add =
and

> secDNS:rem, but the secDNS:chg could be updated to allow an empty

> secDNS:chg.

That sounds to me like a foot-gun loaded for bear.  I think what will<=
BR>
happen is that someone will have some nasty bug that fails to get the

new data into place (think "empty webform gets submitted by

fat-fingered iphone user" or even worse, "webform bug doesn't get=
POST

data properly from client") and submits a syntactically-legal empty
"new state" dataset.  Poof!  Instant DS deletion.

Now, normally I'd argue that the above is policy, not protocol, except

that I dislike very much the habit of overloading "no data" to al=
so

mean "replace data with NULL" (we recovering database geeks just =
see

this sort of thing everywhere).  So I'd say if you want to remove

something, you have to remove it, not change it to "empty".

A

--

Andrew Sullivan

[email-masked]

Shinkuro, Inc.

-=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_3343397724_13212590--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBBM7D1W014300 for ; Fri, 11 Dec 2009 23:07:13 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBBM7Dx1012346 for ietf-provreg-outgoing; Fri, 11 Dec 2009 23:07: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 nBBM7CXh021421 for ; Fri, 11 Dec 2009 23:07:13 +0100 (MET)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 051272FE8CB8 for ; Fri, 11 Dec 2009 22:07:10 +0000 (UTC)
Date: Fri, 11 Dec 2009 17:07:09 -0500
From: Andrew Sullivan
To: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , EPP Provreg
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Fri, Dec 11, 2009 at 03:51:42PM -0500, James Gould wrote:

> corner case that is not covered in the current schema is replacing all DS or
> Key Data with nothing, meaning remove all. I prefer that the client
> explicitly specify what should be added or removed via the secDNS:add and
> secDNS:rem, but the secDNS:chg could be updated to allow an empty
> secDNS:chg.

That sounds to me like a foot-gun loaded for bear. I think what will
happen is that someone will have some nasty bug that fails to get the
new data into place (think "empty webform gets submitted by
fat-fingered iphone user" or even worse, "webform bug doesn't get POST
data properly from client") and submits a syntactically-legal empty
"new state" dataset. Poof! Instant DS deletion.

Now, normally I'd argue that the above is policy, not protocol, except
that I dislike very much the habit of overloading "no data" to also
mean "replace data with NULL" (we recovering database geeks just see
this sort of thing everywhere). So I'd say if you want to remove
something, you have to remove it, not change it to "empty".

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nBBKpr6u003267 for ; Fri, 11 Dec 2009 21:51:53 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nBBKpriW002570 for ietf-provreg-outgoing; Fri, 11 Dec 2009 21:51:53 +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 nBBKpqoZ011616 for ; Fri, 11 Dec 2009 21:51:53 +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 nBBKYZxZ011444; Fri, 11 Dec 2009 15:34: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); Fri, 11 Dec 2009 15:51:47 -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, 11 Dec 2009 20:51:50 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Fri, 11 Dec 2009 15:51:42 -0500
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review
From: James Gould
To: Patrik =?ISO-8859-1?B?RuRsdHN0cvZt?=
CC: EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review
Thread-Index: Acp6SjbgqUW4q0dXRlmP49eU9SEMogAWYcr3
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
X-OriginalArrivalTime: 11 Dec 2009 20:51:47.0865 (UTC) FILETIME=[C187F090:01CA7AA3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id nBBKproZ019218
Sender: [email-masked]
Precedence: bulk

Patrik,

Thanks for the feedback. The secDNS:chg should be able to handle the use
case that you describe, since secDNS:chg is a full replace. Removing all
existing and setting the new DS or Key Data is handled by secDNS:chg. The
corner case that is not covered in the current schema is replacing all DS or
Key Data with nothing, meaning remove all. I prefer that the client
explicitly specify what should be added or removed via the secDNS:add and
secDNS:rem, but the secDNS:chg could be updated to allow an empty
secDNS:chg. Below is the schema update needed to allow secDNS:chg to be
empty. This change is also backward compatible, so the question is whether
it meets the need and whether it is a good practice to include in the draft?
Any thoughts to this?

The sample command looks like:

example.com

ABC-12345

--

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: Patrik Fältström
Date: Fri, 11 Dec 2009 05:10:46 -0500
To: James Gould
Cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for
Review

On 8 dec 2009, at 16.01, James Gould wrote:

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

I think the draft is good, and clarifies a number of things.

But, when adding things (as we are), I ask whether we can not add a feature
to the protocol that we use in .SE that actually make things a bit easier:

If a "rem" has a keytag of zero, then all keytags are removed.

That eliminates some situations (specifically after a transfer to a gaining
registrar) a number of info + multiple rem commands. One can "just" do "rem
keytag=0" followed by the add of the new keys. And, it also makes life
easier when doing a transfer to a registrar that do not support DNSSEC. They
"only" have to be able to do rem, keytag=9 on the domains they gain.

Patrik

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nB9ChrKT016142 for ; Wed, 9 Dec 2009 13:43:53 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nB9Chr0Q022481 for ietf-provreg-outgoing; Wed, 9 Dec 2009 13:43:53 +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 nB9ChqHG000795 for ; Wed, 9 Dec 2009 13:43:52 +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 nB9CeNI2031442; Wed, 9 Dec 2009 07:40: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); Wed, 9 Dec 2009 07:43:50 -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_01CA78CD.41FD0FF2"
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review
Date: Wed, 9 Dec 2009 07:43:50 -0500
Message-ID: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review
Thread-Index: Acp4xBXJFyGvhXfNSmudjxa8ULuzogACSvGw
From: "Gould, James"
To:
Cc:
X-OriginalArrivalTime: 09 Dec 2009 12:43:50.0858 (UTC) FILETIME=[423FB2A0:01CA78CD]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA78CD.41FD0FF2
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Jaap,

Thanks for the procedural guidance. That mirrors the guidance that I've =
had privately. I'm really looking for feedback of the draft from this =
list to ensure that what I'm moving forward with meets the requirements =
of the Registries and Registrars participating on this list. Now is the =
time to provide the feedback while the ink is wet. Do you have any =
non-procedural feedback to the draft?

----- Original Message -----
From: Jaap Akkerhuis
To: Gould, James
Cc: EPP Provreg
Sent: Wed Dec 09 06:38:03 2009
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for =
Review=20

I'm looking for feedback to the draft from the list to ensure
that we have consensus to move forward. Please send your
feedback to the list or to me privately.

[Procedural note].
Note that this list is just a mailing list. To advance this draft
to an RFC, it should either be an individual contribution, find a
home in an existing WG or a new one needs to be started.

jaap

------_=_NextPart_001_01CA78CD.41FD0FF2
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

Jaap,

Thanks for the procedural guidance.  That mirrors the guidance that =
I've had privately.  I'm really looking for feedback of the draft =
from this list to ensure that what I'm moving forward with meets the =
requirements of the Registries and Registrars participating on this =
list.  Now is the time to provide the feedback while the ink is =
wet.  Do you have any non-procedural feedback to the draft?

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

From: Jaap Akkerhuis <[email-masked]>

To: Gould, James

Cc: EPP Provreg <[email-masked]>

Sent: Wed Dec 09 06:38:03 2009

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

I'm looking for feedback to the draft from the list =
to ensure

that we have consensus to move forward.  Please =
send your

feedback to the list or to me privately.

[Procedural note].

Note that this list is just a mailing list. To advance this draft

to an RFC, it should either be an individual contribution, find a

home in an existing WG or a new one needs to be started.

jaap

------_=_NextPart_001_01CA78CD.41FD0FF2--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 nB9Bc7GL001009 for ; Wed, 9 Dec 2009 12:38:07 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nB9Bc7GD012364 for ietf-provreg-outgoing; Wed, 9 Dec 2009 12:38:07 +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 nB9Bc7jF012266 for ; Wed, 9 Dec 2009 12:38:07 +0100 (MET)
Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id nB9Bc3Jh071543; Wed, 9 Dec 2009 12:38:03 +0100 (CET) (envelope-from [email-masked])
Message-Id: <[email-masked]>
To: James Gould
cc: EPP Provreg
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review
In-reply-to:
References:
Comments: In-reply-to James Gould message dated "Tue, 08 Dec 2009 10:01:05 -0500."
Date: Wed, 09 Dec 2009 12:38:03 +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, 09 Dec 2009 12:38:04 +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

I'm looking for feedback to the draft from the list to ensure
that we have consensus to move forward. Please send your
feedback to the list or to me privately.

[Procedural note].
Note that this list is just a mailing list. To advance this draft
to an RFC, it should either be an individual contribution, find a
home in an existing WG or a new one needs to be started.

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 nB8F1G7w008087 for ; Tue, 8 Dec 2009 16:01:16 +0100 (MET)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id nB8F1GR9009395 for ietf-provreg-outgoing; Tue, 8 Dec 2009 16:01: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 nB8F1ELk024571 for ; Tue, 8 Dec 2009 16:01:15 +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 nB8EvmU0020116 for ; Tue, 8 Dec 2009 09:57:48 -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, 8 Dec 2009 10:01:13 -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, 8 Dec 2009 15:01:13 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Tue, 08 Dec 2009 10:01:05 -0500
Subject: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: draft-gould-rfc4310bis-00.txt Submitted for Review
Thread-Index: Acp4F0PEFpQxGDTfOkWVMDcpTV7R9g==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3343111272_6068143"
X-OriginalArrivalTime: 08 Dec 2009 15:01:13.0828 (UTC) FILETIME=[49075A40:01CA7817]
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_3343111272_6068143
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

I haven=B9t received any negative feedback to the draft that I previously sen=
t
to the list, so I=B9m assuming that everyone is fine with it. I officially
submitted the draft. The official draft is available at the URL below. I=B9=
m
looking for feedback to the draft from the list to ensure that we have
consensus to move forward. Please send your feedback to the list or to me
privately. =20

ftp://ftp.ietf.org/internet-drafts/draft-gould-rfc4310bis-00.txt

The draft meets the following goals that were previously sent to the list:

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

I received confirmation that the URI can stay the same as long as the XML
schema is backward compatible.

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

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

All,

I haven’t received any negative feedback to the draft that I previous=
ly sent to the list, so I’m assuming that everyone is fine with it. &n=
bsp;I officially submitted the draft.  The official draft is available =
at the URL below.  I’m looking for feedback to the draft from the=
list to ensure that we have consensus to move forward.  Please send yo=
ur feedback to the list or to me privately.

=
ftp://ftp.ietf.org/internet-drafts/draft-gould-rfc4310bis-00.txt

The draft meets the following goals that were previously sent to the list:<=
BR>

1. XML schema is backward compatible

2. Support for add and rem in the same command

3. Support for passing all four dsData attributes on a rem

4. Support for a dsData and keyData primary interface.  Only one prima=
ry interface should be supported by the server.

5. Remove support for the wildcard delete of dsData in the rem by just usin=
g the keyTag with a clear statement (i.e. Server must return error if the ke=
yTag matches multiple DS records) in the specification.  From my perspe=
ctive and I believe a couple others this is a key issue that must be address=
ed.

6. Clarity in the specification on the use of the chg as a replace or a =
220;change all”.

7. Clarity around the corner case of a client attempting to add and remove =
the same dsData or keyData in a single command.  This must result in an=
error from the server.  Additionally an error must be returned if the =
client tries to remove dsData or keyData that does not exist or tries to add=
dsData or keyData that already exists.

I received confirmation that the URI can stay the same as long as the XML s=
chema is backward compatible.

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

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