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-