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