Re: [v6ops] Mirja Kühlewind's No Objection on draft-ietf-v6ops-conditional-ras-05: (with COMMENT)

[Jen Linkova <[e-mail]>]

Hi Mirja,

Thanks a lot for your feedback!
-06 version has been submitted to address your comments:
https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06.

Also please see my responses inline:

> 1) The shepherd write-up says "The responsible Area Director is Ron Bonica."
> and questions 7 and 8 say "TBD"

I believe Warren has fixed those issues (thanks a lot, Warren!)

>and the RFC8174 biolerplate is missing...

Fixed.

> 2) It seems that ietf-rtgwg-enterprise-pa-multihoming should maybe be a
> normative reference (and that the abstract should be updated with the
> respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is
> published). Any even if it is not a normative reference, should those docs be
> published together in order to refer to the RFC in the abstract (instead of an
> draft)?

Ah, that's a tricky part...Initially I wanted
ietf-rtgwg-enterprise-pa-multihoming
to be a normative reference and those two documents published as a cluster.
However the main reason for writing this draft was to document
tactical solution available
right here right now, while we are waiting for the proper one to come.
So it would make sense to publish
the conditional RAs draft reasonably quick. Unfortunately
ietf-rtgwg-enterprise-pa-multihoming
has been in 'Publication Requested ' state for the last 51 days and
I'm afraid it might take a while
before we can get it published. So it looks to me that this draft
might be published independently (while
ietf-rtgwg-enterprise-pa-multihoming contains all
justifications/explanations on 'why SLAAC and not DHCPv6/ICMP error
messages'
it's still not really necessary to read the whole
ietf-rtgwg-enterprise-pa-multihoming to understand the solution
proposed
in draft-ietf-v6ops-conditional-ras...Or am I biased here?

> 3) Would it makes sense to also discuss what to do when one ISP is down but
> packets from that address space are received at the border router? Should those
> packet be forwarded to that ISP anyway or dropped? Or should they be forwarded
> to the other ISP with or without address translation?

I've added Section 3.2.8:
https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#page-15

Please let me know if it does not address your concern.

> 4) It doesn’t seem right to me that the security consideration section is empty.

Updated it:
https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5

> 5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2.

Fixed.

-- 
SY, Jen Linkova aka Furry