Re: [ietf-provreg] Anyone working on 4310-bis?

[Andrew Sullivan <ajs@shinkuro.com>]

Hi,

On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote:

> 1) it is a little bit unclear to me whether we still want to create an 
> update of RFC 4310 that is fully backward compatible, XML-wise and mostly 
> semantically.

My impression was that we _do_ need at least an update that allows old
clients to continue to work, and will allow new clients to work with
old servers.  I haven't figured out whether it's possible to make the
necessary schema changes and still be technically backward compatible,
though I'm leaning toward "no".  That will mean a bump in the schema
version.  Such a bump would be an even stronger reason to make it
operationally backward compatible.

I attach a -00 version as a scratch proposal.  The draft submission
window is closed due to the upcoming Hiroshima meeting, so I'm posting
it here.  Anyway, this doubtlessly needs changes before really being
submitted.

> 2) there is a consensus that <add> and <rem> elements shall be allowed in 
> a single request, which must be on the other hand mutually exclusive to 
> the <chg> element.

Are we sure that the <add> and <rem> elements have to be processed in
the order in which they appear?  I am not completely sure.  I recall
at least one operator who had an issue related to this
processing-order question.  If they do _not_ have to be so processed,
then in fact they can't be allowed in a single request because the
effect could be different from what is intended.  (Note that this
remark also means that there is by no means a consensus on this matter
yet.)

RFC5731 says, "Commands are processed by a server in the order they
are received from a client."  But in this case these aren't actually
different commands, and I have so far been unable to convince myself
that a server operator has to process the elements of one command in
the order in which those elements appear.  If someone knows otherwise
(and I would be very much pleased to have such proof), I'd like to
hear it.  But as things stand, my reading is that a server operator
could handle all the <add> elements first, and all the <rem> elements
second, and the effect of that could be quite different than what
we're trying to achieve.

> 4) there is a disagreement of how to interpret a  
> <rem><keytag>1234</keytag></rem> in the case that multiple DS records 
> with this key tag have been provisioned earlier. One choice is to reject 
> the operation, the other is to remove all DS records matching the key 
> tag. There is a third choice of removing the the <keytag> element at all.

I have candidate text for this now.  In order to make this backward
compatible, one has to accept it in the protocol.  I have written the
text so that by registry policy, sich an operation can nevertheless be
rejected. 

> 5) there is a disagreement of how to repair the <rem> element. One choice 
> is to use the existing "dsDataType", with the semantics that it must 
> match exactly an existing DS record, otherwise the request will fail 
> (questionable though what an exact match is). The other choice is to 
> create a separate "selectType" datatype which contains optional elements 
> only. All existing DS records are tested against the respective element. 

Not elements, but attributes, is the way I've got it at the moment.  I
didn't include the attributes other than the hash in the text as it's
written, but I think James has convinced me there'd be no harm in
adding the other ones.

Comments are welcome.

Best,

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se