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


To: "'janusz sienkiewicz'" <janusz@libertyrms.info>
Cc: Daniel Manley <dmanley@tucows.com>, ietf-provreg@cafax.se, "Liu, Hong" <Hong.Liu@neustar.biz>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Thu, 25 Jul 2002 15:05:00 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Proposed Document Changes - Pending Operations

> If we have such 'an extension mechanism' what is purpose of 
> this thread? Why
> are we introducing new return codes and messages? The are 
> several extension
> mechanisms (<extension>, <value>) available but for some 
> reason none of them
> can be used when there is a need for protocol extension. Is 
> this protocol
> really extensible?

The whole question is ultimately one of "does this belong in the core
protocol" or "does this belong in an extension".  It seems to me, based on
list discussion over the last two years, that the concept might be of
general enough interest to be in the core protocol.

I haven't seen anyone (other than you above) suggest that the existing
extension mechanisms can't be used.  I disagreed with your assertion of the
<value> element being an appropriate place to park "pending" information
because the <value> element isn't part of the existing extension framework.
In truth it would be quite easy to define an extension, but given that we
already have the concept of offline verification before provisioning an
object in the domain mapping document (and have had it in there for a while)
it seems logical to be consistent when dealing with updates that require
offline verification.

If you disagree with the premise of Hong's suggestion being generally
useful, thus being something that should be punted to an extension, please
explain why.

The answer to your last question is an unqualified "yes".

-Scott-

Home | Date list | Subject list