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


To: ietf-provreg@cafax.se
From: "Liu, Hong" <Hong.Liu@neustar.biz>
Date: Thu, 25 Jul 2002 16:56:07 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Proposed Document Changes - Pending Operations

Janusz,

That is exactly the problem I had when I first raised the issue on the list.
I fully understand your concerns about complexity. In my upcoming draft, I
will present a few options, and hopefully the WG will choose one with
minimum impacts on the core documents. 

Cheers,

--Hong

-----Original Message-----
From: janusz sienkiewicz [mailto:janusz@libertyrms.info]
Sent: Thursday, July 25, 2002 4:32 PM
To: Hollenbeck, Scott
Cc: Daniel Manley; ietf-provreg@cafax.se; Liu, Hong
Subject: Re: Proposed Document Changes - Pending Operations


Scott, Liu,

It is true that a trace of 'the concept of offline verification before
provisioning an object ' can be found in domain mapping document. The
problem
is the part of the document that deals with the subject is very vague. There
is
not much guidance have to use the concept. Such a concept does not exist at
XML
schema definition level. I think more work is required on definition and
refinement of the concept. New result codes and errror conditions could be a
result of the process.

I assume such a definition is a nontrivial task. That's why I suggested  a
solution based on generic extension mechanism. It could be a quick
potentially
temporary solution. From Liu's note I assume he is going to prepare
something
in the matter. I hope it will fill the gaps I can see in domain mapping
document.

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

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