[daniel.karrenberg@ripe.net: [rssac] IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data]

[Daniel Karrenberg <daniel.karrenberg@xxxxxxxx>]

I do not see this in the archive, hence the re-post.

Daniel

----- Forwarded message from Daniel Karrenberg <daniel.karrenberg@xxxxxxxx> 
-----

Date: Tue, 22 Jun 2004 12:25:09 +0200
From: Daniel Karrenberg <daniel.karrenberg@xxxxxxxx>
To: iana-del-data-comments@xxxxxxxxx
Cc: Doug Barton <barton@xxxxxxxx>, ICANN RSSAC <rssac@xxxxxxxxx>
Subject: [rssac] IANA Administrative Procedure for Root Zone Name Server 
Delegation and Glue Data
X-RIPE-Spam-Level: 
X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled


Thank you for publishing this draft procedure. It adresses the issues raised by 
RSSAC.

I have a number of suggestions for clarification and improvement which 
should not hold up implementation if they cannot be agreed right away.


----

It appears to be more logical to execute step 5 before step 1.
There is little point in involving other TLD managers if the requesting
TLD manager asks for a change causes problems for their own TLD.

-----

"5. If the number of name servers or IP addresses in the delegation exceeds 
eight (8), 
the size of the response with the intended delegation will be checked 
to ensure that it fits into a 512 byte UDP packet."

This language implies that the size of responses can be precisely
determined.  However, the size of a particular response depends on the
particular question.  This determination involves some judgement on
the part of the IANA on what are resonable queries; a determination
including consideration of the distribution of actual questions at the time.  
This is explained in the last reference cited.

The procedure would be more clear if the judgement involved was expressed 
explicitly. 

Therefore I suggest to change the language to "...., the size of 
responses to reaasonable queries with the intended delegation ....".


------


"1. A cross check is performed to determine if the name server record(s) 
are mentioned in other TLD delegations. If so, managers of those other 
TLDs are notified. No changes will be performed until confirmation 
is received from each affected TLD."

Firstly, this check needs a short explanation of the motivation for it.
Even though general DNS knowledge is assumed of the reader of the procedure
this motivation is not obvious.

Suggestion: "This coss check is necessary because the change may 
increase the amount of glue of any of those delegations such that
the size of their responses will exceed the limit."

Secondly, if IANA can determine that the change will not increase the
size of responses to reasonable queries for a particular TLD I do not
see the necessity to wait for a response from the manager of that TLD to
the notification.  Note: IANA already has to make that determination for
the TLD that requests the change (step 5 in the procedure).  I can see
no reason why IANA could not repeat that determination for each of 
the other delegations.

Thirdly, as proposed wating for confirmation from each TLD is a serious
bug in the procedure because the procedure does not progress if just one
of the other managers never responds.  There should be a time-out for
any such condition in a well designed procedure.  Note that this is
different from one of the other TLD managers asking to hold the change. 
Such an action at least provides an initial point for discussing a
resoloution of issue.  Not responding at all is far worse as it
does not offer a starting point for resoloution. Peronally I cannot
judge what time-out period would be appropriate and what the
action should be once the time-out period expires. This should be
discussed with the TLD administrators.

Suggestion: "1. A cross check is performed to determine if the name 
server record(s)are mentioned in other TLD delegations. If so, 
the size of responses to reasonable queries for each of these TLDs 
with the intended delegation will be checked to ensure that it fits 
into a 512 byte UDP packet. 

If this is not the case for one or more of the other TLDs 
the managers of these TLDs will be notified copying
the manager of the requesting TLD. The procedure will 
be held at this point, giving the TLD managers involved 
time to reolve the issus. It will be re-started at this point
on request of the requesting TLD manager."

Note: this recognises the fact that the only remedy available to 
the requesting TLD manager may be  to move off the name 
server in question. 

----- End forwarded message -----