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

[Mikael Abrahamsson <[e-mail]>]

On Fri, 23 Sep 2016, Suresh Krishnan wrote:

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

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: [e-mail]