Skip to main content

Narrative Minutes interim-2020-iesg-19 2020-08-27 14:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2020-08-27 14:00
Title Narrative Minutes interim-2020-iesg-19 2020-08-27 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

Narrative minutes for the 2020-08-27 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Loon LLC) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area

Jay Daley / IETF Executive Director
Wes Hardaker (USC/ISI) / IAB Liaison
Magnus Westerlund (Ericsson) / Transport Area
Robert Wilton (Cisco Systems) / Operations and Management Area

Adrian Farrel
Karen O'Donoghue
Sean Turner
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from August 13 being
approved? Hearing none, so those are approved. Any objection to approving the
narrative minutes from August 13? Hearing none, so those will also be posted in
the public archive.

1.4 List of remaining action items from last telechat

     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.

Martin V: Still in progress. To give you a heads up, we were waiting on Pete's
feedback for the ombudsteam. He has no time so has deferred to the fellow
ombudsteam members. We are waiting for their feedback.

     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.

Amy: This was the topic of last week's informal telechat; should we mark this

Barry: Yes, thank you.

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

Warren: In progress.

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

Eric V: I was hoping to get the text today but it will be for next week. In

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at
       updating the I-D Checklist.

Amy: Murray, you had the pen on this or you were waiting for comments from
someone else?

Murray: Both of those are true. Continuing.

     o Eric Vyncke (with Suresh Krishnan) to write a draft of an IoT
       Systems charter.

Eric V: I'm waiting for Suresh's reply, so in progress for this one. Last time
we were discussing IoT operations. Should we combine those things? I will take
it offline.

     o Alvaro Retana and Martin Vigoureux to draft text on guidance
       regarding the number of document authors on documents.

Alvaro: This one is in progress, as is the next one and the other one with my
name on it.

     o Alvaro Retana, Rob Wilton, Alissa Cooper, and Martin Vigoureux to
       draft text on the framework for a long-term future plan for the

In progress.

     o Roman Danyliw to draft text for a request to the Tools Team to move
       BoF requests from the BoF Wiki to the Datatracker.

Roman: That's in progress.

     o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying
       text on Errata Best Practices.

