Re: [v6ops] Spencer Dawkins' Yes on draft-ietf-v6ops-conditional-ras-05: (with COMMENT)

[Jen Linkova <[e-mail]>]

Hi Spencer,

Thank you very much for your feedback!

> I echo Mirja's thanks for a well-written document (and her curiosity about the
> near-null Security Considerations - there's at least one recommendation in this
> document, so it seems possible that some security consideration is worth
> mentioning).

The Section 5 updated:
https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5

> This text toward the bottom of the abstract
>
>    this document
>    adopts the approach proposed in the "ietf-rtgwg-enterprise-pa-
>    multihoming" draft to provide a solution for a limited number of
>    common use cases.
>
> is pretty easy to miss. If the reader misses it, the first sentence is kind of
> misleading - it just says
>
>    This document discusses the most common scenarios of connecting an
>    enterprise network to multiple ISPs using an address space assigned
>    by an ISP.
>
> Perhaps it's worth pointing that out in the first sentence, rather than towards
> the end of the abstract?

I've updated the first sentence, it's now saying:

"This document discusses the most common scenarios of connecting an
   enterprise network to multiple ISPs using an address space assigned
   by an ISP and how the approach proposed in the "ietf-rtgwg-
   enterprise-pa-multihoming" draft could be applied in those scenarios."

(https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06)

Do you think it's more clear now?

> I've been on the IESG far too long, but I have tried repeatedly to read
>
>    While some work is being done in the Source Address Dependent Routing
>    (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]),
>
> without thinking "but SADR isn't an (IETF) area?!?", and I can't do it. If
>
>    While some work is being done on Source Address Dependent Routing
>    (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]),
>
> that would stop startling at least one reader ...

Oops, sorry, did not think that the word 'area' is *so* overloaded..;) Fixed!

> In 3.2.5.  Topologies with Dedicated Border Routers
>
>    For simplicity, all topologies above show the ISP uplinks terminated
>    on the first-hop routers.  Obviously, the proposed approach can be
>    used in more complex topologies when dedicated devices are used for
>    terminating ISP uplinks.  In that case VRRP mastership or interface
>    status can not be used as a trigger for conditional RAs and route
>    presence as described above should be used instead.
>
> "as described above" might be easier to navigate if it was "as described above
> in Section 3.1.2" - it's a six-page jump, if I'm tracking this cross reference
> correctly, and if I'm not, an explicit section reference would be even more
> appreciated.

Fixed:
https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-3.2.5

> I'm not sure that
>
>   It should be noted that the proposed approach is not a silver bullet
>    for all possible multihoming scenarios.
>
> "silver bullet" is clear for readers from cultural contexts that don't include
> werewolves or vampires ... but do the right thing, of course.

Good point ;) I've added quotation marks around 'silver bullet' to
indicate it's a the figure of speech.

>
> It's a nit, but "such as latencyetc".
>
> It's a nit, but "correspodning".

Fixed.

-- 
SY, Jen Linkova aka Furry