Subject: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

From: Ole Troan <[email-masked]>
Date: Mon, 29 Apr 2019 12:02:36 +0200

At the 6man meeting at IETF 104 in Prague there was support to close the working group last call and advance 
draft-ietf-6man-ipv6only-flag-05 to the IESG.

This call is to confirm that decision on the mailing list.

Please give objections and comments to this decision to the mailing list, by 2019-05-13.

Best regards,
Ole, 6man co-chair

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 29 Apr 2019 12:03:27 +0100

> Please give objections and comments to this decision to the mailing

Ole,

There have been extensive objections to this draft during the various 
discussions on the WG, during which a wide variety of fundamental 
problems were raised which were either left unaddressed or were only 
partially addressed.  Some relatively minor edits were introduced in 
-05, and I believe only a single comment was made about -05 on the 
mailing list, which incidentally did not indicate support.

Very few of the objections I've raised over the last 18 months have 
actually been addressed to the point that I'm happy with them.  I didn't 
raise them again in -05 because I assumed that they were still 
outstanding, as they were neither addressed adequately on the mailing 
list or in the draft itself.

Last September, the document moved to WGLC without prior notice to the 
mailing list that this would happen.  This was a surprising move, given 
the extent of the objections over the lifetime of the document, and the 
minimal scope of the changes in -02.  It was remarkable was that the 
scale of the historical disagreement about this document was ignored.

Now again, after another period of quiet and again, after only minimal 
changes, you're proposing moving the document forward.

So, is this ID proceeding on a point of procedure at this point?  I.e. 
is the the slate going to be wiped clean every time an update is issued, 
no matter how minor, and all previous objections are automatically 
invalidated?

If so, I'm inclined to think that this is bordering on abuse of process, 
but if it's the case, please let us know and I'll bring up all the 
previous issues that haven't been addressed.  Again.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Mon, 29 Apr 2019 13:24:48 +0200

>Please give objections and comments to this decision to the mailing list, by 2

This draft should have been killed a long time ago. From the start, this
draft tried to push one particular solution instead finding the best way to 
solve an actual problem.

---

From: Ole Troan <[email-masked]>
Date: Mon, 29 Apr 2019 14:01:43 +0200

Hi Nick,

Thanks for your comments.

> On 29 Apr 2019, at 13:03, Nick Hilliard <[email-masked]> wrote:
> 
>> At the 6man meeting at IETF 104 in Prague there was support to close
>> the working group last call and advance draft-ietf-6man-ipv6only-flag-05 to the IESG.
> There have been extensive objections to this draft during the various discussions on the WG, during which a wide variety of fundamental problems were raised which were either left unaddressed or were only partially addressed.  Some relatively minor edits were introduced in -05, and I believe only a single comment was made about -05 on the mailing list, which incidentally did not indicate support.
> 
> Very few of the objections I've raised over the last 18 months have actually been addressed to the point that I'm happy with them.  I didn't raise them again in -05 because I assumed that they were still outstanding, as they were neither addressed adequately on the mailing list or in the draft itself.
> 
> Last September, the document moved to WGLC without prior notice to the mailing list that this would happen.  This was a surprising move, given the extent of the objections over the lifetime of the document, and the minimal scope of the changes in -02.  It was remarkable was that the scale of the historical disagreement about this document was ignored.
> 
> Now again, after another period of quiet and again, after only minimal changes, you're proposing moving the document forward.
> 
> So, is this ID proceeding on a point of procedure at this point?  I.e. is the the slate going to be wiped clean every time an update is issued, no matter how minor, and all previous objections are automatically invalidated?

Yes, I think that's a somewhat correct reading of working group process.
If I read you correctly, you don't think there is anything that can be done with this document to fix those objections. And that the only outcome is to retire the document?

> If so, I'm inclined to think that this is bordering on abuse of process, but if it's the case, please let us know and I'll bring up all the previous issues that haven't been addressed.  Again.

