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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Jen,

On Wed, Aug 1, 2018 at 6:43 AM Jen Linkova <[e-mail]> wrote:

> Hi Spencer,
>
> Thank you very much for your feedback!
>

This all looks fine. Thank you for considering my comments.

Spencer


> > 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
>