Narrative Minutes interim-2021-iesg-07 2021-03-25 14:00
narrative-minutes-interim-2021-iesg-07-202103251400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-03-25 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
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
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Martin Vigoureux (Nokia) / Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Karen Moore (AMS) / RFC Production Center
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
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Ben Campbell (Independent Consultant) / IAB Liaison
Jay Daley / IETF Executive Director
Sandy Ginoza (AMS) / RFC Editor Liaison

OBSERVERS
---------------------------------
Dave Crocker
Jack Daniels
Lucas Purdue
Rene Struik
Greg Wood

1.2 Bash the agenda

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

Eric V: We may want to discuss informally two items, the last call email and I
forget the other one.

Alvaro: The other one is the paywall thing.

Roman: Didn't you mean the chat as well?

Amy: That's already on the agenda as a management item.

Alvaro: I don't want to add anything but if we want to discuss that, we can
move the author thing I have to the informal next week so we have time for
these other things.

Amy: Okay, so it's the last call list discussion and references behind a
paywall.

1.3 Approval of the minutes of past telechats

Amy: I have two sets of minutes here from February 18 and 25. Does anyone have
an objection to the official minutes from February 18 and 25 being approved?
Hearing none, so we'll get those posted. I have narrative minutes also for
February 18 and 25. Any objection to approving those? Hearing no objection, so
we will get those posted.

1.4 List of remaining action items from last telechat

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

Murray: The RFC Editor asked me to take input from Greg Wood and I haven't seen
any. I'm going to ping him and I'll also invite the new ADs to take a look
before we move it forward. Greg is on the call, did you get a chance to look at
this? [Greg had audio issues, will follow up by email.] New ADs and Greg are
the only ones I'm waiting on at the moment and hopefully we can get this old
item dispatched.

Mirja: Was it a specific recommendation to check with Greg, or was it John our
interim RSE project manager?

Murray: Greg was the person named. I can invite John Levine as well but Sandy
has been weighing in on it for a long time now so I think we have enough
representation from the RFC Editor.

Mirja: I was just wondering how Greg would comment on that. But he can have a
look for sure.

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

Amy: This is on today's agenda as a management item, which you might get to
today or next week.

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to
       investigate ways to recruit, recognize, and retain volunteers in the
       IETF.

Warren: This has fallen off our calendars. We had it on our calendars before
IETF 110 so we'll have to hunt each other down. No real updates.

Amy: Okay, we'll keep this in progress.

Lars: I've been discussing with Karen O'Donoghue about the future of EMODIR,
this new directorate Alissa started for education, mentoring and outreach, and
one conversation we should be having is if this effort is somehow related to
that scope, if this is something hat could find a home in EMODIR. But we don't
have to discuss this now. You can discuss it in a smaller group and we can
circle back afterwards.

     o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035].

Ben: Still in progress.

     o Eric Vyncke to draft text for the WG Chairs about requesting early
       review of documents by existing Directorates.

Eric V: In progress.

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

Alvaro: We've been working on this. We talked a little bit about this with all
of you right before IETF [110]. We're planning on getting a SWOT/PEST survey
out and Jenny is helping us with that. Hopefully by next week we'll have email
out about that so you have time to fill it out. Just like a couple years ago,
the aim is to collect information, then do some summaries and discuss in the
IESG before the retreat. Hopefully there may be some things we can discuss
there as well. Look out for that email in the next few days.

     o Murray Kucherawy to find additional designated experts for RFC 8855.

Murray: This fell off my radar after 110 so I'll get to it by the next telechat.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ace-oauth-authz-38  - IETF stream
   Authentication and Authorization for Constrained Environments (ACE)
   using the OAuth 2.0 Framework (ACE-OAuth) (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: I confess I did not get a chance to review all of the comments and such.

Francesca: I would like to discuss it though. I can just repeat the general
comments. I got an answer from the author giving me some background information
about this and the comment is basically that I just wanted to discuss this. I
think this should move forward as soon as possible but I didn't understand the
motivation for not just requiring CBOR, even if HTTP is used. Ludwig had said
that there has been a lot of discussion in the WG about this. I am okay with
removing my Discuss even though I don't understand the motivation, but I think
there's a lot of points in the document that will need clarification because
there's this additional flexibility. Keeping this in my opinion is more work
than actually removing this flexibility.

Ben: Right. I think I remember some brief discussion coming up about some of
the awkwardness if you have something that was originally written for CBOR and
then you have to try and do it in JSON and there are some of the ways of
actually expressing and serializing the data that are not immediately clear. I
kind of do agree that's a real issue and I'll have to take a look at it some
more as well. I do also note that this document actually needs two more ballot
positions to pass. No, I'm looking at stale data, never mind. We can leave this
in IESG Evaluation and try to get a bit more discussion in email.

Francesca: Okay, I'll wait for your response. So once you have evaluated and if
you tell me no, we're not going to do this, I'm okay with clearing my Discuss.
I'm in the rough and I think it should move forward. So I'll wait for you.

Ben: Thanks for being clear.

Amy: That kind of sounds like AD Followup.

Ben: Yes.

Amy: Okay, that will stay in IESG Evaluation and go into the substate of AD
Followup.

 o draft-ietf-ace-oauth-params-13  - IETF stream
   Additional OAuth Parameters for Authorization in Constrained
   Environments (ACE) (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: Please put that in AD Followup as well.

Amy: Okay, this will be Approved, Announcement to be Sent, AD Followup.

 o draft-ietf-ace-oscore-profile-17  - IETF stream
   OSCORE Profile of the Authentication and Authorization for
   Constrained Environments Framework (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: No, it's pretty straightforward, but it's a very good catch. Thank you
Roman, and thank you Martin for the careful review. This is going to be Revised
ID Needed.

Michelle: Just to let you know, on the profile document we're still waiting for
some experts to get back to us.

Ben: Okay, thank you for calling that out.

Amy: I have this in IESG Evaluation, Revised ID Needed.

 o draft-ietf-ace-dtls-authorize-16  - IETF stream
   Datagram Transport Layer Security (DTLS) Profile for Authentication
   and Authorization for Constrained Environments (ACE) (Proposed
   Standard)
   Token: Benjamin Kaduk

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

Ben: It's the same thing as the previous one; we just didn't catch one of the
changes in the profile documents. Revised ID Needed as well, please.

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

 o draft-ietf-tls-dtls13-41  - IETF stream
   The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
   (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: I think we probably would benefit from briefly discussing that. I know the
TLS WG is not really packed with transport experts, but I also don't think this
was a huge surprise that we were changing this. Martin, do you have any advice
on what we should do here? [Martin having microphone issues, silence] I guess
we can also do this by email. But I do think we should continue to engage on
the topic.

Mirja: I haven't read this draft but TCPM also recently published RFC 8961
which is on considerations for time-based loss detection and also talks about
initial timers and so on. So I think following the same recommendation we have
for other documents makes sense instead of setting up another recommendation
here.

Lars: I didn't put a Discuss in because Martin had but I agree. The second half
of his Discuss has an approach forward for this that looks reasonable to me and
I think that's basically what should be discussed with the WG.

Ben: Yeah, we definitely want to hear from the WG as well.

Martin D: Can you hear me now? I guess Lars understands, and Mirja brought up a
point I have in the Discuss about 8961. I missed your initial introduction,
Ben, but at the bottom I do have an outline of a potential suggestion and I'm
also trying to loop in some of our experts in this area, transport gurus, to
provide some advice here. I really don't want to make you guys try to recreate
TCP in here, I just want to follow some of the guardrails we have for this kind
of thing.

Ben That makes a lot of sense. So you think we should just make sure to get the
dialogue with the WG and then is there anything we should have done differently
in terms of trying to get an earlier Transport review or something like that?

Martin D: I asked for a TSVART review which I guess turned out not to be really
the right person to catch this kind of stuff. I think when you're designing a
retransmission mechanism I think going to someone like TSVWG somewhere during
the WG process would be good. I think some of these comments would have come up
there. This is probably going to be a little bit of an extended discussion but
I don't think we have all of the people we need here today to conclude it. So
let's take it to the list. Why don't I start a thread and I'll try to bring the
right people into it?

Ben: Sounds like a plan, thanks. Let's leave this in IESG Evaluation.

Amy: IESG Evaluation, AD Followup if it doesn't require a Revised ID?

Ben: I guess so. It will probably require a Revised ID but we can leave it in
AD Followup for now.

 o draft-ietf-ippm-ioam-data-12  - IETF stream
   Data Fields for In-situ OAM (Proposed Standard)
   Token: Martin Duke

Amy: I have quite a number of Discusses for this document. Do we need to
discuss any of those today?

Martin D: This one got murdered pretty well. Some of these are late and I have
not yet reviewed them. I hear the concern about namespaces and overlapping
domains. I think I need to take that back to the authors and figure out what
we're going to do there. The other thing I'd say is about the security angle,
and I'd brought this up in an IESG note and this came up in Last Call. Yes, it
is just an individual draft, but it was filed in response to the Last Call
feedback and we were going to fast track that through IOAM, the integrity
document. This is one of those things, this is a community that often runs
things unencrypted and so while I support doing that document, in practice in
the real world, I don't know how much people are going to use those tools. But
at the same time we need to have some capability for people to secure these
things properly and we're going to advance that document forward no matter what
happens with the IOAM. Again, not having looked at all the Discusses because it
happened overnight, the big comment I saw was the domain and namespace
discussion and I need to take that back to the authors and have a conversation.
Am I missing any other really large themes here?

Lars: There's one you didn't look at, which is mine, because I was late in
getting to it with the LLC Board retreat the last couple days. I didn't raise
the things other people raised. There's basically two trace types that they've
defined in the document and they say an implementation may use either one or
the other. That basically means we're going to bifurcate the standard, because
you can be compliant but not interoperable. I think that's a huge problem and I
was wondering if the WG has discussed this at all. Specifically since the only
argument they're giving for having these two is that one is more optimal for
some implementations than others, but you should still require one that's
mandatory to implement in my opinion.

Martin D: Okay, I'll take that back and have that discussion. Thanks. So
clearly this is a Revised ID Needed.

 o draft-ietf-idr-bgp-ls-registry-04  - IETF stream
   Updates to the Allocation Policy for the Border Gateway Protocol -
   Link State (BGP-LS) Parameters Registries (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: Yes, I think so. The main question we probably need to talk about is
why are we doing this and what prevents other people from doing the same thing?
That seemed to be the bigger concern on the list. There's been some email right
before the telechat; I don't know if everyone had a chance to look at that. If
you did and you need to talk about something else, let's please do. Why don't
we start there, are there remaining questions from that? Did anyone not see
those emails?

Eric V: I quickly browsed through those emails but honestly I'm still failing
to understand why RFC 7120 early allocation cannot be used there, and renewed
until publication?

Alvaro: Among other things, it says that specification required registries can
only be early allocated if the document is going to be published as an RFC. In
IDR, singular to them, there's an implementation requirement for your document
to progress. Which means things can only go to RFC if there are
implementations, and there can only be implementations if there are code
points, code points can only be allocated if we know there's going to be an
RFC. So it's the chicken and the egg. We could do exceptions but that's what
7120 says. I don't think bypassing 7120 is such a good idea, and I also don't
think that we could just change this for IDR and it would work for everyone
else, since I'm not sure that's what others are assuming that's what they're
depending on for that. The case of IDR and this particular thing is sort of
unique. I don't see the potential of other WGs, even IDR itself, to just come
and say they want to do the same thing for everything else.

Eric V: So making an exception just for a couple of registries, not a WG? But
as far as I remember, 7120, I'm clicking on this and it's a different problem
but it says WG interest. I don't remember it ready to be published.

Alvaro: In the section 2 of 7120, it says that the normal stuff, IETF review,
standards action, all that can be early allocated, but that of course assumes
IETF work. Specification required registries are allowed if this specification
will be published as an RFC. Then it says somewhere else that the specification
reference, the stable reference 8126 talks about, is an RFC, which also limits
who we can assign things to.

Eric V: I see the sentence, but still, we intend to publish them as an RFC,
right?

Alvaro: It doesn't say "intend," it says "will be published."

Lars: There are several aspects. Adrian had an email that laid them out well.
One is a desire to do early allocation for non IETF documents, which is
currently not possible by 7120. The other is this limitation that the
provisional registrations are only good for one year, and then they need to be
renewed, and they can only be renewed once. That feels like a short period of
time, since IDR has a specific hurdle for documents that are hard to clear
within that time. So I think the reasons are valid for making the change, and
there's some comments about whether we can phrase this better, but the actual
action item for us might be to look and see if we can do a revision of 7120
that can make it more useful to the community. In QUIC we tried to use an early
allocation thing for some QUIC code points as the QUIC RFCs moved to the RFC
Editor and we were basically told it doesn't matter, because by the time you
can ask, you're so close to getting the final allocation, you don't need to
worry about the early allocation, which is also not very useful. I'm trying to
use the email thread to collect some things that would have made 7120 useful
for IDR and maybe we can revise that document to make it a bit more useful. But
that doesn't block this from going forward, I don't want to hold this back
until that's done. But I see the point that we might be seeing more custom
expert review guidelines because 7120 doesn't meet the community need.

Martin D: The provisional thing all makes sense to me now, thank you for
explaining that. Setting aside the issue of provisional, the requirements
appear to match IETF review. But there's a bunch of SHOULDs there. Is that the
right word? Are you envisioning non-IETF stream RFCs being able to prefer this?

Alvaro: Yes, we are, in general it could be non IETF work. BGPLS is used to
send information up to a controller type thing, so there could be other things
that want to send things up using BGP. I don't know that there would be a lot,
but yes, there's a possibility other people that might want to do things there.

Martin D: So then why is it worded like...I could just use the 8126 categories.
Requests should be consistent with the IETF review guidelines, right?

Alvaro: I think the SHOULD was so that we leave that door open. We prefer
things that are done in the IETF, but if the IEEE comes and wants to allocate
something, we can consider that.

John: I think Adrian addressed this in one of his followups and said we could
put a MAY cause in there but in the end, it devolves down to the expert may use
their discretion. It just says if none of these things fit, do the right thing.

Martin D: I guess it's philosophical how much you want to have firm guidelines.
I guess maybe just a little bit of clarification on the content of the SHOULD
and what the considerations are there would be good.

Alvaro: I'm not sure it's just you. Other people made comments around those
SHOULDs and we're going to need a Revised ID for this anyway. And Adrian has
already been talking about the new text.

Lars: Also, Michelle put some things in the Jabber that seem to contradict some
of the things Adrian had in his email, which I thought was taken from 7120.
Specifically she said they do multi year allocations and renew them if needed.

Michelle: IDR has tons and tons of documents that we've done multiple year
extensions because the document hasn't been ready. The intention of the early
allocation RFC was if people need code points and need to do implementation
testing early, they get them, and an RFC would follow. I think in most cases
it's rare that a document actually just uses the one year assignment and then
comes to permanently assign them to the RFC. We are doing extensions all the
time and in multiple years. I was trying to figure out if for this particular
registration, if it is a specification required registry, it's really up to the
expert if for example an I-D is a sufficient reference. I was scrambling just
now to try to look up the document and find out which registry we were
referring to. I didn't know if that process would work.

Alvaro: So this is 7752. There's what 7120 says about the expectation of it
being published as an RFC. Maybe an I-D would work but it wouldn't work for
external requests, so that's the other question of what would we do there.
You're probably very familiar with 7370, which is what the IS-IS guys do for
their TLDs. That's one that was published after 7120 and it's basically the
same text.

Michelle: Are we looking at 7120 and also extending that out to also accept
external registrations?

Lars: [crosstalk] IETF documents as sufficient, so we don't want to have people
submitting Internet-Drafts to do an early allocation if already a
non-Internet-Draft external document exists from somebody.

Michelle: Okay, I will follow up separately to start collecting any information
we might need to start discussing those updates separately.

Lars: One outcome of this is certainly that 7120 needs a revision, probably a
minor one, to make it a bit more useful. I'll lift this Discuss here now and I
think we're sort of in agreement that we'll let this go forward for this
particular registry to not block the work, and it's going into Revised ID
Needed so the other comments that were made can be addressed.

Alvaro: That works for me. I'm getting the AI from the IESG and I'll follow up
with Michelle. Or Michelle can have the AI. Thanks.

Amy: So I understand that this is going to require a Revised ID, and we can
move on.

 o draft-ietf-ecrit-location-profile-registry-policy-01  - IETF stream
   Changing the LoST Location Profile Registry Policy (Proposed
   Standard)
   Token: Murray Kucherawy

Amy: There are no Discusses for this document, so unless there's an objection
now, this document is approved.

Murray: Let's go with Approved, AD Followup. There are just a couple of
comments I want to bounce off the WG before we send it out.

2.1.2 Returning items

 o draft-ietf-hip-dex-24  - IETF stream
   HIP Diet EXchange (DEX) (Proposed Standard)

Eric V: I guess we need to discuss this. Thank you for all the reviews; this is
not an easy document to read with a lot of crypto inside. Thanks especially to
Roman and Ben, who are reviewing this document for the third time. Lars, you
put as well a comment about the process. You removed your Discuss but it's
still in my mind. I see currently two issues; a quality of content issue, which
is basically Roman and Ben's comments. I would suggest that I send the document
back to the WG, aiming now at Experimental, so that should remove all your
valid comments for a standards track. It would require an IETF Last Call if the
author and the WG agree. Back on the fact that this document does not fit the
HIP charter, to be honest, I got it before becoming an AD so I was simply
trusting. I had a chat with Terry just fifteen minutes ago and there was a
process of rechartering HIP to take into account this document, as well as
adding a milestone. At that point of time there was nearly no energy in the HIP
WG, it was basically the chair and one or two authors, so Terry did not press
the button on purpose because he didn't see the energy there. So I'm looking
for advice on what to do. We can do a rechartering process just for this
document, as Experimental, or we tweak it a little bit more and get a milestone
outside of the charter, or we simply say at the point we are, it's been in WG
Last Call, we need to change it to Experimental, and let's ignore the charter.
I would prefer, being lazy and practical, to ignore the charter on this one.

Lars: I agree, although it's not the procedurally right answer. The HIP stuff
just needs to end. I like going to Experimental if that addresses the Discusses
as well. We can talk about that in a minute. The one thing I want to bring up
is there's a normative reference down from the architecture document to dex,
which is a normative reference at the moment, but if you make it Experimental
it'll be a downref. So that's a problem. THere's no need for this reference to
be normative, because it's in an appendix and all the appendix does is
summarize dex and says if you want to use it for IoT here's what you use. One
way forward would be to instruct the RFC Editor to change the reference to
informative, so you don't need to do another Last Call on the architecture
document to get it okay for the downref.

Eric V: That's all good to me, Lars, thanks for the tip. I will ask the authors
if they agree first but that's what we'll do.

Lars: Let's check first whether these Discusses will be addressed by going
Experimental, because that's the big if. And if the authors are okay too.

Eric V: So Roman, Ben, can you say quickly whether, or we can do it over email,
whether going Experimental would clear your Discuss to just a comment?

Ben: I think it will clear most of my Discuss. The specifics about some of how
the crypto is used should probably still be addressed though.

Roman: I'd say maybe. Part of this is the setup. I'm struggling a little bit
with a lot of time and effort got put in based on the assumption that we can't
pull it off on a particular hardware platform, so we have this whole body of
work on this premise. It would seem that we should have validated the premise
that we need it before we put in all of this work, frankly. If we think about
experimental, is that the experiment we're thinking about? We put in all this
work and now we're going to try whether we needed it to begin with?

Eric V: I guess so. I'm not the author.

Lars: The other option, which is a bit more aggressive than reclassifying it as
Experimental, is to punt it to the independent stream. Once it becomes an
informative reference, it doesn't block the arch document anymore. That way it
would be completely somewhere else.

[crosstalk]

Eric V: My only concern is this is also what I was thinking, but it's still too
closely linked to the HIP WG. Is there a conflict with IETF stream?

Lars: That's a fair point. The other thing, if I remember this correctly,
because I was IRTF Chair when dex was discussed in the HIP RG when I was still
around, I think the author really really wanted a standard because they were
trying to get other SDOs to do work based on this. I don't know if that's still
going on. That might be a consideration for them.

Ben: I believe that's still going on.

Michelle: Let me also throw in there that the IANA section is still very
unclear and if it were approved as-is we wouldn't know what to do.

Eric V: Thank you. You're right to say it.

Michelle: We'd asked the authors about section 10 in the document and we never
got a response back. So whatever stream it ends up being published in, we still
need all that to be clarified.

Eric V: Okay. I will try to go back to the author with this decision about
Experimental and fix a few other things. I will ask the RFC Editor to basically
remove completely the appendix, because now the chance that this RFC is
published anyway by the IETF is less than 50%. Thank you so much for the
discussion.

Lars: I think the appendix can stay as long as they change the reference to an
informative one. You an publish RFCs with informative references to I-Ds I
think. It's a smaller change, basically changing a reference from one section
to another rather than ripping out a page of text, which arguably is more
problematic to do at this stage.

Eric V: Okay. Again, thank you everyone.

Amy: So it sounds like this is going back to the author or WG. Is your substate
going to be Revised ID Needed?

Eric V: I think so. It's not really IESG Evaluation if it's going back to the
WG.

Amy: We don't generally change the main state to I-D Exists. Usually the AD
decides to do that.

Eric V: I can do it. I will do it later today.

Amy: That will revert it back to the start of the publication path.

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-tcpm-2140bis-10  - IETF stream
   TCP Control Block Interdependence (Informational)
   Token: Martin Duke

Amy: We have a Consensus Unknown here, so we'll change that to Yes for you. I
have a Discuss for this document; do we need to discuss this today?

Martin D: I think the Appendix C issue is potentially simple. I think this is
actually written in the shepherd writeup. The question is why is it included in
the document? It's a previously undocumented method of doing initial window
sharing that used to be a separate draft, and that's why it's there in detail.
There was rough consensus to put it in the draft. Some people in TCPM said
let's just have an informative reference to the expired draft and leave it at
that. The author preferred to leave it in. If that satisfies your curiosity and
we can move forward, let's move forward; if you think it should be removed, we
can remove it. I don't think it's a critical issue that it be physically
spelled out in this draft instead of in a reference.

Lars: It's going for Informational, right?

Martin D: Yes.

Lars: Okay. In that case I don't care so much. I was just surprised because I
know 2140 so I was surprised to read three pages of text that have very little
to do with everything else. I'm okay with leaving it and I'll clear.

Martin D: Okay. So then I guess there are a few other comments, so I guess it
will go to Approved, Revised ID Needed once Lars clears his Discuss.

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

3.4.3 For action

 o conflict-review-crocker-email-author-00
   IETF conflict review for draft-crocker-email-author
     draft-crocker-email-author-04
     Email Author Header Field (ISE: Experimental)
   Token: Lars Eggert

Lars: I'm still seeing that it needs a reviewer.

Amy: Lars, did you want to start the conversation on who would be an
appropriate reviewer for 5742?

Lars: I can start a conversation but I haven't actually managed to look at the
document. Based on the title I would guess someone from ART would be a suitable
reviewer.

Murray: I'll take it.

Lars: Thank you.

Amy: Thank you, Murray. We will assign Murray to do the review and then when he
puts in the review, it will come to a telechat.

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

 o Effective Terminology in IETF Documents (term)

Amy: I have no blocking comments for sending this to external review, so unless
there's an objection now, external review is approved.

Lars: There were a few suggestions for wording changes I want to make before it
goes out. I can make them right after this call. How do we handle that?

Amy: This will be approved pending edits, so we'll wait for the go-ahead from
you. Once it's ready to go you can send us a ticket.

Lars: Great. And if I didn't manage to capture some of your comments, you can
yell about it during Last Call.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o CBOR Object Signing and Encryption (cose)

Ben: We got some good comments, nit sort of stuff that I need to apply. I think
that's in AD Followup.

Amy: Is external review required; is it a big change?

Ben: Yes.

Amy: Okay, so the external review is approved pending edits. So again, you can
let us know when it's ready.

Ben: Before we move on, Lars, did you want to talk at all about the detailed
nature of the certificate compact encoding stuff?

Lars: It's a comment. I just found it pretty specific for a charter, but it
also seemed to be a narrowly scoped charter, so maybe that's okay.

Ben: Some of the intent here is to justify doing the work at all because
there's a different line in the charter that I don't have in front of me that's
something like defining a new way to bind a name and a key is explicitly out of
scope. The certificate is binding a name to a key, but the idea here is we're
not actually making a new way of doing that, we're just re-encoding to be more
compact with the existing X.509. So that's part of why we put so much text in.
But it is a good point that it's pretty detailed.

Lars: The other issue is if you're basing the work on an individual I-D, that
can change based on what the individual puts in there. So your risk.

Ben: That's also true. I'll take a closer look at the comment; I didn't get a
chance to before today. Now we can move on, Amy.

4.2.2 Proposed for approval

 o QUIC (quic)

Amy: I have no blocking comments on this recharter, so unless there's an
objection now the recharter is approved.

Zahed: There were some comments, mostly nits. I have edited that. Lars, do you
want to check and confirm? Then basically we are done here.

Lars: Sure. I can take a quick look.

Amy: Okay, so it sounds like we're approved and we're just going to get a final
confirmation that the edits were made. That announcement can be sent once the
edits are confirmed.

Zahed: Do you need anything from me now?

Amy: For clarity I think [sending a ticket] would be good, unless Lars pops up
later on the call and says it's good.

Lars: It's good.

Amy: Okay, we don't need a confirmation then. We'll send that announcement
tomorrow.

5. IAB news we can use

Amy: I believe Martin V is our new IAB liaison. Any news from the IAB this week?

Martin V: Yes and no. Since I missed the beginning it might be redundant. The
IAB has discussed the use of Slack as a communication channel and I think we're
going to discuss this as well and see if there are synergies between IAB and
IESG as well. I guess Lars had ideas on that?

Amy: Yes, there's a management item coming up to discuss. Thank you.

6. Management issues

6.1 Designated Experts for QUIC Registries (Zahed Sarker)

Amy: Zahed, you added this to approve Ian, Martin, and Jana as the designated
experts for these registries. Any objection to approving any of these three
folks? Hearing no objections, so we'll get that official note sent to IANA.

6.2 [IANA #1191310] renewing early allocation for RFC 8111 (IANA)

Amy: This is renewing the early allocation for RFC 8111. Alvaro, did you want
to talk about if you approve this renewal?

Alvaro: Yes. I approve. This is an interesting one because the early allocation
was not assigned to a draft, but to an RFC. This is an experimental RFC. LISP
WG has been working on it, it's been deployed, and they're planning on
re-issuing a bis on standards track in the next few months. I think we should
approve this.

Amy: Any objection to approving the renewal of the early allocation for this
RFC?  Hearing no objection, so we'll call that approved and we'll send official
note to IANA.

6.3 Guidance on the Number of Document Authors (Alvaro Retana)

Amy: Did you want to go through this today?

Alvaro: Why don't we do this on the informal and go through the other items.

Amy: Great, we will move this to next week.

6.4 Discussion regarding IESG chat tool (Lars Eggert)

Lars: This came up on the IAB call yesterday. The IAB has been using Slack as a
chat tool instead of Jabber but they have bridged in their Jabber room
basically for Stephen Farrell. They had a discussion of what they're going to
use going forward with the new IAB and it seems like Slack is once again the
winner. As a side note, there's an ongoing trial service from the Tools Team
that has evaluated Zulip and Matrix for the last two IETFs and the plan is
eventually for the IETF to move to one of those two platforms and off Jabber,
at which point the IAB might choose to use that instead of Slack. For now, the
IAB is going to go with Slack. They would really like to have a common chat
system with us, to replace the IAB/IESG Jabber room. I took the item to talk to
you guys about what we think about using Slack and establishing a joint channel
with the IAB. Jay is on PTO today so he's not on the call but he sent an email
outlining some of the options we have. IETF LLC is paying for a Slack instance
that is mostly used for the LLC and some operational stuff. It would be
available for us to move there. Jay also offered to pay for the IAB and for the
IESG for separate instances if we want that, and once we have that we can have
a common Slack channel across the two organizations. Another option is to use
this volunteer provided free instance of the IETF Slack which is not run by the
Secretariat or the LLC. My only concern is that we'd be at the whim of whoever
is the admin there and I wouldn't want to do that until the LLC or Secretariat
has control over that to some degree. The point is do we want to consider using
Slack at all?

Martin D: If we ever stop paying for Slack do we still own the archives? Is
there a way to export them?

Lars: I looked into this for QUIC, because QUIC is using a free instance. We
can get the data out even if it's a free instance. You can't search the QUIC
history for example past the last 10,000 messages, but if you do an export from
the website you can get everything. The data archiving isn't tied to paying.
Paying for this is not expensive. Slack price is based on active users and the
IAB Slack would cost less than $100/month, so it's basically not worth thinking
about, and IESG pricing would be similar.

Mirja: Maybe I should say, we've had the Slack instance around for a year or
so. We've been mainly using it as replacement for Jabber for those who don't
have a Jabber account and we bridged in Stephen.  We're not really making a lot
of use of it otherwise outside of calls. It's really just our backchannel for
calls at the moment. However, we also decided we don't want to kick off the
former IAB members, we've just closed the chat channel so only current members
can see it. It's a nice way to keep cooperating with those people if needed.
That's the current setup, it doesn't mean anything about what we want to use in
the future.

Roman: I don't want to open up the workflow box. The first question for me is
are we bridging with Slack until we use whatever is the IETF solution, or are
we seriously putting on the table how do we increase IESG productivity with
real tool integration? If it's the latter, perhaps we should have a broader
conversation about integrating chat with the actual comms we're using right now
to integrate with a ticketing thing. How big of a box do we want to open here?

Lars: Not that big of a box. The ask is pretty specifically that the IAB has
decided they want to use Slack going forward and they're asking if we would
consider doing the same so they can chat with us and we can all get off Jabber,
which has been problematic for many years. The broader issue we can open up
when we know whether the IETF will use Zulip or Matrix and how that would
integrate with services, because then we we would use that with Meetecho
instead of Jabber and also potentially a Datatracker tie-in so you're
authenticated by Datatracker to those chat services.

Roman: If I can take my tools hat back, I guess something has changed? We have
exit criteria to evaluate Zulip and Matrix? Because last time I heard, we were
going to continue running Jabber and we have the other two but with no exit
criteria, we don't know how we're going to decide and we don't have clear
requirements from the community to reason through all of that. I'm scared to
bind a road map to the thing we don't even know what we're trying to figure out
for the community.

Lars: I don't think we would necessarily do that. The tools people are pretty
overloaded at the moment with migrating off of toools.ietf.org and various
firefighting activities. I don't see this community chat service thing to
resolve itself for at least another couple of months and maybe another year,
given how much integration we want to require before we move off Jabber. For
us, the IESG, the question is do we want to do that for our chat room that
we're using right now and during the IETF week so we can have a common chat
tool that's more modern with the IAB?

Martin D: One concern would be if this chat modernization thing drags on. It
might be untenable to have the IAB and IESG on Slack and make all the peons be
in Jabber for an extended period of time, and that might create pressure to
spend a lot of money to put everyone on Slack.

Mirja: What the IAB decided yesterday was also this is the right decision for
this group of people for the next year. But I don't actually see a problem if
we use Slack in the leadership. If we make good use of Slack and it helps us be
more productive and have shorter communication channels and work more together,
I don't see a problem for keeping Slack even if we use other chat tools for our
usual meetings.

Eric V: Basically I agree that going to a tool for three months, six months,
one year before going to the official tool with IETF protocols that supports
IPv6, right, because there's no way the IETF could use a protocol officially
that does not run on IPv6 or does not provide security. As far as I know Slack
doesn't run over IPv6. For me, I have already enough chat tools. Maybe you all
have Slack on your PC anyway but I don't.

Mirja: That was one of the reasons for the IAB to use Slack for one year and
then reevaluate, because we already had Slack set up.

Eric V: It does make sense then.

Lars: So would moving to Slack be a showstopper for some IESG members? Is there
anybody who couldn't live with that? Anybody who has serious concerns but could
live with it? That's what I'd like to hear.

Ben: I don't think it's a literal hard showstopper for me, but it would be
fairly ineffective for me based on the technical logistics of my current setup.

Lars: Can you say more?

Ben: So I have a problem getting Slack able to actually automatically update
and show me new messages. I haven't put a huge amount of time trying to debug
that but manually having to hit refresh in a browser window to see if there are
new messages hampers usability.

Mirja: There's also a Slack app.

Ben: I don't remember if there's a Linux solution.

Warren: There is a Linux one that works okay. However, I'm currently a member
of 13 different Slack workspaces using one account, and then using a different
account, a bunch more. Even with the app there are issues that you'll hear a
notification and it's unclear which of the many workspaces actually has the
message, then you have to click through 13 different tabs in order to find
where the message went. This can get old really quickly. Some of the workspaces
have 600 or 700 messages within two or three hours, so there are definitely
some usability issues we'd be opening ourselves to that we don't currently have
with Jabber.

Mirja: You guys can do the same thing we did last year and just create a Slack
team and bridge into the Jabber, so people can either use Slack or Jabber, and
see if that brings any value to you. Somebody can run a bridge bot which Marcus
is already doing for us, so maybe he can do it for another channel as well.

Warren: That would address a lot of my concerns. If I click on one of the
workspaces since yesterday there are 14,000 updates.

Mirja: Again, the main use case is using this backchannel that we have during
the calls like we have in Jabber right now. Having this backchannel, looking at
the respective channel in Slack during the call, it's not an issue.

Roman: I'm not a Slack user, we use like three other chat solutions. What's the
killer feature you get versus literally the Jabber window I have right now for
IESG? Is it just that the clients are better?

Warren: It's not Jabber; I think that's the point.

Mirja: We had people who didn't want to or couldn't create or didn't want to
create a Jabber account, so those people were not willing to join the Jabber at
all, but they had Slack. We were starting this during the retreat last year. We
were hoping to get some more asynchronous communication going on between
meetings, which didn't really happen that much but we're still hoping.

Roman: I'm not going to dig my heels in, but let me get this right. Some people
had Jabber accounts and some people didn't want to make Jabber accounts, so the
people that had Jabber accounts need to make a new Slack account to accommodate
the people who have Slack?

Mirja: We had people who didn't want to have a Slack account, we had people who
didn't want to have a Jabber account, which is why we had this bridge set up. A
whole bunch of people had accounts on both anyway and they didn't care.

Lars: Jabber is basically broken. You need to run your own server or you need
to be friends with someone who runs a server to have an account. Even
Jabber.org is using a certificate that's too short and recent Linux
implementations will refuse to talk to Jabber.org because of the short cert.
It's really not usable. The other thing is that there's really no good mobile
client as far as I know, so using anything on the phone is a nightmare. That's
for me the biggest reason to use something else. Zulip or Matrix will have
better clients too, but for now, Slack is that.

Mirja: What we did use a few times is just create a separate channel for some
side conversations we had. We did use that but not very often.

Erik K: It seems like we could solve the account problem if we could host
people's IETF Jabber accounts as part of the Datatracker account stuff.

Warren: I run my own Jabber server and it's annoying but it's not the world's
hardest thing to run. However, I think it does still come down to, it's
relatively clear that Jabber is losing out as the future messaging system. For
a long time it was king, along with IRC, and now clients are not really being
updated. I'm running Adium which has not been maintained for many years. I
really like Jabber, it's my preferred solution, but I suspect that in five
years time there will still be a Slack and there will be almost nobody using
Jabber.

Lars: I think we should scope the discussion similar to how the IAB scoped it.
We're not trying to make a decision for all time. We're trying to make a
decision for the next year and then we can discuss whether whatever tools the
IETF has decided to adopt work for us. The other option is we stay on Jabber
and we tell the IAB to have fun on Slack and send us email. That would also
work. But if we did a setup similar to what the IAB has, where we're creating a
Slack instance and bridging in the Jabber that we have, would that work for the
people who don't want to install Slack?

Ben: That seems like it would meet my needs.

Warren: Can somebody remind me what the actual problem is we're trying to
solve? We're all snarking away in the Jabber room channel and it seems to be
working for us.

Lars: The IAB is moving away from Jabber. They would like to have a joint chat
channel with us going forward like we had on Jabber. The other option would be
that we need to somehow bridge the joint Jabber channel into the IAB Slack,
which would be a second bot setup of some sort.

Warren: So the root is, another group is changing for some set of reasons, so
we're all changing because of them. I don't mean to sound harsh and snarky.

Lars: I would like to change personally because frankly I can't be bothered
with Jabber anymore. The lack of clients is frustrating, it's basically been
dead for years and we are the only ones still using it. I only use it for the
IETF. While I use Slack for a gazillion other things like you do too.

Warren: I actually like the separation and the fact that I can pay attention to
the Jabber one because I have a thousand Slack ones and many of them fill up
with random stuff. Sorry, separate rant.

Lars: So my suggestion would be that we try and do a setup similar to the IAB
and try it out to see if it works for us before we decide whether we're going
to keep doing it. Since we're probably going to use a paid instance, the cost
is minimal because we're only paying for active users. We'd have a bridge to
Jabber and a bridge to the IAB. Does that seem like a way forward? Does anyone
object?

Mirja: Did we decide which instance we want to use or is that something we can
discuss offline?

Lars: You and I can discuss that with Jay. It doesn't matter for practical
reasons, it just matters who sets up the rooms and maintains the rooms which is
probably the Secretariat in either case. So let's do that and try it out and
we'll see if we want to move to it or abandon it. Thanks.

6.6 Last Call Email List

Amy: I think Ben brought this up; is that right?

Ben: It was sent by somebody else to the IESG list.

Warren: I think it was Mike. Anyway, it's not important.

Ben: I think Alvaro, you replied and said we should pick it back up again?

Alvaro: I thought it was just a reply to you that yes, we should probably talk
about this. I think we should get back to Michael and say sure, it's working.

Warren: Is it though? I think when we decided to break this out into a separate
list, a number of people suspected this would simply turn into another version
of the discuss list. Moving this around means that some set of discussions will
go to someplace, and people will either use one or the other, but you're not
going to change the root tone of what's going to be discussed, or make a
substantive change. Things will revert back to what they were before. I don't
know if this is actually fixing things, whatever fixing means.

Lars: I would disagree with that. The tone unfortunately is often the same
because it's the same people who are writing, but there are a bunch of
community members who were unsubscribing from the "main" IETF list because they
couldn't deal with the other discussions there which are not Last Call related.
The point was to create a list you could follow for Last Call related stuff and
not have to deal with the other crazy stuff like how I got to the hotel from
the airport. That separation works. The tone is a separate issue.

Warren: Do you think the separation works? To me it seems like a fair bit of
discussion on this list is trending toward what used to be on the main list. I
don't think we really have a clear separation. But I can have another look,
maybe I'm just wrong and it's just a bias.

Lars: Can you give me an example of something you think doesn't belong on the
Last Call list?

Ben: I think we have some separation. We could perhaps argue if it's a clear
separation, but I think there is some.

Eric V: The only thing is that you need to tune your email filters and brain
filters to also look in the Last Call mailing list to find replies to the Last
Call. But it's been one year now, and it's working for me.

Roman: Maybe I missed it, but wasn't the finesse on the Last Call list that
people were providing technical commentary that wasn't precisely related to the
Last Call list? As I thought the feedback wasn't about tone, wasn't about the
airport stuff, but it was that there are different classes of review feedback
on documents and let's keep the Last Call list specifically to things in Last
Call. So early directorate reviews, while super helpful and should have big
discussions, are not Last Calls and should not be on the Last Call list.

Ben: That was also raised, and I think it's a valid point. Maybe that was even
the initial thread on the public list. There was a separate subthread that was
spun off to wonder if the Last Call list itself was meeting its goals.

Roman: Okay, then I'm behind.

Mirja: I thought the goal was that those people who don't want to subscribe to
ietf@ can still subscribe to Last Call and get those messages. If you're
interested in both you can just put it in the same folder and it doesn't make a
difference. But if you're not interested in both you have an option here.

Eric V: So what do we reply to Mike? Working as expected?

Alvaro: I found the email you were talking about, Ben. You pointed to the email
we'd sent a year ago announcing this, and how we said there we'd wait six
months and evaluate because it's an experiment. One of the things there was
that we said we'd pre-subscribe everyone who was on the IETF list to the last
call list. What I'd be interested in seeing is if other people subscribed to
that list, or if it's even less people, or whatever. If we're getting comments
from the same people only, and of course the replies to the Last Call
announcements go there, but maybe more people don't subscribe to the list.

Mirja: We moved everybody over and then some people unsubscribed from ietf@. If
new people subscribed to Last Call, that would be interesting to know.

Alvaro: That I would count as a success, if people actually subscribed to Last
Call who were not on the IETF list.

Martin D: The only metric that would indicate failure is if the volume of LC
reviews has dropped considerably, which of course you can also blame on the
pandemic, so it's not a great time for an experiment.

Francesca: I just re-read Michael's question, and what he was pointing out is
that there was a lot of discussion for a couple of documents and he was
wondering if that discussion should happen on the Last Call list or should go
back to the relevant list, for example the ECRIT document it could go back to
the ECRIT WG mailing list. That was the point he was trying to make. So it was
less general than asking "is it working?" More "is it working for these
specific cases" I think he was wondering about.

Mirja: Usually many of those things should go to the WG list and the Last Call
list, right?

Lars: Looking at that thread, ECRIT is CC-ed on that list. Maybe the mail
filter that he has didn't filter it there. The default Last Call messages are
cc-ing a bunch of different lists and people individually.

Francesca: My opinion is that it's fine to CC everyone, so my answer would be
yes, this is fine. This is not something that is out of norm or a failure of
using the Last Call mailing list.

Mirja: For the experiment as a whole, nobody has complained and it's been
running for a year. I would call that a success and run with it.

Eric V: I agree. For the reply to the IETF we can still leave it open and say
the IESG is satisfied; what about the community?

Ben: We can also say this is generally a success, but there may be some things
we want to tweak based on feedback we receive, or something like that.

Alvaro: Ben, did you mean you want to ask for more feedback, or the feedback
we've already received? I think we should say we're closing the experiment, we
think it's successful, and that's it. If people have opinions I'm sure they'll
let us know.

Lars: Sounds good.

Ben: That should work.

Eric V: So who is replying to Michael?

Alvaro: I'm not, but we don't only need to reply to Michael, we need to tell
the community we're ending the experiment.

Ben: I was going to ask if you wanted to do that, Alvaro.

Mirja: Who announced the original experiment?

Alvaro: Barry did. Sounds like an ART thing to me.

Warren: Sounds like a general thing to me.

Lars: If nobody wants to write the email, I can do it. We can figure out with
the Secretariat how to formally end an experiment. I guess we just say it
ended. Going quickly back to the chat discussion, Robert is talking to me and
apparently the tools team wants the IESG and IAB to tell the tools team which
chat service the IETF should be using. I told him I don't think many people
from the IAB and IESG participated in this trial and therefore I don't expect
strong opinions here. I don't have one. I told him we were looking for the
tools team to provide a recommendation, so I think we will have to return to
this topic in the future. I recommend you all try them and think about what
your opinion is.

Roman: Having been part of the earlier conversations, part of the challenge is
that we started this experiment with no requirements and no exit, so when the
decision gets made the challenge is we decide based on [insert criteria here].

Lars: But the "we" who started the experiment wast he tools team, not the IESG,
right? I'll talk to Robert offline. Before I forget, Amy, could you give me an
action item that we can track for me to write that email closing the Last Call
experiment? I don't want to forget.

Amy: Sure, we can give you an action item.

6.7 References Behind Paywalls

Amy: Do we want to discuss this today, or push it to next week?

Lars: I'd say let's quickly at least get started to see if we need more time
for it or not. We don't need a terribly long period for the executive session.

Eric V: Regarding the references behind a paywall, I don't think we have a
choice. For some protocols the only normative reference is behind a paywall.
What can we do? I think it can be clearly identified during the Last Call and
that's all we can do.

Francesca: I think that was what Suresh brought up. Some more guidelines for
authors were given about identifying these during Last Call. I didn't see
anything stated. I would be happy with such a statement as a first step.
Obviously I would be happier with no references behind a paywall, but I don't
know how to solve that. As an initial step I think a statement would be good. I
didn't really go into the details of the discussion; can someone who was there
summarize it for us newbies?

Ben: I don't know if this is a summary but another point that came up about
things we could do was to try and make copies of the reference available for
reviewers who need it to do their review. We have some liaison relationships we
can draw on for doing that. In some cases where we don't, we may not have an
official way to get copies of the reference to the reviewers. This is not a
full solution that always works but it would help a lot of the time.

Francesca: If this was combined with an IESG statement saying these need to be
clearly identified, if all this information could be in one place, be it a page
on the website or a wiki, that would be useful.

Mirja: I don't remember why we decided to not put any statement out; probably
because there's not clear guidance that's easy to give. As Eric said, just
saying that you cannot normatively reference documents behind a paywall is not
viable. The discussion was really about how can I evaluate the document if I
don't have context? How can I put my ballot in if I don't know what it's about?
That situation doesn't happen very often because as Ben just said, usually the
authors can provide a copy to people who need it in private. Usually that's
possible. If we ever get in a situation where you feel you cannot evaluate a
document because you don't have the references, it's really not clear what we
should be doing and that could be the reason we didn't go for a statement.

Francesca: I think from what I've seen, a couple of mails asked why we need to
have an IESG statement if we didn't have one until now? Why are we bringing
this up now? That's the type of reaction I saw to Suresh. I still would like to
improve things. We could give advice about maybe not having normative
references, but informative references, and having the part of the document
that is behind a paywall that needs to be read and understood in an appendix.
Maybe not copied word for word, but extracting the information hat is normative
into the document itself so one doesn't have to access the whole document but
the informative reference would be enough in that case.

Martin D: Advice that one should not do this as much as possible. A normative
reference is one where you're taking a little bit of something and using it in
the new standard. It wouldn't be that laborious to recreate it in the RFC. But
in other cases you require use of a very long standards document where you
really can't avoid a normative reference. Informing people in the former case
to just bring the text in is probably good for everyone.

Rob: I don't think we can bring the text in if it's not ours and we don't have
copyright. If we can get permission to do that, that's fine, but I'm not sure
it's a given. Maybe the answer here is just to give a statement of what the
problems are and how we can handle them the best we can. Maybe that's useful to
say. Here are the issues, if we can have access to them that's great, if we
can't, it may be a case where we don't feel comfortable approving a document
because we can't review it, and leave it at that.

Erik K: I think that's kind of the case with the NFC 6LO document. I don't have
the history of that at hand, but it goes way back, 700 or 800 days, and Eric
Rescorla was complaining that there was no way to get access to the NFC
document. My recollection is that I was told that there might have been a
liaison attempt and we couldn't get the document. I also haven't tried myself
so maybe I need to get a copy of the NFC document standard and run that
gauntlet to prove that it's not possible. Of course, getting the document would
solve the problem.

Roman: The suggestion by Rob to publish a soft set of principles guiding
decision making seems like the way ahead. Objections to that? The takeaway is
that there are no hard and fast rules.

Mirja: The minimum I think you should do to avoid having this conversation over
and over again is to document this in the wiki. If you come up with something
you actually want to publish as an IESG statement, you may as well.

John: I think the hard and fast rule is it has to be possible to get the
reference somehow. Being able to get it for free is a nice to have. I guess the
question is how high can the paywall be before it's considered to be
unreasonable? If I have to pay $10 for the article, let's move on; if I have to
pay $10,000 for a membership in an organization that's a different story.

Eric V: Maybe in the Last Call, or when people evaluate whether it's a useful
document, putting the pricing to access the normative reference behind the
paywall should be part of the decision. Then the community can say I want to
implement this but not if I have to pay $10,000 to become a member for one year
to access a ten page document.

Roman: So do we minimally want to write down part of this conversation into a
place on the agenda and that's the step to make sure future members of the IESG
don't have this conversation again? Then depending on what's in there we can
make another call to see whether that's polishable to publish something for the
community? Just trying to close the conversation here.

Zahed: Roman, if you want to write something like a summary, the only summary
I'm getting here is you can reference behind a paywall and the authors or
somebody should make it available when it's time for reviewing the document.
That's the only constructive summary I can get out of this discussion.

John: It comes down to this: reference things behind a paywall at your own
risk, because if people beat you up during Last Call because they say I can't
accept this document because I can't read your references, the problem is on
the author.

Zahed: I don't feel like we need to do all this in the Last Call. Maybe it
should be the WG, any author in the WG that has reference to something behind a
paywall, they should consider it really hard. As Erik said, sometimes we can't
do anything about it, but make it available at time of review.

Mirja: We could add something to the shepherd writeup   like: Is there
reference to a document behind a paywall, and if so, explain how people can
access it.

Alvaro: That's what the statement from Suresh wanted to cover, and it was more
around, if you know this is behind a paywall, at least the WG has to agree this
is okay and the shepherd has to document it.

Mirja: That's maybe a different point. Mine is, if you already know the authors
can provide a copy, then put the information somewhere so people know that and
can ask the authors about it. The natural place would be in the shepherd
writeup or in the last Call email.

Zahed: I would like to have those in the Last Call email. That would be nice.
Sometimes I don't always read shepherd writeups when I'm reviewing. Well,
nowadays I do.

Francesca: There needs to be some guidance for the IESG. Coming into this and
finding a normative reference behind a paywall, there was nothing in the
shepherd writeup so I don't know if it has been discussed in Last Call. What am
I supposed to do? Am I supposed to put a Discuss on it? I'm not sure it's worth
a Discuss. Does it go back to the WG?

Ben: I think it's acceptable to put in a Discuss for that. We need to confirm
there is consensus to do this thing and it's not documented in an accessible
fashion for you.

Francesca: Okay. That would be the type of guidance I was looking for. I didn't
end up putting in a Discuss for this document.

Mirja: I wouldn't expect that the WG wasn't aware of that, because then no one
in the WG would be able to review this document. That would be a full process
failure. I think it would be much more reasonable if you put a Discuss in if
you think you need the document to do your review.

Francesca: Alvaro said Suresh mentioned he wanted to bring this up again
because it had come up. The conclusion was there was no consensus of having
this type of statement but it's coming up again and again so maybe we need to
take this further. I'm okay with taking the action to go over the discussion
and see what was the result of contacting Suresh and trying to figure this out
where we're at at the moment, since I was the one to bring this up.

Lars: Okay. Should we then move to executive session for five minutes?

6.5 Executive Session: Confirmation of ISOC Board of Trustees Candidates