Subject: [MBONED] draft-tsou-mboned-multrans-addr-acquisition

From: Leonard Giuliano <[email-masked]>
Date: Thu, 5 Jul 2012 08:36:12 -0700

Regarding the question of adopting 
draft-tsou-mboned-multrans-addr-acquisition as a WG document, and with 
respect to the larger questions about Multrans work in Mboned, we have 
reached the following conclusion:

- The WG's goal is to standardize only technologies that will see 
significant deployment

- The WG is currently engaged in a discussion regarding the uses-cases 
enumerated in draft-ietf-mboned-v4v6-mcast-ps. WG participants agreed that 
both of the "dual-stack" use cases are likely to see deployment. However, 
the WG has yet to demonstrate sufficient motivation for any solution other 
than "unicast tunneling" in scenarios when the problem network or network 
segment is not both dual stack and multicast enabled. In order to 
demonstrate sufficient motivation, the proponents should explain why 
unicast tunneling until dual stack can be deployed is not a viable 
solution.

- Until the discussion mentioned above is resolved, 
draft-ietf-mboned-v4v6-mcast-ps cannot progress to WG last call

- Because all MULTRANS documents should normatively reference 
draft-ietf-mboned-v4v6-mcast-ps, they cannot progress to WG last call 
until draft-ietf-mboned-v4v6-mcast-ps progresses to WG last call

- However, the WG may accept other MULTRANS work, with the understanding 
that it may have to change pending the outcome of discussions mentioned 
above.

- Therefore, draft-tsou-mboned-multrans-addr-acquisition can be accepted 
as a WG document, given the above-mentioned caveats and the support 
expressed by the WG to adopt.  The authors may resubmit this doc as 
draft-mboned -...

MBONED Chairs

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Jul 2012 12:15:21 -0400

You are taking a rather old-fashioned view of IPv6 transition. The IETF 
held for at least 15 years that dual stack was the way to achieve it, 
but dual stack didn't happen. Behave and Softwires have developed 
alternatives, which operators are deploying. You are ignoring reality 
with your present position.

On 05/07/2012 11:36 AM, Leonard Giuliano wrote:
> enumerated in draft-ietf-mboned-v4v6-mcast-ps. WG participants agreed
> that both of the "dual-stack" use cases are likely to see deployment.
> However, the WG has yet to demonstrate sufficient motivation for any
> solution other than "unicast tunneling" in scenarios when the problem
> network or network segment is not both dual stack and multicast enabled.
> In order to demonstrate sufficient motivation, the proponents should
> explain why unicast tunneling until dual stack can be deployed is not a
> viable solution.
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 9 Jul 2012 13:24:04 -0700

If it is demonstrated that other use cases are likely to be deployed for 
mcast, then the WG will consider those.  

We simply want to focus our efforts on those use cases that are likely to 
deployed for mcast, not every theoretical permutation of cases.

On Thu, 5 Jul 2012, Tom Taylor wrote:

-) You are taking a rather old-fashioned view of IPv6 transition. The IETF held
-) for at least 15 years that dual stack was the way to achieve it, but dual
-) stack didn't happen. Behave and Softwires have developed alternatives, which
-) operators are deploying. You are ignoring reality with your present position.
-) 
-) On 05/07/2012 11:36 AM, Leonard Giuliano wrote:
-) > 
-) > Regarding the question of adopting
-) > draft-tsou-mboned-multrans-addr-acquisition as a WG document, and with
-) > respect to the larger questions about Multrans work in Mboned, we have
-) > reached the following conclusion:
-) > 
-) > - The WG's goal is to standardize only technologies that will see
-) > significant deployment
-) > 
-) > - The WG is currently engaged in a discussion regarding the uses-cases
-) > enumerated in draft-ietf-mboned-v4v6-mcast-ps. WG participants agreed
-) > that both of the "dual-stack" use cases are likely to see deployment.
-) > However, the WG has yet to demonstrate sufficient motivation for any
-) > solution other than "unicast tunneling" in scenarios when the problem
-) > network or network segment is not both dual stack and multicast enabled.
-) > In order to demonstrate sufficient motivation, the proponents should
-) > explain why unicast tunneling until dual stack can be deployed is not a
-) > viable solution.
-) > 
-) > - Until the discussion mentioned above is resolved,
-) > draft-ietf-mboned-v4v6-mcast-ps cannot progress to WG last call
-) > 
-) > - Because all MULTRANS documents should normatively reference
-) > draft-ietf-mboned-v4v6-mcast-ps, they cannot progress to WG last call
-) > until draft-ietf-mboned-v4v6-mcast-ps progresses to WG last call
-) > 
-) > - However, the WG may accept other MULTRANS work, with the understanding
-) > that it may have to change pending the outcome of discussions mentioned
-) > above.
-) > 
-) > - Therefore, draft-tsou-mboned-multrans-addr-acquisition can be accepted
-) > as a WG document, given the above-mentioned caveats and the support
-) > expressed by the WG to adopt.  The authors may resubmit this doc as
-) > draft-mboned -...
-) > 
-) > MBONED Chairs
-) > _______________________________________________
-) > MBONED mailing list
-) > [email-masked]
-) > https://www.ietf.org/mailman/listinfo/mboned
-) > 
-)