Subject: [mif] Experimental RFC ? Re: The DHCP Route - Default Route discussion

From: Arifumi Matsumoto <[email-masked]>
Date: Sat, 28 Jul 2012 00:57:00 +0900

Hi,

> Therefore the answer to your question is quite simple:
> It's dead, Jim.

so there were arguments for and against, and so there was no conclusion.

Then, why not publish it as an experimental document in IETF ?

And, then, why not find a supporter that takes this document back in
the standard track, just like the relation btw RFC 5006 and 6106.

Best regards,

2012/7/27 Tomek Mrugalski <[email-masked]>:
> On 12-07-25 17:07, Alexandru Petrescu wrote:
>> I wonder whether draft-ietf-mif-dhcpv6-route-option-04 is going to be
>> updated and how?
> Alex,
> I'm not aware of such plans. After Paris meeting I got the impression
> that MIF decided to not continue work on this particular draft, but
> chose to continue working on the problem, while not excluding DHCP as
> potential delivery mechanism. I must admit that such decision seems
> somewhat inconsistent IMHO. If the DHCP is a viable way to solve the
> problem, then why this work is abandoned? Or put it the other way
> around: if this approach is broken beyond repair, why bother to try
> another attempt with DHCP? My perception is that major objections raised
> were generic to the whole DHCP protocol, not those specific options
> ("you can't invalidate the data after server crash", "you don't have any
> means of immediately notifying client that don't support reconfigure").
>
> Obviously, the problem touches areas of many WGs, not just MIF.
> Therefore I hoped to receive some form of guidance from ADs after Paris,
> but sadly that hasn't materialized. At least according to my knowledge.
> Please do let me know if I have missed it.
>
> One of the major objections raised by opponents of the DHCP solution was
> default route configuration. At one point in time, it was considered if
> dropping the ability to configure default route would be a viable
> compromise. Sadly, such change would render the solution almost useless
> for MIF environment, so probably another adoption would be required. And
> there was no clear indication whether RA advocates would accept it in
> that form anyway, so the idea was promptly dropped.
>
> Brian's comment about defining both RA and DHCPv6 solutions with
> identical semantics seems valid. It would solve two major objections.
> First, it would provide a way to invalidate routes in case of router or
> DHCP server crash. Second, it would allow to immediately notify the node
> of any configuration changes (even those that don't support DHCPv6
> reconfigure mechanism). However, I doubt it would change minds of some
> RA advocates ("RA and nothing else" approach).
>
> Therefore the answer to your question is quite simple:
> It's dead, Jim.
>
>> In the mif agenda of the Vancouver meeting I do not see any
>> presentation about this topic.
> There won't be any.
>
> Cheers,
> Tomek
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Ted Lemon <[email-masked]>
Date: Sat, 28 Jul 2012 02:15:20 +0000

On Jul 27, 2012, at 11:57 AM, Arifumi Matsumoto wrote:
Then, why not publish it as an experimental document in IETF ?

The objection to the draft was that if any draft ever describes a route option for DHCP, the world will end.   So that's not going to get consensus.   This was in fact roughly the level of reasoning that went on during the discussion—many nightmare scenarios were described, assertions were made that these scenarios were inevitable, and on that basis the proposal had to be dropped.

This has happened every time one of these proposals has been advanced.   I don't see any reason to think that it will ever stop; consequently, there is no way that the IETF can ever gain consensus on this.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Sun, 29 Jul 2012 02:18:17 +0900

Hi,

2012/7/28 Ted Lemon <[email-masked]>:
> The objection to the draft was that if any draft ever describes a route
> option for DHCP, the world will end.   So that's not going to get consensus.
> This was in fact roughly the level of reasoning that went on during the
> discussion—many nightmare scenarios were described, assertions were made
> that these scenarios were inevitable, and on that basis the proposal had to
> be dropped.
>
> This has happened every time one of these proposals has been advanced.   I
> don't see any reason to think that it will ever stop; consequently, there is
> no way that the IETF can ever gain consensus on this.

After re-reading the minutes, I found nobody complains about publishing
this option as a standard track if its usage is limited to routers.

Isn't it overkill the whole usage of this option ?

---

From: Tomek Mrugalski <[email-masked]>
Date: Sun, 29 Jul 2012 02:03:48 -0700

On 12-07-28 04:15, Ted Lemon wrote:
> option for DHCP, the world will end.   So that's not going to get
My perception was similar, but as a co-author, I'm biased.

> consensus.   This was in fact roughly the level of reasoning that went
> on during the discussion—many nightmare scenarios were described,
> assertions were made that these scenarios were inevitable, and on that
> basis the proposal had to be dropped.
I was hoping for some guidelines from ADs, but it didn't materalize.

> This has happened every time one of these proposals has been advanced.  
> I don't see any reason to think that it will ever stop; consequently,
> there is no way that the IETF can ever gain consensus on this.
Section 4.2.3 of RFC2026 documents experimental publication process.
There's interesting section about going ahead with the experimental
publication, even if "the IESG considers that the document proposes
something that conflicts with, or is actually inimical to, an
established IETF effort, the document may still be published as an
Experimental or Informational RFC". A note about warning disclaimer
being added in such cases by IESG follows.

Perhaps a viable way forward would be to ask the most active opponents
to write a disclaimer section in which they could explain, why they
think this option and its deployment is a bad idea? It would be added to
the draft and then experimental publication path could be started?

Arifumi-san mentioned RFC5006. It defines DNS option for RA. It followed
exactly the same path that we are considering here.

Cheers,
Tomek

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Jul 2012 00:52:15 +0200

Will the meeting agenda contain an item about this topic?

(I asked privately a slot to present dhcp default route draft but no 
answer - neither refusal nor acceptance).

This is strange.

Alex