Re: dynamic update zone

"Scott Rose" <scottr@antd.nist.gov> Fri, 13 September 2002 12:39 UTC

Message-ID: <007c01c25b1f$4ac2cf30$b9370681@BARNACLE>
From: Scott Rose <scottr@antd.nist.gov>
To: namedroppers@ops.ietf.org, Edward Lewis <edlewis@arin.net>
References: <a05111b19b9a649f294c9@[193.0.9.238]> <00cd01c25a91$e5f917e0$b9370681@BARNACLE> <a05111b03b9a7377eabc4@[193.0.9.238]>
Subject: Re: dynamic update zone
Date: Fri, 13 Sep 2002 08:15:47 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Edward Lewis" <edlewis@arin.net>
>
> >example).   In this case - is it necessarily bad that the client may
never
> >decide to try again and send another update request?
>
> The problem is whether the client has the information to make the
> decision.  E.g., a person may try an update and see a failure.
> Depending on a lot of factors, the person might be correct to retry
> in an hour or might be correct to not try that query again.  One
> factor just might be whether the person is told that "your key might
> be authorized to make this change, but I'm not listening now" or
> "your key is not authorized to make that change."  (Just an example
> scenario.)
>

Okay - that example clears things up for me.  My only worry is poorly
written implementations that interpret this new "FROZEN" or whatever,
response and keep hammering away at the server until they get a more
positive response.  Of course this can happen already when REFUSED is
returned...

If I'm thinking correctly about this, the new interpretation of the rcodes
would be:
refused - means that the server will never accept an update from the sender
until some misconfiguration is correct, or policy stuff.

frozen(whatever) - means that the sender could normally make the update, but
the server has been frozen by an admin for some time period.  Try again
later and it might suceed.

correct?

Scott

> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          +1-703-227-9854
> ARIN Research Engineer


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>