Narrative Minutes interim-2021-iesg-21 2021-09-23 14:00
narrative-minutes-interim-2021-iesg-21-202109231400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-09-23 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Ben Campbell (Independent Consultant) / IAB Liaison
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Mirja Kuehlewind (Ericsson) / IAB Chair
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area

OBSERVERS
---------------------------------
Oscar Gonzalez de Dios
Wes Hardaker
Lee-Berkeley Shaw

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 the September 9
teleconference being approved? I'm hearing no objection. Does anyone have an
objection to the narrative minutes from the September 9 teleconference being
approved? I'm hearing no objection there either. We will get those posted.

1.4 List of remaining action items from last telechat

     o John Scudder, Martin Duke, and Robert Wilton to review the document
       shepherd templates and propose changes to include updated questions,
       cross-area checks, and an expanded section on the use of YANG
       models.

Rob: We haven't met yet; still in progress.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs
       asking them to always confirm author/contributor status.
     o Alvaro Retana and Martin Vigoureux to draft text to include in the
       I-D submission tool warning about too many authors.

These two are both dependent on the previous item.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling
       normative references to non-SDO documents.

Murray: That work remains in progress.

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in October 2021.

Amy: This will happen in October.

     o Lars Eggert, John Scudder, Ben Kaduk, Mirja Kuehlewind, Murray
       Kucherawy and Warren Kumari to work on short-term improvements to
       "IETF Culture, Toxicity, Inclusion."

Lars: This is in progress but no progress is happening. Mirja is still out on
vacation. I think we can [drop] this, unless someone feels like we should get
the ball rolling again.

Murray: It doesn't seem pressing; I'd be fine with that, it just means that
next time we have any kind of major flare-up, this is going to come around
again.

Lars: I would propose to close this item and put it on the parking lot [agenda]
for the workshop with the LLC and IAB instead. Then this would be a broader
discussion than with the IESG. This is also a topic that's broader than just us.

Warren: I agree. Maybe instead of having it as a parking lot thing we have it
as a group which exists specifically with the intent to respond when stuff
starts blowing up. Instead of the next time there's major drama we run around
to see who's going to talk about it.

Lars: That makes sense, that's an excellent thing to suggest during this
parking lot topic as an outcome. Amy, can I ask you to put this on the Thursday
timeslot of the workshop, which was the parking lot day? Let's do that and
close this item.

     o The IESG to review the feedback on whether to continue the RFC 8989
       experiment 2022-2023 cycle by October 7, 2021.

Lars: I think we've gotten all the feedback we're going to get. I haven't
gotten any since September 2, which is the day after we sent this out.
Everything seems to indicate we should go forward with the option we decided.
October 7 is a formal telechat, so I guess we can leave it open until then.

Amy: Should we add a management item for October 7 to talk about that?

Lars: Yes please. Then we can close the action item too.

     o Warren Kumari to rewrite the IESG blog post on "Handling IESG ballot
       positions" as an IESG statement.

Warren: In progress.

     o Lars Eggert to report back on the maintenance of
       https://github.com/ietf/repo-files by October 28, 2021.

Lars: I think we can close this. We talked about it on the informal last week
and we have a way forward, which is for it to auto-maintain itself by screen
scraping the Trust and IETF webpage. I think this is done.

     o Lars Eggert to finalize text regarding the IETF Lists and send to
       community for review.

