[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
CC: ietf-provreg@cafax.se
From: Michael Young <myoung@ca.afilias.info>
Date: Fri, 12 Aug 2005 14:24:39 -0400
In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com>
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
Subject: Re: [ietf-provreg] Services messages in RFC 3730

>"Superlatives and astonishment aside, there are really three issues here:"


Ok perhaps I was being excessive ;-)


>"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?


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

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-experience-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).

Michael











 















 



Home | Date list | Subject list