RE: [ietf-provreg] Services messages in RFC 3730

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Michael Young [mailto:myoung@ca.afilias.info] 
> Sent: Friday, August 12, 2005 2:25 PM
> To: Hollenbeck, Scott
> Cc: ietf-provreg@cafax.se
> Subject: Re: [ietf-provreg] Services messages in RFC 3730

[snip]

> >"You might have three queues instead of one, with "high
> >priority" messages going into one queue, "normal priority" messages
> >going into a second queue, and "low priority" messages going into a
> >third."
> 
> 
> I dont see the flexibility to do that as it stands, can you 
> elaborate on that please?

This isn't a protocol interop issue.  As I described here (point 2):

http://www.cafax.se/ietf-provreg/maillist/2005-08/msg00027.html

it's an implementation issue.  You can implement whatever queueing
mechanism you wish.  All that matters to the protocol is that the
messages can be retrieved as specified.

> >a. It truly is optional.
> >b. It doesn't complicate other existing implementations.
> >c. It's common IETF practice to add new features via extensions once
> >proposed standards are published.  Extension development is usually a
> >good reason to spin up a new working group.
> >d. It allows us to avoid a core schema change and the resulting new
> >protocol version.
> >
> >Think about d. for a moment.  A protocol version rev likely 
> implies an
> >operational requirement for ALL conforming servers and clients to
> >support both old and new versions for some TBD period of time.  An
> >extension can be deployed without introducing version 
> management issues
> 
> 
> A and B I think in case qualify.  
> For C how would suggest this be addressed in an extension?

All you have to do is define an extension to the <poll> command and
response to add the features you want to use.  You can then publish the
extension as an I-D if you think there's broad interest, or you can do
your own thing for your own use.  Your call.

> As for D I completely take your point but isnt this 
> ultimately a cost benefit analysis not a defacto "don't go 
> there" decision?  For example the poll queue is the only item 
> under discussion at this point, there are certainly other 
> contenders that could result in a schema change (see 
>  
> http://www.ietf.org/internet-drafts/draft-sullivan-epp-experie
> nce-00.txt ).  Can we really resolve all the raised issues 
> via extensions?  If we can would that be less effort on the 
> implementers and users than a protocol change?  I think it 
> really depends on the complexity of the changes.  With a 
> protocol change the resultant client changes required may be 
> considered minimal by the users involved compared to the 
> gains in capability.  An implementer may find running dual 
> protocol less effort than a series of extensions. As always - 
> it depends and we need some feedback beyond ourselves (some 
> registrar feedback would be helpful here).

I'll have to read the document again to see what's changed since Andrew
first showed me a copy.  I don't know if everything described in the
document can be addressed via extensions, so of course some analysis
must be done.  I think that's what we're trying to do right now.

I will read the document again today and provide comments to the list.

-Scott-