Re: [v6ops] Working Group Last Call draft-ietf-v6ops-nd-cache-init

[Fernando Gont <[e-mail]>]

Hello, Jen,

On 9/6/20 09:21, Jen Linkova wrote:
> On Sun, May 31, 2020 at 7:05 PM Fernando Gont <[e-mail]> wrote:
>> I support publication of this document. Bellow you'll find my review:
> 
> Thanks for your review and comments Fernando!
> I've just submitted -02 which shall address your comments.

Thanks!



>> * Section 3.4:
>>>
>>>     o  If the address is in the Optimistic state the RS can not contain
>>>        SLLAO.  As a result the router would only create a cache entry if
>>>        the solicited RAs is sent as as a unicast.  Routers sending
>>>        solicited RAs as multicast would not create a new cache entry as
>>>        they do not need to send a unicast packet back to the host.
>>
>> Of the top of my head, I'm not sure if an RA sent to a multicast address
>> can be a "solicited RA" (as in "having the 'solicited' flag set). Please
>> double-check.
> 
> There is no such thing as a 'solicited' flag in RA.

I have no idea what I was thinking when I wrote this :-) -- sleep 
disorder might be a plausible explanation :-))


>> * Section 3:
>>
>> Thinking out loud: One might move this section (and subsections) to an
>> Appendix?
> 
> IMHO, as some of those options are implemented by some vendors, so I
> believe it makes sense to discuss them.

I would suggest that you note this at the beginning of this section 
(even if it's just a general comment like the one above ("some of these 
options are implemented by some vendors.."). That would signal folks 
that they might expect to see some of this in the wild.  -- Otherwise 
(like myself), they might assume that these are just potential solutions 
that you evaluated and then discarded.

FWIW, if you decide to apply this "change", feel free to schedule it for 
the next rev (i.e., this is not a show stopper, and you don't need a rev 
just for this).

Thanks!

P.S.: Not sure what's the necessary magic for this to happen, but, if 
possible (i.e., assuming that both docs are progressed smoothly and 
timely), I'd suggest that this doc is put in a cluster with the 
companion 6man document, such that both reference each other's RFC 
versions when published.

Cheers,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1