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

All,

I had to make a slight change to 02 to change the MUST to a SHOULD and to
add ³and based on server policy² with the sentence ³In addition, the EPP
<extension> element SHOULD contain a child <secDNS:infData> element that
identifies the extension namespace if the domain object has data associated
with this extension and based on server policy.²  Server policy has to be
considered in returning the secDNS information.  I include this update in 03
of the draft at the URL below.  Please review for feedback.

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

Thanks,

-- 


JG 

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

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

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



From: James Gould <[email protected]>
Date: Wed, 23 Dec 2009 18:04:36 -0500
To: Klaus Malorny <[email protected]>
Cc: EPP Provreg <[email protected]>
Conversation: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for
Review
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for
Review

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

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


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email protected]
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: Klaus Malorny <[email protected]>
Date: Wed, 23 Dec 2009 11:40:35 -0500
To: James Gould <[email protected]>
Cc: EPP Provreg <[email protected]>
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 to
>>  extend
>>  RFC 3915 to report something in addition to the <rgp:rgpStatus>, 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