Re: [Snac] draft-ietf-snac-simple-01 review comments

[Ted Lemon <[e-mail]>]

On Fri, May 19, 2023 at 7:02 AM Michael Richardson <[e-mail]>
wrote:

> Darren Dukes \(ddukes\) <ddukes=[e-mail]> wrote:
>     > 2 – Section 5.1.2.4 – doesn’t account for receipt of multiple
> prefixes,
>     > is there a reason for that? It seems to say any prefix received that
> is
>     > not equal to the currently advertised prefix results in
>     > STATE-DEPRICATING or changes in the advertising on the stub network.
>
> Also I just thought as I read this, what if the prefix length on a prefix
> changes?
> I am thinking of a situation where a process and/or human inadvertedly
> advertises the entire /56 that they got from upstream, and then changes
> their
> mind, fixes things and advertises only the :0::/64 of it.
>

This is a good point—thanks for raising it. I will add text. I didn't find
the text in this section to b exclusive of multiple prefixes, but modified
it a bit to make it clear that there could be multiple prefixes.

-             The stub router may receive a router advertisement containing
a usable on-link prefix on the AIL.
-             If the advertised prefix is different than the prefix the
stub router is advertising as the on-link usable
-             prefix, and the Stub Router bit is not set in the prefix
option for the prefix, the stub router moves the interface to
+             The stub router may receive a router advertisement containing
one or more usable on-link prefixes on the AIL.
+             If any of these prefixes are different than the prefix the
stub router is advertising as the on-link usable
+             prefix, and the Stub Router bit is not set in the prefix
option for that prefix, the stub router moves the interface to


>     > 4 – Section 5.2.3 mentions “cloud services will not be reachable via
>     > IPv6”.  How is this relevant to DHCPv6 PD? Is it more accurate to say
>     > “any address outside the stub network will not be reachable via
> IPv6”?
>
> Both are accurate, but the former is more clearly a reminder to IoT device
> people.
>

I added this sentence, which I think connects the dots a bit more clearly:

   The OSNR prefix in this case is not known to the infrastructure network
   routing fabric, so even though packets might be able to be forwarded to
the intended destination, there would be no
   return path.