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

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-v6ops-conditional-ras-05: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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). But I think I understand this topic, and now I think I understand
it much better. Thanks for that.

I do have some minor comments, but they are non-blocking, so do the right thing.

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

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.

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.

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

It's a nit, but "correspodning".