Here are the minutes for the IETF 104 6man meeting on the topic.
I was also surprised by the lack of resistance in the room. Therefore the extra confirmation on the mailing list.

IPv6 Router Advertisement IPv6-Only Flag,  draft-ietf-6man-ipv6only-flag,
Bob Hinden, 15 min.   
--------------------------------------------------------------

Bob Hinden presents:
https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessa-ipv6-ra-ipv6-only-flag-01

Jen Linkova: The document is nice and ready.  Just one comment.  I had
the strange idea of using it in a dual-stacked network.  There is a use
case for this, moving IPv6-capable devices to use IPv6 only.  Can we
relax section 3 to a SHOULD ? 

Bob: I'm not sure. We tried to make it support different environments but
need to see. 

Tim Chown: I would assume legacy devices wouldn't understand the flag
anyway, so it should work. 

Bob: That's a good point. 

Jen Linkova:  That's the whole idea.  New devices will be moved to IPv6
only and old devices will keep IPv4.  This is a suggestion so that they
move to IPv6, and move to IPV6 as much as possible. 

Bob: That's not the way we were thinking about it, but I think it could
be used for that. We could add some text. But it is an IPv6-only link and 
we want to turn off background chatter. 

There were no more questions nor comments.

Ole: Thinking loudly. Do we want to do a further call for this to get it
advanced ?  Let's do a call on that. 

Hum: There were many hums in favor of advancing this document to the
IESG.   No humming was audible in opposition.   Ole will confirm on the
mailing list.

Cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Apr 2019 14:01:27 -0400

I am a supporter of the operational goal of signaling ipv6only networks.
I am generally agnostic as to the bits-on-the-wire mechanism.  Based upon
objections, I am uncertain if the mechanism (a flag in the IANA-RF) is
justified, given the paupacity of the flags involved.   I think that the
proposal would be easier to accept if it was an RA Option.

I think that the objectors have been rather few, have been unreasonably loud
and very repetitive.  I think that the objections are mostly in the rough,
however.   I have not heard, an https://tools.ietf.org/html/rfc7282 Section 4
objection of the form "Option A does not work in situation X".

I thought I heard that a number of host stack implementors would be unwilling
to implement this.  I would like to have confirmation of this.

I would ask Old to (a)-recruit someone outside else for help, since Bob Hinden
is an author, and (b) to go through RFC7282 sections 4, 5 and 6 and
write some statements of the form found there.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Philip Homburg <[email-masked]>
Date: Mon, 29 Apr 2019 20:31:30 +0200

>and very repetitive.  

Here is the opinion of operators at the RIPE meeting last fall:
https://ripe77.ripe.net/archives/video/2335/
Reactions at 5:38

Of course in true tradition of the IETF, operator input is mostly ignored.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 29 Apr 2019 21:25:11 +0100

Ole Troan wrote on 29/04/2019 13:01:
>> So, is this ID proceeding on a point of procedure at this point? 
>> I.e. is the the slate going to be wiped clean every time an update 
>> is issued, no matter how minor, and all previous objections are 
>> automatically invalidated?
> 

Ok.  Frustrating for all.

> If I read you correctly, you don't think there is anything that can 
> be done with this document to fix those objections. And that the
> only outcome is to retire the document?

That would be the gist of it, yeah.

> I was also surprised by the lack of resistance in the room. Therefore
> the extra confirmation on the mailing list.

Lots of us can't get to ietf meetings. :-(

Nick

---

From: Sander Steffann <[email-masked]>
Date: Mon, 29 Apr 2019 23:25:25 +0200

Hi Ole,

> Please give objections and comments to this decision to the mailing list, by 2019-05-13.

Philip posted the link to the archive of the RIPE meeting. Those objections still stand.

And on behalf of myself as an operator: I see very little advantage to this draft, and many operational problems having to deal with it. As I have stated previously adding complexity to a protocol should be done very carefully. Every flag or option that we introduce carries a cost. In implementation of course, but also in training, brain capacity, extra debugging time needed to check/verify/rule out/etc whether that flag/option is present or not, whether it is handled correctly or not etc etc etc.

