Subject: Opinion requested: Independent submission of draft-sarikaya-6man-sadr-overview-11

From: Suresh Krishnan <[email-masked]>
Date: Thu, 22 Sep 2016 05:33:22 +0000

Hi all,
   The draft describing a problem space overview for Source Address Dependent 
Routing and Source Address Selection for IPv6 Hosts available at

https://tools.ietf.org/html/draft-sarikaya-6man-sadr-overview-11

has been submitted through the Independent stream for publication.

The IESG is currently performing a conflict review on the document as 
described in RFC5742. This document is up for discussion on the 2016-10-13 
IESG Telechat. Since this document was discussed earlier in the 6man working 
group, I would like to solicit the opinion of the WG and the WG chairs on 
whether publishing the document is in any way harmful to the work of the 6man 
WG. Please send your opinions either on list or privately to me by 2016-10-06.

Thanks
Suresh

---

From: Philip Homburg <[email-masked]>
Date: Thu, 22 Sep 2016 11:01:25 +0200

>has been submitted through the Independent stream for publication.

I find this a rather confusing draft.

It seems to combine a number of ideas in a random way.

That starts in Section 2, where, at least to me, the scenarios appear in a
random order. For readability it would be nice if the most basic scenarios are
described first and gradually build up to more complex versions.

For me it helps to keep host behavior separate from router behavior. Trying
to think about all the complexity of hosts at the same time as thinking about
all the different ways to configure routers doesn't really help.

So it is best to focus on the host-router protocols and describe where they
are currently lacking.

Looking at the problem from a host point of view: source address selection is
to a large degree independent of next hop router selection. I.e., the
source address is selected first, and then with dest/src routing the source
is taken into account to select the next hop router.

I think it would help to make this split explicit in the draft. In simple
cases, source selection is almost trivial (two prefixes that are equivalent
from the perspective of the host), but next hop selection still requires
the source address.

In other cases, source address selection is complex, but doesn't really make
next hop selection more complex.

Based on this it is possible to define what information the host needs, both 
for source address selection and for next hop selection.

If I ignore source address selection for the moment, then in many cases
a host already has all the information it needs for dest/src routing.

Even in the redirect ping-pong case, the host can just extract the source
address from the copy of the original packet.

So in a lot of cases, there is no need to change bits on the wire, we just
need to redefine how hosts should behave.

Then what remains (as far as I know only the lack of a PIO option when a host
gets its address from DHCPv6) can be addressed.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 23 Sep 2016 03:10:28 +0000

Thanks for your comments Philip. I do agree with a lot of your comments but 
unlike the IETF stream where we have the possibility to get these addressed 
with extensive text changes, there are only five responses we can provide to 
the ISE for a conflict review request as described in RFC5742

    1. The IESG has concluded that there is no conflict between this
       document and IETF work.

    2. The IESG has concluded that this work is related to IETF work done
       in WG <X>, but this relationship does not prevent publishing.

    3. The IESG has concluded that publication could potentially disrupt
       the IETF work done in WG <X> and recommends not publishing the
       document at this time.

    4. The IESG has concluded that this document violates IETF procedures
       for <Y> and should therefore not be published without IETF review
       and IESG approval.

    5. The IESG has concluded that this document extends an IETF protocol
       in a way that requires IETF review and should therefore not be
       published without IETF review and IESG approval.

Regards
Suresh

---

From: Philip Homburg <[email-masked]>
Date: Fri, 23 Sep 2016 10:45:04 +0200

> Thanks for your comments
> Philip. I do agree with a lot of your comments but unlike the IETF
> stream where we have the possibility to get these addressed with
> extensive text changes, there are only five responses we can provide
> to the ISE for a conflict review request as described in RFC5742

It would be nice to have a good document in this area. Pity if it would be
published as is. 

>        in WG <X>, but this relationship does not prevent publishing.

But I guess it doesn't do any harm either.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Sep 2016 12:16:46 +0200 (CEST)

>       published without IETF review and IESG approval.

Interesting.

I have found over time that draft-sarikaya-6man-sadr-overview has been a 
useful document to ask people to read who have no idea about the SADR 
problem space.

It seems mostly to document ongoing (sometimes historical) work in a few 
WGs (references several expired drafts), but span several of them (MIF 
(now INTAREA), 6MAN, V6OPS), perhaps some other WG.

It's also "informational", which (afaik) lowers the bar for publication.

It has at least one old reference, for instance to 
https://tools.ietf.org/html/draft-ietf-homenet-hncp-10 which is now 
RFC7788. It also claims in 3.1 OSPF is used by HNCP, whereas RFC7788 
doesn't contain the word OSPF.

So my recommendation is that -11 shouldn't be published as-is because it's 
not accurate (which isn't one of the options above?). What to do if these 
problems are fixed in a -12 version, I don't know. I would like to see 
more review for accuracy before publication. I'm not saying this needs to 
be IETF-wide review, but of the options above, that's the only one that 
would fit.

If I didn't have to choose any of the options you listed, I'd say review 
and discussion in V6OPS and INTAREA, a few more revisions, and I'd support 
publication. But... I have little idea about IETF procedures and how these 
kinds of documents have been handled historically.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Sep 2016 09:50:24 +1200

Mikael,

Hat on as a member of (not a spokesperson for) the Independent
Stream Editorial Board, and intentionally *not* answering Suresh's
question:
On 23/09/2016 22:16, Mikael Abrahamsson wrote:
...
> It's also "informational", which (afaik) lowers the bar for publication.

RFCs in the Independent stream are always Informational.

> RFC7788.

The RFC Editor fixes such references.

> It also claims in 3.1 OSPF is used by HNCP, whereas RFC7788

Good catch. Tell the author and I'm sure he'll fix it.

> be IETF-wide review, but of the options above, that's the only one that 

No it doesn't, because that option is conditioned by "this document extends
an IETF protocol", which it clearly doesn't.

> kinds of documents have been handled historically.

6man already declined to publish this draft, so essentially it's nothing to
do with the IETF any more. I'm sure the author would still appreciate constructive
comments at this stage, but the document belongs to the Independent stream,
which is, er, independent.

Regards,
    Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 24 Sep 2016 04:20:49 +0000

Hi Philip and Mike,
   Thanks for your comments. I will pass your reviews onto Nevil (the ISE) 
for his consideration and see if we can get them addressed by the authors.

Regards
Suresh