Subject: LLC Board Meeting Details - 14 May 2020

From: IETF Administration LLC Board of Directors Chair <[email-masked]>
Date: Thu, 07 May 2020 16:07:07 -0700

IETF LLC Board of Directors meetings are conducted via web/teleconference. Members of the community are welcome to attend certain portions of these meetings as observers. Regular meetings are divided into four sections:

1. Open (to Observers)
2. Board + Support Staff Only
3. Board + Executive Director Only
4. Executive Session (Board-Only)

The next meeting will be held on Thursday, 14 May 2020 at 12:00 PT (19:00 UTC). WebEx and Dial-in information is at the bottom of this message and also at <https://www.ietf.org/about/groups/llc-board/meeting-info/>.

The agenda for the meeting can be found at <https://www.ietf.org/about/groups/llc-board/minutes/2020/>.

A calendar of upcoming public meetings can be downloaded or subscribed to at: 
https://calendar.google.com/calendar/ical/ietf.org_vmffrv4hq14aqpedenuv5v42hs%40group.calendar.google.com/public/basic.ics

------------------------------------------------------- 
JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=mbb9c7dbde03b4be9f055368b0bc9d117
Meeting number (access code):  640 897 669

JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)
Access code:  640 897 669

IMPORTANT NOTICE: This WebEx service includes a feature that allows
audio and any documents and other materials exchanged or viewed during
the session to be recorded. By joining this session, you automatically
consent to such recordings. If you do not consent to the recording,
discuss your concerns with the meeting host prior to the start of the
recording or do not join the session. Please note that any such
recordings may be subject to discovery in the event of litigation.

---

From: Fernando Frediani <[email-masked]>
Date: Fri, 8 May 2020 12:21:46 -0300

I guess the Board/LLC either missed all the discussion about trying to 
use tools and SaaS that have IPv6 support (which is not the case of 
WebEx) or they have followed it and decided not to respond to it with 
their view at all.

A pity in my view this pragmatic way of doing things and not willing to 
compromise on such small things in order to give the example.
I am convinced that replacing the tool used for these meetings for 
another one that supports IPv6 is not a big deal and will not compromise 
the results and the efficiency that Board can keep conducting its business.

Fernando

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 8 May 2020 12:19:15 -0400

Hi Fernando,

> On May 8, 2020, at 11:21 AM, Fernando Frediani <[email-masked]> wrote:
> 
> I guess the Board/LLC either missed all the discussion about trying to use tools and SaaS that have IPv6 support (which is not the case of WebEx) or they have followed it and decided not to respond to it with their view at all.

I didn’t miss it. I read the emails. The discussion seemed inconclusive and opinions were quite varied. 

I think (just my opinion) if the community is unhappy with the tools the IETF is using and providing to get its work done, what would be useful is an RFC that spells out the guidelines the community wants the LLC to follow when choosing tools to provide. That way we can feel confident that we’re following community consensus and we can be consistent in applying the same guidelines with each choice.

Best,
Alissa

> 
> A pity in my view this pragmatic way of doing things and not willing to compromise on such small things in order to give the example.
> I am convinced that replacing the tool used for these meetings for another one that supports IPv6 is not a big deal and will not compromise the results and the efficiency that Board can keep conducting its business.
> 
> Fernando
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 08 May 2020 19:03:23 +0200

I promise to work on that this weekend ... I've been a bit busy!

El 8/5/20 18:20, "ietf en nombre de Alissa Cooper" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Fernando,

    Best,
    Alissa

    >> https://calendar.google.com/calendar/ical/ietf.org_vmffrv4hq14aqpedenuv5v42hs%40group.calendar.google.com/public/basic.ics

**********************************************
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: Fernando Frediani <[email-masked]>
Date: Fri, 8 May 2020 14:17:23 -0300

Hi Alissa
Thanks for your reply.

Yeah, that discussion may have seen inconclusive, but it doesn't stop 
the Board/LLC to state their view on the matter at some point.

Having a RFC to spell de guidelines may be something good for the future 
and for several other situations, but without having it right now 
doesn't stop the Board to adopt another tool and say: "We have discussed 
the matter and we think that it is important for us to give the example 
to all community even on these small things rather than use a tool we 
have some preference and are used to". For the Board to do that it 
doesn't require any RFC as it's a purely an administrative decision that 
can be taken the same way it was taken when WebEx was chosen. Or Board 
could also say: "We have discussed the matter and we believe this is 
something unimportant in our view and we are not going to replace the 
tools currently used"

If such actions are taken, and in the case Board's view matches mine and 
others that could perhaps be an incentive to have a future document with 
guidelines that would apply to other scenarios.

Kind regards
Fernando Frediani

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 May 2020 10:51:55 -0700

> guidelines that would apply to other scenarios.

I would make two points here:

First, I think you are wrong on the merits. I do not believe that support
for IPv6 (nor DNSSEC, nor TLS 1.3) should be a primary criterion for
selecting tools. It may make us sad that these technologies are not being
adopted at a faster rate but I don't think that inconveniencing ourselves
in order to make a statement is the right answer.

Second, for the LLC board to take this kind of unilateral action on a
matter which does not primarily impact the efficient operation of the IETF
but rather is about messaging, seems like precisely the kind of overreach
that people were worried the LLC would engage in. That kind of policy
decision should come from the IETF, and as Alissa says, the position you
are espousing does not seem to have gathered even rough consensus.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 May 2020 18:52:11 +0000

Why does their opinion matter more than anyone else?  Why do you want to hear from them in particular?