Amy: We have a management item to discuss the text for this so it's
provisionally done.

     o Warren Kumari to find designated experts for RFC 9108 (YANG Types
       for DNS Classes and Resource Record Types) [IANA #1208738].

Amy: We also have this as a management item so this is also provisionally done.

Warren: I have a quick question/suggestion. Specifically for the designated
experts/IANA things, can we do those at the beginning of the action items list?
Then we can often run around finding people during the telechat and that saves
us a round of annoyance. I don't know how hard it would be to organize those to
the front of the list, or if people think that's a good idea.

Amy: So instead of date order, you just want to put those at the top of the
list so you get them earlier in the call?

Warren: Yeah. Because five or six times during the call we've found the
designated experts, so by the end of the call we can suggest and appoint them.
Only if it's not hard.

Amy: This is a text list, so it's our discretion where things come up on the
list.

Warren: If nobody thinks it's a bad idea, it would give us an extra 12 minutes
to find people during the call.

Amy: I'm hearing no objections, so we can try it.

Warren: Thank you.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-tls-md5-sha1-deprecate-09  - IETF stream
   Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2 (Proposed
   Standard)
   Token: Roman Danyliw

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this is approved.

Roman: I really love the feedback and the IETF coming together to support a
document with eleven yeses. Thank you for the review. I believe all of the
feedback and comments have been addressed so I think we are actually approved.

Amy: Excellent; we will put this into Approved, Announcement to be Sent.

 o draft-ietf-opsawg-vpn-common-10  - IETF stream
   A Layer 2/3 VPN Common YANG Model (Proposed Standard)
   Token: Robert Wilton

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

Rob: Not in the context of this document. I think we can do that in the context
of the next document. I know the authors were responding back to this so I hope
they've addressed it anyway. Maybe Zahed can comment.

Zahed: I got an email and I looked at the diff and I think this is resolved.
I'm going to clear.

Rob: Okay, thank you everyone for the reviews.

Amy: With that being cleared it sounds like this one is approved.

Rob: That works for me.

Amy: Once Zahed clears, this will be approved. Does it need any notes in the
tracker?

Rob: I'll just check that everything has been addressed; I think they have and
I know the authors have been proactive at trying to address them.

Amy: This will go into Approved, Announcement to be Sent, AD Followup.

 o draft-ietf-opsawg-l3sm-l3nm-11  - IETF stream
   A Layer 3 VPN Network YANG Model (Proposed Standard)
   Token: Robert Wilton

Amy: I have quite a few discusses; do we need to discuss those?

Rob: Yes please. For the specific Discusses, on most of these the authors have
been proactive to address them. That's all progressing fairly well. I did want
to see if any other ADs wanted to comment on the document anyway. It's quite an
interesting problem they're trying to solve here. I did have a chat with the
authors today before this meeting to get a bit more background on what they're
trying to do and how it works. The key thing here is that they're trying to get
a stable base to work off of. There's an expectation down the line to have
augmentations to these models to have extra functionality as required, as other
use cases come up. One of the comments that's come in from a couple of ADs is
in terms of differences in this model vs what's being standardized in the
device models. The tricky point is trying to balance requirements of what's
coming down from the top level service model down through the network model to
the device model. They're trying to pragmatically choose in each case which one
they align to, so you get some discontinuity in those. I think they're trying
to, whenever they get feedback, to proactively address it when they can. There
are seven implementations of this already so it is being implemented by
different operators and vendors and it's been deployed once as well. I think
this has quite a strong interest going forward.

Warren: I balloted Abstain because I felt like the Jurassic Park line: your
scientists were so preoccupied with whether they could do it, they didn't think
about whether they should do it. It feels like it's going to be kind of
impossible to get a working YANG model that is not so wildly large, supporting
everything, that it's usable while also being sufficiently small that it
supports the important bits. I think maybe I was a little hasty on that so I
guess I can move to No Objection, which would be helpful for the count.

Rob: I appreciate it, Warren. And to be honest, that's a fair comment. I think
they tried really hard to have this model be the core of what's needed, and
then using Yang augmentations, you could extend them in different ways. I think
there is a fine balance here between not making a kitchen sink, throwing
everything in, which becomes as you describe unwieldy, and making it too small
it doesn't cover the use cases. I think the approach they're taking of trying
to look at how they're actually provisioning these services in their networks,
and looking at those parameters, and the ones that vary on particular VPN basis
rather than the parameters that may be common across the entire network, they
are trying quite hard to find that common subset, but it is tricky. And I do
expect there to be more stuff over time. But thank you. Any other comments or
questions? The authors are addressing those Discuss comments. I don't know
whether that will be enough to take it over the threshold. So, I'll ask the
other ADs to ballot if they haven't done so.

Roman: I guess I am not so familiar with the difference between the device
models versus the service models and the overlay. So my comments are that it
seems like we have other Yang models that provide more flexibility and I think
that's flexibility we want, which seems agnostic of device or service, and I'm
less concerned about just the reuse of the code which seems like a good idea,
but making sure that we don't lose what seemingly is good flexibility in this
iteration, whether it's improved or not in the future.

Rob: It's worth saying I have got one of the authors on the call, and they may
be able to give a better answer to that. I think it comes down to they didn't
want to put too much in because then the model becomes unusable. So they
started with almost the minimal content for their own actual use cases coming
along with expectations to extend it as needed. So that's the approach they
took, which sounds reasonable to me.

Warren: I think the biggest issue is, there are so many different things that
are called layer three VPNs, and there are so many different implementations
and vendor knobs and specific different features that everybody's added on that
the authors had an almost impossible job trying to get it, so I'm impressed
that they managed. Anyway I've changed to no objection.

Rob: Does that address your concern or not, Roman?

Roman: Well, I guess not really. If the only way I have to represent key
material in the Yang model, if I understand the Yang ism here, is with
effectively ASCII text. How do I put high quality crypto kind of stuff with
binary blobs that would require things like the hex encoding so we're actually
going back through a weaker kind of key material as a result?

Rob: I'll follow up with the authors on that specific point and see if that can
be addressed. Thank you all for the reviews. I appreciate this is sort of
slightly out of the comfort zone for what we normally review.

Amy: Okay, so it sounds like this is going to stay in IESG evaluation with
perhaps a revised ID needed as a substate.

Rob: Yes I think so. I know that Med has recently published once covering some
of these concepts, and it sounds like there'd be more changes that might be
required, so yes.

 o draft-ietf-tcpm-rfc793bis-25  - IETF stream
   Transmission Control Protocol (TCP) Specification (Internet
   Standard)
   Token: Martin Duke

Amy: I have quite a number of Discusses. Do we need to discuss any of those
today, Martin?

Ben: Yes.

Martin D: Okay, yes. I was just thinking that given how well Roman's document
sailed through it might be better just to deprecate TCP and save a lot of work.
[laughter] So, the Discuss I've had a chance to process fully due to time
differences is Lars's and I think there's an action item for the agenda to
approve all those downrefs. I scanned through these other Discusses in the 10
minutes before the meeting but I don't have anything intelligent to say about
them. I'm sure Wes will. Ben, if you'd like to bring up something in
particular, let's do that.

Ben: I think three or four of my points were basically just, in the same way
that Lars's Discuss was, to have the IESG explicitly approve the list of
downrefs. If it's easier to turn that into a management item, I'm happy to do
that. I'm not really sure how much difference it makes. And my first point,
number one, is not really one of those and we might want to discuss it
separately. My point number two is akin to a downref, in that there's some text
that appears to be at a lower maturity level that we can probably still approve
anyway because the point of that text seems to be a no brainer, like, things
will obviously break if you don't do this. Number three and number four are a
little bit less clear to me. Number three, I don't know if Amy can scroll or
not [on the screen]. Number three is sort of saying that there's a couple of
technical aspects of this spec that seem to be broken, like the appendix A.2 is
describing some scenarios where you get into a SYN|ACK loop and never complete
the handshake, similar types of things where it just doesn't actually work if
you happen to meet all of these edge cases. And that would be to me a little
surprising even to see in a Proposed Standard. On the other hand, RFC 7093 is
already at Internet Standard, and it has the same properties as this document
in that regard. So in some sense, we're not making it any worse by approving
this for Internet Standard even with these potential issues.

Warren: Specifically on that type of issue, we publish documents all the time
that have stuff in the security considerations saying warning, there's a sharp
pointy edge here. I think that this feels a very similar sort of thing. And in
the real world, you know, this doesn't really happen.

Ben: I think the document even says in the real world implementations mostly
have ways to address this, we just don't have an IETF standard consensus for
how to address it. At least that was my reading of it.

Martin D: It was an explicit non goal of this document to innovate in any way,
it's more just to update, fix really out of date stuff in this document,
address all the errata, and consolidate a few things that are incorporated here
but not to change the standard in any way. Not to hide a change to the TCP
standard in this sort of exercise.

Ben: Sure. And for my point three, that seems reasonable. I don't think that we
as a whole should hold up the document and insist on a change for this, but I
didn't want to just implicitly have my own personal feelings be the default
IESG consensus. We had a couple of people speak for point 3, so maybe we can
consider that sufficiently addressed.

Martin D: On Part four regarding their privacy review. Are we going to uncover
something new about the privacy issues at TCP? I don't recall seeing this text.
It's been a while since I did the AD review or maybe I just missed it, or maybe
I thought someone had done it or maybe someone has done it and I just didn't
know.

Ben: I don't expect broadly new issues to come up from some review; there might
be some renewed focus about particular aspects that deserve to be discussed
more prominently in this document as opposed to in the assembled body of
community knowledge about TCP. That would be my biggest expected outcome from
such a review.

Martin D: There is a late add in the text. I think it's in security
considerations, basically just for pointing out that this metadata can be
useful for people who are out to steal your privacy, in so many words.

Ben: And I also don't know who we would really ask to do that sort of review
and expect to get something back in a bounded amount of time. So, my own
personal feeling is that I'm inclined to not hold up and specifically get a
focused review like this, even though it might still be useful to have the
outcome of that.

Lars: TCP has been around for ages so I don't think we need a new review to
know what the problems are. Somebody just needs to basically look at the
analysis that has been done over the decades and write a paragraph or two.
Maybe the addition to the security considerations section that Martin talked
about is that or is the beginning of that.

Martin D: It's the very last paragraph of security and privacy considerations,
basically about how the cleartext headers expose metadata and on-path
adversaries can do things with that. And then there's a bunch of RFCs that have
further information. If there's some other aspect of a privacy exposure of TCP
that we should cover, then I'm happy to do that. I don't even know what PERPASS
is, but I feel like we've addressed that unless there's some big thing I'm
forgetting.

Ben: I think PERPASS was an IAB program that has been concluded.

Zahed: I also had a thought about this one. I saw Lars's comment and I was
thinking, well, these are the known facts, that's why we're working with QUIC
and stuff like those papers that really focus on this kind of thing, perhaps
not completely privacy related but, like, what happens with your cleartext data
or metadata. I let it go because as Martin was saying, is there anything new
out there? If there's not anything new out there I think one paragraph or two
saying like this is what it is, maybe something from the QUIC WG to say why
they're encrypting everything, would be sufficient here.

Martin D: Yes, the same paragraph I keep referencing in fact says, oh by the
way, newer protocols like QUIC encrypt all this transport header stuff based on
what we learned from TCP.  I think this particular point is concisely but
adequately addressed by that paragraph. I invite people to take a look at it
before they lift their Discuss points. And if there's some additional text I'm
sure everyone would be happy to add it.

John: I did notice that paragraph and I agree, between that and everything else
already being like Captain Obvious, I was comfortable with what was in there
anyway.

Martin D: Clearly this is a Revised ID Needed. There are also a lot of comments
that don't rise to the level of a Discuss, and this downref issue. I did
already file the action item for the downref issue but I think we need to add
one more Zahed pointed out, 6093. Amy, can we add that to the agenda item down
at the bottom?

Zahed: That's one thing, and then the other one me and Ben chatted about, and I
think we had some sort of confusion there. I put it in a Discuss comment, and
that's basically, this should be 1011 but they're saying 973 so it's wrong. You
should be pointing out, there not here, not the last octet. So the pointer is
basically saying like, here, urgent data is basically, this is the last point
we have urgent data. And then, then this was more like, to me, trying to
understand what happens. So this bis obsoletes 6093, and then 6093 says it
updates 1011. And so that's basically putting me in a situation I don't know
how to interpret when this is not a bis anymore. And Wes replied that this is
where we are. 6093 basically updating 1011, and we want to have all normative
things in this bis of 6093. That makes me say okay, shouldn't this also say it
updates 1011, because it's reversing what it was saying there. That's basically
what I'm asking. You guys are more experienced than me on this referencing
thing.

Ben: Yeah, I guess the question here is that 1011 is updating 793 itself, and
even when this bis document is published, 1011 will still be marked as updating
793, and 793 will be obsolete. And so, the fact is that you have this document
that's updating an obsolete document, and what it says isn't quite right
anymore. But what it's talking about is obsolete, anyway. Does that really
matter?

Zahed: That's my question, does it matter? I don't know the answer.

Martin D: Is there additional information in 1011 that is not covered in 793?
I'm gonna have to take a look at it, I don't remember off hand.

Zahed: No, I think we're focusing on this urgent data stuff.

Martin D: Okay, there's other stuff. So I'd have to cross check this, but one
would hope that the bit of 1011 that updates 793 is reflected in 793bis. And if
so, that bit of 1011 is not relevant anymore.

Ben: Right, that particular bit of 1011 is obsolete, in some sense.

Martin D: It hasn't changed, it's just mentioned somewhere else. So, I don't
know if that's an updates or not.

Ben: Even for this document itself, it says we're gonna update 1122.

Martin D: Yeah, okay, so it should be an update to 1011. So obviously this is
Revised ID Needed and it doesn't sound like there are any huge obstacles to
clearing these Discusses once Wes does a little bit of wordsmithing and
updating some of these fields. We have the upcoming agenda item to add all
these downrefs. I think we have a clear path forward here. Unless people have
other comments?

Ben: I guess maybe I want to go back to my Discuss point number one. I
understand and broadly agree with the WG's goal of not stealth introducing
changes to the TCP standard. Joe replied to me overnight, saying that the
strength of requirements that we have in place now have IETF consensus, and my
response to that is, well, they had IETF consensus when we published them, but
we continue to form new IETF consensus on related topics as time passes on. We
just published a decent number of protocols for which the underlying philosophy
is basically 'encrypt everything that you can, and those things that you can't
encrypt, randomize.' And that to me is sort of indicative that the overall IETF
consensus may have shifted since that time. And I don't really have a great way
to bridge the gap between the consensus we've observed recently, and the
consensus at the time these other proposed standards were published.

Roman: I just wanted to foot stomp what you were saying, which is, you know
we're opening the box after 40 years on this one, we have proven evidence that
this was a problem. This could be a problem, and I guess I just also struggle
with why we can't make a stronger statement. And this idea that we want to make
sure we keep it weak for a different class of future devices we're working on
is a very confusing design pattern today.

Lars: I have another question for Martin. Does the WG think this is like done
now and will remain unchanged for forty years, or do they think they want to
rev more frequently now that they have done the big lift?

Martin D: I don't think the goal is to change the TCP spec but the goal is to
update 793bis to be just more modern in most respects. Further TCP extensions
will continue to be new documents and not just revs to 793. There's not an
agenda item to start on 793bisbis next week or anything.

Lars: I'm asking because my gut feeling is that it's unfortunate they're
falling short in terms of what they're delivering. We had the opportunity here
to create a much more readable version of the TCP specification but they tried
to stay as close to the 793 structure and language, I guess to minimize the
diff which is great but 793 is a really old document and if you were writing it
today, it wouldn't be like that anymore. And that's just on the presentation
side; and on the other side they are conservative in terms of rolling things in
that most major stacks have already rolled in. It feels like we are updating
it, which is a big lift, but we're not really delivering everything we could
have delivered.

Ben: Yeah and if I can put a little bit of a sharper edge on at least part of
that. If I were to go tomorrow and write a draft that says we're going to
update 793bis to change these requirements I mentioned to be a MUST level
requirement, and we try to publish that as a proposed standard, is that type of
draft something that the working group would be considering?

Martin D: If it's in scope, and it seems like a short document, I don't see why
that would be an issue but I can't speak for the group consensus on that.

Ben: Of course.

Martin D: It seems like a reasonable thing to do. That seems to be how the
authors envision that kind of thing happening.

John:  I don't quite understand from the conversation so far. With this stuff
that we're talking about right now, where it's obviously the right thing, won't
somebody else think 'no actually, it's not obviously the right thing'? You
know, there is this use case for not using randomization and we affirmatively
don't want to put this into the document. Or, is it that the WG looked at all
the process documents and said oh shit, if we incorporate the slightest little
thing that isn't already a Standards Track RFC, the IESG is going to crap all
over it. What's their motivation for being so hesitant to do anything at all
aggressive?

Martin D:  I don't recall the precise context of this paragraph on the fly but
I do know that SYN cookie generation is, you know, the SYN cookie is embedded
in the ISN, and there's some times like time factors and stuff you might want
to integrate into that. I've never discussed this with Wes, it's just off the
top of my head, but that precise function may not be the one you want to use.
The appearance of being random is important, and yes, in terms of the right
thing to do it should appear to be random to outsiders. That is definitely
true. And I don't know if Wes has responded to this Discuss yet because I just
woke up, but I certainly wouldn't push back on saying it must appear random to
observers, if everyone was okay with that. It seems like a small enough thing,
and it is a little silly to write an entire RFC to say, no, this SHOULD is now
a MUST.

Warren: Doesn't that almost immediately open the huge can of worms of what is
really secret enough that you're matching the MUST? Six, chosen by random dice
roll, or four. Do we think that there are implementations where people are
likely to ignore the SHOULD and that those same people would read the MUST and
be like, well I guess I'm no longer supposed to ignore the SHOULD?

John: Two points. One is we're not the protocol police so it's not necessarily
a problem for us if it's hard for people to come to agreement on whether
they're complying with the MUST or not. And the second point is that surely
there is some basic understanding of what the word 'random' means that exists
in our industry.

Warren: Well, does it need to be cryptographically random? if you're running a
small embedded device can you actually really do that? And the protocol police,
every time we use that argument, it kind of cuts away at the meaning of MUST.
You must do this. If you don't, we're not going to beat you with a big stick.

John: Can we minute that Warren has volunteered to write the draft called yes,
we are the protocol police?

Martin D: That was already done on April 1, right?

Warren: I mean, I guess it probably doesn't seem like asking the WG if they are
very grumpy saying that we think that this is a MUST. And yeah I do actually
have a protocol police badge somewhere.

Martin D: So let's see how Wes replies. I don't think it's a violation of the
objective of this document to switch that 'SHOULD be random' to 'MUST be
random' or 'appear to be random' thing. But if Joe or someone has a giant
problem with that for some reason I can let Ben who's the owner of the Discuss
and Joe work that out. In my opinion it's not that big of a deal one way or the
other.

Ben: If there is an actual problem with making it a MUST I'm willing to be
convinced, but I would probably want to see some acknowledgement of the nature
of that problem in the document security considerations or something. I'm happy
to continue that discussion with the authors and the working group over email.

Roman: Or perhaps a middle ground is, then you have to write an applicability
statement for when would be the times when it would be acceptable to not have
randomization. Let's fully document that.

Martin D: I think that sounds like a good idea, Roman. Thanks. All right, are
there other points to bring up, or have we beaten this to death? All right,
thank you. It is a Revised ID Needed, obviously.

Amy: Okay, so I have this staying in IESG Evaluation, Revised ID Needed. I know
we're going to talk about the downrefs in the management items, but you want to
add RFC 6093 to that list?

Martin D: Yes please.

Ben: I mentioned in the slack that may be problematic because this document is
also proposing to obsolete 6093.

Martin D: Oh, so then it's not a reference. It's not a normative reference if
you obsolete it, right?

Ben: It can't really be, at least not at this maturity level. And so, if 6093
is cited in a way that would make it a normative reference and we also want to
obsolete it, that would suggest that we need to incorporate some additional
content from 6093 into this document, at least to me.

Martin D: Let's not add 6093, Amy, and we can work this out with the authors
and how they want to approach it.

Amy: Okay, and the only other thing I was gonna say is, all of the rest of
these downrefs were in the Last Call. So the world has been alerted that these
downrefs exist. We can table this discussion until the management item but I
just wanted to put out there that this was alerted that these downrefs exist.

Roman: As a side note, maybe kind of as a meta thing. I wonder whether there's
a datatracker feature that we might want to have somehow that it's easy to
track downrefs and somehow annotate that this is an okay downref and if it's in
the Last Call or not, because this seems to come up a bit. Is that too much
work?

Lars: Idnits does it but I don't think idnits does it for stuff within the
standards track, which is what we found with HTTPBIS documents recently. I grew
functionality from my own little tool and this was a good test case for that.
The draft pages have the list of references that at the moment get scraped from
the text versions and not from the XML, which will at some point change. And
based on that the datatracker flags stuff, and it also has the downref
information now, so we might want to see if there's a downref, put a red thingy
somewhere on the main draft page or something. Or on the button or what have
you.

Roman: The sentiment of my comment is let's encode the references into the text
so we don't have to remember the process and the community doesn't either.

Martin D: So we don't need an IESG agenda item to approve because it already
went through last call.

Amy: Downrefs are so confusing but the way I understand it is, you really only
need to call them out as a separate thing if they're not included in the Last
Call and the community is not alerted.

Francesca: We are implicitly approving downrefs when they have been Last Called.

Amy: Right, so that when it comes up at the telechat, these are the downrefs
that have been Last Called, they're in the document. If this document was
approved, our question to you would be, are we adding these downrefs to the
downref registry where they would go into the datatracker and anything else
that might downref these, they would already be there and it wouldn't have to
be downref-ed again.

Martin D: So there is still an IESG action here just to do the registry.

Amy: Yeah. Because this is clearly not going to be approved today, we would
come back to you after and say, Are these appropriate downrefs, do we need to
add them to the registry?

Warren: A quick question on that. The document is going to have to change, but
is there any disadvantage to asking us now if stuff should be added to the
downref registry, just because it's all fresh in our minds?

Amy: Other than the fact that the document is going to be revised and some of
those downrefs may or may not go away? No. We can always ask the question.

Warren: I personally don't see much harm in adding stuff to the downref
registry.

Amy: I mean we agree that there's no harm in adding things to the downref
registry but a previous IESG did not have that feeling so we were asked to
always ask. People can say no, you don't need to add this, it's a one-off and
it's never going to come up again. The datatracker will spit back a question to
us after we approve this document and it goes into Approved, Announcement to be
Sent, it will spit back a question saying which of these do you want to add to
the registry and we will click the ones that people say as Yes add this, or No
don't add this. It separates them out.

Roman: I think you're highlighting that it is seemingly more complicated that
we need and that was kind of my point, if we can jam any more of this logic
into the datatracker that would be a win.

Amy: So what I'm hearing is that all seven of these, once this document is
approved, all seven should go into the downref registry, for this particular
document.

Warren: I think so.

Martin D: I don't see any reason to prevent other Internet Standards from
downref-ing those proposed standards.

Warren: I still think the important part is whether the bit that people point
at is important and useful and sane and the maturity level is not that
important for this particular type thing.

Martin D: I hear consensus that we should go ahead and add them to the
registry. So Lars, does that address your Discuss?

Lars: It does.

Martin D: Thank you.

Lars: The registry is completely orthogonal.

Amy: Okay, so when this document is approved, I think we have a way forward
there.

 o draft-ietf-core-senml-data-ct-05  - IETF stream
   SenML Data Value Content-Format Indication (Proposed Standard)
   Token: Francesca Palombini

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

Francesca: I think Murray, we talked about this, so probably not.

Murray: We're good.

Francesca: And Ben, I saw your points. I think I would like to hear the authors
and the WG's answers. For the second one, I was surprised to read that and I
had missed it so thank you for bringing this up. And if you have noted
somewhere, more specifically, what is diverging from the httpbis-semantics and
ABNF that will be helpful, but otherwise I will ask the authors and the WG to
take a second look anyway.

Ben: I don't think I wrote down specific notes. I know there was one rule where
this document uses SP instead of OWS, I think it was something like token or
tchar maybe that did not include HTAB and obs-text.

Francesca: This might be an unintentional mistake, which might come from the
fact that they didn't use the semantics reference, the new documents.

Ben: Even when I was looking at this I was looking at both the new semantics
document and the old 7231 so maybe I missed some changes in between those two
as well.

Francesca: Thank you for that check; I should have done that myself. For the
first one, my first reaction was that we're probably doing it this way because
we don't have a use case to do it differently. But I need to check with the WG
to see if this was discussed and there was consensus about it, or if it's just
that we can't see why we would do it differently.

Ben: That seems like the right thing to do, ask the WG. It would be totally
reasonable to leave the protocol mechanism as is, but it would probably be
worth adding a note to say why they did that.

Francesca: Great, so we'll get back to you on these points. We'll definitely
need a Revised ID for this one.

Amy: Okay, this will stay in IESG Evaluation, Revised ID Needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-ietf-trill-multilevel-single-nickname-15  - IETF stream
   Transparent Interconnection of Lots of Links (TRILL) Single Area
   Border RBridge Nickname for Multilevel (Proposed Standard)
   Token: Martin Vigoureux

Amy: Martin V could not be with us today. I have no active Discusses for this
document, so unless there's an objection it looks like this is approved.

Ben: I guess I would like to mention in the live call that remark about why are
we publishing this? I know Martin is not on the call, so maybe I can't get an
answer. It does seem like maybe there's some wasted work here. We asked the
community to review it, we got directorate reviews, now we're going to send it
to the RFC Editor and spend what I'm told is a noticeable amount of money to
pay people to edit it, and get it published. It's not really clear that we're
getting value from that.

Warren: Well, yes. My counter to that is we had a bunch of people in the WG do
a bunch of work, and then we had a bunch of people in the IETF review it, and
then we had a bunch of IESG people all review it, and we've already sunk a
chunk of time and cost and effort into this. Is the additional bit from the RFC
Editor worth spending so that we haven't wasted all of this time and work and
effort? Presumably the authors and what was the WG thought there was enough
value in it to push this forward.

Ben: I'll assume that you are familiar with the sunk cost fallacy.

Warren: Yes, that's why I said it. It's not purely a sunk cost and we can stop
doing stuff. There is a cost in abandoning it in that the authors and people
who worked on it feel that their work was wasted and so are less likely to be
willing to do stuff in the future.

John: Ben, I have a question. Are you having a go at this one in particular
because it's AD sponsored? When I look at the entire spectrum of drafts we
advance, this doesn't rise to the level for me of saying it's not pulling its
weight.

Ben: I think the AD sponsored was a factor. It was AD sponsored because it
didn't make it before the WG closed, and it also had what appeared to be a few
periods of inactivity. It came back from those, but what's the motivation?

John: Let me propose that if AD Sponsoring turns into a bad mark against a
draft on presumption of uselessness, that creates a barrier to closing WGs.
I've known of a number of WGs in the past that have closed with a few more
documents left to AD sponsor.

Ben: That's a good point. I don't actually feel a strong need to talk about
this more today. I think that it's clear that it has the approvals it needs to
go ahead and that's the default path if we don't actively decide to change
anything. I'm not hearing much desire to actively change anything. Thanks.

Amy: Okay, so it looks like this is approved. We're going to put it in
Approved, Announcement to be Sent, but we're going to add the AD Followup so
that Martin can do his last checks before it is approved. Thank you all.

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

 NONE

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

 NONE

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 Oblivious Applications using Relayed HTTP (oarh)

Amy: I have no blocks for this chartering effort so unless there's an objection
now it looks like the OARH charter is approved.

Francesca: Let's have this name discussion once more. First, I think I have
answered all comments, except the ones about a possible name change. And I'm
just seeing now that Erik K had a comment, which I haven't answered because I
didn't see the email about it. To answer your comment, I don't think that we
need to expand the acronym. It's expanded in the name of the working group so I
would keep it this way, but we can talk about it more. About the name, I am
reluctant to change it again. I do want to get a good name, and I agree that
OHAI is a better acronym, but I am not sure that the name itself is better than
OARH. I personally like it better. But I have also sent a couple of emails
around to see what other people think, especially to those where the first name
change came from. So, I am waiting to hear a bit more from the community about
if the acronym is important enough to make this name change, or if this name is
not as good as the current one. And I just wanted to hear from those of you who
liked OHAI better if you will be willing to, I mean these are comments and not
blocks so I assume that you're fine with this name but I just wanted to hear
any additional comments today.

John: I am perfectly happy with whatever name the group ends up wanting to call
itself.

Martin D: Ditto

Francesca: Okay, thank you. This will need revision to address the comments,
and possibly a name change, so we can hold the announcement until that's done.

Amy: I believe you also need chairs.

Francesca: That's right. I am looking for chairs, and I have one, but I'm
looking for a second one.

Lars: And milestones.

Francesca: I have added them. I forgot to move the ones from OHTTP we already
had there. So thank you for the reminder.

Lars: Thank you. Sorry for not seeing it. Have you considered doing an open
call for chairs? I'm guessing the chair you have is an experienced chair, so
this might be a chance for getting somebody new into the HTTP space as a chair.

Francesca: Yes. I might do an open call and I need to figure out where to send
the open call to reach the right audience. And also I probably need to talk to
Ben and Roman and synchronize there.

Lars: Wherever you send it, CC the systers also.

Zahed: Just to check, Francesca, you sent me an email with a proposal Martin
Thomson made. Your plan is to update the charter with this one, right?

Francesca: Yes. His proposal also has the name change, which we're not sure
that we'll do. But it should answer your comment and if it doesn't, please let
me know.

Zahed: Okay.

Amy: I have that it is provisionally approved, pending the revision and chairs
and possible name change. And with that we can move on.

 o DANE Authentication for Network Clients Everywhere (dance)

Amy: Roman is our area director who is shepherding the chartering process, and
I know Roman had to drop off the call. I currently have no blocking comments
for this charter effort so unless there's an objection now it looks like it is
approved, pending a final okay from Roman.

Ben: Roman says he did make the edits that Lars suggested so I think it is just
okay.

Amy: It looks like we've got one chair. If you think that this is ready to go
we can approve it.

Ben: It doesn't actually go out until Monday anyway.

Amy: Well we can hold it until Monday. Usually these are a Friday action.

Ben: Drafts are Monday and charters are Friday, is that how it works?

Amy: Yeah, an IESG three or four IESGs ago wanted the working group charters to
go faster.

Ben: I think we can leave this in approved and send it out on Friday. Roman can
holler today if he wants more time.

Warren: A previous IESG decided that. Is it hard, if we think this one's useful
if it were to go out, just be like, hey, this one seems important because we're
running out of time. Can we do this one now? Or is it a process?

Amy: No, we can send it out at any time, really. It's already got a session
request in. So we can hold it over the weekend for Roman to do last checks or
we can send it tomorrow as we normally would.

Warren: If we think that it should be more checks, that's fine but if our only
reason for not hesitating is in case that annoys the previous IESG, then--

Amy: No, no. It used to be that everything went on Monday, and a previous IESG
was like, is there any reason we're holding the charters until Monday? Well,
no, just for you guys, and they were like, we don't need that extra time, can
you send them on Friday? Of course we can send them on Friday. You can change
your procedure at any time. Okay, so we think Roman is okay with this and it's
ready to go and we can send it tomorrow as we normally would. Sounds good.
Thank you.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Amy: Ben Campbell and Lars are the only folks here today from the IAB who can
give us any news. Is there news?

Ben C: I did not come prepared to answer the question.

Lars: Neither did I. But what I dimly remember from yesterday is that we talked
about the workshop they had on user facing network quality, I forget the exact
title. And then they reviewed the PANRG research group, which, but they
occasionally do. Otherwise I don't recall anything noteworthy.

Ben C: I remember about the same.

Amy: Okay, great. Thank you.

6. Management issues

Lars: Can I bash something that came in while we were talking? Can you add
something on at the end of this about the update that the Trust has done to the
TLP and how we're going to coordinate what needs to change on our side? This
will not take long because we can't really do much. Robert Sparks isn't on the
call and Greg is on vacation, which are the two people who need to do stuff.
But we can talk about it.

6.1 [IANA #1206926] Renewal for early allocations for
draft-ietf-idr-segment-routing-te-policy (IANA)

Amy: Alvaro, do you want to speak to renewing this early allocation?

Alvaro: Sure. So, this draft is already past Working Group Last Call and there
are implementations. The only interesting thing to note is that we actually
approved the renewal of some other registrations, about a month ago. For some
reason, they were requested in separate batches so one expired a month ago and
the other one expired now. So I think we definitely need to approve this.

Amy: Okay, is there any objection to approving early allocations for this
document for IANA? Okay, I'm hearing no objection so we'll call that approved
and we will send that official note to IANA.

6.2 [IANA #1208738] Designated experts for RFC 9108 (YANG Types for DNS Classes
and Resource Record Types) (Warren Kumari)

Amy: Warren, it looks like you have identified two people, Petr Spacek and
Ladislav Lhotka, as designated experts. Is there any objection to these two
folks being designated experts for this?

Michelle: I sent a clarification message because after further review I just
wanted to clarify that 9108 actually brought to our attention that there were
no experts for DNS classes, but the RFC is actually 6895. We do have the
experts for the resource records already so this is technically just for DNS
classes for RFC 6895. So I was just checking in with Warren that these two are
still good for just the DNS classes.

Warren: Oh I had missed that. Yeah, I think so. I think there is going to be a
grand total of zero requests for this over the next 10 years.

Michelle: Okay, thank you, Warren.

Amy: Okay so I'm hearing no objection there.

Michelle: Amy, can I provide you some updated text to include when you send it
back to us?

Amy: Absolutely.

Michelle: I'll throw it in the slack chat.

Great. Okay, so this is approved and we will send the official notice to IANA.

6.3 Downrefs for RFC793bis (Martin Duke)

Amy: Is there anything more to say on this other 'we approve these seven'?

Ben: I mentioned in the chat that several of these are draft standards that
might actually be appropriate to move to Internet Standard themselves.

Lars: That's what I was going to suggest, that we look to see if there are any
that we can upgrade. Also ECN seems weird as Proposed Standard.

Ben: How so?

Lars: That should be higher, I think is what I'm saying.

Martin D: I would be happy to do maybe a status change for 1191 or 5681 if it
doesn't require me to do a bis, which I don't think it would.

Ben: Yeah, if you're willing to take a look at if that's feasible, please do
so. That would be useful.

Lars: It's not just the status change, you can ask the working group to take a
look and see if there is  somebody that would volunteer to hold a pen on some
of these. Okay.

Amy: Okay. I think you have a way forward there.

6.4 Proposed Experiment for IETF 112: Moving the Plenary (Lars Eggert)

Lars: So there's announcement text. And I've heard from Alexa in the meantime
that the operational side has indicated that it's okay to do this experiment.
Robert believes there's some minor datatracker work that is needed. I was more
worried about the NOC and Meetecho, but apparently that's doable. So, my
suggestion would be that at the end of the call, I'll send out the announcement.

Ben: The only comment I had was that we did get some feedback that was opposed
to the experiment and had some varying levels of reasoning as to why. It might
be useful if we could acknowledge the nature of the feedback that we got in
opposition, even as we say that we are going to go ahead and try the
experiment. But I don't have any specific wording suggestions and I don't know
that we really need to hold it up on that point.

Lars: We discussed the feedback on either the informal or the last formal, I
can't remember. Do you think we should add something to the announcement saying
that we're doing it, although we didn't get full unilateral support for it?

Ben: Yeah, like in the first paragraph [where it says] based on the feedback
received we decided to go ahead, we could add another sentence like 'we did
receive some feedback indicating reasons why this experiment is problematic for
some people. We think it's still worth running the experiment to get a better
picture.'

Lars: That sounds like a good addition. Do you want to type that into the
Google Doc and then I'll wait for it to show up there?

Ben: I will try to do so.

Lars: Thank you. Anything more on this one?

Amy: I'm hearing nothing more. So it looks like we can move on.

6.5 IETF Mailing List - important-news (was: Re: "ietf-all"_) (Lars Eggert)

Lars: This is yet another thing that should go out. There was some discussion
about what name this new mailing list should have, which was the last thing. If
you haven't looked at this recently I've also added some numbers that I got
from the secretariat about how many people are subscribed and how many people
have datatracker accounts and I learned that a lot of people have datatracker
accounts, I think there's over 13,000 and only 960 of those are subscribed to
IETF-announce which is a very small fraction. I think that sort of underscores
why you'd want to do this. Jay felt very strongly that it needed to say
something like 'important' and not just news and so I settled on important-news
because it's shorter than important-announcements, which was his suggestion. We
can wordsmith it if you want to and bikeshed on it, but I would like to avoid
that.

Warren: I was just gonna note that just important is even shorter and still
clear, but it truly is bikeshedding at this point. Important@ietf.org seems
like a fairly clear, obvious thing but truly, it's just a label.

Lars: Okay. With that feedback I'll actually send both of these out tomorrow my
time so you guys have the rest of your day to take a look and suggest feedback.
And then we're going to talk to operationally how we're going to do this while
the feedback period for this is running.

Zahed: You are going to send an email so I can reply to the email? If you just
put 'important' I see questions coming like, important for whom? Am I supposed
to send important things there?

Lars: Let's just leave it as important-news. Even Warren said that it was
bikeshedding.

Zahed: I like important-news, that's fine with me.

Lars: Let's just leave it at that.

Amy: So we have important-news. The announcement will go out from Lars.

6.6 Trust update to TLP (Lars Eggert)

Lars: So this is something we talked about before. The Trust detected that the
TLP basically since forever called the Revised BSD license, which applies to
the code in our documents that we apply to various repositories that we use for
IETF work, they call it the Simplified BSD license. The text that is actually
in the TLP is that of the Revised license so it's not that we've used the wrong
license for the last however many years, but we called it the wrong thing.
They've fixed it now on their website in the TLP, but it's still wrong on some
other pages. There is also text that goes into the boilerplate of all the
Internet-Drafts and the RFCs, there's a copyright note in there that talks
about the BSD license so we would need to talk to the tools people about a
timeline for updating XML2RFC most importantly, but also idnits, and possibly
other things. And we would also want to talk to Greg about ietf.org, to check
whether we have pages that have the wrong term that we need to fix. This is
basically at the moment just a management item to make sure we sort of track
this. Greg's on vacation this week so I don't think we can talk to him and I
guess we need some more time to talk to the tools people about it. Our tools
liaison should maybe take it up with the team there. Should it be an action
item to talk about this in a week or two, or should we keep a management item
standing on this or what we want to do? [long silence] Nobody cares.

Ben: It sounds like you're describing to keep a management item open.

Lars: I think actually what I would suggest is we give an action item to our
tools liaison to engage the tool team about the needed changes, and we give an
action item to Greg, I don't know if we can do that, but we can try, to look at
our web properties and make sure that this is fixed on them as well.

Ben: I said it sounded like a management item but I meant to say it sounds like
an action item.

Lars: I think that would be more appropriate. So let's do those two things,
Amy, and I think that covers what we need to do.

Sandy: Just FYI, I was looking at these changes this morning, and the
boilerplate is in the RFCs. I was going to file a bug with the XML2RFC team,
asking them to update the copyright notices. But that would be, I think, more
specifically for the RFCs because it differs a bit. I guess maybe it could
cover both Internet-drafts and RFCs.

Lars: It's the same boilerplate I think; it's the copyright notice that needs
to be updated.

Sandy: Okay, so I'll add that there.

Lars: When you've opened that ticket can you forward it to the IESG or
something so our liaisons are in the loop and can track when we have it?

Sandy: Sure.

Lars: Great. Thank you.

Amy: Okay, so I have a couple of new action items. Do you want to keep this as
a management item for October 7 to bring it up again and see where we are?

Lars: We're going to talk about it when we have the action items so that should
be fine. Can we email Eric V that he has an action item so he knows that he has
something?

Amy: We'll alert him.

Lars: Same for Greg, I don't know when he's back.

Amy: I think he's back in October.

Lars: Okay. It's not so urgent, it just needs to get done.

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

Amy: Is there anything to discuss?

Warren: Just a really quick note. I can't remember which document, but on one
of them I thought Francesca's comments were really nice, the way she laid them
out and said these ones are actually important. Please provide feedback so I
can understand them. I can't remember which document it was but I'm going to
try and steal that as a general concept.

Francesca: I appreciate that, I'm trying. I also saw that you put the IESG blog
about the Discuss in your Discuss, and I'm going to do that as well when I
Discuss.

Warren: Thanks.

Francesca: Maybe Murray wanted to discuss a BOF?

Murray: Oh, yeah, so there was a side meeting at 111 and that group would like
to have a BOF but they missed the deadline. I asked them if they have anything
I can show to the IESG because Warren for example had said that he might be
willing to listen. And so I went back to them and asked what they have and I
looked at the non working group list they created. They haven't discussed the
charter. Although the side meeting itself was well attended, maybe five people
have posted to the list since it was created a couple months ago, and no
charter is circulating around. So I just said I don't think you've done enough
work between now and then so I don't really want to bring it up. But thanks for
poking at it. I think that there's just not enough there to support a last
minute flurry to get them in after the deadline; they should have done it by
the deadline if they were serious about it.

Lars: I'd like to do a quick executive session at the end.

Amy: Okay, there is nothing else, so let's move to executive session.