Re: [gnso-irtp-b-jun09] Proposed agenda IRTP Part B WG

[Marika Konings <marika.konings@xxxxxxxxx>]

Ahead of tomorrow’s call, Scott Hollenbeck would like to encourage everyone to 
review Section 2.3 of RFC 5731 which can be found hereunder or at 
http://datatracker.ietf.org/doc/rfc5731/.

With best regards,

Marika

======

>From Extensible Provisioning Protocol (EPP) Domain Name Mapping
RFC 5731


2.3.  Status Values

A domain object MUST always have at least one associated status
value.  Status values can be set only by the client that sponsors a
domain object and by the server on which the object resides.  A
client can change the status of a domain object using the EPP
<update> command.  Each status value MAY be accompanied by a string
of human-readable text that describes the rationale for the status
applied to the object.

A client MUST NOT alter status values set by the server.  A server
MAY alter or override status values set by a client, subject to local
server policies.  The status of an object MAY change as a result of
either a client-initiated transform command or an action performed by
a server operator.

Status values that can be added or removed by a client are prefixed
with "client".  Corresponding status values that can be added or
removed by a server are prefixed with "server".  Status values that
do not begin with either "client" or "server" are server-managed.

Status Value Descriptions:

-  clientDeleteProhibited, serverDeleteProhibited

Requests to delete the object MUST be rejected.

-  clientHold, serverHold

DNS delegation information MUST NOT be published for the object.

-  clientRenewProhibited, serverRenewProhibited

Requests to renew the object MUST be rejected.

-  clientTransferProhibited, serverTransferProhibited

Requests to transfer the object MUST be rejected.

-  clientUpdateProhibited, serverUpdateProhibited

Requests to update the object (other than to remove this status)
MUST be rejected.

-  inactive

Delegation information has not been associated with the object.
This is the default status when a domain object is first created
and there are no associated host objects for the DNS delegation.
This status can also be set by the server when all host-object
associations are removed.

-  ok

This is the normal status value for an object that has no pending
operations or prohibitions.  This value is set and removed by the
server as other status values are added or removed.

-  pendingCreate, pendingDelete, pendingRenew, pendingTransfer,
   pendingUpdate

A transform command has been processed for the object, but the
action has not been completed by the server.  Server operators can
delay action completion for a variety of reasons, such as to allow
for human review or third-party action.  A transform command that
is processed, but whose requested action is pending, is noted with
response code 1001.

When the requested action has been completed, the pendingCreate,
pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status
value MUST be removed.  All clients involved in the transaction MUST
be notified using a service message that the action has been
completed and that the status of the object has changed.

"ok" status MUST NOT be combined with any other status.

"pendingDelete" status MUST NOT be combined with either
"clientDeleteProhibited" or "serverDeleteProhibited" status.

"pendingRenew" status MUST NOT be combined with either
"clientRenewProhibited" or "serverRenewProhibited" status.

"pendingTransfer" status MUST NOT be combined with either
"clientTransferProhibited" or "serverTransferProhibited" status.

"pendingUpdate" status MUST NOT be combined with either
"clientUpdateProhibited" or "serverUpdateProhibited" status.

The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and
pendingUpdate status values MUST NOT be combined with each other.

Other status combinations not expressly prohibited MAY be used.

On 22/03/10 11:47, "Marika Konings" <marika.konings@xxxxxxxxx> wrote:

Dear All,

Please find below the proposed agenda for tomorrow’s IRTP Part B WG meeting.

Best regards,

Marika

Proposed Agenda IRTP Part B WG – 23 March 2010


 1.  Roll Call
 2.  Discussion with Scott Hollenbeck (VeriSign) on lock status in EPP
 3.  Update from sub-team (James)
 4.  Continue review of Constituency Statements (see updated grid on wiki)
 5.  Initial Report Timetable – in order to be considered / discussed at the 
ICANN meeting in Brussels, the Initial Report would need to be published on 
Friday 4 June at the latest.
 6.  Confirm next meeting