Subject: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Wed, 09 Jan 2019 13:20:00 -0800

Spencer Dawkins has entered the following ballot position for
draft-ietf-v6ops-transition-ipv4aas-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm willing to believe that

   Since it is impossible to know prior to sale which transition
   mechanism a device will need over its lifetime, IPv6 Transition CE
   Router intended for the retail market MUST support all the IPv4aaS
   transition mechanisms supported by this document.  Service providers
   who specify feature sets for IPv6 Transition CE Router may specify a
   different set of features than those included in this document, for
   example supporting only some of the transition mechanisms enumerated
   in this document.

we can't do better than requiring all IPv6 Transition CE Routers to support all
five transition mechanisms listed in this document, but I am wondering if five
is hitting a natural law, or if someone is likely to come up with more
transition mechanisms (that the existing CE routers won't support because
they're already deployed).

But I trust the working group is doing its best ...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 09 Jan 2019 22:47:55 +0100

Hi Spencer,

I think the key point is understanding that all those transition mechanisms share a single data plane, code is already available and there are many "common" parts among them, etc.

Explaining that was the reason for section 7 (Code Considerations) and there are several Open Source implementations (OpenWRT and VPP, for example), and I know there are several vendors already using those for their own "implementations".

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Spencer Dawkins <[email-masked]>
Fecha: miércoles, 9 de enero de 2019, 22:20
Para: The IESG <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
Asunto: [v6ops] Spencer Dawkins' No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)

    

    

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 9 Jan 2019 16:05:16 -0600

Hi, Jordi,

On Wed, Jan 9, 2019 at 3:47 PM JORDI PALET MARTINEZ <
[email-masked]> wrote:

> Hi Spencer,
>
> I think the key point is understanding that all those transition
> mechanisms share a single data plane, code is already available and there
> are many "common" parts among them, etc.
>
> Explaining that was the reason for section 7 (Code Considerations) and
> there are several Open Source implementations (OpenWRT and VPP, for
> example), and I know there are several vendors already using those for
> their own "implementations".
>

Thanks for the background. It's helpful.

I noticed another AD mentioning combinatorial complexity in a ballot
position on another draft on this telechat, and wish we could could start
to push back on mandatory support for multiple mechanisms, but I do
remember enough about the history of IPv4/IPv6 transition and coexistence
that I'm not surprised this isn't the right draft to start that discussion
with!

Spencer

> Asunto: [v6ops] Spencer Dawkins' No Objection on
> draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)
>
>     Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
>