Narrative Minutes interim-2025-iesg-18: Thu 14:00
narrative-minutes-interim-2025-iesg-18-202509181400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2025-09-18 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Mike Bishop (Akamai) / Web and Internet Transport Area
Mohamed Boucadair (Orange) / Operations and Management Area
Morgan Condie (AMS) / IETF Secretariat
Deb Cooley (Independent) / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Gorry Fairhurst (Univ. of Aberdeen) / Web and Internet Transport Area
Liz Flynn (AMS) / IETF Secretariat
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Jean Mahoney (AMS) / RFC Editor Liaison
Cindy Morgan (AMS) / IETF Secretariat
Andy Newton (ICANN) / Applications and Real-Time Area
Tommy Pauly (Apple) / IAB Chair
Orie Steele (mesur.io) / Applications and Real-Time Area
Ketan Talaulikar (Cisco) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area

REGRETS
---------------------------------
Matthew Bocci (Nokia) / IAB Liaison
Jay Daley / IETF Executive Director
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

OBSERVERS
---------------------------------
Donald Eastlake
Sandy Ginoza
Vratko Polák
Ben Schwartz
Greg Wood

1.2 Bash the agenda

Mahesh: Can we take the BFD documents first so I can drop off after?

Roman: Of course; we'll do those right after the action items.

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes from the September 7
teleconference being approved? I'm hearing no objections, so they are approved
and will be posted in the Datatracker. Does anyone have an objection to the
narrative minutes from the September 7 teleconference being approved? I'm
hearing no objections, so they are approved and will be posted in the
Datatracker.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Paul Wouters to find designated experts for RFC 9770 (Notification
       of Revoked Access Tokens in the Authentication and Authorization
       for Constrained Environments (ACE) Framework) [IANA #1421561].

Liz: We'll mark this in progress for Paul.

     o Orie Steele to find designated experts for RFC 9795 (Personal
       Assertion Token (PASSporT) Extension for Rich Call Data)[IANA
       #1423169].

Orie: In progress.

     o Deb Cooley to find designated experts for RFC 9788 (Header
       Protection for Cryptographically Protected Email) [IANA #1428133].

Liz: We have a couple of names to approve for this one in the management items
section, so this one is provisionally done.

   * OPEN ACTION ITEMS

     o Roman Danyliw to take a look at Datatracker documentation of
       document states and update as needed.

Roman: Half the request is in. Making the changes on the WG states is done and
that will go into production; there is still a little revision to be made on
the IESG states because of the difference between Waiting for AD Go-Ahead and
AD Writeup so we need to polish that text. In progress.

     o Paul Wouters to propose a sentence to add to the "IESG Statement on
       Clarifying the Use of BCP 14 Key Words" regarding normative
       language in diagrams.

Liz: We'll mark this in progress for Paul.

     o Mahesh Jethanandani and Ketan Talaulikar to work with Dhruv Dhody
       and Suresh Krishnan to look into potential retreat locations in
       Asia.

Ketan: Still in progress.

     o IESG to draft a response to "Appeal to the forwarding of draft-
       ietf-lsr-igp-ureach-prefix-announce."

Liz: This went out so we will mark it done.

     o IESG to review & update the Non-WG List spreadsheet.

Cindy: Several people had sent out mail to lists saying if there was no
objection by X date we'll close it, and that X date for most is later this
month.

Mike: I think the last one is October 1st.

     o Éric Vyncke and Mike Bishop to schedule AMAs for people considering
       accepting nominations for IESG positions (one in Madrid, one remote
       after Madrid).

Mike: These are scheduled, so we can close it.

     o Roman Danyliw and Mahesh Jethanandani to draft update to "Guidance
       on Area Director Sponsoring of Documents" statement.

Roman: This one and the next are in progress.

     o Roman Danyliw to check with the Trust about whether the IESG
       Statement on Copyright is overtaken by RFC8721 Section 4.3.

     o Paul Wouters to suggest next steps on "IESG Statement on Maximizing
       Encrypted Access To  IETF Information."

Liz: We'll mark this in progress for Paul.

     o Med Boucadair and Mahesh Jethanandani to review "IESG Statement on
       Proposed Status for IETF Documents Reserving Resources for Example
       Purposes" and propose what needs to be updated.

Mahesh: In progress.

     o Roman Danyliw, Andy Newton, Cindy Morgan, Paul Wouters to work on an
       IESG statement about submitting appeals.

Liz: We'll talk about this later in the agenda, so this is in progress.

     o Andy Newton and Roman Danyliw to work on re-chartering dispatch to
       cover multiple areas.

Roman: In progress.

     o Ketan Talaulikar, Mahesh Jethanandani, and Roman Danyliw to work on
       an announcement regarding Datatracker state change for WG adoption.

Ketan: In progress.

     o Cindy Morgan to follow up with the Tools Team about the difference
       between "Waiting for Writeup" and "Waiting for AD Go-Ahead."

Cindy: I had a conversation with Robert about this and I've sent the details to
Roman, so we can mark this done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-netconf-port-numbers-07  - IETF stream
   Updates to NETCONF Transport Port Numbers (Proposed Standard)
   Token: Mahesh Jethanandani

Liz: We have no Discusses, so unless there's an objection now this one is
approved.

Mahesh: I think it's pretty much ready to go but put it in AD Followup please.

 o draft-ietf-lamps-rfc5272bis-08  - IETF stream
   Certificate Management over CMS (CMC) (Proposed Standard)
   Token: Deb Cooley

Liz: We have no Discusses, so unless there's an objection now this one is
approved.

Deb: Revised I-D Needed, please.

 o draft-ietf-lamps-rfc5273bis-08  - IETF stream
   Certificate Management over CMS (CMC): Transport Protocols
   (Proposed Standard)
   Token: Deb Cooley

Liz: We have no Discusses, so unless there's an objection now this one is
approved.

Deb: I don't really have anything to say with this. We got a thorough review
from Ben Kaduk and an HTTP directorate review as well, which is going to drive
some change. They may have to go back to the wg to double check the HTTP
changes the HTTP directorate guy wanted, so I think Revised I-D Needed is
probably where we need to leave this.

 o draft-ietf-lamps-rfc5274bis-08  - IETF stream
   Certificate Management Messages over CMS (CMC): Compliance
   Requirements (Proposed Standard)
   Token: Deb Cooley

Liz: We have no Discusses, so unless there's an objection now this one is
approved.

Deb: Can we put it in AD Followup, please? Also a question, when I progress
these three together is there anything I need to do to make sure they go en
masse?

Liz: If you push the buttons at the same time we'll get the tickets at the same
time. If you want to be sure you can just send us a note about it. This
document does have a downref; do you want to add 9579 to the downref registry?

Deb: 9579 currently has a bis draft in the RFC Editor's queue, and this will
eventually get updated to reference the bis RFC and we'll add that to the
downref registry but not 9579.

Liz: Great, so this is Approved, Announcement to be Sent::AD Followup.

 o draft-ietf-scitt-architecture-20  - IETF stream
   An Architecture for Trustworthy and Transparent Digital Supply
   Chains (Proposed Standard)
   Token: Deb Cooley

Liz: We have no Discusses, so unless there's an objection now this one is
approved.

Deb: AD Followup, please.

 o draft-ietf-httpbis-optimistic-upgrade-05  - IETF stream
   Security Considerations for Optimistic Protocol Transitions in
   HTTP/1.1 (Proposed Standard)
   Token: Mike Bishop

Liz: We have no Discusses, so unless there's an objection now this one is
approved.

Mike: Let's do AD Followup; I want to check a few of the comments.

Deb: [An author] Ben is on the call.

Mike: Thanks. Ben, is there anything you want to add?

Ben Schwartz: Let me know when I should cut a new version.

Mike: Whenever you're ready!

 o draft-ietf-tsvwg-usr-exp-14  - IETF stream
   User Ports and Port Identifiers for Experiments (Proposed Standard)
   Token: Gorry Fairhurst

Liz: We do have a few Discusses in the tracker; do we want to discuss these now?

Gorry: I think so. I think we need to work with Joe to revise this. I'd love to
know what Deb thinks about port based security so I know which way to prod him.
Do you have thoughts now, Deb, or would you rather discuss this afterwards?

Deb: I'd rather discuss it afterwards once I gather my thoughts.

Gorry: That's okay. What about Ketan? You didn't particularly like the idea of
a registry at all.

Ketan: The registry for the experimental parts. I was not fully convinced about
the PExIDs but I'll leave that to Mike. It's 4 billion; having a registry for
that, I don't know if we have an IANA registry for experimental allocations
which are expected to be short lived and in closed conditions. My concern is
that having a registry makes it official and well known and things could just
stick or stay there. Not having a registry is a good incentive to move on after
the experiment and if it's successful go on and get the ports. If the firewalls
are open for the user port but now we have PExIDs and firewalls are not able to
look at it, some other PExIDs or other traffic can also get in, right? I'll
leave that to Deb. My concern is I'm just not comfortable having an
experimental [registry] thing. And one other thing which was a small simple
thing to fix is the layout of the registry. Maybe the reference was wrong
there, but that should be simple to fix.

Gorry: I think the layout is easy. The bigger question comes to security when
you start opening up ports and then you multiplex on them, and whether that is
a thing we want to put guidance around or whether there are things we don't
want to have. I guess that's a useful point to clear before we look at the
other things. Is there anything other people think is the first thing we should
look at? Mike, did you want to say something?

Mike: Yes. I feel like this document is about ¾ of the way to 2 different
designs and hasn't picked one yet. Either you have a shim protocol for demuxing
experiments that you can register an identifier for and you can expect a
package or an OS to implement, so and so. You can define that shim protocol;
whether or not it's useful is a separate question. You can define it, someone
can build it, and then you can run your experiments over that. Or you can do
what a lot of protocols do today and embed a magic number that I randomly
generated a 32 bit or a 64 bit thing I'm going to throw my packets at a place I
know to check. If I get a packet that doesn't look like that, it's not mine,
I'm going to ignore it. I feel like this draft builds the registry, describes
how you could demux on it, and then says you'll stick that identifier somewhere
in the packet at the beginning of your connection. If I were going to build
that in the OS, I can't implement that. I can't find it somewhere in the
handshake. It's all SHOULDs, not MUSTs. If you're defining a protocol you need
to be specific enough that it can be implemented. If you're not doing that,
then it's just guidance and you probably don't even need the registry.

Gorry: That boils down to why the IANA ports team gave this over to TSVWG as
something they wanted to do. I think we could push back a little bit and find
out what their detailed requirements were that came up with this solution and
that would be helpful input into this discussion. I get what you're saying,
Mike.

Mike: To be clear, I think I would ballot NoObj to either of those designs, but
this isn't either one.

Gorry: Okay. Does anyone else want to say anything at this stage? Okay, then we
need to discuss with the editor and possibly include the ports team because
it's an IANA registry change and it's a bit complicated.

Liz: This document is staying in IESG Evaluation. What substate would you like?

Gorry: Let's go for AD Followup and try to get answers to some of these
questions first and then move it to Revised I-D Needed later.

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-bmwg-mlrsearch-14  - IETF stream
   Multiple Loss Ratio Search (Informational)
   Token: Mohamed Boucadair

Liz: There are no Discusses in the tracker, so unless there's an objection now,
this one is approved.

Med: Revised I-D, please.

Liz: So this one is Approved, Announcement to be Sent::Revised I-D Needed.

 o draft-ietf-bfd-optimizing-authentication-33  - IETF stream
   Optimizing BFD Authentication (Experimental)
   Token: Ketan Talaulikar

Ketan: A clarification on the Discuss from Éric; it's about whether this
experimental document updates the base BFD RFC which is Standards track. The
answer is no; there have been some updates made by the authors to clarify this,
but perhaps more is needed. This experimental document is introducing new
authentication types, and each type defines its own format. There is some
language that might have given an impression this updates, but that's not the
case, so I'll work with the authors to clarify.

Mike: Suggest you address mine and Roman's abstain as part of this?

Ketan: Yes. Next to Gorry's Discuss about use of the word optimizing and the
idea that that gives an impression it's better authentication. There are some
alternate proposals; we could call it perhaps lightweight BFD authentication.
One other key part is this brings the ability to alternate between use of the
regular message digest authentication for less regular packets, that are
control packets let's say and a lightweight CSPRNG based one for packets which
are identical, more like an echo request and reply which go at a faster rate.
We could consider calling it lightweight authentication or CSPRNG based BFD
authentication. We have some options and we can discuss now or on email.

Gorry: All those sound like things we could do by email. Any of those would be
okay for me.

Ketan: Deb has a few points. The authors are ready to change 'strong' to
something else. Except for the simple and null authentication, the others are
like message digests over the entire BFD packet, whereas the less CPU intensive
one is pseudo random number based. I wonder if we can work out those
terminologies offline.

Deb: Certainly. Message digest authentication is not a bad idea.

Ketan: Before we move on to the abstains, Mahesh, as a co-author would you like
to add anything?

Mahesh: We've gone back and forth on how to describe the method currently
described as optimized. We're open to the idea of naming it whatever the
security ADs feel is the right way to describe the mechanism.

Ketan: I think we'll need more time to work through these but at the high
level, we can work on terminologies. The key difference is the lightweight
mechanism that's pseudo-random based. Moving on to the abstains, I believe the
interpretation was there was no known implementation or planned implementation
and that was the main reason for the abstain.

Mike: Correct. That's what the shepherd writeup says for all three.

Ketan: I'd read that as no current plans. We don't know, there may be a need
to; the state of deployments right now is that there is [practically] no
authentication used in BFD at all. There may be a need for this in the future.
Since the WG has spent efforts and they realize that without implementation
there's no proof in the pudding, that's why it's experimental.

Mahesh: These documents were always meant to be PS all the way until WG last
call. At that time since there was a lack of implementation, the agreement was
to make it experimental and make sure it was easier to implement in the future.
A lot of vendors don't want to implement an experimental draft. The idea was
that if it's published as an RFC, even if it's experimental, vendors would be
more open to running it as an experiment. It's not that there's no interest in
implementation.

Roman: PS documents don't have implementations sometimes. What I'm more
confused by is if no one plans to implement it, why publish it at all? That's
what I am reading literally from the shepherds report.

Mahesh: It's not like no one wants to, it's just they feel hesitant to
implement something that is experimental. I don't think it's true there's
absolutely no interest. We have vendors saying they'll take a look at it once
it's published as an RFC.

Deb: So the shepherd's writeup is incorrect?

Mahesh: I think it's unfortunate to be described as no interest; that's not
fully true.

Mike: 'We'll take a look' isn't that great as well.

Ketan: Whether vendors prioritize implementation is market driven. All of these
have some implications. And especially on the silicon as well in many cases.
Personally I believe it's good to document it. If there is any attack on BFD,
suddenly there will be a market [for this]. Since a lot of WG time and
engineering has been done, I think it's fair to document this as experimental.

Roman: Wearing my security hat, that's an interesting setup, because it says we
don't have the feature, we're waiting for an attack that will happen, and we
were just talking about silicon. So with silicon, the delay to implement this
feature to get this in the wild to mitigate attacks, we're now talking years.
I'm a little unpersuaded by this argument if the delay is going to be years
away.

Ketan: I believe that's the accurate state of affairs.

Deb: Are there implementations of 5880?

Ketan: Oh yes.

Deb: What authentication method have they chosen?

Mahesh: The ones that silicon vendors have decided to implement have been with
no authentication.

Ketan: When we say implementation there are two kinds; one that we can do in
software and any authentications can be done straight away. That would work to
a certain scale. To go to a higher scale with a faster interval, those use the
silicon and those don't have any authentication as far as I know.

Deb: It sounds like there have been software implementations but no hardware
implementations?

Mahesh: In software, only at the very slowest speeds. It's not fast enough.

Deb: Even if we approve these experimental drafts, you still can't run this
stuff in software, can you?

Mahesh: The authentication requirement kicks in only for control packets that
are transitioning the state of the BFD session. Those have a much higher
interval, I believe up to a minute. Strong authentication can still be done
there. The optimizing part is to say for the remaining packets that do not
affect the session other than to keep the state, it doesn't need to be
authenticated that way; it can use a less computationally intensive method.

Ketan: Right, one that is message digest based with the CSPRNG based assumption
that the CSPRNG ones can have certain properties or characteristics that have
possibility of being used in silicon. But that detail is in the other draft,
not this one.

Deb: But your hashes are all in software, you can't afford to do them very
fast. Therefore, if you do them just on the control package, you think that
might work. The question is what are the options for less intensive? I made a
comment about that on the other draft.

Mahesh: There's also the question of key management Deb brought up.

Deb: Don't look at this one yet, I need to go back and read 5880 to find out
where those keys come from. I thought they were in your discriminator and my
discriminator and apparently that's not correct. That's fine.

Mike: I think I'd found they were supposed to be out-of-band configured by the
administrator?

Ketan: Yes.

Mike: So it's effectively just a PSK.

Deb: Or a password. In the other draft the example given is just an ASCII
string. Which looks a lot like a password.

Liz: This document will stay in IESG Evaluation; which substate would you like?
I'm guessing Revised I-D Needed?

Ketan: Yes.

 o draft-ietf-bfd-secure-sequence-numbers-25  - IETF stream
   Meticulous Keyed ISAAC for BFD Optimized Authentication
   (Experimental)
   Token: Ketan Talaulikar

Liz: We also have a couple of Discusses on this one.

Ketan: There is a proposal from the authors to use ISAAC. Is that okay or do we
want to look at other CSPRNGs? I think that's a longer conversation we should
probably have offline. Unless Deb or Mahesh wants to discuss it here.

Deb: It's sort of the optimized draft plus, right? There are more issues with
key management, more issues with how to do implementations, more issues with
statements of the fact it's a robust algorithm, things like that. If you
downscale how much security you're getting from this, and just accurately
document how things are handled and put in a statement saying just because
we're using this algorithm here doesn't mean you're going to use it anywhere
else and that sort of thing, then I think the actual security requirements here
are very minimal. That just needs to be stated properly. And again you have the
same problem; nobody's using this, nobody's even attempted to implement it. Who
knows what you're going to find out once you attempt to implement it. My other
comment is, a lot of times AES is a standard cell in the library of lots of
CPUs. Why can't you run AES in a stream mode in hardware and just generate
random numbers the same way you're doing for the ISAAC thing? Chuck them into a
table and use it the same way. But the base algorithm is actually something
that's had actual evaluation for decades.

Ketan: That's maybe a little difficult to answer. I think we can have this
discussion on email, that may be better.

Mahesh: BFD is implemented on all sizes of routers; single RU boxes all the way
to line cards. It becomes a bit of a challenge in those situations where you
don't have any help in hardware to generate streams, even an AES stream.

Deb: I guess it just depends on what they've got from a hardware point of view.
But I will just say AES has been in standard cell libraries literally since the
mid 2000s.

Mike: Also even if the answer is many of them don't have AES in hardware, I'd
be willing to bet they don't have ISAAC either.

Ketan: That's a fair question. I think we need to get some answers and more
details.

Deb: I think the claim is that ISAAC runs fast enough in software that it
doesn't need to be in hardware, and that's because it's RC4 based. If you're
doing this sort of thing in the background anyway, how fast does it really need
to be? ISAAC doesn't run in real time, it runs in the background generating a
page of values.

Mahesh: I think that's a fair statement and I'll take it back with the authors.

Deb: One more thing. SipHash has been proposed. I don't feel it's necessary to
drop one unevaluated algorithm for another. As far as I know it hasn't been
rigorously tested.

Mahesh: Since Ketan has stepped away, I think we can also put this one in
Revised I-D Needed.

Liz: This one is IESG Evaluation::Revised I-D Needed.

 o draft-ietf-bfd-stability-19  - IETF stream
   BFD Stability (Experimental)
   Token: Ketan Talaulikar

Liz: There are no Discusses on this one, so unless there's an objection now,
this one is approved.

Ketan: I think this probably still needs updates from the comments. Can you put
it in AD Followup, please.

Liz: This one is Approved, Announcement to be Sent:: AD Followup.

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-lim-apv-00
   IETF conflict review for draft-lim-apv
     draft-lim-apv-07
     Advanced Professional Video (ISE: Informational)
   Token: Roman Danyliw

Liz: Do we have a volunteer to do this conflict review?

Roman: This is a codec video processing thing, so I'm thinking maybe ART could
take it?

Andy: Sure, I can take it.

Gorry: AVTCORE had a presentation on this, but I think it's more ART.

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

 NONE

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)

Liz: There are no blocking comments here; are there any objections for sending
this to external review? [Silence] Okay, so this is approved for external
review but since Paul isn't here, we'll check with him to make sure it's ready
before we send the announcement.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Deb: There are a bunch of comments the IAB is sending out; one is on ICANN's
root server system advisory committee discussion. There's also a WSIS+20 draft
they're also commenting on. And a bunch of liaison discussions.

6. Management issues

6.1 [IANA #1427994] Management Item: Acceptance of media type registration from
prostep ivip

Liz: We had this on the agenda last time and we agreed to bring it back today
after having some more time to look into it. Has anyone had a chance to do that?

Andy: I looked at it. They're a standards body. I'd say we go ahead and approve
this.

Roman: I concur.

Liz: Any objections to approving this media type registration? [Silence] This
is approved and we'll send the official note to IANA.

6.2 [IANA #1428290] Management Item: Renaming IP address registries

Liz: This is the new proposed naming from IANA. Are we ready to approve?

Andy: Is this the updated one?

Cindy: Yes, this is the updated version that was sent around yesterday.

Sabrina: These are the new names.

Ketan: Looks good to me, thank you.

Erik K: I missed the discussion last time; can I ask why IANA is being dropped
from the title? Is that happening for all such registries?

Sabrina: Yes, along with the word registry. We're trying to remove those to
make it more consistent.

Roman: Or else you have the official name being something-something registry
registry.

Erik K: Okay. I see. That makes sense.

Liz: I'm not hearing any objections or questions. I think this is approved, and
we'll send a note to IANA.

6.3 [IANA #1429248] renewing early allocation(s) for
draft-ietf-sidrops-aspa-profile

Liz: This is a request for a renewal from one of Med's documents. Med, do you
have anything you want to let us know about?

Med: Nothing specific other than this document is likely to be in WG last call
soon, so I think it's worth extending.

Liz: Any objections to approving this renewal? [Silence] Okay, this is approved
and we'll send an official note to IANA.

6.4 [IANA #1428133] Designated experts for RFC 9788 (Header Protection for
Cryptographically Protected Email) (Deb Cooley)

Liz: Deb has found Daniel Kahn Gillmor and Bernie Hoeneisen as DEs for this
registry. Are there any objections to approving them? [Silence] Great, so they
are approved and we'll send the official note to IANA.

6.5  [IANA #1429703] Designated experts for RFC 9820 (Authentication Service
Based on the Extensible Authentication Protocol (EAP) for Use with the
Constrained Application Protocol (CoAP)) - (Paul Wouters)

Liz: This is a new action item for Paul, so we'll put this on the list for him.

6.6 Executive Session: Appeals and statement on appeal norms

The topic was discussed in an executive session with IESG, IAB Chair, and
Secretariat present.

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

Deb: EODIR met yesterday to talk about preparing some information about GitHub
for various communities. They have three things they're going to start with;
how a WG chair would organize a workspace, how to use Martin Thomson's
template, and how to make a pull request from a reviewer's point of view.
They'd probably love help with this, if you know of anyone who'd be interested
in working on it.

Andy: We have a couple of RFCs on how to use GitHub that are informational; how
is this different?

Roman: They're trying to give a click by click tutorial.

Deb: Education, yes. For all sorts of different people and what sorts of levels
of Github guidance do people need. An author needs one thing, but a reviewer
needs another thing. An opportunity to provide click by click instructions on
how to do things is the goal.

Roman: Imagine a circumstance where you're providing feedback and the WG says
give us a pull request. If you're not familiar with the process, especially if
you're not coming from an element of a day job where you have this in your
workflow like you're a policymaker or a civil society rep.

Deb: This is a result of feedback they've received online and from the WG
chairs lunch in Madrid.

Liz: Reminder that WG scheduling closes tomorrow.