Subject: Usage of services without IPv6 Support

From: Fernando Frediani <[email-masked]>
Date: Sat, 18 Apr 2020 00:10:43 -0300

Hello all

I want to call attention to a open wound. Some people may feel 
uncomfortable about the content of this email but I can assure I come 
with good intentions.

Recently I got to know that a 6man meeting ironically was conducted via 
Webex Videoconferencing tool which does not have IPv6 support. Other 
tools used by IETF like GitHub also don't have and in this case is even 
worst because there are several alternatives with IPv6 support as 
GitLab, Bitbucket or even a self-hosted option.

I want to talk about some points like value and productivity.
How can IETF that standardizes IPv6 can accept keep using any SaaS 
products that don't yet have IPv6 support ? How is it not prepared to 
eat its own dog food ? Even if the service is given for free it should 
be refused as in my view IETF should always give the example worldwide 
and say: "We thank your offer, but it is more important to us give the 
example about our fundamental building blocks."
Some other questions that are worth put are: "Does it really have to be 
*that* specific tool that doesn't have IPv6 support, or could we live 
without this and that specific feature and at the end of the day doing 
that same work we intended to ?"

I feel sometimes people are too stick to certain tools that are not 
prepared to let them go, even above values. Some may have a endless 
to-do list and just want to get things out of their way without much 
consideration to these points. Both in my view are bad.

I do understand that sometimes it is difficult to find a proper tool 
that will do the job, but unless we are talking about something rare or 
unique and in that case *really* there is no other choice, I believe 
more effort should to be put into using tools that support IPv6. Perhaps 
even an in-house hosted solution should be considered. They may not have 
all the features but may be able to do the job until some SaaS can feel 
incentivized to get proper IPv6 support and differentiate themselves.
If we were talking about a private company perhaps this could be more 
loose, but we are talking about IETF. Values should always prevail and 
give the example about IPv6 usage should always be among the list of 
Priorities number 0.

Over the years I see companies giving all sort of excuses about not 
having IPv6 on their products. "This plugin"," that component that 
doesn't have it", "Nobody asked for yet" (this is the worst), "My 
provider which uses component XPTO has promised me that for next year", 
etc. Very little are dispose to change suppliers to try get things 
working and helping give the example. I even guess that sometimes this 
may be a reliever to some people so they always have an excuse on the 
pocket. Believe it or not but we are in 2020 and there are new products 
coming out to production without proper IPv6 support, including and 
mainly SaaS products. How come this can be considered a normal thing at 
current times ?

Sometimes I hear from people: "Well, it has passed 20 years and we still 
have trouble with IPv6 deployments". Of course we do, people a unwilling 
to change even small bits of their way of doing things, get out of their 
comfort zones and start to require IPv6 as mandatory to providers and 
SaaS services.
And even when IETF doesn't give the example how are we suppose to ask 
people to do the right thing about it and for the survival of the 
Internet for the next decades ?

Shall we do the right thing and put values above other priorities going 
forward ?

Best regards
Fernando

---

From: Michael Richardson <[email-masked]>
Date: Sat, 18 Apr 2020 21:58:56 -0400

I hear you, and I agree.

I have been asking questions for about 6 years about the webex which was
provided "free", which nicely means that it never went through an RFP.
That it officially doesn't support the desktops that a lot of IETFs use.
That it has no IPv6.

github access at least, NAT64s relatively easily, but that also means that
there is really no excuse for not having native access.
I don't know if I have tried webex by NAT64.

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Apr 2020 23:05:53 -0300

Hello, Fernando,

> GitLab, Bitbucket or even a self-hosted option.
[...]
> Shall we do the right thing and put values above other priorities going 

Thanks for posting this.

I essentially share the same concerns as you.In the specific case of 
webex for the recent interim meetings, I would probably be more flexible 
(when it comes to the recent interim meetings)  since there was a lot of 
"on the fly" planning to deal with the contingency of COVID-19. -- and, 
as far as I understand,use of Webex has not been formalized in any way 
(i.e., nothing prevents us from using something else for the next IETF 
or interim meetings).

