Skip to main content

Narrative Minutes interim-2020-iesg-06 2020-03-05 15:00
narrative-minutes-interim-2020-iesg-06-202003051500-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2020-03-05 15:00
Title Narrative Minutes interim-2020-iesg-06 2020-03-05 15:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2020-iesg-06-202003051500-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-03-05 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke / F5 Networks Inc / incoming Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline / Loon LLC / incoming Internet Area
Suresh Krishnan (Kaloom) / Internet Area
Murray Kucherawy / Facebook / incoming Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Alice Russo (AMS) / RFC Editor Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Robert Wilton / Cisco Systems / incoming Operations and Management Area

REGRETS
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Chris Box
Francesca Palombini
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today's agenda?

Alissa: I have a request for the action items, whether we can say if each of
them needs face to face discussion items in Vancouver so we can add them to the
list.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the February 20
teleconference being approved? Hearing none, so we'll call those approved. Any
objection to approving the narrative minutes? Hearing none, so we'll get those
posted as well.

1.4 List of remaining action items from last telechat

     o Roman Danyliw to draft text to be posted on ietf.org about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: This is not something that needs to be discussed in Vancouver. Please
mark this as in progress, along with all my other items.

     o Martin Vigoureux with Wes, and Alvaro to work on some
       mechanism to obtain wider or private feedback from people who are
       disenfranchised; anonymous flagging of offensive emails to inform
       leadership; more opportunities for private feedback.

Wes: We had a little bit of discussion over email, and there's more to be done.
I think there's a plan evolving and some face to face time at 107 would be good
to run it by everyone.

     o Alvaro Retana and Barry Leiba, with Warren Kumari, Alexey Melnikov,
       Martin Vigoureux, and Roman Danyliw to work on more transparency in
       the Datatracker about how long each phase of doc process takes / New
       datatracker flag to indicate who has the ball: area directors,
       authors, or chairs.

Barry: I've done some thinking about this so I can honestly say it's in
progress. I don't think we need to talk about it as a body in Vancouver but
those of us who are on the item can chat about it.

     o Alexey Melnikov and Warren Kumari to add keyword tags to WG charters
       to identify specs that pertain to some general concept.

Warren: I think we can discuss this face to face. It feels similar to the
previous one.

Alexey: I agree we should talk about it in Vancouver.

     o Alvaro Retana to work on a framework for analyzing new proposals.

Alvaro: I sent an email to the IESG a couple of days ago about it. I know we've
been busy with other stuff, so please take a look at it. On the one hand it may
be useful and on the other hand we may just be reshuffling stuff around. Take a
look and let me know, and based on that we can either drop or discuss.

     o Warren Kumari to work on acknowledging shepherds, directorate
       reviewers in a more standardized/formal way.

Warren: This should be either keep or discuss face to face.

Alissa: If you're not going to do any more work on it before the meeting, we
shouldn't talk about it face to face again, because we already did discuss it
face to face. If there's going to be something new we should talk about it, but
if there isn't going to be anything new we shouldn't.

Warren: Okay, then I guess I should recruit some more people to help me move
this along.

     o Alexey Melnikov to organize IoT overview discussion with interested
       ADs.

Alexey: Let's discuss face to face.

     o Alvaro Retana and Adam Roach to look at updating the I-D Checklist.

Alvaro: I think this is a Keep, but we haven't started and probably won't do
anything before 107. I'd be very grateful if someone else would want to also
work on it.

Ben and Murray will be added and Adam will be taken off.

     o Eric Vyncke to write up draft text on Special Interest
       Groups and send to the IESG for comment.

Eric: Keep this; I hope to get to this before 107.

     o Magnus Westerlund to draft an IESG Statement regarding the IETF
       as the default change controller for IANA Registration requests.

Magnus: Keep. I hope I will get to this soon.

     o Suresh Krishnan to draft a "best errata practices" document and
       post it on the IESG Wiki.

