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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Jen,

see below.

> Am 01.08.2018 um 13:31 schrieb 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?

I unterstand this concern but actually a publication delay is not the right basis to make a decision if this should be a normative reference or not. If there is any part in ietf-rtgwg-enterprise-pa-multihoming that the reader needs to consult to understand this document, it’s a normative reference. However, actually I think form my read that it is probably possible to understand this doc without having read ietf-rtgwg-enterprise-pa-multihoming. It’s just that the way the draft is referred in the text seems to require to read it. So I guess you could change the wording used a bit and eventually add additional explanation from ietf-rtgwg-enterprise-pa-multihoming where needed to this doc to make sure they can be read independently, and then keep is informative.

However, having said that, given ietf-rtgwg-enterprise-pa-multihoming is in „publication requested“, I wouldn’t not be to worried about the additional delay. Maybe just ping the responsible AD of ietf-rtgwg-enterprise-pa-multihoming and make sure it will be moved forward soon (given this dependency).

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

Yes thanks! 

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

Thanks!

Mirja

> 
>> 5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2.
> 
> Fixed.
> 
> -- 
> SY, Jen Linkova aka Furry