A quote that we should keep in mind, as this is something that I feel we have failed at with IPv6: "Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away"

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 29 Apr 2019 22:35:11 +0100

Ole,

All the comments in this summary email still hold:

https://mailarchive.ietf.org/arch/msg/ipv6/lZ6ScXew_7q-BeVOK8L1dHEpVAc

Is a reference to the URL considered to be a valid objection, or do the 
contents need to be pasted into an email to be considered valid?

Nick

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Apr 2019 10:12:19 +1000

> https://ripe77.ripe.net/archives/video/2335/

How many have read the draft?

Should they be making judgement and we accept judgement based on a short
and single presentation by somebody who has a bias against it?

Have they seen a presentation from somebody who is for it?

> Of course in true tradition of the IETF, operator input is mostly ignored.

I think this is approaching an appeal to authority.

>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Apr 2019 11:48:36 +1000

> That would be the gist of it, yeah.

"Very few of the objections I've raised over the last 18 months have
actually been addressed to the point that I'm happy with them.  I didn't
raise them again in -05 because I assumed that they were still
outstanding, as they were neither addressed adequately on the mailing
list or in the draft itself."

You were never going to be happy with them. You've been arguing in bad faith.

---

From: Fred Baker <[email-masked]>
Date: Mon, 29 Apr 2019 19:45:13 -0700

> On Apr 29, 2019, at 4:03 AM, Nick Hilliard <[email-masked]> wrote:
> 
> There have been extensive objections to this draft during the various discussions on the WG, during which a wide variety of fundamental problems were raised which were either left unaddressed or were only partially addressed.

My objections, and related objections by others, have been summarily dismissed.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Apr 2019 16:20:21 +1200

Sander,

I agree that we should take notice of operators' opinions. But a live video recording is not the best way to convey them. I also agree that every added feature comes with an operational cost, as well as the intended benefit. However, general arguments like this are not actionable.

Whatever Nick says, we have done our best to update the draft in response to every objection that has been raised. He's entitled not to agree with our updates, of course. But absent new actionable comments, there's nothing the authors can do at this point.

I agree that having a neutral party help Ole evaluate the consensus would be good.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Apr 2019 16:47:55 +1200

Fred,

> My objections, and related objections by others, have been summarily dismissed.

I've just read through about eight messages about this draft from you. I don't think your comment is quite fair. You've objected to the basic model (a given IPv6 router says "I don't route IPv4"), I assume because it doesn't convey authoritatively that there is no other IPv4 router on the link. As the draft has evolved, it's stated more and more precisely that this is the intended semantic and how hosts SHOULD interpret it. It's also stated more and more precisely what the network manager SHOULD do. But indeed, we haven't changed the underlying semantic that a single router can only state that it doesn't itself route IPv4. That is fundamental, since we are not proposing a command-and-control solution.

We've also expanded the security considerations considerably, another aspect that you mentioned.

And we didn't mention you in the Acknowledgments, which is a mistake, sorry.

Regards
   Brian Carpenter

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Apr 2019 10:16:17 +0200

Philip,

> Of course in true tradition of the IETF, operator input is mostly ignored.

I am not sure whether this is a sarcasm.  If it is, this is what I think:

For me, Operator input is highly valuable in many contexts, since the 
Internet sheer size is mostly covered by Network Operators.  But not in 
all contexts.

There are IPv6 contexts in which there are no operators in the ISP 
sense.  Yet there are people who run the networks in these ISP-less IPv6 
contexts.

For example, there are very little, if incumbent, operators in vehicular 
networks.  Another example is the IETF network where the operator is, 
err, I dont know, but surely not an ISP.

In that sense, I do appreciate if IETF has tradition that takes 
operator's input as much as other input.

This opinion is about operators input and IPv6.  This opinion is not 
about this draft.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 30 Apr 2019 10:15:03 +0100

