Re: [Crisp] new status for DREG2

Andrew Newton <andy@hxr.us> Tue, 21 March 2006 15:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLj8J-0001H0-54; Tue, 21 Mar 2006 10:50:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLj8H-0001GW-Vg for crisp@ietf.org; Tue, 21 Mar 2006 10:50:53 -0500
Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLj8H-0004hY-OX for crisp@ietf.org; Tue, 21 Mar 2006 10:50:53 -0500
Received: from [130.129.130.179] ([::ffff:130.129.130.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 21 Mar 2006 10:49:59 -0500 id 01584379.442020A7.0000542B
In-Reply-To: <20060321092454.03ea09d2@garlique>
References: <6CEB55DE-2DD5-463B-BE15-145B241D8DCF@hxr.us> <20060321092454.03ea09d2@garlique>
Mime-Version: 1.0
Message-Id: <6D898A12-FA4C-403A-ABF5-1B784BC1B671@hxr.us>
From: Andrew Newton <andy@hxr.us>
Subject: Re: [Crisp] new status for DREG2
Date: Tue, 21 Mar 2006 10:50:51 -0500
To: George Michaelson <ggm@apnic.net>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: crisp@ietf.org
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1073116727=="
Errors-To: crisp-bounces@ietf.org

On Mar 21, 2006, at 10:24 AM, George Michaelson wrote:

> who gets to set it? the data originator, or the data(base) manager
> or ...

In the particular case I have been given, it would be the TLD  
operator.  This is similar to the lameness check.  In the general  
case, I would assume it would be up to the policies of the server  
operator (who is most likely the TLD operator) as to where they get  
the information.

> is it revised after the event?

Just like the other enhanced status values, the operator can attach a  
date so they can indicate compliance and then noncompliance and then  
compliance if they want.  However, I think it is more likely that  
they simply only indicate the current status.

> does it require differential ACL?

As with any of the use cases for IRIS, that is up to the TLD  
operator.  However, the particular example I was given was that this  
status would be exposed to everybody (annonymous access).

-andy
_______________________________________________
Crisp mailing list
Crisp@ietf.org
https://www1.ietf.org/mailman/listinfo/crisp