Re: [ietf-provreg] XML Schema versioning in 4310bis

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] XML Schema versioning in 4310bis

Bernie,

> Sorry, but in this case you can not declare it "consensus", as there was
> not even a sufficient public disussion to reach a consensus.

Maybe the word “consensus” from a WG perspective is not correct, but based on the work done on this list for the past few months I believe I can fairly claim that no one on the list had a major concern using the existing URI and maintaining backward compatibility.  Andrew looks like he now has a different view and sees this as a “serious problem”, which was not previously expressed on the list or in private messages.  Scott Hollenbeck was the one that brought the potential need to change the URI to my attention, and that’s when I went to the AD to find out what the options are.  The AD said that the same URI can be used as long as the schema is backward compatible. That is when I sent the message out to the list with the goals along with the results of my communication with the AD.  There is no way for me to define “consensus” from a mailing list, but I have done the best I can with an individual submission.    

> I don't think the burden should be on the clients. Servers will have to
> implement both versions during a transition period, and Clients will
> gradually upgrade to the new version.
    
The burden is certainly going to be on the clients, who will most likely have to use different implementations across different servers.  The servers don’t have to implement both versions and most likely will not.  We will most likely look to implement one version of the extension, which would be 1.1.  Clients can’t gradually incorporate the new features of the new draft since the new URI is a syntax change and is therefore not backward compatible.         

> I don't think that it is a good idea to make a standard that expects such
> a behavior. Servers and clients might run into (unexpected) error cases,
> which are difficult to catch due to ambiguity in the standards, which is
> to be avoided

I don’t believe that there is much ambiguity in this case.  The new draft is additive to RFC 4310, so the only confusion is the ability to do more with the new draft.  A server can support the old model and the new model without the URI change, since the new draft supports the old syntax.    

> Another thought: Have you considered to make a complete new XML Schema for
> the new functionality, leaving the existing XML Schema untouched?
> [Note: I have not studied in detail whether or not such an approach is
> at all feasible.]

No, the changes are cross cutting and would not work in a separate XML schema.   

My goal in this effort was to address the main issues with RFC 4310, while having the least amount of impact to existing implementations, and maximizing the adoption of DNSSEC by supporting new usability features.  Creating a different URI for the new draft is not a large effort on my part, but I believe is fundamentally against the goals of the work.


-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

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

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

---

From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
Date: Mon, 25 Jan 2010 16:05:30 -0500
To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] XML Schema versioning in 4310bis

Hi James

On Mon, 25 Jan 2010, James Gould wrote:

> I had multiple private messages associated with this, but on the list
> the only message that directly references is from me on December 8th:
>
> http://www.cafax.se/ietf-provreg/maillist/2009-12/msg00000.html

Thanks for the pointer.

Sorry, but in this case you can not declare it "consensus", as there was
not even a sufficient public disussion to reach a consensus.

> The other indirect item is the goal of “XML schema is backward
> compatible”, which is included in multiple messages on the list.  

Well, I'd say many people are just not aware of this work going on. e.g. I
only spotted it accidently today, which leads to the other discussion
about making EPP work in the IETF official...

> Changing the URI (version number) would break this goal, since clients
> would be required to upgrade their clients to use the new URI, assuming
> that a server only supports the new draft.  The servers could support
> two URI’s, which is technically feasible but not simple.  

I don't think the burden should be on the clients. Servers will have to
implement both versions during a transition period, and Clients will
gradually upgrade to the new version.

> > What are the disadvantages if the XML schema version number was changed to
> > urn:ietf:params:xml:ns:secDNS-1.1 ?
>
>  1. Clients that support 1.0 would be required to upgrade to 1.1 for servers that support 1.1.  Backward
>     compatibility does not provide a huge benefit if the URI changes.  Client EPP SDK’s need to be
>     upgraded to support this, where if backward compatibility is maintained the clients don’t need to do
>     anything.

If servers are implementing both versions, clients do not need to
implement both versions during a transition period. If you keep the schema
backward compatible (as you intend to), there is little complexity added
to the server.

>  2. Servers might have to support more then one version at a time to migrate users to the new draft.  I
>     don’t know of any servers supporting multiple versions of anything now, so adding this requirement
>     for a backward compatible scheme seems kind of overkill.

Well, I implemented such a scenario with two XML schema versions on a
productive EPP server with extension RFC 5076, which had a change in the
XML schema during the standardization process. It worked just fine.

> I don’t see a huge advantage of changing the URI, other then clarity in
> the EPP greeting.  Clients can start exercising the new features of the
> new draft when the servers supports it as an option instead of as a
> requirement.  

I don't think that it is a good idea to make a standard that expects such
a behavior. Servers and clients might run into (unexpected) error cases,
which are difficult to catch due to ambiguity in the standards, which is
to be avoided

Another thought: Have you considered to make a complete new XML Schema for
the new functionality, leaving the existing XML Schema untouched?
[Note: I have not studied in detail whether or not such an approach is
at all feasible.]

cheers,
  Bernie