Suresh: Please keep this in progress.

     o Roman Danyliw to find designated experts for RFC 7636 [IANA
       #1160634].

Roman: That's still in progress.

     o Suresh Krishnan to write a draft of an IoT Systems charter.

Suresh: Still in progress.

     o Alexey Melnikov to find designated experts for RFC-ietf-cellar-ebml
       [IANA #1163482].

Amy: This is on the agenda as a management item today.

     o Suresh Krishnan to find designated experts for the IPv6 Low Power
       Personal Area Network Parameters registries [IANA #1163481].

Suresh: Still in progress.

     o Ben Kaduk, Alvaro Retana, and Suresh Krishnan to divide community
       suggestions in the "AD Workload" thread into workload-specific
       topics and workflow-related topics.

Ben: That's still in progress and I did add it to the topic list for Vancouver.

     o Mirja Kuehlewind to circulate email on the IESG list about
       possible IETF-specific superlatives to award.

Mirja: At some point we need to follow up but this specific item is done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ecrit-data-only-ea-21  - IETF stream
   Non-Interactive Emergency Calls (Proposed Standard)
   Token: Adam Roach

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Adam: I don't think so. The authors are being pretty responsive. I want to make
sure Ben saw Brian's response to his comments a couple of days ago. Aside from
that I think things are moving along.

Ben: I did see the email but I haven't internalized it yet.

Adam: It's obviously going to need a revised ID.

Amy: Great; so this will stay in IESG Evaluation with Revised ID Needed.

 o draft-ietf-pim-msdp-yang-15  - IETF stream
   A YANG Data Model for Multicast Source Discovery Protocol (MSDP)
   (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Alvaro: No, I don't think so. I want the authors to reply and address this.
We'll definitely need a Revised ID.

 o draft-ietf-lamps-5480-ku-clarifications-02  - IETF stream
   Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key
   Information (Proposed Standard)
   Token: Roman Danyliw

Amy: I have no discusses in the tracker, so unless there's an objection now it
looks like this one is approved. I also see no notes in the tracker; are there
any needed, or can this go on Monday?

Roman: Can you just put this in AD Followup? I have not been able to track the
conversations on some of the nits folks brought up. They seemed good but I
don't know whether they've been closed and I just want to double check.

Amy: This will go into Approved, Announcement to be Sent, Point Raised, Writeup
Needed and you can let us know when it's ready.

2.1.2 Returning items

 o draft-ietf-hip-native-nat-traversal-30  - IETF stream
   Native NAT Traversal Mode for the Host Identity Protocol (Proposed
   Standard)
   Token: Eric Vyncke

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Eric: Not for me; I don't know about Magnus or Ben. The author is already
starting to address a couple of discusses, so let's keep it in IESG and Revised
ID Needed. If it's okay for Magnus and Ben of course.

Magnus: It's fine.

Ben: That sounds fine.

 o draft-ietf-alto-cost-calendar-19  - IETF stream
   Application-Layer Traffic Optimization (ALTO) Cost Calendar
   (Proposed Standard)
   Token: Mirja Kuehlewind

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Mirja: I don't think so. Just waiting for a reply from the authors.

Amy: Do you think this will require a Revised ID?

Mirja: Probably, but I'm not sure. Let's put it in AD Followup.

2.2 Individual submissions
2.2.1 New items

 o draft-halpern-gendispatch-consensusinformational-03  - IETF stream
   IETF Stream Documents Require IETF Rough Consensus (Best Current
   Practice)
   Token: Alissa Cooper

Amy: I have no discusses in the tracker, so unless there's an objection now it
looks like this one is approved.

Alissa: You can do Revised ID Needed.

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-avtcore-multiplex-guidelines-11  - IETF stream
   Guidelines for using the Multiplexing Features of RTP to Support
   Multiple Media Streams (Informational)
   Token: Barry Leiba

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Barry: That's up to Magnus, I think. Magnus, do you want to chat with Ben about
this?

Magnus: I think we can remove the explicit reference to this section in the RFC
so it doesn't look like we override it; it's just saying it's good for
applications to use explicit mappings and have the recommendation on that level
instead.

Barry: So we're going for Revised ID Needed.

Amy: So that will stay in IESG Evaluation and Revised ID Needed.

 o draft-ietf-dmm-distributed-mobility-anchoring-14  - IETF stream
   Distributed Mobility Anchoring (Informational)
   Token: Suresh Krishnan

Amy: Suresh, I have consensus set as Unknown for this; should it be Yes?

Suresh: Yes please.

Amy: So we'll set consensus as Yes. I've got a Discuss in the tracker; do we
need to discuss that today?

Suresh: No, I got Carlos to get on it. He will respond to Ben. I see Mirja's
abstain and probably Ben will also switch to Abstain. I do understand your
position but I think it's valuable enough to get documented. This kind of thing
recurs every 5-10 years in the IETF. At least for the IETF there's archival
value in this to make sure this discussion is captured somewhere. If another WG
picks this up in ten years they'll have this as a record. I do see your point
though and thank you for making it. I'll make sure your Discuss gets resolved.

Amy: Is that going to require a Revised ID?

Suresh: Absolutely.

Amy: So we'll keep it in IESG Evaluation with a subset of Revised ID Needed.

 o draft-ietf-dmm-pmipv6-dlif-05  - IETF stream
   Proxy Mobile IPv6 extensions for Distributed Mobility Management
   (Experimental)
   Token: Suresh Krishnan

Amy: I have consensus as Unknown, should that be a yes?

Suresh: Yes please.

Amy: And I have a few Discusses; do we need to discuss any of those today?

Suresh: No, that's fine. Carlos is on them. If you haven't seen a response yet
you'll see one in the next couple of days. All the discusses are clear so I
don't think we need to discuss. There are a bunch of comments I'll make sure
they're addressed too.

Amy: Sounds like it will require a revised ID?

Suresh: Yes please.

Amy: So we'll keep it in IESG Evaluation with a subset of Revised ID Needed.

 o draft-ietf-rmcat-wireless-tests-09  - IETF stream
   Evaluation Test Cases for Interactive Real-Time Media over Wireless
   Networks (Informational)
   Token: Mirja Kuehlewind

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Mirja: I would like to have a very quick discussion. Roman, I think the point
is because there are no security concerns about simulation, that's why it's not
mentioned in the security section. I think we can add a note about it but I
think it's purely editorial and I don't think you need to hold the Discuss,
unless I'm missing something.

Roman: Part of it is that it looked like it was boilerplate, the text said it
thinks can escape to the internet, but the actual discussion of the metrics
that everything is done by simulation. Editorially, all the cleanup needs to be
is that we're doing it in simulation and there's no escape to the internet.

Mirja: The test cases are kind of defined independent of how you evaluate them.
It's not the intention of the document to say you can only do it in simulation.
From a logical point of view, especially for the wireless test cases, it makes
the most sense to do it in simulation. There's also a document which is
specifying not wireless test cases with the same security considerations. The
whole point is it's actually not the fundamental part of the document; the
document is really just specifying this test case and how you evaluate them is
a different question.

Roman: So just to replay, you're saying that while the recommendation is to do
it in a simulator, of course it might not be done in a simulator so it all
still just applies.

Mirja: Yes.

Roman: I can live with that.

Mirja: We can add another sentence there, but I don't think it's a real issue.

Roman: I'll clear if you could just add the sentence, that will work for me.

Mirja: Do you want to see an update or do you want to clear now?

Roman: I always like to see the update.

Mirja: Okay, that's fine.

Amy: So it sounds like this is going to get a Revised ID and it's in IESG
Evaluation.

 o draft-ietf-ntp-packet-timestamps-08  - IETF stream
   Guidelines for Defining Packet Timestamps (Informational)
   Token: Suresh Krishnan

Amy: I have Consensus Unknown for this, is it Yes?

Suresh: Yes, thank you.

Amy: I have no discusses in the tracker, so unless there's an objection now it
looks like this one is approved.

Suresh: Can you please put it in Point Raised? There were a bunch of comments
that came up that I'm discussing with the chairs. I'll get back to the IESG on
that. One of the things I thought was not BCP candidate was the different
formats. There's also an exception case when none of these formats fit. I'm
thinking BCP might be a bit premature but I'll have a discussion to make sure
the WG is informed that this came up and I'll turn around before the next
telechat next week and come back with a proposal to address that.

Barry: From my side it's not a downref issue, it seems like it's saying if you
do this, this is the right way to do it. If you're writing a spec about
timestamps, this is what you should do. To me that sounds BCP. But none of us
who said that put discusses on, so it's obviously [cut off]

Suresh: No, but it's a valid point, and of course I'll consider it. I'll go
back and check if there's some other background behind this.

Amy: So this will go in Approved, Announcement to be Sent, Point Raised,
Writeup Needed.

Suresh: Just out of curiosity, if everyone says this should be a BCP I'll have
to go back to last call, right? Yes, okay. Sounds good.

 o draft-ietf-rmcat-eval-criteria-12  - IETF stream
   Evaluating Congestion Control for Interactive Real-time Media
   (Informational)
   Token: Mirja Kuehlewind

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Mirja: I think it's fine; the authors need to address it. It needs a new
revision.

Amy: So this will stay in IESG Evaluation and go to Revised ID Needed.

 o draft-ietf-tcpm-converters-17  - IETF stream
   0-RTT TCP Convert Protocol (Experimental)
   Token: Mirja Kuehlewind

Amy: I have a couple of Discusses in the tracker; do we need to discuss those
today?

Mirja: Yeah, Ben, I'm wondering if we should discuss.

Ben: I guess I have mixed feelings. The protocol actually seems like it's a
pretty good protocol for use in the mobile provider networks. It's just the
text of the document tries to frame it in a different way, perhaps with a
broader scope, and that sets me off as trying to say things I don't believe are
actually true or applicable or internally consistent. I'm happy to work with
the author to try to change the text around so that it is more focused on the
narrow scope that if I understand correctly they already agreed with Roman was
the right thing to do. I'm not sure there's too much for me to discuss.

Mirja: To give the history, this was in the MPTCP working group only focusing
on MPTCP in one specific use case and then I moved it into another WG because I
really wanted the TCP experts to give feedback and also it was tightly coupled
with TCP and TCP options and now it's more an application layer on top. Because
of the application layer they made it more generic and even if you say this is
the main use case, you wouldn't prevent someone from using it in a different
use case. However, for all other TCP options it really makes very limited
sense. This is the only TCP option where it isn't a valid use case. Keep that
in mind.

Ben: I will. Thank you.

Amy: So is this going to require a revised ID?

Mirja: Yes.

Amy: So this will stay in IESG Evaluation and go to Revised ID Needed.

 o draft-ietf-dnssd-prireq-05  - IETF stream
   DNS-SD Privacy and Security Requirements (Informational)
   Token: Eric Vyncke

Amy: I have no discusses in the tracker, so unless there's an objection now it
looks like this one is approved.

Eric: Just put it as Revised ID Needed and I will look at the comments.

Amy: Okay, just let us know when it's ready to go.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-dolmatov-magma-00
   IETF conflict review for draft-dolmatov-magma
     draft-dolmatov-magma-05
     GOST R 34.12-2015: Block Cipher "Magma" (ISE: Informational)
   Token: Roman Danyliw

Amy: I have no Discusses in the tracker so unless there's an objection now, the
no problem message can go back to the ISE with the note in the tracker. Hearing
no objections, so we'll send that.

3.4.2 Returning items

 NONE

4. Working Group actions
4.1 WG creation
4.1.1 Proposed for IETF review

 NONE

4.1.2 Proposed for approval

 o WebTransport (webtrans)

Amy: I have no blocking comments, so unless there's an objection now it looks
like webtrans is approved.

Barry: Mirja made a couple of comments yesterday and I asked for suggested
text. Mirja, do you want to have an opportunity to suggest some text changes or
should we just go with this?

Mirja: I replied; I'm not able to suggest text because the reason why I'm
asking for it is that I don't know what it will be.

Barry: I don't see a particular connection to TAPS with this. If you have some
angle you think is appropriate I'd like to know what it is.

Mirja: TAPS specifies message based transport APIs so I think this is very
closely related to the API they will work on. Only the API they work on will be
specified by a different organization. I'm wondering if there's any kind of
intention to keep the transport API in mind and try to align those things, or
look at the requirements that have been specified in TAPS and maybe try to
apply them as well.

Barry: Would it make sense just to add TAPS to QUIC and HTTPBIS in the list of
wgs to coordinate with?

Mirja: I think it would make sense, if there is actually intention to do that
coordination.

Barry: We can tell them that they have to if you think it's important. I'm
happy to make that addition.

Alissa: It's important to keep clear that this group is not developing the API
in this case. It sounds more like a requirement on the TAPS working group to go
to the web transport API people, which are not in the IETF.

Barry: The wg can reasonably act as a liaison there. I think it does make sense
to say that they should make sure what they're doing doesn't conflict with what
the TAPS people are doing, and I'm happy to say something about that in the
charter.

Mirja: My point was also that I think the web transport API is not done yet. If
it was done it would be easy but it's a moving target so there should be some
way to align things.

Barry: Okay, so just put it in Approved and by the time the call is over I'll
have a quick edit done.

Amy: When your edit is done, can you let us know?

Barry: When we get to Any Other Business, I'll confirm.

 o Web Packaging (wpack)

Amy: I have no blocking comments in the tracker, so unless there's an objection
now it looks like this one is approved.

Ben: I just wanted to ask if Alexey was planning to make any additional changes
to the text. I know Jeffrey had replied some time ago to some of my comments
but I don't know if there was a plan to do anything with that.

Alexey: I'm not sure whether I missed them. How about we'll do Point Raised and
I'll check with you? I didn't think there was anything else pending.

Ben: Sure, that works. His response was not in a form that was directly
transferable to changes in the charter text, so someone would have to come up
with something.

Amy: Okay, so this is approved pending edits and Alexey, you can let us know
when that's squared away.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Transport Layer Security (tls)

Amy: There are no blocking comments. Is this going to require external review?

Ben: We should definitely go for the external review.

Amy: So external review is approved unless someone has an objection.

Magnus: Are you addressing my comment before or after?

Ben: I can address it before. I'll put the RFC number in.

Amy: Great, so we're just pending that edit and we'll make sure this goes after
that is made. Do you want a seven day review?

Ben: I don't think we're in a hurry. This can go on the next telechat after
Vancouver.

 o IPv6 over Low Power Wide-Area Networks (lpwan)

Amy: I have a couple of blocks here. Do we need to discuss those?

Suresh: No, I can add the resolution for Mirja's on to the charter. I think
this baseline technology thing came up in Magnus's and Ben's. I can expand that
out; that part of the charter didn't change from the last time around. There
were four technologies chosen, so I will make sure I can pull that out. That
part of the charter didn't change at all. That should take care of Magnus and
Ben's comments. For Eric I'll remove the marketing text as well. That just
leaves Mirja and I'll expand the reliability for retransmission stuff. So once
these are resolved we can just send it out directly, does anyone have
objections to that?

Mirja: No, I don't have an objection but I have a question. When you say
reliability do you think about something like retransmission or is it only for
error correction?

Suresh: Retransmission.

Mirja: Then I actually change my mind, I'll want to see the text first.

Suresh: Sounds good, thanks.

Amy: So when all of these edits are made does that mean we're sending this for
external review or we're just making the changes?

Suresh: I'm just making the changes and I'll throw this on the next telechat if
there's room so we make sure it gets chartered. But I really want to get this
done without external review.

Amy: Thanks for clarifying. We can put it on the telechat agenda for March 12
and you can make the changes in the meantime.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Mirja: A couple of things. For the user document the public comment period
ended yesterday so they will do an e-vote to publish this document and it's
basically done. Then they also finished the conflict of interest policy which
is on the IAB website already and Ted will announce it today. Also they talked
about the next meeting and roughly half of the IAB will be remote at this
point. Just FYI. And based on that they decided to have the chair selection
process a little bit earlier, so they'll have a call next week and the official
chair handover will be on Sunday of the meeting week.

6. Management issues

6.1 [IANA #1161777] Management Item: Protocol Number for Transparent Inter
Process Communication (TIPC) (IANA)

Michelle: We gave the IESG two weeks to look at it and ask questions.

Suresh: Yes. There's also another question that came up from Ben and I'm
following up with the author. I'm keeping track of it and I'll keep it going
for now; hopefully by next week I'll have an answer.

Michelle: So we can get in contact with the requestor to give status, does that
mean we'll put this on the telechat for next week?

Suresh: Yes please.

6.2 [IANA #1163482] Designated experts for RFC-ietf-cellar-ebml (Alexey
Melnikov)

Amy: Alexey wants to approve Dave Rice as primary and Steve Lhomme and Moritz
Bunkus as backups. Any objection to approving these experts? Hearing none, so
we will send note to IANA.

6.3 Approve experts for "The TCP Convert Protocol (Convert) Parameters"
registry (Mirja Kuehlewind)

Amy: Mirja wants to approve Mohamed Boucadair and Olivier Bonaventure as
experts. Any objection to approving these experts? Hearing none, so we will
send note to IANA.

6.4 Disposition of HIP-DEX (Benjamin Kaduk)

Ben: This document was originally scheduled on today's agenda but I deferred. I
left some high level comments but I didn't do a full review. I was proposing
that we take it off the agenda for next week to give the authors a chance to
work on those high level comments before we bring it back to the IESG.

Eric: I've been in touch with the authors and they will work on it but I don't
think they have time before next week, so let's postpone to the first formal
after 107.

Ben: That works for me, thanks.

6.5 Doodle for a COVID-19 Update Call March 10 (Alissa Cooper)

Alissa: I think we have enough responses to the Doodle to schedule this. The
10am Eastern slot is the winner. It doesn't include everybody so I'd ask people
who can't make the call to send an email to the list with your thoughts early
next week as to what you think we should do in light of the survey data that's
rolling in. Amy, please add the call to the IESG calendar.

7. Any Other Business (WG News, New Proposals, etc.)

Barry: Go with the webtrans charter for now.

Ben: Likewise for tls, the edit has been made.

Amy: Couple of reminders: Daylight savings time in the US begins next week; if
you're outside the US please check your calendar. We are also still waiting for
some AD assignments in certain areas, and if there are any directorates or any
other group that's not a WG, please let us know who will be taking those over.

Barry: Murray is going to take MILE.