When it comes to GitHub, there seems to be more formalized use of it 
(there's even a WG), and, as you correctly note, given the many 
alternative options it seems kind of hard to back a decision to use it.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Frediani <[email-masked]>
Date: Sun, 19 Apr 2020 00:43:32 -0300

Sure Fernando
Certainly we all understand that recent times and the need to adapt to 
it in order to keep going.

But long term the main thing I believe must be the the mindset, to be 
committed to require IPv6 support on *all possible SaaS solutions* used 
within IETF, specially where there are well known alternatives.
As mentioned, sometimes people are just used to an specific tools 
because some specific feature or way of using and try to make that is 
'really' necessary, but if you look it better it isn't and it's probably 
perfectly fine let it go.

Overall the most important is to have the will to give the example on 
all possible opportunities without hesitation. This not only gives 
everybody a good example but also helps to push vendors to perhaps think 
about when an organization like IETF denies the use of their services 
due to the lack of IPv6. How long more are we going to keep accepting 
all sort of excuses and pretending it is going to happen soon ?

Productivity is certainly important, but values are above.

Regards
Fernando

On 18/04/2020 23:05, Fernando Gont wrote:
>> Recently I got to know that a 6man meeting ironically was conducted 
>> via Webex Videoconferencing tool which does not have IPv6 support. 
>> Other tools used by IETF like GitHub also don't have and in this case 
>> is even worst because there are several alternatives with IPv6 
>> support as GitLab, Bitbucket or even a self-hosted option.
> [...]
>> Shall we do the right thing and put values above other priorities 
>> going forward ?
>
> Thanks for posting this.
>
> webex for the recent interim meetings, I would probably be more 
> flexible (when it comes to the recent interim meetings)  since there 
> was a lot of "on the fly" planning to deal with the contingency of 
> COVID-19. -- and, as far as I understand,use of Webex has not been 
> formalized in any way (i.e., nothing prevents us from using something 
> else for the next IETF or interim meetings).
>

---

From: Alejandro Acosta <[email-masked]>
Date: Sun, 19 Apr 2020 00:28:31 -0400

Hello Fernando,

  I do no have much too say, just that I agree with you 100%. I hope
your email is received with the good intention I know you sent it.

Alejandro,

On 4/17/20 11:10 PM, Fernando Frediani wrote:
> is even worst because there are several alternatives with IPv6 support
> as GitLab, Bitbucket or even a self-hosted option.
>
> Some other questions that are worth put are: "Does it really have to
> be *that* specific tool that doesn't have IPv6 support, or could we
> live without this and that specific feature and at the end of the day
> doing that same work we intended to ?"
>
> that will do the job, but unless we are talking about something rare
> or unique and in that case *really* there is no other choice, I
> believe more effort should to be put into using tools that support
> IPv6. Perhaps even an in-house hosted solution should be considered.
> They may not have all the features but may be able to do the job until
> some SaaS can feel incentivized to get proper IPv6 support and
> differentiate themselves.
> provider which uses component XPTO has promised me that for next
> year", etc. Very little are dispose to change suppliers to try get
> things working and helping give the example. I even guess that
> sometimes this may be a reliever to some people so they always have an
> excuse on the pocket. Believe it or not but we are in 2020 and there
> are new products coming out to production without proper IPv6 support,
> including and mainly SaaS products. How come this can be considered a
> normal thing at current times ?
>
> Sometimes I hear from people: "Well, it has passed 20 years and we
> still have trouble with IPv6 deployments". Of course we do, people a
> unwilling to change even small bits of their way of doing things, get
> out of their comfort zones and start to require IPv6 as mandatory to
> providers and SaaS services.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 19 Apr 2020 06:44:14 +0200

On 2020-04-18, at 05:10, Fernando Frediani <[email-masked]> wrote:
> 
> a 6man meeting ironically was conducted via Webex Videoconferencing tool which does not have IPv6 support

Worse, I'm sometimes forced to join these meetings with a Bluetooth headset that doesn’t do IP at all.

Not wanting to belittle your quite serious point.

Sometimes the market makes us choose flip-flops instead of proper shoes.

Grüße, Carsten

---

From: Fernando Gont <[email-masked]>
Date: Sun, 19 Apr 2020 01:40:50 -0300

> I don't know if I have tried webex by NAT64.

NAT64 still means IPv4-only services.

Thanks,

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Apr 2020 10:19:54 +0200

Hi Fernando, all,

Fully agree with you.

I must say that Webex was an emergency solution for the Covid-19 situation for an on-line meeting instead of the Vancouver one (our usual tool for that is Meetecho, but probably it was not obvious if it can support so many participants, and not designed for not having a "local" venue).

However, there is NO excuse for GitHub, and we, as a community, especially our leadership, shall be ashamed of using it, whilst simply a self-hosted solution could change that aspect.

(I heard several times that GitHub is working on the IPv6 support, but it has been long time since that ...)

Regards,
Jordi
@jordipalet

El 18/4/20 5:11, "ietf en nombre de Fernando Frediani" <[email-masked] en nombre de [email-masked]> escribió:

    Hello all

    Best regards
    Fernando

**********************************************
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: "Bron Gondwana" <[email-masked]>
Date: Sun, 19 Apr 2020 23:11:09 +1000

> uncomfortable about the content of this email but I can assure I come 

With likewise good intentions I present:

https://www.theguardian.com/cities/2018/oct/05/desire-paths-the-illicit-trails-that-defy-the-urban-planners

A pathway that people desire to follow has no need to shame people for not choosing it.

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Fernando Frediani <[email-masked]>
Date: Sun, 19 Apr 2020 12:53:28 -0300

Thanks Jordi

So, can we formally request a review to the WG and people responsible 
for choosing these SaaS services in favor or some with IPv6 support ?

Can we start with: https://datatracker.ietf.org/wg/git/about/ ? What 
type of unique thing GitHub has that justifies continuing using it in 
detriment to other SaaS that already have full IPv6 support ?

Then what about WebEx, is it something with IETF LLC ?

Regards
Fernando

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 19 Apr 2020 18:03:49 +0200

On 2020-04-19, at 17:53, Fernando Frediani <[email-masked]> wrote:
> 
> Can we start with: https://datatracker.ietf.org/wg/git/about/ ? What type of unique thing GitHub has that justifies continuing using it in detriment to other SaaS that already have full IPv6 support ?

Github has an audience that nobody else has.

If the objective of the github repo is to open communication lines to actual developers; these are overwhelmingly on github; using another service just misses the mark.

For other projects, gitlab etc. work well, too, but do require some additional learning for people who work on more than one project at the time.  There is no institutional bias against those services; I have participated in IETF-related projects both on gitlab and on bitbucket (even with, shudder, mercurial).  It’s just not the default choice.

Note that we are not talking about a company that routinely engages in criminal behavior (you know who I’m talking about; do not discuss this here as it is off-topic), but a service that merely hasn’t got around to enabling IPv6.  This is ugly, but not the original sin.

Grüße, Carsten

---

From: Fernando Frediani <[email-masked]>
Date: Sun, 19 Apr 2020 13:19:21 -0300

Hello Carsten
Thanks for your input.

Don't you think that not choosing the default choice is just a question 
of adaptation ? The additional learning is expected and a normal thing I 
would say.

I guess that putting the fact IPv6 has not been enabled to a particular 
SaaS as something small should not be the case, not for IETF. Perhaps 
for a private company it could be the case, but IETF should stand to 
values and also have focus on giving the example, otherwise why put all 
the effort in standardize something ?
Has anyone done any type of assessment of how much would possible be 
lost by directing people to use other tools versus how much is lost over 
the years by people and companies looking that not even IETF is 
concerned about favoring products with IPv6 ?

Otherwise we will spend another 20 years asking people to adopt IPv6 and 
having to deal with the growing issues related to legacy IPv4.

Best regards
Fernando

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 19 Apr 2020 17:30:07 +0100

I would prefer that in our day to day work we placed technical pragmatism before technology religion.

The design job we do is hard enough without a forced move to other than best in class tools.

We should pick the best tools based on their ability to perform the service we require of them, and not whether they are accessible using IPv6

- Stewart

---

From: Fernando Gont <[email-masked]>
Date: Sun, 19 Apr 2020 13:25:44 -0300

> If the objective of the github repo is to open communication lines to actual developers; these are overwhelmingly on github; using another service just misses the mark.

What do you mean by "open communication lines"?

AFAIK, gihub is being proposed for editing documents, to to work on 
code. As such, I'm not sure it makes much of a difference.

(p.s.: I personally use github. Personally, I don't care myself which 
internet protocol it supports. Whether the IETF should care is a 
different story...)

Thanks,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 19 Apr 2020 12:38:49 -0400

This was discussed in the working group.
For folks who did not participate in the working group, the right time 
to raise this was during the IETF LC.   Which did occur.  And was 
publicized the same way all IETF decisions are publicized.

The IESG leadership concluded (as far as I could tell correctly) that 
there was IETF rough consensus for the two documents from the working group.
Those documents are now on the RFC Editor queue.

Yes, some people disagree.  That happens.  That is why we have a rough 
consensus process.

I do not think it is or should be incumbent on the participants to 
rehash the issues because the issue has been re-raised.

Yours,
Joel

On 4/19/2020 12:19 PM, Fernando Frediani wrote:
>> If the objective of the github repo is to open communication lines to 
>> actual developers; these are overwhelmingly on github; using another 
>> service just misses the mark.
>>
>> For other projects, gitlab etc. work well, too, but do require some 
>> additional learning for people who work on more than one project at 
>> the time.  There is no institutional bias against those services; I 
>> have participated in IETF-related projects both on gitlab and on 
>> bitbucket (even with, shudder, mercurial).  It’s just not the default 
>> choice.
>>
>> Note that we are not talking about a company that routinely engages in 
>> criminal behavior (you know who I’m talking about; do not discuss this 
>> here as it is off-topic), but a service that merely hasn’t got around 
>> to enabling IPv6.  This is ugly, but not the original sin.
>>
>> Grüße, Carsten
>>
>

---

From: Fernando Frediani <[email-masked]>
Date: Sun, 19 Apr 2020 13:46:27 -0300

Fine Joel.
We are not exactly discussing IESG decision on that document, just 
quoted it as an example of something that should be avoided (the usage 
of SaaS that do not support IPv6 by IETF officially).
This applies to other cases that do not necessary have a similar 
document that reached consensus or not.

Therefore the discussion on whether it's worth to concern about it in 
general when it comes to the tools used by IETF or not can continue and 
we can gather people's view on that.

Regards
Fernando

On 19/04/2020 13:38, Joel M. Halpern wrote:
>> Don't you think that not choosing the default choice is just a 
>> question of adaptation ? The additional learning is expected and a 
>> normal thing I would say.
>>
>> I guess that putting the fact IPv6 has not been enabled to a 
>> particular SaaS as something small should not be the case, not for 
>> IETF. Perhaps for a private company it could be the case, but IETF 
>> should stand to values and also have focus on giving the example, 
>> otherwise why put all the effort in standardize something ?
>> lost by directing people to use other tools versus how much is lost 
>> over the years by people and companies looking that not even IETF is 
>> Otherwise we will spend another 20 years asking people to adopt IPv6 
>> and having to deal with the growing issues related to legacy IPv4.
>>
>> Best regards
>> Fernando
>>
>>>> Can we start with: https://datatracker.ietf.org/wg/git/about/ ? 
>>>> What type of unique thing GitHub has that justifies continuing 
>>>> using it in detriment to other SaaS that already have full IPv6 
>>>> support ?
>>> If the objective of the github repo is to open communication lines 
>>> to actual developers; these are overwhelmingly on github; using 
>>> another service just misses the mark.
>>>
>>> bitbucket (even with, shudder, mercurial).  It’s just not the 
>>> default choice.
>>>
>>> Note that we are not talking about a company that routinely engages 
>>> in criminal behavior (you know who I’m talking about; do not discuss 
>>> this here as it is off-topic), but a service that merely hasn’t got 
>>> around to enabling IPv6.  This is ugly, but not the original sin.
>>>
>>> Grüße, Carsten
>>>
>>

---

From: John C Klensin <[email-masked]>
Date: Sun, 19 Apr 2020 14:51:09 -0400

Agreeing with Joel about the process although not necessarily
about the conclusion (i.e., I may be in the rough part of that
rough consenus), let me make what I hope is a constructive
suggestion.  

Almost no decision make in the IETF, especially not procedural
ones, can ever bind the IETF forever.  There is always, in
principle, the possibility of a new document and a new consensus
that changes a prior decision.

If people think a decision like this was wrong, and specifically
wrong because there were important issues raised (or otherwise
evident) that the IESG did not properly conside, that is part of
what we have an appeals mechanism for (no matter how poorly the
term describes the intent of the mechanism).

If the appeal window has passed (or an appeal is inappropriate
for some reason) and someone still thinks this is worth going
through again, then create and post a new I-D that carefully
explains what you think is wrong with the decision, what
alternatives you think would be better and why, and why it is
appropriate at this time and why (the latter because those who
believe the decision was correct will certainly argue that it
would be a better use of everyone's time to let the RFCs be
published and some months or years of experience accumulated
with them before coming back to the question).  

Or, if the real issue is whether the IETF should be eating its
own dogfood and how stringently under various circumstances,
write an I-D about that and about the circumstances and see if
you can get it through the system, updating these other
documents and practices as needed.  Don't expect the IESG to
take that issue up spontaneously: not only has it be raised
several times before (about other matters) and gotten nowhere,
but I think there is a strong argument that taking it up in the
context of this particular decision without strong community
input that identifies new issues would possibly be improper.

Either way, with an i-D posted that would define the problem as
you see it and suggests remedies, we would have something to
discuss (or reject), not just what Joel describes (AFAICT,
correctly) as re-raising and rehashing the issues.

Disclaimer: speaking only for myself and my opinions; YMMD.

    john

--On Sunday, April 19, 2020 12:38 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> For folks who did not participate in the working group, the
> right time to raise this was during the IETF LC.   Which did
> occur.  And was publicized the same way all IETF decisions are
> publicized.
> 
> The IESG leadership concluded (as far as I could tell
> correctly) that there was IETF rough consensus for the two
> documents from the working group.
> Yes, some people disagree.  That happens.  That is why we have
> a rough consensus process.
> 
> I do not think it is or should be incumbent on the
> participants to rehash the issues because the issue has been
> re-raised.
> 
> Yours,
> Joel
> 
>> Don't you think that not choosing the default choice is just
>> a question  of adaptation ? The additional learning is
>> expected and a normal thing I  would say.
>> 
>> particular  SaaS as something small should not be the case,
>> not for IETF. Perhaps  for a private company it could be the
>> case, but IETF should stand to  values and also have focus on
>> giving the example, otherwise why put all  the effort in
>> standardize something ?
>> Has anyone done any type of assessment of how much would
>> possible be  lost by directing people to use other tools
>> versus how much is lost over  the years by people and
>> companies looking that not even IETF is  concerned about
>> favoring products with IPv6 ?
>> 
>> Otherwise we will spend another 20 years asking people to
>> adopt IPv6 and  having to deal with the growing issues
>> related to legacy IPv4.
>> 
>> Best regards
>> Fernando
>> 
>>>> Can we start with:
>>>> https://datatracker.ietf.org/wg/git/about/ ? What  type of
>>>> unique thing GitHub has that justifies continuing using it
>>>> in  detriment to other SaaS that already have full IPv6
>>>> support ?
>>> If the objective of the github repo is to open communication
>>> lines to  actual developers; these are overwhelmingly on
>>> github; using another  service just misses the mark.
>>> 
>>> For other projects, gitlab etc. work well, too, but do
>>> require some  additional learning for people who work on
>>> more than one project at  the time.  There is no
>>> institutional bias against those services; I  have
>>> participated in IETF-related projects both on gitlab and on 
>>> bitbucket (even with, shudder, mercurial).  It's just not
>>> the default  choice.
>>> 
>>> Note that we are not talking about a company that routinely
>>> engages in  criminal behavior (you know who I'm talking
>>> about; do not discuss this  here as it is off-topic), but a
>>> service that merely hasn't got around  to enabling IPv6. 
>>> This is ugly, but not the original sin.
>>> 
>>> Grüße, Carsten
>>> 
>> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Apr 2020 08:42:36 +1200

Stewart,
> I would prefer that in our day to day work we placed technical pragmatism before technology religion.

I completely agree, but our definitions of "religion" might vary. The argument for preferring IPv6-capable tools is not, I think, religious. IPv6 doesn't have magical properties. It's simply a better protocol than IPv4, without limits to growth and without the need for NAT. The argument for the IETF preferring IPv6-capable tools is partly that it's better, and partly that it is to the benefit of IPv6 deployment that the IETF is seen to be using it. No religion there, but I am talking about a *preference*, not a dogmatic rule.

> The design job we do is hard enough without a forced move to other than best in class tools.

It's reasonably clear to me that in practice, GitHub is "best" but purely due to preferential attachment (i.e. success breeds success). I certainly wouldn't suggest that it's technically best, and many aspects of its user interface are plain horrible.
As for Webex, I much prefer both Meetecho and Zoom, but the question of "best in class" seems to be wide open.

> We should pick the best tools based on their ability to perform the service we require of them, and not whether they are accessible using IPv6

I think IPv6 access should be one of the major criteria in choosing tools, but I agree that it should not be determinant.

I also think that the IETF leadership could and should use its reputation to press the companies involved to provide IPv6 support.

Incidentally, there is a reason why the IETF chose the dual stack co-existence model for IPv6 - precisely to mitigate this whole set of problems.

     Brian

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Mon, 20 Apr 2020 08:45:04 +0000

On 19 Apr 2020, at 20:42, Brian E Carpenter wrote:

Brian,

> I completely agree, but our definitions of "religion" might vary. The 
> argument for preferring IPv6-capable tools is not, I think, religious.

It’s not even “preferring” or if it is “better”.

It’s locking people out of the community if it’s not available.  The 
argument from 10 or 20 years ago does not work anymore.  There are 
people on IPv6-only without NAT64 (unless one uses a public one on the 
internet).  These people currently have a very different view of the 
internet as most people but they are part of the global community.

> It's reasonably clear to me that in practice, GitHub is "best" but 
> purely due to preferential attachment (i.e. success breeds success). I 
> certainly wouldn't suggest that it's technically best, and many 
> aspects of its user interface are plain horrible.

It also comes with Terms & Conditions.

/bz

---

From: S Moonesamy <[email-masked]>
Date: Tue, 21 Apr 2020 01:57:24 -0700

Hi Fernando,
At 08:10 PM 17-04-2020, Fernando Frediani wrote:
>uncomfortable about the content of this email but I can assure I 
>come with good intentions.

Some of the points which you made were raised on other threads when 
questions such as: "should the IETF use github?" were on-topic.  A 
person would have to figure out which points to raise to push 
matters, such as the one which you commented about, forward.  If that 
was easy to do, lobbying efforts would result in the desired results.

Given that you wanted to call attention to the topic, I am curious 
about why you did not comment during the Last Call(s).

Regards,
S. Moonesamy

---

From: Fernando Frediani <[email-masked]>
Date: Tue, 21 Apr 2020 12:19:46 -0300

Hello
I am not sure if you followed the whole discussion of if you have seen 
only this message, but this has been already clarified that it's not 
about Github specifically and that document. As mentioned there are 
other cases, and other tools that do not go under the same process.

It's instead about IETF keep using any tools that have not done their 
part in implementing IPv6 on it yet. It's about showing the example, not 
just get the work done regardless. I know some people are more pragmatic 
and just want to get work out of their way, but I personally believe 
sticking to values in this situation is indeed important. What good is 
it if IETF standardizes things if some people don't bother if they will 
be adopted and followed or not ?

IETF not requiring SaaS solutions that it uses to support IPv6 is be the 
same than AWS using Azure for running its internal stuff, Oracle using 
Microsoft SQL Server as its Database or Microsoft hosting its corporate 
emails on GSuite.

In the case of IPv6 is even more important because not only this has 
been around for over 20 years but also the healthy growth of the whole 
Internet ecosystem depends on it and we cannot dismiss the role IETF 
plays with regards this subject.

Best regards
Fernando

On 21/04/2020 05:57, S Moonesamy wrote:
> person would have to figure out which points to raise to push matters, 
> such as the one which you commented about, forward.  If that was easy 
> to do, lobbying efforts would result in the desired results.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Apr 2020 18:19:51 +0000

> Can we start with: https://datatracker.ietf.org/wg/git/about/ ? What type of unique thing GitHub has that justifies continuing using it in detriment to other SaaS that already have full IPv6 suppor…

The community of users.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Apr 2020 18:21:33 +0000

This is not correct. There are WG's that want to use GitHub, and we have documented good ways to do so.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2020 14:26:17 -0400

>      > Can we start with: https://datatracker.ietf.org/wg/git/about/ ? What type of unique thing GitHub has that justifies continuing using it in detriment to other SaaS that already have full IPv6…

I disagree.    We're in a transition period for which neither universal 
IPv4 nor universal IPv6 connectivity can be assumed. Any service that 
isn't usable from both IPv4 and IPv6 is therefore inaccessible to some 
people.

Also, that argument ignores the concerns of many users who have 
abandoned github for valid reasons.   Why are those users' concerns 
irrelevant?

IETF really needs to transition away from github even if they started 
supporting IPv6 tomorrow.

Keith

---

From: S Moonesamy <[email-masked]>
Date: Tue, 21 Apr 2020 12:42:29 -0700

Hi Fernando,
At 08:19 AM 21-04-2020, Fernando Frediani wrote:
>I am not sure if you followed the whole discussion of if you have 
>seen only this message, but this has been already clarified that 
>it's not about Github specifically and that document. As mentioned 
>there are other cases, and other tools that do not go under the same process.

I read the thread.

>It's instead about IETF keep using any tools that have not done 
>their part in implementing IPv6 on it yet. It's about showing the 
>example, not just get the work done regardless. I know some people 
>are more pragmatic and just want to get work out of their way, but I 
>personally believe sticking to values in this situation is indeed 
>important. What good is it if IETF standardizes things if some 
>people don't bother if they will be adopted and followed or not ?

I took a quick look at an old statement of work for Meetecho.  It 
does not mention IPv4 or IPv6.  I find it difficult to disagree with 
the Meetecho team as I got good support from the team for free.

It is not about getting work out of the way or being pragmatic.  I 
would agree with your point about it not being worth publishing a BCP 
if it will not be adopted.  The point which you made is known as 
"dogfooding".  Here's a comment whcih I made about that topic: 
https://mailarchive.ietf.org/arch/msg/ietf/6PxMGowo_74RuXNWxfZf-8lfdO8/

>been around for over 20 years but also the healthy growth of the 
>whole Internet ecosystem depends on it and we cannot dismiss the 
>role IETF plays with regards this subject.

In my opinion, telling people (outside the IETF) that IPv6 is 
important is not a convincing argument.  Showing them that the IETF, 
for pragmatic reasons (I assume), cannot run its services on IPv6 
might be a convincing argument.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 21 Apr 2020 17:44:32 -0400

>abandoned github for valid reasons.   Why are those users' concerns 

Probably because they don't have a veto over the larger number of
people who do want to use github.

R's,
John

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2020 23:57:37 +0200

On 2020-04-21, at 20:26, Keith Moore <[email-masked]> wrote:
> 
> Also, that argument ignores the concerns of many users who have abandoned github for valid reasons.   

Hi Keith,

I’m curious; is there a writeup of these reasons somewhere?

> Why are those users' concerns irrelevant?

I have a lot of concerns about github, but it seems to me that they were reasonably addressed in the work of the git WG.

(I am much more concerned that I now find my self excluded from WG meetings that are run via Zoom, where there are quite strong concerns that certainly haven’t been addressed.)

> IETF really needs to transition away from github even if they started supporting IPv6 tomorrow.

I don’t agree.  I don’t even see a debate (beyond the concerns that were addressed).

Grüße, Carsten

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Apr 2020 15:12:00 -0700

> On Apr 19, 2020, at 1:19 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 

I agree that the tools we use should be IPv6-capable. I'm doing work in ICANN and ITU, and by the way stay in touch with family using IP-based A/V. What I'm using is Zoom, which is IPv6-capable. They have had some widely-publicized security issues lately, which as near as I can tell are resolved if one places a password on a scheduled meeting, and possibly forces the moderator to manually accept each attendee on the assumption that they know them. There remain a couple of issues - limits on the number of attendees, and a 40 minute time limit. Both of those can be overcome at a cost of $12/month.

I have never recorded a call, but I think it can be done.

Zoom is IPv6-capable, and with a small amount of common sense the known issues can be overcome as far as I know. I'd be willing for my working group to use my zoom account for its meetings...

---

From: Fernando Frediani <[email-masked]>
Date: Tue, 21 Apr 2020 19:46:08 -0300

Hello all

Thanks for all inputs on this discussion, but I wanted to call attention 
to the main topic of this thread which is the acceptance of IETF to work 
with services that do not have IPv6 support in detriment to those who have.

I understand the feelings that may be around GitHub, in favor or against 
it, but that main point is not really to discuss if it's a good or bad 
tool. I just mentioned it because in this case in particular it had to 
well known alternatives that support IPv6. If tomorrow GitHub does its 
job to bring IPv6 support I personally don't have a problem in seeing 
IETF using it.
There are other SaaS like WebEx that is widely used and doesn't have 
IPv6 support as well. Does it have to be it ? Even if it's given for 
free can't Management not find another solution and refuse it ?

That's what the discussion is about. Does it make sense IETF to accept 
keep using *any* SaaS that do not support IPv6 in order to get things 
done or could them be replaced and IETF can give the example ?

Fred - As far as I know Zoom does not support IPv6 either. I have just 
opened a session here, captured traffic and it flows on IPv4-only. Zoom 
is basically hosted in AWS which apart of having IPv6 support has also 
so many development tools that don't support IPv6, so probably it's the 
case. I have opened support requests to them to ask about and they never 
responded unfortunately.

Best regards
Fernando

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 21 Apr 2020 18:36:43 -0700

Hi Fernando,

There is a point that's been grating on me for the entire thread but I had
trouble finding a good way to express it:

> be adopted and followed or not ?

Couldn't I make this same argument about *any* IETF standard?  Do we need
to reject services that don't implement TLS 1.3 or NFSv4 or QUIC or OSPF
(v2 or v3?) or ...?

Bjoern made (upthread) a much more compelling argument about why IPv6
specifically is so important, and I think you're doing yourself a
disservice by using only the "it's an IETF standard" argument.

Sorry for the digression,

Ben

---

From: Fernando Frediani <[email-masked]>
Date: Wed, 22 Apr 2020 00:12:36 -0300

Hello Ben
You actually have a very point.

However I don't think it applies the very same way as IPv6. NFSv4 for 
example is not an relevant protocol for Internet, is not something that 
is exposed publicly, the same as OSPF. If IETF uses them it's on 
internal infrastructure and no exposed to external knowledge so it is 
harder to use the same argument when I say show the example. With 
regards the others mentioned, perhaps, need to see if it applies on a 
case or not, for example QUIC.

IPv6 instead applies to ALL cases, any situation that involves internet, 
has been around for 20 years and the continuous and healthy growth of 
the Internet depends on it, including to mitigate growing issues and 
conflicts related to IPv4 exhaustion. It is not something 'nice to have 
if possible anymore' that can continue being disregarded.

Kind Regards
Fernando

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 22 Apr 2020 07:25:00 +0200

Hi,

for what it’s worth, Meetecho is IPv6-enabled.

Cheers,
Simon

Inviato da iPhone

> Il giorno 21 apr 2020, alle ore 21:46, S Moonesamy <[email-masked]> ha scritto:
> 
> Hi Fernando,
>> I am not sure if you followed the whole discussion of if you have seen only this message, but this has been already clarified that it's not about Github specifically and that document. As mentioned there are other cases, and other tools that do not go under the same process.
> 
> I read the thread.
> 
>> It's instead about IETF keep using any tools that have not done their part in implementing IPv6 on it yet. It's about showing the example, not just get the work done regardless. I know some people are more pragmatic and just want to get work out of their way, but I personally believe sticking to values in this situation is indeed important. What good is it if IETF standardizes things if some people don't bother if they will be adopted and followed or not ?
> 
> I took a quick look at an old statement of work for Meetecho.  It does not mention IPv4 or IPv6.  I find it difficult to disagree with the Meetecho team as I got good support from the team for free.
> 
> It is not about getting work out of the way or being pragmatic.  I would agree with your point about it not being worth publishing a BCP if it will not be adopted.  The point which you made is known as "dogfooding".  Here's a comment whcih I made about that topic: https://mailarchive.ietf.org/arch/msg/ietf/6PxMGowo_74RuXNWxfZf-8lfdO8/
> 
>> In the case of IPv6 is even more important because not only this has been around for over 20 years but also the healthy growth of the whole Internet ecosystem depends on it and we cannot dismiss the role IETF plays with regards this subject.
> 
> In my opinion, telling people (outside the IETF) that IPv6 is important is not a convincing argument.  Showing them that the IETF, for pragmatic reasons (I assume), cannot run its services on IPv6 might be a convincing argument.
> 
> Regards,
> S. Moonesamy 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Apr 2020 09:35:28 +0200

I just realized something.

We have RFC6540 since 2012, which clearly express that we should not work in anything which is IPv4-only.

Should this document be applicable as well to our tools?

Shall we update it to clearly express that?

Regards,
Jordi
@jordipalet

El 22/4/20 0:47, "ietf en nombre de Fernando Frediani" <[email-masked] en nombre de [email-masked]> escribió:

    Hello all

    Best regards
    Fernando

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Apr 2020 16:09:56 +0800

All,

I fully agree that we should make sure that our tools have support
for IPv6.

That said we today have tools that does not have this support.

So we need an ordered transition from "old" tools (ipv4 only) to "new"
tools (ipv support).

So when you identify something that is ipv4 only, you also need to
identify a substitute that has ipv6 support and does not add extra cost
or extra operational complexity.

/Loa

-- 

My mail server it under a DOS attack, we are working to fix it but it
may take some time.

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: [email-masked]
Date: Wed, 22 Apr 2020 13:58:25 +0200

> Shall we update it to clearly express that?

We are 20+ years in.
If we (as the collective we) believed in this transition shouldn't the next step be to remove the A records from {mail,datatracker,www}.ietf.org? And add a piece of Javascript blocking any client coming through a translator from v4.

I would expect ridicule from such a proposal.
Our tools including our collboration tools are centralized, they don't benefit much from IPv6 and end to end transparency either.

Best regards,
Ole

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 08:27:27 -0400

> If we (as the collective we) believed in this transition shouldn't the next step be to remove the A records from {mail,datatracker,www}.ietf.org? And add a piece of Javascript blocking any client c…
Our recommended transition strategy was dual-stack.    Removing IPv4 
support is premature until IPv6 is ubiquitous.   Nobody is proposing 
that github be made IPv6-only.
> Our tools including our collboration tools are centralized, they don't benefit much from IPv6 and end to end transparency either.

No but it's entirely possible that there are, or soon will be, IETF 
participants who cannot access github because of the lack of IPv6 
support.   As IPv6 becomes more available and IPv4 space more and more 
scarce we should expect that some existing access networks will 
discontinue IPv4 support.   Who wants to maintain equipment and routes 
that aren't used anymore?   When public IPv4 network access disappears, 
it will happen gradually at first, and then everywhere suddenly.

I don't think the github situation is an emergency yet, but I agree that 
we need to make sure that all of the tools that we use and expect 
participants to use are accessible via IPv6.  Maybe not this week, but 
probably this year.

Keith

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Apr 2020 14:40:10 +0200

+1

Exactly, is not for "right now", but we should make sure to work on that.

Even if we plan for not removing the A RRs or to do so in several years, anticipation is needed.

Regards,
Jordi
@jordipalet

El 22/4/20 14:28, "ietf en nombre de Keith Moore" <[email-masked] en nombre de [email-masked]> escribió:

    Keith

---

From: Fernando Frediani <[email-masked]>
Date: Wed, 22 Apr 2020 09:48:30 -0300

So folks

How can this advance within IETF ?
Is it Management responsability to ensure all tools have this requirement
by default, and that any exceptions to be fairly justified.

How can a proper analisys be done in order to replace tools like GitHub and
WebEx until they support IPv6 ?

Who's responsability is to make it happen and be accountable for ?

Regards
Fernando

On Wed, 22 Apr 2020, 09:40 JORDI PALET MARTINEZ, <jordi.palet=
[email-masked]> wrote:

> El 22/4/20 14:28, "ietf en nombre de Keith Moore" <[email-masked]
> en nombre de [email-masked]> escribió:
>
>     > If we (as the collective we) believed in this transition shouldn't
> the next step be to remove the A records from {mail,datatracker,www}.
> ietf.org? And add a piece of Javascript blocking any client coming
> through a translator from v4.
>     > Our tools including our collboration tools are centralized, they
> don't benefit much from IPv6 and end to end transparency either.
>
> 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: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Apr 2020 14:56:37 +0200

I don’t think we need to do such analysis … we don’t work like that at IETF.

We must just draft a plan for our “requirements for IETF tools”, write it down in an ID, may be update the previous one, maybe a different (new) one, and see if we can reach consensus.

I’m happy to work on that, and I’m sure others as well!

Regards,

Jordi

@jordipalet

El 22/4/20 14:49, "ietf en nombre de Fernando Frediani" <[email-masked] en nombre de [email-masked]> escribió:

So folks

Is it Management responsability to ensure all tools have this requirement by default, and that any exceptions to be fairly justified.

How can a proper analisys be done in order to replace tools like GitHub and WebEx until they support IPv6 ?

Regards

Fernando

On Wed, 22 Apr 2020, 09:40 JORDI PALET MARTINEZ, <jordi.palet=[email-masked]> wrote:

+1

Regards,
Jordi
@jordipalet

    Keith

---

From: [email-masked]
Date: Wed, 22 Apr 2020 15:03:24 +0200

> Our recommended transition strategy was dual-stack.    Removing IPv4 support is premature until IPv6 is ubiquitous.   Nobody is proposing that github be made IPv6-only.
> No but it's entirely possible that there are, or soon will be, IETF participants who cannot access github because of the lack of IPv6 support.   As IPv6 becomes more available and IPv4 space more and more scarce we should expect that some existing access networks will discontinue IPv4 support.   Who wants to maintain equipment and routes that aren't used anymore?   When public IPv4 network access disappears, it will happen gradually at first, and then everywhere suddenly.
> 
> I don't think the github situation is an emergency yet, but I agree that we need to make sure that all of the tools that we use and expect participants to use are accessible via IPv6.  Maybe not this week, but probably this year.

I'm quite aware of the IETF transition strategy.

20+ years in isn't apparent that it is working. The IETF cannot disable IPv4 from it's properties in the forseeable future. It is equally unforseeable when a client can communicate only IPv6 end to end.

The sorry reality is that the centralized network combined with the fact that a single IPv4 address is sufficient for a small country (with a port overloading NAT) there is no urgency to the transition.

I would love to be proven wrong of course...

Cheers,
Ole

---

From: Fernando Frediani <[email-masked]>
Date: Wed, 22 Apr 2020 10:06:31 -0300

Sure Jordi
It is indeed something great long term.
But I was also looking for something that can be done within the Management
for internal stuff and things they make available for us.

For example: Board meetings can stop using WebEx and Management can find
another solution so the example can start from there. Same applies to
similar cases.

Regards
Fernando

On Wed, 22 Apr 2020, 09:57 JORDI PALET MARTINEZ, <jordi.palet=
[email-masked]> wrote:

> We must just draft a plan for our “requirements for IETF tools”, write it
> down in an ID, may be update the previous one, maybe a different (new) one,
> and see if we can reach consensus.
>
>
>
> El 22/4/20 14:49, "ietf en nombre de Fernando Frediani" <
> [email-masked] en nombre de [email-masked]> escribió:
>
>
>
> So folks
>
>
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 09:10:02 -0400

> 20+ years in isn't apparent that it is working. The IETF cannot disable IPv4 from it's properties in the forseeable future. It is equally unforseeable when a client can communicate only IPv6 end to…

Just because we don't know when IPv4 will be discontinued, doesn't mean 
that it won't be discontinued.   I wasn't able to predict the end of 
BITNET either.   If memory serves, that network was still growing 
(slowly) until it shut down almost overnight.

Anyway, the discussion wasn't about disabling IPv4, which we all know is 
very premature, but about enabling IPv6.   It took longer than most of 
us hoped, but by now there's certainly enough global usage of IPv6 to 
utterly dismiss the notion that the transition was a failure.

> The sorry reality is that the centralized network combined with the fact that a single IPv4 address is sufficient for a small country (with a port overloading NAT) there is no urgency to the transi…

Uh, no.   Because there are a lot of services that cannot be run in the 
presence of NATs without also having servers in global address space 
willing to forward traffic.   That has been understood for decades.

Also, the network is not centralized.   That's not an accurate 
representation of the organization of the network either at the IP level 
or at the application level.

Keith

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2020 13:15:45 +0000

>    We have RFC6540 since 2012, which clearly express that we should not work in anything which is IPv4-only.

We should update this to mark it as deprecated.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 09:22:25 -0400

> We should update this to mark it as deprecated.

No, we should  make it mandatory.  There is no path forward using IPv4.  
It is a dead end.

Keith

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2020 13:43:34 +0000

support.

And presumably, the owner of GitHub will fix things so that their userbase isn't needlessly limited by this.

I mean really, IPv6 is the hill the IETF wants to die on?  As Ben said, we not TLS 1.3 with early data for faster response?  Why not DNSSEC for more security?

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2020 13:46:18 +0000

It is a dead end.

"We're not the protocol police."  Except this one hobby-horse that some have.

Mandatory IPv6 to disenfranchise those that have only IPv4 and find it works fine?  Balkanization?

---

From: "John Levine" <[email-masked]>
Date: 22 Apr 2020 09:49:55 -0400

In article <[email-masked]> you write:
> There are people on IPv6-only without NAT64 ...

Can you say where?  If so, I'd think think that getting to IETF
projects would be the least of their problems.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 09:52:16 -0400

> And presumably, the owner of GitHub will fix things so that their userbase isn't needlessly limited by this.
If that happened (and who knows, maybe it will), that would address this 
specific problem.
> I mean really, IPv6 is the hill the IETF wants to die on?  As Ben said, we not TLS 1.3 with early data for faster response?  Why not DNSSEC for more security?

Nobody's proposing to die on any hill.   IETF doesn't need github, after 
all, it can work just fine without it or with different tools.    As for 
TLS, we probably should make sure that nothing we're still using is 
still using TLS 1.0 or 1.1.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 09:53:10 -0400

> Mandatory IPv6 to disenfranchise those that have only IPv4 and find it works fine?  Balkanization?

Ok, we're done.   You keep misrepresenting the other side of the discussion.

Keith

---

From: Fernando Frediani <[email-masked]>
Date: Wed, 22 Apr 2020 10:55:31 -0300

This discussion is not about being police and mandate people do things, 
but about showing the example within our bounds so other people can see 
that and do themselves as well .

Otherwise people may look and think: "If not even IETF is bothered about 
using products that have full IPv6 support, why should I bother ?"

Regards
Fernando

---

From: "John Levine" <[email-masked]>
Date: 22 Apr 2020 14:04:38 -0000

In article <[email-masked]>,
Fernando Frediani  <[email-masked]> wrote:
>is exposed publicly, ...

Sure it is.  Lots of us do remote NFS mounts over the net to retrieve
a few files.

To be blunt, refusing to use a service solely because it doesn't
handle IPv6 would be self-defeating virtue signalling.  It won't
change anyone's mind, it'll just get in the way of our work.  We
should certainly keep pointing out all of the reasons that IPv6
support is a good idea, e.g., no need ever to renumber again, no need
for NAT, no problems with running out of 10/8 space, but let's keep
our eye on the ball.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2020 14:13:53 +0000

> IETF doesn't need github, after all, it can work just fine without it or with different tools.

But many WG's find it more efficient to do so. It's available on the Internet, it can be used compatibly with our mechanisms, so why deny them?

And I notice you didn't respond about DNSSEC :)

---

From: [email-masked]
Date: Wed, 22 Apr 2020 16:22:33 +0200

> for NAT, no problems with running out of 10/8 space, but let's keep

Indeed.

Actually the renumbering problem for IPv6 in home networks is a lot worse than for IPv4 home networks (that never renumber).
That's what you get for exposing the home network to global addressing.

Cheers,
Ole

---

From: john heasley <[email-masked]>
Date: Wed, 22 Apr 2020 14:36:14 +0000

> We
> support is a good idea,

and asking why folks are resisting or do not think it compelling, and
heeding the responses.

---

From: "John R Levine" <[email-masked]>
Date: 22 Apr 2020 10:56:05 -0400

> That's what you get for exposing the home network to global addressing.

I guess it depends on your ISP.  When I switched from cable which provides 
IPv6 to the local telco fiber which doesn't (I'm talking to them about 
it), I got a HE tunnel for global addresses but my ULAs didn't change.

