On 02/08/2018 11:12, Michael Richardson wrote:
>
> Brian E Carpenter <[email protected]> wrote:
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >> Section 6.10.4:
> >>
> >> "The value of the Interface Identifier is left for future definitions."
> >>
> >> I don't understand how this is usable without some definition. I.e.,
> if I
> >> assign every interface ID in my ACP to be 0, it's not going to work.
> Could you
> >> elaborate about what is expected in this field?
> >>
>
> > Why not:
>
> > The value of the Interface Identifier SHOULD follow [RFC8064].
>
> > That would work fine and is a SHOULD to allow for alternatives
> > if there's a good reason.
>
> The ACP addresses (including interface identifiers) are assigned by the ANI
> Registrar, and are embedded in certificates issued by the Registrar.
> Schemes 6.10.2 and 6.10.3 support this mechanism.
>
> Section 6.10.4 is about very much MANUAL allocation, which is basically
> a non-zero-touch backdoor which nobody is supposed to use, unless they aren't
> doing ANI stuff.
>
> Really, it's about the Registrar doing it's work (section 6.10.7), and the
> only reason to have any statements about addressing schemes is so that we can
> paint off some areas for manual allocation. (I didn't want any of these
> schemes here,
> I don't think it helps, but maybe it causes no harm).
>
> The explanation in 6.10.7.2 further allows for multiple Registrars to operate
> without coordinating via a centralized database (or blockchain).
>
> So, by all means, suggest an RFC8064 IID in the UI when configuring a manual
> address, but if the admin is even close to that part of the configuration,
> then they probably meant to do something very specific.
Absolutely, but Alissa is correct, we need to say *something*.
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
