This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
Draft Guarded Field document
- Previous message (by thread): Draft Guarded Field document
- Next message (by thread): Draft Guarded Field document
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marten Terpstra
Marten.Terpstra at ripe.net
Fri Jan 21 13:17:30 CET 1994
Havard Eidnes <Havard.Eidnes at runit.sintef.no> 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 at Czechia.EU.net 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 at Czechia.EU.net 931217 source: RIPE -Marten
- Previous message (by thread): Draft Guarded Field document
- Next message (by thread): Draft Guarded Field document
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]