[anti-abuse-wg] Discussion on 2011-06

Hi,

> 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.

I do not see this as a problem at all, quit the opposite.

The proposal asks for a place to store abuse contact information and
some non technical features around that. As a proposer I do not care
about the way it will be implemented. That's one of the reasons a TF was
created to get as much input from RIPE NCC tech staff as possible and
come up with the best possible way from their point of view. And in this
case I appreciate interpretations that make sense.

> 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.

RIPE NCC does not create policies. The question is where to put the line
between what is a policy and what is implementation. I think on the
other extreme it does not make sense if community dictates RIPE NCC how
to implement things. Because at the end RIPE NCC has to run and maintain
the DB and not the community. But that is a tricky questions that
probably can never been answered completely.

> 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).

I maybe have a clue why it's the role object, but I'm not sure. Maybe
it's the part about personal and non-personal data. But hei, let's just
ask.

Does anybody know and I bet people who wrote the impact analysis do, why
this should be a role-object?

> 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 can live with that as well. And I will propose this to RIPE NCC, that
we will have a look at irt later on.


> 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.

Agree. So let's keep the irt discussion out of this policy proposal and
review this later. Makes a lot of sense to me and keep focus on the main
intend of the proposal.

> 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.

I think that should be possible.
@Emilio, can we change the irt part and add something like this to it.
I think it does not hurt in anyway, neither technical nor from a policy
perspective.

Thanks,

Tobias


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20120623/e2bf6e52/attachment.sig>