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]/
[anti-abuse-wg] Discussion on 2011-06
- Previous message (by thread): [anti-abuse-wg] Discussion on 2011-06
- Next message (by thread): [anti-abuse-wg] Discussion on 2011-06
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gilles Massen
gilles.massen at restena.lu
Fri Jun 22 13:54:41 CEST 2012
Hi Tobias, >> Under A.: "The "abuse-c:" attribute must reference a role object". >> >> The policy text does not specify 'role'. And I see no good reason for >> the NCC to interpret the policy that way. (btw, if a policy needs >> interpretation even before it is implemented then maybe it might need >> some refining) > > I did that on purpose. :-) > > The first version of this proposal was very technical and did not really > take care about internal RIPE NCC things. The idea now was to shorten it > to a minimum and let the maintainers of the DB, the RIPE NCC tech staff, > come up with a starting point for further discussion. > > RIPE NCC tech staff has much more experience in developing and > maintaining their database, than I will ever have. ;-) I certainly hope so :) It certainly makes sense to include feedback from NCC. But if that feedback shows that the policy text is interpreted, then the policy text should be amended accordingly. A fundamental statement of the RIPE NCC is not to create policies, but to implement the policies coming from the community. A large part of its credibility comes from that setup. So for the 'role' thing: for a proper process either the RIPE NCC feedback needs a clear technical reasoning on why this MUST be role objects, or the requirement should be dropped, or it should be included in the policy text (and then I'd still like to know why). > >> Under C, phase two: I was under the impression that the policy was to be >> voluntary at first, and that the mandatory part was to be discussed >> further on, ideally with some information about the uptake of the >> object. Now I missed when the restrictive appeared in v.2 of the draft >> appeared...so be it. But now "The RIPE NCC will also plan to >> decommission irt objects...". >> >> So if the current, short and simple, policy text is used to sneak in >> undiscussed features via the impact analysis I have no choice but to >> object. > > I think this is not a completely undiscussed topic at all. We have > already talked about the future of the IRT Object. And undiscussed > issues are one of the reasons, that Emilio last week and Brian today > asked for feedback. It has been mentioned several times - but the discussion has always been postponed until after the abuse-c. From your last email on that topic (unless i'm mistaken): "That's why I would like to wait for an implementation of the abuse-c if we find consensus on that and look at the numbers of the IRT Objects again and start making decisions on what should happen with it." Although it seem the wrong way around, I can even live with that...and won't go into further details > I do not see RIPE NCC sneaking in undiscussed features. RIPE NCC was > asked to make a suggestion on how to implement the policy text into DB. > The irt issue is part of the clean-up that I talked about in the > proposal. RIPE NCC just described it in the way they would implement it. If it was only discussing possible ways forward, then the wording is appropriate. I'd go even further: supposing that if you need a policy to create an object, I'd expect the same to deprecate one. Any comment from the NCC beyond 'and in case of clean-up the IRT object needs consideration' would be a step into policy-making territory. Now don't get me wrong, I do not suggest that the text from the NCC is a deliberate attempt to avoid a discussion or policy. But the fact that it does exists makes me suggest to have a more narrow policy text, with an explicit reference that IRT objects are to be handled later on. Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473
- Previous message (by thread): [anti-abuse-wg] Discussion on 2011-06
- Next message (by thread): [anti-abuse-wg] Discussion on 2011-06
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]