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: Draft Guarded Field document

  • To: Havard Eidnes < >
  • From: Marten Terpstra < >
  • Date: Fri, 21 Jan 1994 13:17:30 +0100
  • Cc: Tony Bates < >

Havard Eidnes <Havard.Eidnes@localhost writes
 * Hi,
 * 
 * just a small comment:
 * 
 * > 3.  The Basic Procedure
 * > 
 * > For each of the guarded attributes detailed above,  a  list  of  all
 * > networks  having  this attribute is kept separately from the general
 * > database itself.  These lists (also called `guarded files') will  be
 * > maintained and be served as the `only' source of membership informa-
 * > tion used in the database.  Normal database updates  `never'  change
 * > these  attributes.   If  an  update includes such an attribute and a
 * > discrepancy between the values in the update and those in the  data-
 * > base  is  found, a diagnostic message will be sent to the originator
 * > of the update and the guarded value(s) will not  be  affected.
 * 
 * What about the rest of the attributes if the object contains a mismatched
 * guarded field?  Will they be updated, or will the whole object be rejected
 * (I assume the latter).  I assume the answer to this question will be
 * evident when I produce the first "guarded-reject" update, but it would be
 * nice to have this stated clearly in the text as well.

Actually, what the document says (maybe not too clear) is that when
you send in an object that has guarded attributes, and you have
defined them different than what the files say, the object WILL be
updated, BUT all guarded attributes will be reset to their "guarded"
value. So, all other changes to the object will simply be done. I
don't think I can refuse the other updates. The sender will get a
warning though that these guarded attributes have been reset. For
instance with the current bdrygw-l attribute, a message like below
would be generated:

inetnum:   193.84.96.0 - 193.84.99.0
netname:   MPO
descr:     Ministry of Industry and Trade
descr:     Prague
country:   CZ
admin-c:   Pavel Pokorny
tech-c:    Pavel Pokorny
connect:   RIPE EASI NSF
bdrygw-l:  ACONET
changed:   ors@localhost 931217
source:    RIPE
WARNING:   guarded field bdrygw-l reset to current value

This update was send in without the bdrygw-l attribute:

inetnum: 193.84.96.0 - 193.84.99.0
netname: MPO
descr:   Ministry of Industry and Trade
descr:   Prague
country: CZ
admin-c: Pavel Pokorny
tech-c:  Pavel Pokorny
connect: RIPE EASI NSF
change:  ors@localhost 931217
source:  RIPE


-Marten



  • 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