> > Well, even if you do not want to change the status quo then this > > complaint has one undoubtful point: > > This whole BCP (whatever that includes in detail) is nowhere > > documented. > It is now, since Anand replied to the list, in <68c1d8f7-7b0b-a5d0-d1 > ed-d75f21562...@ripe.net> . > > I suggest that we perform the absolute minimum of policy footwork to > endorse this procedure as is. Because I feel we have a strong if not > absolute consensus for carrying on as usual from those who spoke up > here. > > I'm a tad rusty on procedure here, so others will have to help with > how > we continue. > > Regards,
Ok, thanks everyone for the input - i do see that the negative effects of combining auth. resolver with open recurses outweight the positive ones now. I wouldnt have started all this if there was documentation about requirements for reverse delegation nameservers somewhere. I do know that time ago there were no open resolver checks (or they didnt work properly), so my assumption was that this was silently introduced (since i didnt find any "changelog"). Now that Anand has provided insight on how RIPE does its checks, this should be easy to find for any upcoming questions. I do agree with Mans that there is no new policy etc needed and we can move on. - Jonas
signature.asc
Description: This is a digitally signed message part