> You were never going to be happy with them. You've been arguing in bad faith.

Bad faith implies intent to deceive.

I've been up-front all along that the draft is unfixable in principle 
and the concerns I raised consistently reflected this.  In particular, 
it's ok to raise concerns which are legitimate, but you feel cannot be 
resolved.

Nick

---

From: Brian Carpenter <[email-masked]>
Date: Tue, 30 Apr 2019 22:45:24 +1200

FWIW I agree that Nick has been arguing consistently. The authors got that
he doesn't like the idea :)

Regards
    Brian
    (via tiny screen & keyboard)

---

From: Sander Steffann <[email-masked]>
Date: Tue, 30 Apr 2019 13:17:35 +0200

Hello Brian

> FWIW I agree that Nick has been arguing consistently. The authors got that he doesn't like the idea :)

And Nick is not alone. I consider this draft to be harmful and oppose it's fundamental idea. There is no rule that bad drafts can't be opposed because we can't suggest text to "fix" our objections.

You asked for something actionable: withdraw it. Its cost far outweigh its benefits.

Cheers,
Sander

---

From: Tim Chown <[email-masked]>
Date: Tue, 30 Apr 2019 12:47:20 +0000

> On 30 Apr 2019, at 12:17, Sander Steffann <[email-masked]> wrote:
> 
> Hello Brian
> 

I'm quite neutral on this flag option, but is this something that could soon be progressed via draft-troan-6man-universal-ra-option rather than adding it to the IANA IPv6 ND RA registry?  I don't see mention of this in the ipv6only-flag draft.

Tim

---

From: Sander Steffann <[email-masked]>
Date: Tue, 30 Apr 2019 16:33:15 +0200

Hi Mark,

> Should they be making judgement and we accept judgement based on a short and single presentation by somebody who has a bias against it?

I gave that presentation after discussing it with Ole to provide some sort of feedback on this draft from the operator community. I presented both the benefits and the dangers. Yes, I am personally against this draft, but I gave an honest representation of both sides.

I haven't seen any active outreach from the IETF, and the operators who do speak up here are often ignored as "single voices" that don't represent the operators, and when someone goes out and tries to get broader feedback its biased. All of this makes it very difficult for operators to deal with the IETF, and I know many who have given up.

If you have a better way of getting a feel for operator support I am all ears.

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 May 2019 08:48:23 +1200

> I'm quite neutral on this flag option, but is this something that could soon be progressed via draft-troan-6man-universal-ra-option rather than adding it to the IANA IPv6 ND RA registry?  I don't s…

No, but to be honest it's a secondary question. If the idea is fundamentally bad, encoding it as a universal RA option rather than a single bit doesn't really change anything.

So I'd rather understand *why* the costs outweigh the benefits. One more thing for an operator to configure and check in each first-hop router, vs reduction of pointless traffic on updated hosts. I'm not sure how to make that an objective rather than a subjective trade-off.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 30 Apr 2019 22:55:40 +0100

Brian E Carpenter wrote on 30/04/2019 21:48:
> So I'd rather understand *why* the costs outweigh the benefits. One 
> more thing for an operator to configure and check in each first-hop 
> router, vs reduction of pointless traffic on updated hosts. I'm not 
> sure how to make that an objective rather than a subjective 
> trade-off.
Hi Brian,

Email is being a serious barrier to communication in this discussion :-(

The problem statement just isn't there:

https://mailarchive.ietf.org/arch/msg/ipv6/GCGYTXhg0V9mQBrcO7zhC5wtnp0

The contents of this email largely still apply to the current text in -05.

The cost is too high:

https://mailarchive.ietf.org/arch/msg/ipv6/NIJ194PI8CLkuZT8U_jKEOY01QI

You've shown no analysis of realistic use cases.

For something standards track, and this far down the protocol stack and 
with such a large security considerations section, the proposal ought to 
be thoroughly compelling for a wide variety of deployment scenarios, but 
it isn't.  There are better ways of skinning this cat.

Nick