Subject: Re: [Anima] I-D Action: draft-eckert-anima-stable-connectivity-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Mar 2015 08:47:40 +1300

Hi,

Thanks for this.

Just one comment. I'm not sure it's very useful to mention ULA-C,
since no such thing has been standardised; RFC 4193 doesn't
even hint at it beyond saying "Another method, indicated by
clearing the L bit, may be defined later." I think the
discussion will just confuse readers.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Mar 2015 19:16:00 -0400

Brian E Carpenter <[email-masked]> wrote:
    > Just one comment. I'm not sure it's very useful to mention ULA-C, since
    > no such thing has been standardised; RFC 4193 doesn't even hint at it
    > beyond saying "Another method, indicated by clearing the L bit, may be
    > defined later." I think the discussion will just confuse readers.

I take it differently: I think that this is a reason to document ULA-C.

---

From: James Woodyatt <[email-masked]>
Date: Mon, 9 Mar 2015 12:28:12 -0700

I agree with Brian, and furthermore I don't agree with the judgment in this
paragraph:

Centrally assigned ULA addresses (ULA-C) would be an even better
> choice than currently available randomnly self-assigned (ULA-R)
> addresses, because they would permit to audit who owns the address
> prefix if these addresses show up in places where they are not
> expected (for example in above mentioned operational issues).

I can see an argument here for a registry, but not one for an assignment
authority. It is not at all clear to me how a central assignment authority
can operate with even less risk of duplication than the already epsilon
level of risk in the random self-assignment of RFC 4193. This statement
appears to take it as axiomatic, and I think it's very debatable.

On Sun, Mar 8, 2015 at 4:16 PM, Michael Richardson <[email-masked]> wrote:

> since
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Mar 2015 09:06:42 +1300

> appears to take it as axiomatic, and I think it's very debatable.

It is. In fact, IMHO the best approach if you want a registry is the one
which already has running code (but would need to be operated under IANA
authority to be reasonably reliable):
https://www.sixxs.net/tools/grh/ula/
In any case this isn't an Anima problem and it is already proving a distraction
here ;-)

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 23 Mar 2015 12:11:23 -0700

Inline, 

On Mon, Mar 09, 2015 at 12:28:12PM -0700, James Woodyatt wrote:
> authority.

Yes, i was also wondering if there was a more lightweight
solution than assignment.

> It is not at all clear to me how a central assignment authority
> level of risk in the random self-assignment of RFC 4193.

What are existing cases of duplication through assignment ?

Also: can you define how "self registration" should work ?

Eg: Thinking about this i couldn't get up with a better scheme
than taking money, or else you have trolls depleting the space.
And once you take money, could you really give less "guarantees"
than you have to give in the "assignment" case ?

Self registrastion portal at ulac.internetsociety.org,
$20 to create an account, $20 for every registered prefix,
can only look up a prefix (not search, not list prefixes)
when you have an account ? 

Still looks a lot like assignment...

> This statement

Any suggestions for better text welcome.

Thanks!
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 23 Mar 2015 13:01:20 -0700

> In any case this isn't an Anima problem and it is already proving a distraction

Nice. I just worry about this being abused when it becomes
more successful to the extend that somebody needs to earn money from it to harden it.
And as i said, taking in money also reduces the attack vectors.

Cheers
    Toerles