---

From: "John Levine" <[email-masked]>
Date: 8 May 2020 15:37:16 -0400

>in order to make a statement is the right answer.

I happen to agree with this sentiment but I really wish we could give
this endless argument a rest.  

It's come up over and over for at least a decade, we have never come close
to resolving it, and we're not going to do it right now.

---

From: Fernando Frediani <[email-masked]>
Date: Fri, 8 May 2020 16:38:19 -0300

On 08/05/2020 14:51, Eric Rescorla wrote:
> <clip>
> First, I think you are wrong on the merits. I do not believe that 
> support for IPv6 (nor DNSSEC, nor TLS 1.3) should be a primary 
> criterion for selecting tools. It may make us sad that these 
> technologies are not being adopted at a faster rate but I don't think 
> that inconveniencing ourselves in order to make a statement is the 
> right answer.
Perhaps one of the reasons they are not being sufficiently adopted 
because of the lack examples of people and organizations using them and 
the main propose is that as much as possible organizations start to do 
that in the many ways possible, and IETF is an natural one. Really do 
you see such an inconvenience on that ?
> matter which does not primarily impact the efficient operation of the 
> IETF but rather is about messaging, seems like precisely the kind of 
> overreach that people were worried the LLC would engage in. That kind 
> of policy decision should come from the IETF, and as Alissa says, the 
> position you are espousing does not seem to have gathered even rough 
> consensus.
When you say "unilateral" action I see as something natural. I don't 
think the community has to tell very detailed how the Board conduct 
every step of their business, that's why I am askinf for their 
consideration for this matter. They should have a fair amount of 
freedoom to decide smaller things like this which as I said are just 
administrative decisions. If there was a guiding document telling them 
how to do on this matter specifically fine, but there isn't and that 
doesn't stop them to make some adjustments, should they have the same 
view about the example it gives to other people and organizations and 
*specially to products that get more aware they can start to be rejected 
for not having support for the current Internet Protocol*

Rich - answering your question here it is not about that their view 
matters more of less of anyone else. It's just about being practical 
that *this* type of adjustment can be taken by themselves without need 
of any document with guidelines as it was already done for the tool 
currently used. If in the future community reach consensus on how this 
should be done, not just for the Board but for other scenarios, then all 
will adjust for that.

Regards
Fernando

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 May 2020 12:49:16 -0700

On Fri, May 8, 2020 at 12:37 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:

I totally agree, which is why I avoided responding to this thread for so
long. However, I thought it was worth responding to clarify what I took to
be the appropriate role of the LLC in this, and I figured if I was going to
do that, I should probably be transparent about the merits.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 May 2020 12:54:25 -0700

On Fri, May 8, 2020 at 12:39 PM Fernando Frediani <[email-masked]>
wrote:

> Perhaps one of the reasons they are not being sufficiently adopted because
> of the lack examples of people and organizations using them and the main
> propose is that as much as possible organizations start to do that in the
> many ways possible, and IETF is an natural one. Really do you see such an
> inconvenience on that ?
>

Well, the other example besides videoconferencing that usually comes up
here is Github, and yes, it would be quite a large inconvenience not to be
able to use Github.

> When you say "unilateral" action I see as something natural. I don't think
> the community has to tell very detailed how the Board conduct every step of
> their business, that's why I am askinf for their consideration for this
> matter. They should have a fair amount of freedoom to decide smaller things
> like this which as I said are just administrative decisions.
>

But this is not just an administrative decision, because you are asking the
LLC board to take into account factors which are not about the efficiency
of the IETF. And for that reason I would expect the LLC to remain agnostic
until instructed otherwise by the community.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 May 2020 16:25:29 -0400

fhfrediani> Perhaps one of the reasons they are not being sufficiently adopted
    fhfrediani> because of the lack examples of people and organizations using them
    fhfrediani> and the main propose is that as much as possible organizations start
    fhfrediani> to do that in the many ways possible, and IETF is an natural
    fhfrediani> one. Really do you see such an inconvenience on that ?

Eric Rescorla <[email-masked]> wrote:
    > here is Github, and yes, it would be quite a large inconvenience not to
    > be able to use Github.

I'd like to moderate the discussion/decision slightly.

1) I would like to see native use of IPv6 for a service to be considered among
   the top-5 criteria for selecting one service over another.

2) The time I would make IPv4-only connectivity for a service to be a problem
   is if fails to work for an IPv6-only desktop/etc. system via NAT64.
   (use of XLAT464 not acceptable).
   I believe that is essentially identical to the criteria that Apple applies
   to their AppStore.

I use github.com from IPv6-only systems regularly via NAT64.
It works great, except for certain docker configurations, which are a problem
with Docker.  I haven't tried ietf.webex.com yet.
(I will note that webex audio appears to have stopped working this week from
the public IPv4 that my desktop has)

There are a number of places that are running publically accessible NAT64s.
I'm skeptical that these will survive as they are identical to open proxies
from a nuissance point of view.

{I would otherwise suggest that any IPv4-only service that we IETF decides we
*need* have a DC:SIIT proxy in front of it, operated by us.  But, it won't
work unless we put our AAAA into their DNS, otherwise TLS issues.}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 11 May 2020 10:56:01 +0200 (CEST)

> Il 08/05/2020 21:37 John Levine <[email-masked]> ha scritto:
>  

Putting together the last few messages in this thread, a logical conclusion would be that to solve this argument permanently you need an RFC that says that the IETF is not going to do this.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy