Skip to main content

Narrative Minutes interim-2021-iesg-19 2021-09-09 14:00
narrative-minutes-interim-2021-iesg-19-202109091400-00

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

narrative-minutes-interim-2021-iesg-19-202109091400-00
INTERNET ENGINEERING STEERING GROUP (IESG)

Narrative minutes for the 2021-09-09 IESG Teleconference

These are not an official record of the meeting.

Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia

1.1 Roll call

ATTENDEES

---------------------------------

Jenny Bui (AMS) / IETF Secretariat

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

Mirja Kuehlewind (Ericsson) / IAB Chair

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

Martin Vigoureux (Nokia) / Routing Area

Eric Vyncke (Cisco) / Internet Area

Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS

---------------------------------

Jay Daley / IETF Executive Director

OBSERVERS

---------------------------------

Carlos J Bernardos

Toerless Eckert

Yiu Lee

Lee-Berkeley Shaw

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 the August 26
teleconference being approved? Hearing no objection.  Does anyone have an
objection to the narrative minutes from the August 26 telechat being approved?
Hearing no objection there either; we will get both of 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: No updates on this.

     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.

Amy: These two both depend on the previous item so we'll mark these in progress.

     o Eric Vyncke and Francesca Palombini to draft text for guidelines/

       best practices for directorate reviewers.

Francesca: This is done. I sent an email to the IESG mailing list so you might
have seen that. Now it's up to you [the other ADs] to update the wiki page and
advertise it to your directorates. I leave it to you to do with as you please.

     o The IESG to report on the RFC 8989 experiment after the 2021 NomCom

       is seated.

Amy: I believe this is done; it's on the website and has been announced.

Lars: Yes. Could we add an action item in eight weeks to decide what we're
going to do for the next year's NomCom cycle? This report asks for feedback and
we proposed one way forward, but we need to decide on that.

Amy: Sure, we can do that.

Lars: I think four weeks are probably enough, actually; we want to give the
next NomCom chair enough feedback.

Amy: That would be at the beginning of October.

Lars: That's fine. I haven't seen much feedback and I don't expect a flood to
come, we just need to make a decision.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling

       normative references to non-SDO documents.

Murray: This is in progress; I got the original materials from the RFC Editor.

     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: We'll bring this back up in October.

     o Lars Eggert to update BCP 45.

Lars: This is with my sponsoring AD so I'd consider this done. It's not updated
yet but it's dispatched and on the way. I guess let's bring this back in four
weeks to see if anything has happened.

Rob: Sounds fine with me as well.

Amy: We'll mark that as done and check back in on the document itself in about
a month.

     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.

     o Eric Vyncke, Lars Eggert, and Rob Wilton to work on improvements to

       authoring and reviewing tools.

Lars: I'd claim this is done now too since we have a small team now to work
with Jay on authoring and reviewing will come up there too. I think both Eric
and Rob are on that team .

Eric V: I agree. This moved to another place.

     o Lars Eggert to send email to Aaron Falk about HotRFC.

Amy: I know this was done.

Lars: Yes, it's done. Aaron is joining the next ops call with Jay and the
Secretariat on discussing what he wants to do and I'll report back when I know.

     o Francesca Palombini to find designated experts for RFC 8006,

       "Content Delivery Network Interconnection (CDNI) Metadata" [IANA

       #1207888].

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

2. Protocol actions

2.1 WG submissions

2.1.1 New items

 NONE

2.1.2 Returning items

 NONE

2.2 Individual submissions

2.2.1 New items

 NONE

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-opsawg-ipfix-mpls-sr-label-type-08  - IETF stream

   Export of MPLS Segment Routing Label Type Information in IP Flow

   Information Export (IPFIX) (Informational)

   Token: Robert Wilton

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

Rob: I think so. I'll check that all the updates have been made, so you can
just hold it for that, but then it will be good to go.

Amy: Okay, this will go into Approved, Announcement to be Sent, AD Followup and
you can 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

 NONE

3.4.2 Returning items

 NONE

4. Working Group actions

4.1 WG creation

4.1.1 Proposed for IETF review

 o DANE Authentication for Network Clients Everywhere (dance)

Amy: I have no blocking comments, so unless there's an objection DANCE can go
for external review. I'm hearing no objection, so this will go out for external
review and we'll put it back on the agenda for approval next time.

Roman: I just wanted to thank everyone for the feedback. All of those different
items are in -02 so it is ready to go for external review as-is.

Amy: Thanks; we will get that sent tomorrow.

4.1.2 Proposed for approval

 o MAC Address Device Identification for Network and Application Services
 (madinas)

Amy: I have no blocking comments; unless there's an objection now it looks like
this WG is approved.

Eric V: It's approved but some people suggested some editorial changes and
clarifications, so I will be doing it in the next hour or tomorrow morning.
Then we can crystallize on this and approve the WG.

Amy: We'll mark this as approved pending edits. It has milestones and
everything else you need once you're done with the edits, so you can let us
know when you're ready.

Eric V: Thank you for the review; there were some clarifications that were
really helpful. Thank you.

4.2 WG rechartering

4.2.1 Under evaluation for IETF review

 o Delay/Disruption Tolerant Networking (dtn)

Amy: I have a couple of blocks for this rechartering; do we need to discuss
those today?

Zahed: We have time so we can discuss a bit. I talked with Alvaro a bit and I
think this is most likely an editorial thing where we should be more explicit
about having routing discussions in coordination with MANET and RTGWG WGs. I
think that's something I've already edited but I haven't updated the version in
the Datatracker yet because we have had some more comments. Rob, with your
[comment] I got a bit confused because it almost felt like you were commenting
on the charter as well as draft-ietf-dtn-ama-01. To focus on the charter, I
pretty much think you're right that this has a lot of overlaps with the same
kind of thinking as the NETMOD and RESTCONF concepts. So I don't know the full
history of DTN but this work is the couple of things that were discussed very
early when the DTN group was formed. This was postponed to this end because
they wanted to focus on the base drafts. So it's coming back again and as far
as I can see on the mailing list there has been some discussion with Yang,
NETCONF, and CORE WGs. The response was that if you want to work with it,
that's fine. That's what I heard from the previous ADs. I don't know the
history of how much it has been discussed and how much we should do and if we
have a consensus in the IETF that this work should be done in DTN. Having a new
one rather than not extending the current ones. One of my chairs, Rick, is on
vacation and when he comes back we can have a discussion. I'll ask them to
clarify why this charter looks like this and the history of it and how much
they've been discussing with other WGs. My take is that I got really good
comments and this is what this rechartering effort is for. Thanks for the
comments and there are some WG suggestions in here that DTN should work with,
so those are very good things happening during this review and thank you for
that. Any comments from Rob or anyone?

Rob: Thanks for the background. Is it Rick Taylor who's the chair? I know he's
certainly familiar with Yang; I've had discussions with him about Yang in the
past, but I don't know if it was in this context or another context. He's
certainly familiar with the technologies. It may be that this is the right
solution. It's just trying to understand more about the reason behind it. The
reason I picked up on that document is because it felt like the recharter was
to pull that document into scope before. Looking at that document, when I
scanned through it, I'm not sure I agreed with the assumptions it was making
about why a new architecture was required. If that comes up to IESG review I'd
end up putting similar sort of comments. I think there needs to be a discussion
either to reframe exactly why this stuff doesn't work, because what they were
saying doesn't seem to hold that well. That was the thing that meshes these
together. Having a conversation with Rick and others to understand what's been
discussed so far, and whether that's within DTN or with these other wider WGs,
that would be a good thing to do before we burn this into the charter. I am
concerned about building a new manageability stack here if it's not required.

Zahed: That's a very valid observation. This WG, before it went for
rechartering, they had been discussing these addressing and naming schemes and
other things which would be very important for the operations and management of
this DTN networking. There, they are really focusing on something that has no
guarantee that it will connect to a network and there will be a long delay. You
cannot give up on the operation because you didn't get a response back. The
idea was to have a self contained data model where it knows what they want to
do in case that happens. I think let's do it like this, I'll definitely ask the
chairs and the WG to fill in the history of it and maybe we should then think
about it and to be clear why this needs to be done in DTN. Thanks for your
comments, Rob.

Alvaro: If I can add a little more to that, you're right about that, Zahed.
There are a lot of especially disruption related use cases where you can't even
assume that there's a management station. That you could ever reach a
management station. So there's a lot of overlap between that and what MANET
does. MANET is just a bunch of nodes that get together and who knew if you
could ever get to a management station at all. At some point when Spencer was
the AD we actually talked about MANET taking the AMA work. Again, there's a lot
of overlap there. I don't know if part of what needs to be done in the charter
is focus the work towards those use cases, because certainly if you can get to
your infrastructure, you can do Yang, but other security stuff, you can rely on
some server you can get configuration of keys from. If you don't, that's where
the weird use cases come in. I think that's what AMA is trying to do. That's
why I also made a comment about coordination with MANET, because MANET is in
the same boat. There are cases where we have infrastructure and there are many
cases where we just don't know. Two nodes, or 20 nodes, together, trying to
talk to each other, like that. Rick is not only the chair there but very active
in MANET as well. If you could include me in that conversation as well that
would be great.

Zahed: I'll do that. There's a lot of conceptual overlap between MANET and DTN.
That's why I think this is a very good discussion to have in this internal
review so we understand we're rechartering it for a purpose. If that's not
clear in the charter, it should be. Maybe I was listening to them in meetings
which was why it was pretty clear to me that there was separation, even though
there's overlap. Last time I can see there was some discussion about netconf
was in 2016 but there might have been more since then. It's a good observation
and thanks for doing that.

Lars: One thing to keep in mind is that DTN stuff comes from the IRTF
originally, so they were always kind of disconnected from what's going on in
the IETF because they were on the research side. Then the deployments started
and they wanted to do standards, which is why they ended up in Transport. The
first thing they wanted to standardize was the bundle, so I'm also wondering if
one way forward would be to do a small recharter that has this extension stuff
they want to do and try to do some joint meetings or make them go BoF for the
routing and management stuff to have a broader discussion. It might well be
that what they need is so different from what we have that they need to do
their own thing, but that's probably a discussion they need to have more
broadly with the community and not just talk to individuals.  That would let
them start with something now, the extensions, but require them to jump through
a few more hoops to get input for these topics that we have the blocks on.

Alvaro: You're right that they started with that bundle thing that was
definitely a transport protocol. Now we're getting to the point where it's a
lot wider. I think we need to be careful here about how we do this because the
community is very small. There's some defense contractors, aerospace guys, like
that, and the last thing we want is to put them through a lot of process and
scare them away. Yes, we should focus things; I don't know that the community
at large has more input than what they would have, but just do it carefully, is
what i'm saying.

Lars: In the past when we have  had this, we've appointed a technical advisor
to a WG; we could leave it where it is in transport but maybe they could get an
ops or routing advisor or something. We did this for NFS on
internationalization and some other topics and it was pretty helpful for that
group. Historically there was nothing the IETF did that was usable in space so
they were in this pattern where they didn't even look. Maybe they're just
applying the same pattern when we have something that might actually be useful
to them. I think specifically for the disconnected case, something in this
space might be useful on Earth too. Even for non mobile networks, partitions do
happen and it might be interesting to see if there's something that can be done
that would also address those use cases.

Zahed: Am I hearing there's a need for an educational roadshow kind of thing
where DTN can talk about their needs? Or am I hearing that the charter needs to
be fleshed out more on the requirements for the cases for the existing
protocols or extension to those are not really useful?

Rob: I thought Lars's suggestion was a good one; move ahead with stuff that
isn't contentious. There needs to be some discussion I think around some
routing protocols, so whether that could be done as them presenting in a couple
of WGs or getting together in some joint meeting somewhere; it's really just
about getting the right people together.

Lars: The other thing we could do is to make them write some informational
documents about those areas where they explain why the current IETF stuff
doesn't work for them and what solution might be useful to them. The work items
we don't know what's standards track and what isn't, but it sounds like all of
those are supposed to be standards. Maybe for those two areas, routing and
manageability, they need to do some informational work first and once they've
written those docs, ops and routing can say they're good and you can go
standardize your thing.

Rob: That's why I was actually reviewing that document; it does cover the
manageability side as to why they want to do this separately, but I was looking
at their justification and it didn't feel like they held water. It may be that
they aren't capturing the right reasons, or it may be that the technology has
moved along and they're still referencing older technology in terms of how
things work.

Zahed: Rob, I think you're right. I'd like to know more about this and whether
they just started where they left off four or five years ago without reviewing
the existing technology. I didn't feel that when they were presenting their use
cases for new chartering, but it might be good to have more of you guys
involved in those discussions and reassess that one. If the existing one
doesn't work or if they're just referring to old technology and things have
moved on. So what I'll do, I'll let it sit and let Rick and the chairs reply to
Rob and Alvaro, and then at the same time talk with them about the feedback I
got from here. Does that sound good?

Rob: Sounds good to me.

Zahed: Thanks. So if there are no more comments on this I think we're done here.

Amy: Thanks. It sounds like we're going to wait for instructions to move ahead
so we'll move on.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Martin V: None that I can report specifically.

6. Management issues

6.1 [IANA #1207888] Designated experts for RFC 8006, "Content Delivery Network
Interconnection (CDNI) Metadata" (Francesca Palombini)

Amy: Francesca has named Kevin Ma and Nir Sopher. Any objection to approving
these two as designated experts? I'm hearing no objection. Has Nir accepted the
role yet?

Francesca: I'm still waiting; he hasn't done so yet.

Amy: We'll keep that name and send an official note to IANA for Kevin, and when
you hear back from Nir, let us know.

Eric V: By the way, thank you so much, I don't know to whom, for writing in the
RFC name, rather than just the number. It makes my life so much easier.

Amy: I think you can thank IANA for that.

Michelle: I will pass on your thanks.

6.2 Approval of http core documents status change (correcting intended RFC
status to Internet Standard) (Francesca Palombini)

Amy: This is just to check if there's any objection to changing the status for
these, right?

Francesca: Yes, and also to see if anyone has any more comments. I noted that
there has been no objection on the mailing list following this last call for
the status change, but there have been a couple of reviews. The documents will
most likely get an update before going to the RFC Editor and Ben, I haven't
seen anything from your side. I think I was waiting on you?

Ben: I think Julian relayed his comments overnight my time and I have a work
deadline in a couple hours so I was hoping I could at least have until the end
of today my time to send a couple of PRs with potential suggestions.

Francesca: Have you gotten Roy's comments?

Ben: Yes.

Francesca: So you should have all the data you need.

Ben: Yes, I just need the time to process it.

Francesca: I will monitor the github and tell the authors to expect PRs. When
you have those, please do let me know so I can know the status. And thank you
for taking the time to do that.

Ben: You're welcome, and I don't want to hold things up unduly. If there's
nothing by the end of the week please go on without me.

Francesca: Thank you, Ben.

Lars: Should we look at these downrefs and see if some of them can be upgraded
on the standards track? I know that Martin Thomson is already looking at TLS.
But there are other things here that seem like they might be ready like media
types and base 16, 32, 64 and so on, and a bit of extension so should we use
this as a trigger to push some other things upwards?

Francesca: Yeah, I don't know what the process is for this. I guess the IESG
needs to look at this downref and send the document forward.

Lars: I mean, independent of this one. We can approve the downrefs and publish
this but I don't want to hold this up. What I'm saying is, now we have like a
big spec that has the downrefs, and a bunch of the downrefs seem to be things
that are pretty solid. It's time to move these pretty solid pieces, also to
full standard but without holding this particular document up.

Francesca: So yeah, two things. Does this need a different management item to
approve of the downref for this document? That's a question about the process.

Lars: Amy would be the person to know, but I think we could just minute that we
approve it.

Amy: Generally, if a document already has a downref that is in the Datatracker,
when the document is approved and we send the approval announcement, we'll get
the list of things that says that it's a downref. If a document is approved on
a telechat, we'll ask the question: Should all of these downrefs go into the
downref registry? And generally we just click on the ones that are appropriate.
Generally it's usually only the informational and experimental documents that
get downref-ed in the downref registry, if that makes sense. Like, these all
these things that say Best Current Practice or Proposed Standard; we don't
generally downref those unless you explicitly tell us to.

Lars: So formally we have to because 2026 says that anything at a lower
standards level than the document that is to be approved needs these downrefs
acknowledged so if a full standard references a Proposed Standard that's a
downref, although they're on the same track. And if it's a different track,
informational or experimental, it's definitely done.

Amy: Acknowledging those in the last call for the document is different than
adding it to the downref registry.

Lars: Right, and I wasn't talking about the registry, when we talked earlier I
actually was wondering whether we should upgrade those standards to a higher
level. Whether we also put them in the downref registry or not is an orthogonal
issue.

Rob: I mean, it certainly looks like some of these should be full standards.

Amy: Are you looking to do a whole bunch of status changes?

Lars: Yes, that's another way to put it,

Amy: Okay, because those are two different things.

Ben: You can't status change a document if there's errata open, so this would
be a bunch of bis documents.

Lars: Yeah, that's a lot less fun then.

Francesca: That's the proper way to do it, right? With a bis and the whole
process of last calling and assuming that we AD sponsor. Anyway, yeah, that's a
different thing, yes.

Ben: I'm trying to find the datatracker button to give me the list of downrefs
from the document. Is it only from nits?

Francesca: To be honest, I looked at the mail that Julian sent. I trust him,
but I think he used his own tool for that.

Ben: Yeah, I have no reason to distrust him.

Francesca: Is there something in the datatracker?

Ben: There must be something in the Datatracker of some sort.

Francesca: I guess otherwise it's the idnits tool. Okay. There is the spot in
the datatracker.

Ben: The datatracker is taking a very long time. I believe it will eventually
show me those results.

Lars: The other thing is I think Julian's email still talks about draft
standards which don't exist anymore so I think his script still has the three
levels.

Ben: Well, there still exist documents that are at that status.

Lars: That makes it worse, right, because when we did 6410 we didn't reclassify
draft standards to Internet Standard, which I believe it should have been.

Ben: The IESG has the option of going through and reclassifying at its
discretion to Proposed Standard, I believe.

Lars: Maybe we'll leave it to area directors to decide if they feel the urge to
do this, knowing that it would be a good thing to do so. I realize it's a lot
of work.

Francesca: It's more about, we would need to find people to push this forward
because we can't push it forward by ourselves. But, okay, so I guess that for
the first item being approval of the downref, do we want to leave it for the
last management item, and, and hopefully everybody else can check these by
then? I'll paste in the chat. These are for the semantics document. If you go
down the nits you see the references. Which is strange that it still says
Proposed Standard though, it shouldn't say that.

Francesca: I don't know what to do at this point because I assumed that
Proposed Standard or Internet Standard doesn't matter for the tool basically.
And what we're seeing is just downref to informational, and Amy I think that's
what you were saying, that doesn't matter that it's Proposed or Internet
Standard.

Ben: I think I agree with Lars that from the perspective of the process
documents, it does matter for what we Last Call.

Francesca: Yeah, the only thing that means is that I don't have a datatracker
way to show these references, and I'm trusting the authors and their tool to
show these references, because they also show a Proposed Standard downref. I
think they're just listing all the references.

Ben: All the normative references, that would be the straightforward way to do
it.

Amy: It's the semantics document, is that right?

Ben: Yeah, that's going to have the most references, yes.

Amy:  The second Last Call that went out two weeks ago or so, notes the
document that it updates, and all the documents it obsoletes, and then it also
has only two normative downward references and they're both Proposed Standard
documents. RFC 7405 and RFC 8446.

Ben: Amy, do you know how that list of two documents was generated?

Amy: It was generated in the datatracker. I don't know exactly how, you'd have
to talk to Robert to figure that out.

Ben: Okay, but it was automatically generated.

Francesca: I assume that this must be the references that have not been
previously approved by the IESG? Everything else that is a downref is probably
already approved. And I assume these are the ones that we would have to maybe
approve.

Amy: Yeah, the datatracker only flags things that are not already in the
downref registry.

Ben: So if we just spot check though -- the mail from Julian lists normative
reference from semantics to 4648, which is supposedly a Proposed Standard. And
if I pull up the downref registry 4648 does not appear on that page.

Lars: The datatracker thinks that is informatively referenced and that is not a
downref. I don't know if that's correct, but that's why it doesn't show.

Amy: These are only for normative references.

Ben: Okay, so that would suggest that Julian's script is incorrect, but if I go
and pull up the latest version of the draft, it does seem to list 4648 in the
normative section.

Francesca: But that is Proposed Standard, 4648.

Lars: The datatracker has a bug, because it doesn't classify this one correctly.

Ben: That's what it sounds like.

Francesca: But it could also be what Amy was saying before that because these
are both Standards track, then it doesn't show it as a downref.

Ben: Even if that's the explanation, there's still a bug.

Francesca: It might be that it's implemented correctly but the thing behind
it's not correct, the understanding behind. I don't know if I'm explaining
myself.

Ben: The bug could either be correctly implementing an incorrect understanding
of the process, or it could be the incorrect implementation of something.

Francesca: Exactly. Thank you.

Ben: So I guess that leaves the question of what we do for these documents. Do
we try to fix the bug in the datatracker and do another Last Call or do we
think that we can just approve it with IESG action? My understanding without
actually going and double checking into source RFCs is that the IESG has the
ability to approve the downrefs, even if they were not specifically mentioned
in the last call.

Francesca: That sounds right but I am not 100% sure.

Ben: I'm virtually looking at Lars. The question is, what do we do for these
three documents? Can we approve them today, or do we have to fix the
datatracker bug and rerun the Last Call again?

Lars: I don't know if we need to fix the datatracker but in order to approve
the downrefs we need to know what the downrefs are. So either we need to trust
Julian's script, or somebody needs to manually look at the normative references
in those documents so we know what downrefs we're approving, I think.

Francesca: So to look at all of them, it's everything that is not Internet, or
full standard.

Lars: And a normative reference.

Ben: All of the normative references that are not Internet Standard maturity.

Francesca: Okay, I can do that.

Ben: Is BCP okay? I'm not sure if BCP is okay.

Lars: I think BCP is fine. It's sort of a thing on the side of the standards
track.

Ben: Yeah, I think it's fine as well.

Francesca: So every normative reference that is not BCP, Internet standard, or
full standard.

Lars: Yes.

Ben: Full standard and Internet standard are the same thing.

Francesca: Yes, but aren't some of them characterized differently?

Lars: Internet standard is draft standard plus full standard. Going forward
from 6410.

Francesca: Yes, but I think some of the RFCs are still characterized
as--[crosstalk]

Lars: Not Internet Standard and not full standard.

Francesca:  Exactly.

Lars: And not BCP.

Francesca: Okay, that's what I said, yes.

Ben: There are only like 20 references from semantics. We still have an hour
left in the call, right?

Francesca: I can try to do this, but I don't know how many items we have. I
really would rather not wait two more weeks, and have this in the next
telechat. If we have an informal can we somehow make the approval then?

Amy: At this point, Francesca, these three documents have been all the way
through so many times to be on a telechat and now it's just the cleanup so
we're waiting for you to say, send these approval announcements. You know,
they've all been through a telechat.

Francesca: Yes, that's correct.

Lars: What we need to know is the list of downrefs, and that's what we're
trying to get.  I think we can do an e-vote or something if we know what they
are. We can send them to the IESG list and ask if anybody objects to any of
these downrefs.

Amy: And then you can come back to us and say, they're approved and these are
the downrefs to add to the registry or whatever.

Francesca: Okay. I will try to do this now, but if I don't make it, then we
will do it by mail. Does that sound good?

Amy: Sounds great.

Francesca: Okay. And Lars, let us know what Robert says [about the datatracker
bug]. This is what we're gonna do for these documents but what about others?

Lars: I put the ticket URL into the chat, so if people are interested you can
add yourself to the CC, and then you get updates from the datatracker when this
thing gets worked on.

Francesca: Okay, thank you.

Ben: So one of the normative references that showed up was 5322, and I could
have sworn that we had a draft underway to move email to Internet Standard. Or
is that just that we have a working group to do that?

Warren: I was unable to parse the words.

Ben: Pete wanted to move email to Internet Standard. And I forget if there's an
actual draft that was already almost done for that or if it's just we made a
working group to do that.

Francesca: Murray might know.

Murray: I'm sorry, I missed the question.

Ben: Is email going to full standard?

Murray: That's the intent of EMAILCORE, yeah.

Ben: Okay, so it is just the working group. I was misremembering about there
being a draft that was almost done. Okay, thank you.

Amy: Okay, I think we have a way forward on this management item for Francesca.

6.3 Maintenance of https://github.com/ietf/repo-files (Lars Eggert)

Lars: So this is a repository that I found on the IETF GitHub organization
recently and it's basically, I think Alissa created it a number of years ago to
give a home for specifically contribution guidelines that draft repositories or
WG repositories might want to use on GitHub. And there's some other things in
there but they are copies of things where the canonical version exists
elsewhere like the notewell or some example contribution guidelines from
existing working groups such as QUIC or TLS. So I think the proposal would be
that there's really just one thing in there that is this contributing.md
markdown template. And I don't know if that needs to live on GitHub or not but
that's the one thing that should be there, and the others I'm proposing that we
remove. I do know that most working groups heavily customize their
contributing.md, and so it's not clear to me how useful it is to have a
starting point that's available but there's no harm in it. Let me see if I'm
forgetting anything now or if that was it. I thought there was a reason why I
wanted a maintenance team, but having said what I just said I don't think we
need one. But it might be the case that I'm forgetting something.

Rob: Quick question; if somebody spins up a new working group they use Github,
where will they take the source files from? Will they just take them from
another existing one, or…?

Lars: One of the GitHub Working Group documents links to this repository saying
there are some templates here so that for that reason, it needs to stay around,
right. There's a license.md, which is basically the Trust license for open
source repositories and the canonical text is actually over on the Trust
website. This is just a markdown copy. And so the question is how do we make
sure that this thing doesn't get stale? There's contributing.md, which is
basically a copy of what is in, or was at some point in, Martin Thomson's ID
template repository. If we trust that Martin has sensible text we could just
point to that instead of maintaining our own copy.

Mirja:  I would actually assume that this was intended to be the other way
around, that Martin Thomson would use this official one from the IETF instead
of having his own copy maintained.

Lars: I don't think anybody has talked to Martin about this and he's changing
his, as he realizes things. His is the default for many reasons because people
just take his stuff and it comes from there.

Mirja: Yeah, but I think it wouldn't be too hard for him to add to his script
that he would actually pull this repo and then take this as the basis for
whatever is in his repo.

Lars: We can ask him if he can make it a sub module or something so it
automatically gets populated from ours. But that's really the only thing. The
other thing might be that we want to ask the Trust to maintain a markdown
version of their license that we can pull. I noticed that the TLP actually has
a bug that the Trust is at the moment fixing. Basically ever since its
existence, the TLP has called the revised BSD license the simplified BSD
license. The text they have in the TLP is that of the revised license, but they
call it simplified, and that made it into the boilerplate. For example, it goes
in all the I-Ds and all the RFCs so we published like 3500 RFCs where the
boilerplate says this is subject to the simplified BSD license when it is
actually the revised BSD license.

Ben: I think you sent mail to the IESG list about this already.

Lars: I did. But the problem is that they're fixing it now, and so we also need
to fix it and these discrepancies, if we copy material around rather than
having a canonical version somewhere, is hard to maintain.

Rob: And that was the point I was trying to get to, Lars, is that if, if people
don't have a canonical version to use when they create new ones these are
updated, then it gets harder, whereas if there is somewhere they can always
check and find the canonical version that's good. And in this case I sort of
agree with you, it's better to reference the stuff from source than to maintain
separate copies that have to be updated through some manual process.

Lars: The only problem is that the Trust license isn't the markdown document so
it's, you know, it's a web page. And Martin Thomson's is somewhere over there.
It's a markdown document but it's not in this repository.

Erik K: With respect to the note well and the license, I wouldn't necessarily
remove them, because I think it might contribute to them being forgotten. If
they were renamed to a template and that template.md file just said, pull the
latest version from this URL and stick it in here before you finish
initializing your repo, would that be a way to maintain it?

Lars: But the note well will also change, or has already changed, since this
became populated, and it will change again, once the antitrust BCP makes it
through Gendispatch, which is currently being discussed there, because we're
going to add another BCP to the list of BCPs that you need to be aware of and
so it'll change the note well. We don't change these things often. But we
change them often enough that having multiple copies around this is annoying,

Erik K: I see, so even just making a copy when you initialize your repo will
eventually get out of sync.

Mirja: What's the canonical version, the source we should use here?

Lars: I think it's the one that's on the IETF website, which Greg maintains.

Mirja: It's on a number of slides, or just the text on the website?

Lars: I think it's the text on the website but Greg is on the call so if that's
wrong he can tell us.

Mirja:  Because like for those things that we actually do change from time to
time it would be nice to have them in a Git repo and pull everything else from
there so actually pull the text on the web page from this Git repo, rather than
the other way around.

Lars: Yes, I agree. There's a little bit of a problem with the separation
between the LLC and the Trust because I'm not sure how comfortable the trustees
are of pulling their legal documents from an IETF owned repository.

Mirja: Yeah I guess they don't have a repo anyway but maybe they could just
provide us an empty version of this, and we could pull it from them.

Lars: My expectation would be they do what we did here and they're gonna make a
markdown and give it to us and then they never give us another markdown.

Mirja:  The idea would be rather to just upload the markdown on the Trust web
page and give us a link so they have it in their sources.

Lars: They don't have a markdown version.

Erik L: Does the full text have to be in every repo, or does it suffice to say
have a note well or every readme.md has to have a link to the note well.

Lars: According to what's there it needs to be in there. It says there's
official boilerplate text, and it says this repository relates to activities
the IETF blah blah blah. So they do actually want that it's another bit of
boilerplate that isn't the note well that's supposed to be in this repository
as a license.md file.

Mirja: Yes, for the license, it's usually good to have the separate file but it
could also just point to some other web page. It doesn't need to have all the
license text in this empty file.

Lars: Yes, but they've decided that this is what they want. So I agree that you
know a link might be all that's needed but this is what they want. The Trust.

Mirja: Okay now I think we're talking past each other. So the licensing file in
this Git repo.

Lars: Yes, comes from the original that's maintained by the Trust. It's not
something that we can change.

Rob: Mirja's comment was can we change license.md just to say go here to see
the license. Is that not…?

Lars: I don't think so because the Trust webpage says you need to have this
text in your repository.

Rob: Another choice, I know this is a bit horrible, could be to have a script
that screen scrapes the license off the web page and generates an md file or,
you know, or something like that, or checks whether it changes for example.

Lars: Yeah, that's a fair point. Let me think a little bit if we can, we can do
something like that so we don't have to actively monitor things. Alright, I'll,
I'll get back to you guys on this in a little while. This is not super urgent,
I just noticed it this week and I wasn't sure what the status was.

Mirja: It would be good to reach out to Martin Thomson and see if he can use
these files and if we want to keep them so that people who actually use the
scripts use the right files.

Lars: Yes. Once we have a way to have this repository be canonical, or at least
not out of sync with what's canonical, I think it makes sense for Martin to
pull them and I'm pretty sure he would.

Erik K: Also the IETF Trust link points to Martin's contributing rather than
this one.

Lars: Yeah, it's an example.

Erik K: Yeah, but the IESG repo was not listed as an example.

Lars: The bottom one where it says official boilerplate text, I think that's
what they're looking for. And it's not what Martin has in his contributing.
Anyway, okay, I'll get back to you in a little while on this. Can I get an
action item like an eight weeks or something to remind me that I was gonna do
something here? [Make it] Report back on maintenance of this repository.

Amy:  Sure, we can do that. That will be the end of October-ish.

6.4 Adding a second IESG rep to the IETF-IANA team (Lars Eggert)

Lars: This is something that actually I discussed already with Alissa during
the handover, this team of IETFers that occasionally meets with IANA to discuss
how things are going and review progress reports. The chair at the moment or,
well, also in the past has been the only IESG member on that little team and
there was a discussion that it might be helpful to have a backup, or a second
person involved. If anybody feels strongly about our relationship to IANA and
wants to participate, let me know and we'll add you. I think it's a monthly
call with you guys, Michelle?

Michelle: Yeah, not even monthly. We have scheduled meetings that correlate
with the three IETF meetings per year. We will add an additional meeting every
so often, if there's something specific to discuss. We have a very small
mailing list, very low volume, and not too many fireworks. Pretty much business
as usual but the group is just to help deal with any issues that come up and
working together with the IAB representatives and hopefully the IESG and I'm
just monitoring and making sure everything's going all right as Lars said.

Roman: I'm happy to give you back up on that.

Lars: Does anybody want it more than Roman?

Warren: I'm happy to help as well but Roman sounds more excited. I could be
backup to Roman who's backup to you.

Lars: I don't see a reason not to add two people, Michelle, if that's okay with
you guys.

Michelle: Yeah, I'll go ahead and add Warren and Roman to the mailing list.

Lars: Thank you. And thanks for volunteering, you guys.

Mirja: I think because that's an IAB support activity so we also want to update
the datatracker there and list all the members. I'm not sure, even if that's up
to date. I would double check.

Michelle:I was gonna say Mirja I can also double check that and send mail.

Cindy: I'm also on the call and I can do that update.

Mirja: Okay, so I definitely don't have to do it.

Michelle: Thank you. I'll work with Cindy.

6.5 Designated Experts for RFCs 8007 and 7975 (Francesca Palombini)

Amy: Francesca, it looks like you have identified two people to be the
designated experts for these RFCs;  Kevin Ma and Ben Niven-Jenkins. is there
any objection to naming these two people as the experts for these two RFCs? I'm
hearing no objection so it looks like these two folks are approved as the
experts and we will send that official note to IANA saying so. Thank you.

6.6 Next steps on "handling IESG ballot positions" (Ben Kaduk)

Ben: Yes, so I added this because it came up in a call that we had with the
HTTP authors but it seemed apropos to bring it back up. Warren wrote this
document about six-ish months ago and it's pretty useful. It's currently just a
blog post on the website. And I think at the time, we had talked about
including a link to that post or something like it in the actual emails that
the datatracker sends with IESG ballot positions, but I don't think that ever
actually happened. And so I just wanted to cycle back and ask again. Do we want
to do something like that? We could also bless this document and make it a
little bit more official by publishing it as an IESG statement, possibly with a
little bit of rewriting to take all the fun out of it. But I think it's a very
useful document to have and we should try and make it more prominent. So I
wanted to see what other people thought.

Francesca: Just to add to that. The feedback we got from the authors was that
this was really good, and they would have liked to have seen it before. And
that's why they said it would have been good to have it as an IESG statement or
something like that.

Ben: There was a qualification on 'this is really good' because it misspelled
Mark Nottingham's name.

Warren: For obvious reasons I think that it should be an IESG statement, but
I'm biased. I have had a couple of places where authors have been like, I got
this thing and I don't know what I'm supposed to do now I clicked go and it was
sent to the IESG so presumably it's all done. What am I doing with these ballot
things, help! I've pointed them at the document and they say oh wow, great, now
I understand what I'm supposed to do and this isn't so scary. And so I think we
should do it as an IESG statement.

Alvaro: So if the objective is to get people to actually see it, I don't think
an IESG statement meets that because no one knows where the IESG statements
are, no one remembers them and much less go look for them, and you get the
ballot. So I like the other idea of putting a link to it. People will have to
click on the link, put a link on it when we send ballots. Maybe just Discusses,
I don't know if [we should do it for] everything. But that would give it more
visibility than just a web page because the blog is there but it would be the
same place as an IESG statement. So I like the idea of something with the
ballots.

Warren: Okay, I mean, I think possibly both. People do actually read the IESG
statements and if we think they don't we should give up on doing them.

Alvaro: They might read it at the beginning when they come out. I just don't
think they go back and refer to them later.

Warren: I just didn't see harm in having it as a statement, as well, because
that makes it seem more official than some random thing that some random person
wrote and we stuck somewhere.

Mirja: For me that's the difference. It's also helpful to point people at it
saying this is the official position of the IESG, but you know, in this case
having a blog post was already doing it and this step that you need to point
somebody explicitly to it will not change for IESG statements.

Ben: When the blog post first came out, we did have a few people make some
effort to link to it, some of the time, and then we stopped doing that, which
is understandable.

Francesca: I remember it was a blog post, but even some of us didn't remember
where this got posted, and I think one of the authors even mentioned, Oh, how
did I not see this? I'm getting the feed from the blog and still didn't see it.
So I disagree with Alvaro that IESG statements are as seen as the blog.

Alvaro: People will have the same hard time finding the statement as they have
the blog, not that they're the same thing.

Warren: I sort of see what you say but I know how to find IESG statements so I
can send people a link. I type in IESG Statements.  I actually have no idea how
to find this document anymore.

Mirja:  The blog post I can find easily on the webpage but statements are very
hidden. I have the problem the other way around.

Warren: Can you find stuff on the website, without knowing what the document is
called?

Mirja: The blog post is relatively easy to find.

Francesca: I think having both. Maybe the IESG statement should be slightly
rephrased.

Mirja: But an IESG statement has a different purpose, it says this is how we
interpret this, this is how the community should expect the IESG to do
something.

Warren: I thought we'd also discussed this. We don't send out very many IESG
statements, and we had discussed trying to make them more common and friendly
and useful to the community partly so that when we do send them out, they're
not viewed as, you know, a major thing that the IESG has spent hours and weeks
discussing and thinking about, but more, interesting things that you all should
know. I guess people could say that's what the blog is for but I think it's a
fairly different thing. I had actually put in a pull request, or something to
update the datatracker to point at the statement but I can't find it.  I
thought actually the datatracker was supposed to point to it but I have no idea
where that went or if it ever got integrated, or what.

Mirja: I remember the discussion about how to use IESG statements but I don't
remember that we came to some conclusion. I think IESG statements have value
where we actually write something down that has IESG consensus, and we are able
to point people to that in future. And I think keeping this value means you
have short statements from time to time. And if you want to communicate more
often with the community than having a blog post, sending emails, having
different mechanisms are the right ones.

Warren: Okay, I mean this, this was published on the blog towards the end of
February. I don't think any newcomer is going to go and look at our blog and
scroll all the way back, looking at random stuff till they stumble upon it.

Mirja: No newcomers will look through all the IESG statements. I understand
your problem. I think there's something we need to fix and I'm all in for it
because it's a really good document, but I don't think publishing it as an IESG
statement will help in any way.

Alvaro: Can we start with linking it on the ballots, and then worry about it
when we change the form?

Warren: So apparently this is supposed to already have been integrated into the
something something. Robert Sparks integrated a pull request type thing so it
shows up in the ballot comment mail whatever that counts as. I will put a link
to the ballot comment mail, although the svn tools link is now broken. So in
theory it's already being included in something somewhere but I don't know
where. So yeah, it seems broken.

Mirja: So I think, you know what you want is really to make sure that authors
who don't have a lot of experience in the IETF and don't know this process,
read this document before their document enters IESG processing. And I think
the way to achieve that is to educate our shepherds and chairs, and make sure
those people point the authors at this document at the right point of time.

Rob: Can we somehow get the tooling to when it moves the documents into IESG
eval, it automatically emails the authors with a link to this post, or
something like that?

Mirja: I'm not against it, I'm just I think if you create any automatic emails
with this information, people will not read it. I think you need to manually
figure out who are the authors that need to be addressed and send them the
information right away if you really want to get this in.

Ben: I think manual processes will not be fully reliable. Maybe we want to do
both.

Warren: I think we want to do both.

Lars: I have no problem with republishing this as an IESG statement.

Ben: I think I'm hearing three or possibly four different things that we could
do. One would be to republish as an IESG statement, another would be to include
a link to it from the ballot position emails. A third would be to include a
link to it in an email that goes out when the document changes into like IESG
evaluation status or the ballot gets created or something. The other one was
encouraging shepherds and working group chairs to do it.

Lars: The one thing that's already in the ballot email is the discuss criteria
IESG statement, so I'm wondering if we should either add it to that paragraph
in the email, or we add it to the webpage and say, you know, start reading here.

Warren: So as I say I put in a request to change the "please refer to blah blah
blah for more information," and I'd gotten something from Robert saying that
that had been fixed or integrated. I'm trying to see if there's a way I can
send a link to it. Maybe that got reverted or lost, or something.

Ben: Maybe it was only on a branch that didn't end up anywhere useful.

Warren: We should be able to re-change it because it was approved. It also
seems like the tools/tickets system disappeared or exploded, or something.
Okay, there we go. I found the ticket. So in theory, this ticket where I
provided the change was fixed in blah blah blah and merged in blah blah blah
five months ago, but it seems like that isn't working. So I guess I will ask
Robert to redo it. But I still think we should also do it as a more visible
statement as well.

Ben: If I click through to change set 78911 It's just removing the word IESG.
So the link says 'for more information about DISCUSS and COMMENT positions.'
That does not seem correct.

Mirja: It shouldn't remove the link to the discuss criteria, it should just add
another link.

Ben: Right. The one word change did not do that. It's just a plain text word
that was removed.

Mirja: So I guess Robert didn't see that he didn't actually change it.

Warren: Okay, so we can get this part done.

Mirja: In this case, it's maybe better for the tools liaison to reach out to
Robert directly, because it's a larger change.

Lars: I reopened the ticket; you should get email about this.

Ben: And just a minor point, Amy, can we edit the existing blog post to fix the
spelling of Mark's name?

Warren: Greg has fixed it.

Ben: Excellent.

Warren: How do we make it so that it's more noticeable? I think one thing we
might want to do is link to it wherever the new authors site is going to be, or
the I-D guidelines. I still think it's worth having it as an IESG statement as
well for multiple reasons.

Ben: Amy, please give Warren an action item to rewrite this for an IESG
statement.

Warren: Do other people agree with that? I'm happy to do so.

Eric V: I agree. The only thing we need to be clear is replace the blog post
and point to the IESG statement, because I don't like two places having similar
information.

Warren: That's reasonable. How much different do people want it? I think it's
fairly done but I'm guessing that people want it a bit less informal.

Francesca: Yes,a bit less informal.

Mirja: I don't think this is the right use of an IESG statement but maybe we
could actually get a much, much shorter IESG statement that then only points to
the blog post for the extended version.

Ben: I propose that we let Warren come up with something, and we can look at
the actual concrete proposal. We were, after all, going to have a short meeting
today.

Lars: Greg in private chat has pointed out that there's another thing on the
website, that I put a link to in Slack just now, about IESG ballot procedures,
which a past IESG approved. So there's some overlap there. Maybe we should give
Warren an extended action item to figure out whether his thing subsumes what's
there and should replace it or if there is something that can be merged from
there.

Warren: I've thought about this and I don't think mine does subsume it. I think
this is more advice for the AD so we understand what we're doing. And I often
copy and paste from this text because I think it's really useful. So I did
actually look at that when I first wrote the thing. Maybe we could have them
point to each other just for more links.

Amy: Okay, so I just have that action item for Warren, and then unless there's
anything more to discuss on this we can move on to our next management item.

6.7 Refactoring ietf-announce (Lars Eggert)

Lars: This came out of a one on one discussion with some ADs, and Mirja was
involved quite a bit, and also Jay.   What we heard from the feedback from the
community is that the list is too noisy and therefore, they don't want to be on
it. And, while other people really like what's on it, I think there was
somebody that really liked that every single internet traffic gets announced on
that list, but many people don't don't care. And so the proposal would be to
really make ietf-announce the most minimal we can, only include the things that
really everybody should have seen, and create either push other things to
existing homes or find new homes for them. And what's there in this textbox is
the current proposal that I synthesized from a whole bunch of discussion. And
basically we would keep on ietf-announce all the stuff that is manually sent by
me or Mirja or Jay or the Secretariat, which are the things that are not
automatically generated by the datatracker. I think we also want to keep new
charter announcements; although these are datatracker generated I think they
are infrequent enough and broadly interesting enough that we want to keep them.
There's a question of whether we want to keep WG conclusion emails. I think
they're rare enough that we can, but it's not  so generally interesting I guess
when WGs close so that's up for discussion. There's another mailing list called
new work @ ietf.org that was originally set up in the dark ages for the IETF to
post to but also other standards bodies to post to, I think the IEEE uses it
occasionally and sometimes the ITU-T, so it's basically an inter-SDO list to
inform each other of new work.

Ben: Some of the lore I heard about that was that it was intended to be
restricted distribution because some of the external SDOs didn't want to make
all of their stuff public and there's loophole on that because the IETF secdir
list is subscribed to new-work and secdir has public archives. So if you know
where to look you can see all of the content.

Lars: We could make that public or we could make a new list to basically add WG
stuff on it. So I think those are  more or less equivalent. And then we would
also probably want to keep the IESG announcement of new non-WG mailing lists
simply because they are generally interesting by definition. And then there's
stuff that we will move elsewhere. One is new RFC announcements. There's
already a list the RFC Editor maintains so we can basically just take those off
and tell people that if you're interested, subscribe over here. The IESG and
LLC telechat announcements. I think the IAB's for some reason don't go there
but I don't think the telechats are public, are they. Basically we could
announce them in some other way. Maybe on a new list or somewhere. There's also
the standing idea to have an IESG-discuss list, or something like the IAB has,
so if you want to discuss topics with the IESG publicly post them there. I
think LLC telechats are already announced on admin-discuss, so they will have a
home anyway. Document actions; the proposal is that they would really only go
to the WG mailing list in question where they are already CC-ed to anyway.
Conflict review results, it is a little bit of a question mark. We do them for
ISE and IRTF documents. Where would those get announced? They're not so
frequent that we couldn't put them in ietf-announce but I also think they're
not so generally interesting that we need to put them there.

Ben: I agree they're not enough interest to merit going to ietf-announce.

Lars: We could put them on the same document actions list if we created a
separate one for those. Charter updates; I think new charters definitely should
stay on ietf-announce; the question is should charter updates stay there. I
think somebody made a suggestion privately that they are also low volume enough
that we could keep them on ietf-announce and that's fine with me too. Last call
announcements are already CC-ed last-call and we would only have them there.

Alvaro: I thought that when we created last-call, the point was to advertise
last calls as broadly as possible but then to limit the discussion to the
last-call list. So, if we don't do it in ietf-announce or some other really big
list, we're only telling people in the last-call list that this is being last
called.

Warren: I'm fairly concerned with this because it feels like we're putting the
ones that we think are important and interesting in ietf-announce and other
ones and other places and this is our view of what's reasonable, and our view
might not line up with other people's views. I think interim working group
meeting announcements should be announced everywhere, and new RFCs, etc. So I'd
be a lot more comfortable if instead of us changing what goes to ietf-announce,
we make a new thing which is, you know, ietf-announce-restricted or IETF-you're
not really paying that much attention, or something. And we put just the ones
that you said to that list and leave ietf-announce alone. People have
subscribed to announce with the expectation that they'd get all of this stuff.
It feels impolite to be changing stuff underneath.

Eric V: I agree.

Mirja: We have handled this in the past. For example when we created the last
call list, we auto subscribed everybody to that list who was previously
listening to these kinds of emails. So we could decide to do something like
that as well to make sure that those people who are subscribed now don't see a
change. I would be okay to create another email list but I think it would
actually be slightly confusing; I would be more in favor to clean up what we
have here, because a lot of these things just grew over time. We added more
notifications to the datatracker and the default mailing list was just this
mailing list. There was no good reason to send it to ietf-announce but that's
what we did because we had this in the datatracker. So I think this urgently
needs a review and I think it would be cleaner to remove things here.

Eric V: But there are a few things that should be kept. For the charter update.
If you announce a closing and a new WG, we should for consistency also send the
charter updates, and like Alvaro, the last call is the only chance to capture
the attention of other working groups. So for me that's if there's one thing to
keep for the broad community it's the last call.

Lars: If you want to comment on a last call you already need to be on the last
call list.

Eric V: No, you can reply to all [from the announcement].

Lars: Does the comment make it to the list then?

Ben: Yes, the global whitelist.

Warren: And also, I see a last call that I feel strongly about and I've already
got a copy of this, I guess I'll go join the last call list. But also we could
take any one of these, like I think interim working group meetings are really
important for everyone to see, because they see them when we have a normal
meeting, you know, people see all of the working groups on the agenda and maybe
I'm not subscribed to IDR, but I should be because this is an interesting
topic. So, you know, if I were getting the list of interim working group
meetings, I'd be like oh I need to go to that.

Eric V: But in your case you want to get the agenda, actually, right, so it's a
different story.

Warren: If I see the announcement for IDR I'll be like, oh I should go see what
this is.

Mirja: These interim meeting ones make no sense for me at all because we don't
announce the meeting agendas for the IETF meeting there, we only announce
interim meetings; that really doesn't make any sense,

Warren: But we announced the fact that there's an interim meeting and if I want
to follow what's going on in IDR, I'd be like, oh the IDR is having an interim
meeting on Thursday. Let me go and investigate and see if there's useful stuff
then I'll go participate.

Mirja: But wouldn't you be already subscribed to the IDR list if you are
interested in IDR?

Warren: Maybe, maybe not.

Lars: Try and put yourself into a position of somebody who isn't full time
invested in the IETF, where basically it's like 10% of their job and they do
TCP or some other thing, but they don't want to get these emails from groups
that they will never be interested in.

Eric V: You can skim through them very quickly; that's what I am doing.

Lars: People unsubscribe or don't subscribe to ietf-announce so then they don't
get the other stuff. That's the problem we need to solve; we don't have a
dissemination channel that actually gets to the community. And when we tell
people they should go to ietf-announce they say it's too noisy.

Warren: That's why we make a new list for reaching people with stuff that is
important for the non-core participants to know. Instead of changing the
existing one.

Francesca: I like the idea of getting a summary or digest of some of these.
That would reduce noise a lot and interims would be like the perfect example,
and maybe some more things could go into a digest.

Lars: It's a mailman option to receive a digest from a mailing list. Instead of
each mail individually.

Warren: You were thinking of a summary?

Francesa: I was thinking about combining some of these. You might still want to
have singular announcements for some of these, but you might want to have like
all the interims for that month in one mail or something like that.

Mirja: Maybe I'm using this in a different place, but usually I just look at
the calendar. I'm subscribed to the interim calendar.

Lars: Let's go the other direction Warren suggested; if we had an ietf-all
list, what should be on it?

Warren: Largely, the things you'd said to put on ietf-announce.

Lars: Okay. Would we be okay with subscribing people actively to that, if
they're participating in the IETF?

Warren: I think so.

Lars:  So when you're subscribed to any of our mailing lists, we're going to
subscribe to ietf-all?

Mirja: If you have a datatracker account we subscribe you.

Lars: Datatracker is not enough because most people don't have one; that's why
we did the survey based on the subscriptions and not the datatracker.

Warren: I think largely what you have on keep on ietf-announce would be on
ietf-all, I also happen to think new RFC announcements are useful because it
gives people the feeling of things are moving forward.

Lars: No, not on ietf-all.

Mirja: That's the most useless part of it.

Warren: I mean, we actually publish so few RFCs, but I'm fine with that.

Lars: the current volume of ietf-announce is not insubstantial if you're
looking at the archives.

Mirja: There are over 100 messages a month.

Lars: All the volume that goes there together at the moment is a lot. For this
to be acceptable to people it needs to be a mail a week or something like that.
Anything more, I think, is pushing it.

Warren: What about if we have something like every month, we could have a list
of the four RFCs the IETF published this month. But I'm happy to be told that's
silly. It just seemed like a way for people to see this organization I'm
involved in has accomplished these every week, every month, something. Because
our primary work product is this output.

Eric V: I agree with you.

Mirja: If we actually create a new mailing list, I would like to have only
manually sent messages there actually. I would not even have those three auto
generated messages here, because that's a really important one where you want
to reach people and for everything that's auto generated there are other
mailing lists you can use instead.

Lars: Do people think that the new mailing list is the thing we should try to
do rather than do refactoring? I'm trying to establish a direction and then we
can talk about what the proposal should be.

Erik K: Can we just make ietf-announce somehow more useful for email filters?

Lars: People can already set up filters.

Erik K: If there's a whole bunch of random things that are all going to the
same mailing list and are unaffiliated and then you have to start having
customized subject lines or whatever, right. Can we use the plus folder trick?

Lars: I think people will not do the effort, and they will just unsubscribe or
not subscribe from the beginning, I think that's that's the problem. It
requires a certain amount of willingness to do this when few people have.

Warren: I don't think we want 5,000 people to each have to manually update
their filters, unfortunately, I like the idea though.

Mirja: Yeah, and I would like to have this in a way that we can auto subscribe
people when they register for a meeting or create a datatracker account or
whatever. So the volume is so low that you really don't need filters. So I'm
perfectly fine with having a new mailing list. The only concern I have is that
I think this new mailing list should be called ietf-announce and the other one
should be called ietf-all because that's what it is. So I think the naming of
the mailing list is very confusing.

Martin D: I think we should just have an ietf-all list. It should be, at most,
the four things you have there. I could make the case for just the first thing,
like Mirja said, but I think your instincts about having it be auto subscribed
and being very low volume are the correct ones.

Lars: I'll come back with a bit more text about what that might look like.

Warren: I should also point out ietf-announce is mentioned in a whole bunch of
documents we already have. We have a bunch of people who subscribe to it. But
if we want to, I don't know if somebody wants to go through and change a whole
bunch of RFCs and say you know, this used to be ietf-announce, now it's called
something else.

Lars: That's a good point. I think I'll go flesh out the new mailing list and
for lack of a better term, let's call it ietf-all unless somebody has a better
name for me. It would be not great, I think, if we subscribe all 50,000 people
that are currently subscribed to an IETF mailing list to this thing. But what
might work and we need to talk to the tools people, if somebody is an active
participant in the sense that they're sending email. So when you send an email
and you're not subscribed yet, we subscribe you to ietf-all, and you can
immediately unsubscribe if you want to.

Mirja: Before you move on. Jay brought this up already and we discussed this a
little bit, and there are some legal points about auto subscribing. If I
remember correctly, his conclusion was that auto subscribing anybody with a
datatracker account shouldn't be a problem because those people already agreed
to get information from us, but auto-subscribing people from other mailing
lists might be a larger problem, but I'm not sure if I remember this correctly.

Lars: Okay, I'll certainly talk to Jay. The other option would be to have a
checkbox on the meeting registration form, like you have for attendees.

Mirja: But this is kind of the equal to subscribing everybody who has
datatracker accounts, because you need a datatracker account to register for a
meeting.

Roman: True, but you have the ability to opt out on the registration.

Mirja: Everybody who currently has a Datatracker account, those people are not
subscribed to the new list and I would really like to see at least those people
subscribed because those people are either active or have been very active in
the last couple of meetings because you need an account to go to a meeting. So
I would really like to autosubscribe those people. And then there's new people
who come to an IETF meeting, but if they wish to just have one IETF meeting,
they first have to create an account so they will also be there.

Lars: Basically, it will be subscribing people with current datatracker
accounts, and auto subscribing them when they create a new account. And then
basically allowing you to unsubscribe.

Mirja: That would be my proposal.

Lars: Okay, that was useful. So I'll write this up, and I'll circulate it, and
we can hash on it a bit more than I'll send it to Jay and I guess we would then
send it out for community feedback and get yelled at a lot.

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

Amy: Does anyone have anything to share?

Francesca: Yes, I have compiled the list of references, and if we have a second
I'd like to go over them. They are in the chat. So, I have taken out everything
that was not a BCP, Internet Standard, or Full Standard. And then I have
checked with the downref datatracker page. Highlighted in yellow are those that
are not currently in the downref registry, and the green are those that have
been last called in the second last call. So I guess the question is: Anybody
have any objection to having these downrefs in these documents?

Ben: For me, these particular downrefs are fine, like these are well
established documents that everybody uses and they're de facto standards even
if they're not formally Internet standards. I do think that we should still
send this list to the email group of IESG and give people a couple days to look
at it because I knew we had several people that had to drop from the call.

Francesca: Yes, I will do that, I will send this to the IESG mailing list. And
I tried to look at what the authors sent to the HTTP and I think it was this
list that  didn't include the downref tag, let's say, but I wouldn't say that
I'm 100% sure that it's the right one. This has been seen by the community as
well, even if it wasn't last called.

Lars: Francesca, I also think USASCII is not a downref because it's an ANSI
standard.

Francesa: Okay, yeah I just marked it here because I was going for everything
that wasn't BCP, internet standard or full standard, but I can remove this as
well. And the other question I guess is, are we adding any of these to the
downref registry or are we doing that later?

Ben: I think Lars's point about the downref registry is not really considering
the case of downrefs from internet standard to lower maturity but still
standards track documents.

Lars: I don't think it's set up that way; it's only only from standards track
to non standards track.

Ben: Right, so I don't think that we need to consider the question of adding
them to the registry.

Francesca: Okay. But even if the tool is not checking downrefs for internet
standard and proposed standard, you can still have these in the list, I guess.
But maybe we could take this up later.

Lars: We could; we would probably need to ask for an extension because the list
at the moment doesn't show the standards level.

Ben: That's something we could do but I don't really see much value from doing
it.

Francesca: Okay, well we can wait for that.  Then I will post this to the
mailing list and I will wait for an objection. Thank you.

Amy: Thank you, Francesca. Anybody have anything else to discuss today. Any
other business.

Lars: The only thing is that quick heads up that um, I think all of you have
now filled out the Doodle for this workshop / retreat thing. We'll pick some
slots soon.

Amy: And one more reminder that the first BOF coordination call is next
Wednesday.