In progress.

     o Murray Kucherawy to find designated experts for content SDP
       Parameters, QoS Mechanism Tokens [IANA #1175036].

Murray: I've reached out to a couple of people. I'll probably have something
for the next meeting.

     o Eric Vyncke to follow up on the suggestion at IETF 108 to share a
       list of grammar checking tools with the community.

Eric V: This is in progress and will be shared very shortly.

     o Barry Leiba to discuss possible datatracker feature request regarding
       flagging who is responsible for the next step for a document; the
       document authors, the WG Chairs, the AD Discuss Holder, or the
       Responsible AD, with Robert Sparks. The feature request should include
       a "length of time in state" flag.

Barry: That is in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-regext-dnrd-objects-mapping-09  - IETF stream
   Domain Name Registration Data (DNRD) Objects Mapping (Proposed
   Token: Barry Leiba

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

Barry: No, that just came in and we need to wait for the authors to respond to
it. Put this in AD Followup, please.

 o draft-ietf-bess-rfc5549revision-04  - IETF stream
   Advertising IPv4 Network Layer Reachability Information with an
   IPv6 Next Hop (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: No, not specifically, just to say that I think it's a good point and
it will be resolved. I don't think it's a difficult one. Thank you for your
review. There are also a lot of valuable comments so we will put this in
Revised ID Needed. Thank you very much.

 o draft-ietf-pce-pcep-flowspec-10  - IETF stream
   PCEP Extension for Flow Specification (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I don't think so. The authors are busy discussing. I think it's all
okay, so let's keep it in IESG Evaluation, Revised ID Needed.

Ben: There was a question about whether it's better to do something in this
document or in 5575bis. In particular relating to when you AND two different
constraints together and when you OR them together. I don't know if Alvaro had
followed that discussion or not.

Alvaro: No, I hadn't, but now that you mention it I'll go take a look and reply
on the thread.

Ben: Thanks. Actually, I think that may have been the next document, sorry.

Deborah: No, it was this one. Alvaro, do you know if 5575bis is an RFC or in

Ben: It's in the RFC Editor queue.

Alvaro: We approved it a couple weeks ago. I'll go take a look at that today. I
doubt we're going to change anything in 5575bis. It's a bis because it's
reflecting everything that's been implemented and deployed. So if we need to
clarify something, sure. If we need to change something, that's going to be a
lot harder. In any case I'll go take a look.

Amy: Thanks, let's move on.

 o draft-ietf-lamps-cms-update-alg-id-protect-03  - IETF stream
   Update to the Cryptographic Message Syntax (CMS) for Algorithm
   Identifier Protection (Proposed Standard)
   Token: Roman Danyliw

Amy: I have no Discusses in the tracker, so unless there's an objection now it
looks like this is approved. Hearing no objections. There are no notes; are
there any needed or is this ready to go?

Roman: Thank you everyone for the review. Can you please mark it Revised ID
Needed? There are a couple of good comments the author has been working with to
revise and he'll drop them in the document. Thanks.

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

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-ntp-mode-6-cmds-09  - IETF stream
   Control Messages Protocol for Use with Network Time Protocol
   Version 4 (Informational)
   Token: Erik Kline

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

Erik K: The author's been responsive on the mailing lists for all the feedback.
Thank you everyone for viewing. If there's a bit of time, it might be worth
discussing one or two points. This document is a bit unusual in that it's
bringing forward and updating an appendix from NTPv3 that was essentially not
dealt with at all in NTPv4, between 1305 and 5905. 5905 references mode 6
commands but it nowhere really goes into detail about what those are.
Apparently there have been some new commands added in the meantime, but it's
also not been updated, as Ben notes. The authenticator is particularly old.
This document does not propose to go back and fix any of it. The question of
Historic status vs Informational came up in the WG. I don't know if folks have
thoughts here on what's the best status for this kind of situation? The WG was
originally targeting Historic and during Last Call folks pointed out that it's
still being used, we don't have a replacement, etc, and there are
implementations that actually implement this.

Barry: Is it still being used only in the context of RFC 1305 or is it being
used in more recent versions?

Erik K: It's being used with NTPv4.

Eric V: Karen is here on the call and can answer.

Warren: It seems like this is still being used so it's better to have it
documented and clear instead of not. If Karen's got something useful to say we
should ask her.

Karen O'Donoghue: This document has sort of a tortured history. There is one
person who really wants it to be Standards track, one person who really wants
it to be Historic, and most people think Informational is a good compromise. It
is still being used in the context of NTP-D implementation. That is the most
widely used implementation at this point.  It's used, it's evolved a bit, but
we had sort of struggled with what the right answer is. In my latest email on
this subject I punted and said I was looking for IESG guidance.

Warren: Has anyone considered Experimental?

Barry: That would be inappropriate, I think.

Martin D: I was going to say, what about the ISE? Is there IETF consensus that
this is a good design, or are we just documenting what there is, what is
happening out there?

Ben: We can publish an Informational document with IETF consensus that this is
useful information, without saying it's a good idea.

Karen: I thought that was what we did. Part of the issue is that RFC 1305 was
Standards track, and this was an appendix in RFC 1305, so you can debate if
that piece was standards track or not, but it was an oversight that it was not
included when we published NTPv4. When this effort first started we thought
we'd just correct a mistake we made and publish the material we left out, and
as happens when you take too long to do something, all of these other
considerations come into play.

Barry: Given that discussion, Informational sounds like the right thing and it
would be useful to add some text in the introduction that says while these
things are still in use, they're not recommended for new implementations. There
is something to that effect but maybe making it clearer that they are still in
use but that use has faded.

Warren: But don't new implementations still have to do this if they want to
interact with existing implementations? Isn't it more that this is still in
use, and we acknowledge it's a bad idea, but what are you going to do?

Karen: It's more of a management piece. It technically can make changes but
nobody uses it that way, they use it to gather data. In the real world perhaps
you'd be using SNMP but people don't really monitor their NTP instances using
SNMP that much.

Barry: Maybe a sentence or two to clarify the situation and keep it
Informational. It sounds like if it's still in current use Informational is
right and not Historic.

Ben: Barry, would you have a stance about having it Informational as NTP
control mode packets vs the Network Time Foundation's NTP implementation of
control mode packets? As far as I can tell from the list discussion, that's the
only one that implements it.

Barry: I'm not sure how I would spin that. They leak, they're not just in that
one organization, right?

Karen: Right. The challenge is that a number of promotional products base their
products on the NTF Foundation's implementation of NTP. On the one hand you
could say it's just this single open source implementation out there that
people can go and get, but it's the one that's been around the longest and
therefore it's embedded in the most products.

Ben: In some sense it's the de facto reference implementation, even if it's
debatable that we call it the reference implementation.

Karen: Please don't use that word.

Barry: Thats why I think it belongs in the IETF stream and that Informational
is appropriate. Just a sentence or two to make the situation clear is all
that's needed.

Warren: Does anyone strongly object to it being Informational and tossing in an
extra sentence?

Ben: Yes, if you phrase it like that I will strongly object. I think we need to
also wordsmith the bits in the text that talk about it being Historic as well,
and that's more than a single sentence.

Karen: Okay. But with that, if we did all the appropriate wordsmithing, you
think Informational? I think we can do the wordsmithing if we just get a final
answer on Informational vs Historic.

Murray: There was one aspect that caused me to ballot Discuss and that was that
this is all plugging into RFC 1305, which is NTPv3, but the title of this is
version 4. If we're going to make clarifying text it would be nice to tease
that out as well.

Karen: Right, okay.

Ben: And part of my Discuss is that it has normative dependency on some of the
procedures from 1305 so we need to clear that up and make it self contained as
well. Or, refer to the modern NTPv4 authentication mechanisms and stuff.

Erik K: That might also be a critical change.

Roman: That's the opposite of making it self contained, is it not?

Ben: We need to not be depending on things that are obsolete.

Roman: Karen, where do folks that write the code now get their security
guidance from? Are they pivoting to the v4?

Karen: NTPv4 is the de facto implementation that's out there now. That's what
everybody is using. The question is whether you say are people moving to NTS or
are they using the 5905 stuff.

Erik K: NTS has only just been published, right?

Karen: Right. It's technically not quite published yet.

Ben: I thought NTS did get published.

Karen: No, it's in the RFC Editor queue. It's getting there.

Erik K: I think Ben's Discuss about various BCPs that we should consider, my
understanding is it would be revising the protocol. Swapping out the supporting
algorithmic agility, supporting a different authenticator, more space for the
authenticator, some mechanism to avoid the replay attack, that's all new work.

Ben: I don't really know what people are doing. It seems likely that people
took the mode 6 logic from v3 and forklifted it into the v4 code base. That
would suggest that the v4 authentication mechanisms are actually what's being
used, but I don't remember seeing a clear answer to that on the list yet.

Karen: I don't have a clear answer to that question. I think what you're really
saying is this either needs to go back to the WG to be properly updated and fit
into v4 and be published as Informational or it can be published as Historic.

Ben: That's my sentiment.

Karen: If we're just going to put a couple of sentences in and fix the
language, that's not a big effort, but I think making sure that we've updated
all the authentication mechanisms appropriately and it adequately reflects
what's in 5905 is a bigger effort.

Warren: One of the things we need to try and figure out is which is more
important, getting the document published so people can understand and read it,
or getting it properly polished and resolving all the outstanding issues and
making it perfect?

Karen: The thing is, just to further muddy the waters, the thing complicating
this a little bit is the history of how 5905 got published. We've been dancing
around doing the NTPv5 and cleaning up a number of problems that we created for
ourselves in the process of doing NTPv4, this being one of them. At the time
the NTPv4 was published there was really only the Network Time Foundation
public implementation so everything was basically what they said. Since then
there have been a number of other implementations that have come along that
have caused some contention and disagreement about what is and what is not the
way NTP should work. This is an artifact of part of those disagreements because
the other implementations don't think this should be used.

Erik K: Do we know if the community generally uses this particular
authenticator? My impression, with virtually no data, was the only safe way to
run this stuff was to use IP access control lists, say which machines can get
this data, and to effectively run it in read-only mode rather than allow any
old person to make changes to the NTP server.

Karen: I don't speak for all the implementations of NTP out there, but all of
my experience in this stuff has been using it in read-only mode as a data

Erik K: Would one option be to go back to the WG and ask if that is the case
and reshape the document a bit?

Karen: Narrow the scope to read-only?

Erik K: To avoid having to essentially redefine a protocol, including all of
its security parameters that people don't generally use? Would that satisfy
some of your concerns, Ben?

Ben: I expect so. I was going to ask if we think the editor has the energy to
make those changes or if they're just pushing to get it done.

Karen: The editor is very cooperative. He's easy to work with.

Ben: That was the sense I got.

Roman: Maybe if I can try to channel all of the input. It seems like we have a
couple of options and please correct me if I have it wrong. We can simply write
down what we'd hoped to write up and call it Historic, with the caveat that
what we have written down, we're just writing down, but no one uses it the way
we are describing it. That's one option. Option 2 is we're going to call this
document Informational, we realize there are some holes, but this is describing
how people are actually using it in the real world . Option 3 is this is
Informational and it's describing not only how people use it, but here are some
protocol changes as well that harden it. Is that fair in terms of the options
we threw out on the table?

Erik K: That's my understanding, thank you.

Roman: Personally I think option 2 may be the happy medium, which again is
bring it back, let's not try to necessarily fix it, let's bring in the
operational practices that are currently used to harden, this may not be enough
but it's documenting the real world right now. I could get behind an
Informational if it's written like that.

Ben: I could get behind an Informational written like that. Even if the
security story is pretty lousy, with the caveat that we document the ways in
which the security story is lousy, Informational is what people do even though
we know it is not perfect.

Erik K: The security section already documents a number of weaknesses, yeah.
When you say bring it back, do you mean bring it back to the WG, or just
continued work with Brian and on the list?

Roman: I guess it comes down to if we need WG consensus on those practices. I
don't have a sense of how controversial those practices are, to get those
written down. That's the discriminator for me.

Erik K: Karen and I have a sync tomorrow; we can discuss at that time whether
it really does need to go all the way back to the WG or not and if it does I'll
request that. Otherwise we can try to carry on processing feedback with Brian.

Martin D: So if this is IETF stream, should these things be in IANA registries,
all these code points and so on?

Erik K: The mode grammars are. You're saying it does actually create an IANA
registry for some stuff?

Martin D: There are tons of code, and four or five different tables here that
it would seem have IANA implications, in section 3.

Erik K: That's an interesting question. Again, I think the history coming from
the code I don't know what it would mean to file IANA requests for all this
stuff. Karen, do you have a thought?

Karen: No, not really.

Erik K: We can continue to iterate on that. Karen and I can talk tomorrow or
later today about how to handle whether we're bringing the document back to the
WG or whether we can just iterate on the feedback from this telechat. So is
that AD Followup?

Amy: Yes, I think since you're not sure where it's going to go from here, AD
Followup is appropriate.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-atkins-suit-cose-walnutdsa-00
   IETF conflict review for draft-atkins-suit-cose-walnutdsa
     Use of the Walnut Digital Signature Algorithm with CBOR Object
   Signing and Encryption (COSE) (ISE: Informational)
   Token: Benjamin Kaduk

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

Ben: I do want to talk about this, not least because there's a proposed IESG
note and I didn't spend a huge amount of time wordsmithing it and I wanted to
double check that people had actually looked at it. I'm also sympathetic to
Roman's point that we should at least consider explicitly disclaiming any
stance about the validity of the claims that are made. There was a little email
discussion with Adrian about being careful about the wording of this. My stance
here is that I plan to basically accept the spirit of the change but we'll need
to wordsmith it a bit more, possibly in conjunction with some wordsmithing
changes to the document itself. I don't know if that means we should approve
the conflict review with the expectation that there will be more wordsmithing
on the IESG note, or if we want to hold it in IESG Evaluation fora bit longer
to make sure it settles down and we have the IESG agree with the final version
of the note.

Roman: That's the process question I wanted to ask as well. I just wanted us to
talk about that. I'm not convinced my words are right but I wanted to talk
about putting that extra shim in. Process wise, should I clear my comment and
we work on it, or what do we do?

Ben: I'm open to putting extra shim in there. Given Adrian's comment I'm not
sure if we should be consulting the IETF lawyers. Alissa is probably not here
yet, right?

Roman: I don't think Adrian was implying lawyers, I think he was implying just
more precision, is how I read it. It looked like he was open to shim language
like this. I thought he was poking more at the claims of post-quantum secure vs
resilient. Since we're taking no position on the claims, we're not going to
guide what those claims are.

Ben: Right. I was not interpreting Adrian's remarks as definitively you should
check with the lawyers, but it did make me wonder.

Alissa: I don't think we need legal advice about this but should it really be
the IETF that's not taking the position, or the IESG since it's an IESG note?

Ben: When I was writing there was at least one spot when I used IESG as opposed
to IETF. 'The IETF has chosen,' 'the IESG believes.' I don't have a consistent
usage in the current text.

Warren: While you're figuring that part out, I have a question on how strong of
a smackdown this sounds. If instead this sort of comments was folded more into
the document, would we be happy without the response? If instead of us saying
you've got this document, we take no position on whether or not it's right, if
the document itself had something that it was unclear if everyone thinks it's
right, if that would change things.

Ben: Funny you should mention that, since Adrian asked me a similar question.
I'm open to that possibility but I haven't had a chance to think about it very
hard in terms of what that would look like to be in the document vs as an IESG

Warren: The IETF or IESG takes no position on a thing sort of always sounds
like we don't agree with it. Even though we explicitly say we take no position,
the fact that we feel the need to not take position carries some sort of

Ben: In this case it's true, we don't really agree with it.

Roman: The origin of why I was shimming that in is that where we previously had
national crypto kinds of things, they'd very often say in the abstract that
this wasn't IETF position but we're publishing here for code points. That's the
analog I had, because this wasn't in the text I wanted to make sure it was

Ben: I appreciate that you have done so, because it should be somewhere.

Roman: Process wise, do we have do decide this now? Can we continue to iterate
somehow in this not-decided state?

Ben: I was just going to propose that we leave this in IESG Evaluation and
bring it back next time.

Warren: If Adrian has something useful, maybe he can contribute.

Ben: I'll ask Adrian if he's comfortable waiting another couple of weeks to get
something back.

Adrian Farrel: Sure. I'm much more enthusiastic about you working on getting
the right text that makes you happy than I am about progressing this in the
next two weeks. I would say I believe it looks better if the document can go
with the right text in the document than having an IESG note. I think that
typically looks politically better but it's also more likely to be read. I
would hope that if we can come up with text that addresses all the issues and
goes in the body of the document, that's a better thing. But if we can't do
that, then I'm quite supportive of the note you've got modulo the changes under

Roman: So as the Discuss holder, I think we can work out prose that we can put
in the body of the text. To me, whether it's in the body or a note, I'm fine
either way.

Ben: So I guess we should leave this in IESG Evaluation and think harder about
the text.

Amy: Did you want to automatically put this on the agenda for September 10?

Ben: Yes, let's go ahead and do that to make sure we keep it on our mind.

 o conflict-review-turner-sodp-profile-00
   IETF conflict review for draft-turner-sodp-profile
     The SODP (Secure Object Delivery Protocol) Server Interfaces:
   NSA's Profile for Delivery of Certificates, CRLs, and Symmetric
   Keys to Clients (ISE: Informational)
   Token: Roman Danyliw

Amy: There are no Discusses in the tracker, so unless there's an objection now
it looks like this conflict review is approved.

Roman: Ben, I just wanted to make sure since we were talking about this. Sean
is ok with the text I have there, does that clear it up for you?

Ben: I believe so. I'd added a note at the top of my working copy for my
comments that are not in the datatracker yet because I still have a page left
to go in the document. Hopefully it'll be ok if I sneak my comments to the
datatracker in the next half hour. I think this is the right conflict review
response and your proposed text sounds good.

Roman: Ok.

Amy: It sounds like this conflict review is approved.

3.4.2 Returning items


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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Alvaro: Nothing new this week.

6. Management issues

6.1 [IANA #1175759] renewing early allocations for
draft-ietf-bess-evpn-igmp-mld-proxy (IANA)

Amy: This is renewing an early allocation that is going to expire next month.
Martin V, did you want to speak to this?

Martin V: Just that this document is about to finish WG Last Call so it's
renewing for just a couple of months. The document is well on the way.

Amy: So it sounds like you're advocating to renew this early allocation?

Martin V: Yes.

Amy: Is there any objection to renewing the early allocation for this document?
Hearing no objections, so we'll get note sent to IANA.

6.2 [IANA #1175809] Upcoming Parameter Expiration: Early IANA Allocations for
draft-ietf-idr-segment-routing-te-policy (IANA)

Amy: This is another early allocation that's due to expire in early October.
Alvaro, did you want to speak to this?

Alvaro: There are implementations in progress for this. IDR has a policy that
we need implementations before the drafts go forward, so it's not ready for WG
Last Call but hopefully before the end of the year it should happen.

Amy: Is there any objection to renewing the early allocation for this document?
I'm hearing no objections, so we'll get note sent to IANA.

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

Eric V: Just want to say that the INT area is currently running a call for
adoption for SOCKS v6, which is the 1996 evolution of the SOCKS v5, mainly to
improve the TCP opening by sending early data. It's currently in INT Area, I
don't know why, but there's impact as well on Transport and maybe Security.

Ben: Do we still need SOCKS versions if we have MASQUE?

Eric V: That's a very good question. It just happened today, the call for
adoption, and it's only one technical university in Bulgaria doing it. They've
done INT Area presentations mostly every IETF meeting. So honestly if nobody is
shouting that we need to adopt it, I'd say don't adopt it. I don't know whether
Transport or Security, you want to say anything else.

Ben: We can probably send a heads up to SAAG just to increase the visibility.

Eric V: That would be cool. Okay, that's it for me.