FWIW, they say my IPv4 address is nominally dynamic but they don't ever 
expect to change it.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 10:59:26 -0400

On 4/22/20 10:04 AM, John Levine wrote:

> handle IPv6 would be self-defeating virtue signalling.

That would only be true if there were no actual need to support 
IPv6.     And eating our own dogfood is not virtue signaling, it's 
making sure that we understand firsthand the advantages and limitations 
of our recommendations.

Again, this isn't an emergency, and there's no firm deadline (yet).   
Making sure everything works with IPv6 is just being proactive.

I also suspect that there are multiple paths to address this problem 
with a minimum of disruption.

Keith

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 22 Apr 2020 11:02:39 -0400

> Sorry for the digression,

Last time I looked, Internet standards were VOLUNTARY standards. They 
are only mandatory to the extent that implementation is necessary for 
something to actually work (if your router doesn't pass IP packets, you 
can't really do very much with it), or when a customer's specs require 
specific standards.

The last time something was mandated, that I recall, was the TCP/IP flag 
day, which, arguably, is what marks the birth of the Internet.

Having said that, seems to me that the IETF should eat it's own dogfood 
- set an example and all that.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 11:24:54 -0400

On 4/22/20 11:02 AM, Miles Fidelman wrote:

> Last time I looked, Internet standards were VOLUNTARY standards.

Yes, but we're talking about the tools that /we/ choose (i.e. volunteer) 
to use.   Nobody's proposing that github be forced to implement IPv6, 
the question is only whether IETF should continue to use it if we can't 
somehow make it accessible via IPv6.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Apr 2020 11:32:02 -0400

Let's take this apart.

We can't and won't stop individuals from developing drafts using github.
    Nor can we stop them from posting pointers to those githubs on WG 
email lists.
Similarly, we can't and won't stop design teams from using github.

Given the above, I am glad we have documents describing the best 
practices for using those.
Also given the above, insisting that if a WG formally wants to use a 
repository, they MUST use something different seems really odd.  While I 
personally would prefer not to use github at all, I think the current 
path is the right one for the community.
And more importantly, it is the one the community adopted.
And adopted knowing the constraints.

Yours,
Joel

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 11:37:55 -0400

> Similarly, we can't and won't stop design teams from using github.

Ideally, I think people should be able to use whatever tools they want 
to use.   However, those choices do affect people's ability to work 
together and sometimes individuals have to make compromises in order to 
work effectively with others.   These conflicts are not new; they've 
been around as long as I've been programming.

Github is problematic for several reasons and I don't really think the 
community has come to terms with that yet.   (Just like, say, using HTML 
email is problematic for several reasons that we really haven't come to 
terms with yet.)   IMO the thing to do is try to avoid learn from the 
experience with github (or HTML email) and use that experience to 
develop better tools.   But also we should try to avoid painting 
ourselves into corners.

It's not wrong to focus attention on github's problems.   Denial is not 
a virtue.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Apr 2020 11:43:14 -0400

On 4/22/20 11:37 AM, Keith Moore wrote:

> IMO the thing to do is try to avoid learn from the experience with 
> github (or HTML email) and use that experience to develop better tools.

I don't know where the word "avoid" came from, but it wasn't intended.

(I can't even blame autocorrect.)

Keith

---

From: Fernando Frediani <[email-masked]>
Date: Wed, 22 Apr 2020 12:44:41 -0300

On 22/04/2020 12:14, Benjamin Kaduk wrote:
>
> To be clear, I agree that IPv6 is in some sense "special"; I'm just 
> asking
> that you include that step of reasoning when you are arguing for us to
> treat it as special.

There is nothing special about IPv6. It is the Internet Protocol and 
IPv4 is already legacy. And there are serious issues related to IPv4 
exhaustion that perhaps many people are not yet aware.

It should already be deployed in most places and services and it's not 
because of many reasons like of people unwilling to do whatever 
necessary and treating it as something less important or even cosmetic.
In fact I get surprise often the amount of effort people put trying to 
find ways to not have to do it than to find out how to do.

I do my bit when I am the one who decides: I always prefer to pay for 
tools and SaaS that have IPv6 support, I request it from potential 
suppliers and in RFPs, Have turned down business already because of lack 
of IPv6, I make content I host available in IPv6 and so on. Yes, some of 
these tasks require more time to do done and that's one of the ways I 
get to contribute to it and show example myself.
What I am proposing is to get out of the comfort zone and start to make 
the same requirements mandatory in order to show example, so other 
people can feel they can do the same. Does anyone believe IETF should 
not give example in this sense ?

Regards
Fernando

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Apr 2020 08:46:44 +1200

> or extra operational complexity.

Why did anybody bother to write anything after this message from Loa, except +1?

Clearly that's the right policy for IETF tool choices to follow (and has been
for some years).

    Brian

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Apr 2020 07:37:15 -0600

Just small tiny point … I’d like to point that right now I am on a LTE network that only provides a V6 address to my phone and WebEx is working just fine - So, thought I agree there are many ways WebEX could do more, I realize that deploying more NATs may not have been the original design goal of V6, it might be good to actually gets the facts straight.

(and for full disclosure, I work at Cisco)

---

From: Fernando Frediani <[email-masked]>
Date: Thu, 23 Apr 2020 11:49:48 -0300

Hello

The fact that you can use tools that are IPv4-only like WebEx using LTE 
IPv6-only address is probably because the ISP uses 464XLAT, but to 
external world from your ISP Border to them it's simply IPv4-only traffic.

Regarding WebEx, and to not stick only to GitHub, what I mentioned other 
day is an example of an easy thing that would be expected  by IETF's 
Board to stop using it while doesn't have IPv6 support and privilege 
other tools that do. There are several others like Google Meet, 
Microsoft Teams, Jitsi, etc. Some people may say "Well, but I like WebEx 
because this and that feature which I am used to."
Well, in order to show example and stick to values we have to get out of 
our comfort zone and not always do everything as we would wish. Beyond 
all what would be the "loss" of making a change like this other than 
getting people out of the comfort zone for a short period ? Even if it's 
currently given fro free it should be refused as I am sure in the worst 
case even if necessary to pay for another tool would not bankrupt the 
organization.

Regards
Fernando

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Apr 2020 11:03:22 -0400

On 4/23/20 10:49 AM, Fernando Frediani wrote:

> Well, in order to show example and stick to values we have to get out 
> of our comfort zone and not always do everything as we would wish. 

We're supposed to be an engineering group, and engineering is all about 
pragmatism and compromise.  IMO we should expeditiously gravitate toward 
tools that best support our work, and that includes a lot of 
considerations like supporting IPv6 and avoiding vendor lockin.   But we 
should not let that impede our work. It's a difficult balance to 
maintain because inertia gets in the way.   It's easy to get stuck.

IMO any vendor-provided services that aren't well-defined by open 
standards or maybe open source code are inherently suspect, because we 
won't be able to easily modify such tools to suit our changing needs, or 
migrate to other tools that support our needs better.   Our organization 
is dedicated to producing and promoting open standards, so anything we 
use that isn't entirely or at least mostly specified by open standards 
inherently puts us in a conflicted position and impedes our work sooner 
or later.   Lack of IPv6 support is only one example of an issue that 
results from reliance on nonstandard tools.

Keith

---

From: Fernando Frediani <[email-masked]>
Date: Thu, 23 Apr 2020 12:22:41 -0300

On 23/04/2020 12:03, Keith Moore wrote:
> We're supposed to be an engineering group, and engineering is all 
> about pragmatism and compromise.  IMO we should expeditiously 
> gravitate toward tools that best support our work, and that includes a 
> lot of considerations like supporting IPv6 and avoiding vendor 
> lockin.   But we should not let that impede our work. It's a difficult 
> balance to maintain because inertia gets in the way. It's easy to get 
> stuck.
Sure Keith, fully agree.
That's why I asked on my first message "What unique feature does it have 
that it has to be it?". With the other tools that have support will not 
the meeting happen the same and the work get done pretty much with the 
same efficiency? If so then it matches both criteria you just mentioned.
> won't be able to easily modify such tools to suit our changing needs, 
> or migrate to other tools that support our needs better.   Our 
> organization is dedicated to producing and promoting open standards, 
> so anything we use that isn't entirely or at least mostly specified by 
> open standards inherently puts us in a conflicted position and impedes 
> our work sooner or later.   Lack of IPv6 support is only one example 
> of an issue that results from reliance on nonstandard tools.

You said well: not just producing but promoting as well. That's why 
eating our own dog food is something pertinent here, specially when it 
doesn't bring any losses to the work to get done at the end.

Regards
Fernando

---

From: Rob Sayre <[email-masked]>
Date: Mon, 27 Apr 2020 18:08:02 -0700

> Clearly that's the right policy for IETF tool choices to follow (and has

This sounds right to me, but there is an extra step non-IETF parties can
take, in the interests of advocacy:

Provide services only over IPv6. One example is https://ipv6onlyhosting.com/
(no affiliation whatsoever).

thanks,
Rob

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 28 Apr 2020 19:21:57 +1200

> On Apr 28, 2020, at 1:08 PM, Rob Sayre <[email-masked]> wrote:
> 
> Provide services only over IPv6. One example is https://ipv6onlyhosting.com/ (no affiliation whatsoever).

Ironically, that site is also accessible via IPv4 :-)

	Ross.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 28 Apr 2020 02:05:18 -0700

On Tue, Apr 28, 2020 at 12:22 AM Ross Finlayson <[email-masked]>
wrote:

> > Provide services only over IPv6. One example is
> https://ipv6onlyhosting.com/ (no affiliation whatsoever).
>

Fair. I'm going to move my stuff to IPv6-only services (not necessarily the
place I linked).

thanks,
Rob