Subject: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 11 Jun 2017 10:39:46 +0200

Hi Barbara,

Regarding 5.1, Tore already explained it. Moreover, I’ve not changed that from what you have at your document RFC7084, so may be one of your co-authors added that text at some point and you didn’t realize it.

I think is pity that you come after 6 versions of this document, with a generic banning of it, while you had the opportunity to say so at any point or even in the Chicago meeting, and then we could have discussed then alternative ways to move on. It’s life, I take it and keep moving.

After a few private email exchanges and also Brian email, I think I got a different picture (even if I’m not totally convinced myself), of what we need. Basically, we need to go back to RFC6204 (which didn’t included transition at all) and even more NOT include IPv4 support at all. ISPs that need to deploy very very very simple IPv6-only networks for IPv6-only devices and apps and may be not supporting anything else than hosts (not clear about this at this point, see my latest email to Brian). And then another document for a more “realistic” CE which allows cascading routers and hosts that may need IPv4 transition support.

Do you think you will agree on that?

Stay tuned, I’m trying my best to have a draft of both documents today. Then we can call for a poll to the WG about that …

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 5 de junio de 2017, 18:28
Para: "[email-masked]" <[email-masked]>
Asunto: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02

    I've reviewed draft-ietf-v6ops-rfc7084-bis-02 and these are my comments.
    
    General: While I support providing CE router vendors with information on IPv6 transition technologies, I think that an RFC7084-bis is not the right way to do this, and this particular draft tries to do more than just add those transition technologies; some of these additional items I don't support. I think this draft weakens RFC7084 by adding such a lengthy list of transition technologies and adding other requirements and text that are not broadly useful. I would prefer a stand-alone document that described just the transition technologies.
    
    Specific comments:
    3. Usage scenarios
    I don't find this new and very lengthy section to be more useful than the existing simple statement of "This document defines basic IPv6 features for a residential or small-office router". I question the need to expand the original simple sentence into this lengthy section (6 bullets and 8 paragraphs).
    I don't understand what "exporting IPv6 services" means. I don't understand why discussion of IPv4 NAT configuration is particularly relevant as part of preamble discussion for the requirements in this draft.
    
    5.1 General Requirements, G-5
    I don't understand what additional functionality G-5 provides that was not covered by G-4. G-5 seems redundant.
    
    5.5.  IPv4 Multicast Support
    I disagree with recommending this functionality in all CE Routers. It is very definitely not necessary in a basic CE router. 
    
    8. ANNEX A: Code Considerations
    I disagree with much of the editorializing and assumptions made in this section and would prefer to see this section removed. Every CE Router vendor (and ISP) must decide for themselves whether using open source code is appropriate for them. Licenses must be carefully examined, as some license can be very problematic for vendors and for ISPs that ship the vendor's products. Claiming that existence of open source code means cost of developing code is negligible ["negligent" is probably not the intended word] is unsubstantiated and therefore inappropriate. Claiming that "only integration and testing cost may become a minor issue" is also inaccurate and inappropriate. The more code a CE router has, the more testing that has to be done, and this cannot be assumed to be minor. It also creates usability and support issues, if the functionality is presented via the UI. Every additional feature adds cost to these very low margin devices.
    
    Barbara
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

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

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: [email-masked]
Date: Sun, 11 Jun 2017 19:43:25 +0200

> On 11 Jun 2017, at 10:39, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Barbara,
> 

If you look back in the archives you will see that several of us have been saying that since this draft came out.

> After a few private email exchanges and also Brian email, I think I got a different picture (even if I’m not totally convinced myself), of what we need. Basically, we need to go back to RFC6204 (wh…

I'd be happy to add HNCP and routing support to 6204bis.

Then move what you have added in 7084bis into a separate document "Basic IPv4 CE requirements for every IPv4 sunsetting mechanism ever invented" ;-)

Cheers,
Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 11 Jun 2017 20:58:38 +0200

Hi Ole,

When we started this discussion, I agree that was some folks that showed their contrary opinions to proceed that way.

However, those contrary opinions ceased before the Chicago meeting, and in the meeting itself, it was clear that there was an outstanding support, and in fact that was the reason it was adopted as a WG item.

Never mind, see my next email on this.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: domingo, 11 de junio de 2017, 19:43
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] comments on draft-ietf-v6ops-rfc7084-bis-02

    

    
    Cheers,
    Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 12 Jun 2017 13:02:43 +0000

> Basically, we need to go back to RFC6204 (which didn’t included transition at
> all) and even more NOT include IPv4 support at all

RFC 7084 added requirements for MAX SOL RT (RFC 7083) to RFC 6204. In fact, this one requirement was responsible for delaying publication of RFC 7084 by almost a year. It was such an important requirement that everyone agreed it was better to wait for this than to publish without it.
There were also a few other changes to RFC 6204 requirements, but that was by far the most important and most needed. 
Therefore, I do not support reverting to RFC 6204. 
When Hans Liu was distinguishing between support for RFC 6204 and RFC 7084, I'm hoping he didn't mean that CE Router vendors aren't supporting MAX SOL RT. I think MAX SOL RT did get added to the UNH-IOL IPv6 Ready CE Router tests. I'm hoping he just meant that many CE Routers don't support any transition technologies.

The "Transition Technologies Support" section that was added was done with purely "optional" language. There is not a single mandatory transition technology in RFC 7084. A CE Router can be 100% compliant with RFC 7084 and support no transition technologies.

I'm perfectly happy with pulling the entire "Transition Technologies Support" section out of a RFC 7084-bis.
Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 12 Jun 2017 15:14:26 +0200

Hi Barbara,

Agree, I was not considering dropping RFC7083 at all.

In RFC7084-bis I conserved the "optional" language status for the transition, so I still think this is the correct way forward. Despite that, I think if you look to either

1) https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis2/?include_text=1

or

2) https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis4-hncp/?include_text=1

You will be fine, as in both cases transition support has been completely removed and that will be a separated document.

Difference among both of them:

1) Is an “IPv6-only” CE, very minimalistic approach, for simple networks, may be even “smaller” ones that a home network.
2) Is an IPv6 CE, “dual-stack” support, including HNCP.

Somehow both of them are in the “middle way” between 6204 and 7084.

Of course, other combinations are possible … 

Regards,
Jordi