About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: 193.in-addr.arpa block delegation procedures (draft)

  • To:
  • From: "Wilfried Woeber, UniVie/ACOnet, +43 1 436111 355" < >
  • Date: Fri, 19 Mar 1993 16:01:10 EST
  • Cc:

| * > Another thing would be to create YADO (Yet Another Database Object) for
| * > delegated blocks only, but I do not quite like that idea either.
|
|After some in-house discussion here we would like to following:
|
|- requests for delegation of a block in 193.in-addr.arpa should be done
|  by sending in the xxx.193.in-addr.arpa domain object to HOSTMASTER.
|- we will then forward all entries that are already in the 193.in-addr.arpa
|  zone that belong to this block
|- we will check that the existing entries are put into the delegated zone.
|- we will delegate authority, and pass object to the database
|- we will forward any request for reverse registration inside this block
|  to the zone-c for this reverse block.

I like it.

|The question about zone-c in the inetnum object and/or removing the rev-srv
|field and replace it by an individual net.block.193.in-addr.arpa domain is
|something for the database and dns working group. We really would like to get
|the block delegation going.

I think this is the essential thing. I propose to go ahead _doing_ it.

Otherwise I'd even like to suggest a "back to square one" approach for the DB
issues. I think we have to back up and figure out/define _what_ we want to
organize for _which_ group of people. Generally my feeling is that we should
try to

- use _existing_ procedures wherever possible without "bending" them
- invent new and _simple_ things if there is a need (the KISS principle)
- keep the procedure for the "users" as simple as possible. 
  Personally I prefer additional "small" objects that can be cross-checked
  automatically for consistency against "huge" multi-purpose objects with a
  lot of options and implied semantics. But that's probably a question of
  taste...

|If noone has strong objections against the above procedure for block
|delegation (not the net things), I will update the document and send out a
|new version later today (probably tonight).

My vote in favour.

wilfried.
--------------------------------------------------------------------------------
Wilfried Woeber                : E-m: Wilfried.Woeber@localhost (Internet)
Computer Center - ACOnet       :      Z00WWR01@localhost (EARN)
Vienna University              : [    woeber@localhost (X.400)   ]
Universitaetsstrasse 7         : [    S      O   P      A   C            ]
A-1010 Vienna, Austria, Europe : Tel: +43 1 436111 355, Fax: +43 1 436111 170
--------------------------------------------------------------------------------



  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community