Obsoleting "connect"
Hi, if my memory serves me well, I think the RIPE DB working group concluded to restrict the legal values for the "connect" field to only "LOCAL", and if wider connectivity for a net has been established to not use this attribute in the objects in the database. However, this is somewhat at odds with the current definition of the connect field in the inetnum template, where the attribute is mandatory. So what do you put in an object which has wider connectivity than internal to the "home" autonomous system? My proposal to progress this decision (as mentioned at the end of the RIPE meeting) is thus to initially demote the "connect" attribute from mandatory to optional, and later add stricter checks in the RIPE database software for the values of the connect attribute. Currently updates missing the connect field are being bounced (I know, I tried it while I was at the RIPE meeting :-) - Havard
Havard Eidnes <Havard.Eidnes@runit.sintef.no> writes: * Hi, * * if my memory serves me well, I think the RIPE DB working group concluded to * restrict the legal values for the "connect" field to only "LOCAL", and if * wider connectivity for a net has been established to not use this attribute * in the objects in the database. * * However, this is somewhat at odds with the current definition of the * connect field in the inetnum template, where the attribute is mandatory. * So what do you put in an object which has wider connectivity than internal * to the "home" autonomous system? * * My proposal to progress this decision (as mentioned at the end of the RIPE * meeting) is thus to initially demote the "connect" attribute from mandatory * to optional, and later add stricter checks in the RIPE database software * for the values of the connect attribute. Currently updates missing the * connect field are being bounced (I know, I tried it while I was at the RIPE * meeting :-) * * Wow - as ever the pace of decision moves quicker than documentation and configuration. I tend to agree with you here but before we change the database config to make connect optional I guess we should get the okay from the chair who will be coordinating the new definitions for the objects. Also, we can take it a step further in that if the connect field is there it is LOCAL (something to add to the syntax checker ;-(). * - Havard --Tony.
I tend to agree with you here but before we change the database config to make connect optional I guess we should get the okay from the chair who will be coordinating the new definitions for the objects.
I agree.
Also, we can take it a step further in that if the connect field is there it is LOCAL (something to add to the syntax checker ;-().
I was thinking of a multi-step phase-in of the new policy, and that this would be the natural next step. Or do we just jump into it with both feet rigt away? - Havard
Havard Eidnes <Havard.Eidnes@runit.sintef.no> writes:
I tend to agree with you here but before we change the database config to make connect optional I guess we should get the okay from the chair who will be coordinating the new definitions for the objects.
As long as we do not hear anyone with a "show-stopper" on this list we will make the field mandatory after an OK from Wilfried Woeber.
Also, we can take it a step further in that if the connect field is there it is LOCAL (something to add to the syntax checker ;-().
I was thinking of a multi-step phase-in of the new policy, and that this would be the natural next step. Or do we just jump into it with both feet rigt away?
This is *not* a good idea to do before the routing registry is in place. There are still a number of poeople out there who use this to generate configurations. They need some warning and an alternative. Daniel
Daniel,
As long as we do not hear anyone with a "show-stopper" on this list we will make the field mandatory after an OK from Wilfried Woeber. =========
I guess you intended optional
Also, we can take it a step further in that if the connect field is there it is LOCAL (something to add to the syntax checker ;-().
I was thinking of a multi-step phase-in of the new policy, and that this would be the natural next step. Or do we just jump into it with both feet rigt away?
This is *not* a good idea to do before the routing registry is in place. There are still a number of poeople out there who use this to generate configurations. They need some warning and an alternative.
As far as GARR is concerned as soon as the NCC accomplish to our request of being guardian of "community: GARR" attribute we can easily change our configuration scripts: then the connect attribute is no longer needed.
Daniel
---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
bonito@nis.garr.it (Antonio_Blasco Bonito) writes: Daniel,
As long as we do not hear anyone with a "show-stopper" on this list we will make the field mandatory after an OK from Wilfried Woeber. =========
I guess you intended optional
Indeed I meant optional.
As far as GARR is concerned as soon as the NCC accomplish to our request of being guardian of "community: GARR" attribute we can easily change our configuration scripts: then the connect attribute is no longer needed.
Working on it.
participants (4)
-
bonito＠nis.garr.it -
Daniel Karrenberg -
Havard Eidnes -
Tony Bates