Skip to main content

Narrative Minutes interim-2019-iesg-13 2019-06-13 14:00
narrative-minutes-interim-2019-iesg-13-201906131400-00

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

narrative-minutes-interim-2019-iesg-13-201906131400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes of the June 13, 2019 IESG Teleconference

These are not an official record of the meeting.

Reported by: Cindy Morgan, IETF Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Deborah Brungard (AT&T) / Routing Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Sandy Ginoza (AMS) / RFC Editor Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area

REGRETS
---------------------------------
Heather Flanagan / RFC Series Editor
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Wes Hardaker (USC/ISI) / IAB Liaison
Mirja Kuehlewind (Ericsson) / Transport Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

OBSERVERS
---------------------------------
Greg Wood

1.2. Bash the agenda

Amy:  Does anyone want to add anything new to the agenda?

Alissa: When we get to management items, let's talk about the second retreat
dates before the telechat dates; I think that makes more sense.

Amy: Sure, we can swap the order of 6.3 and 6.1.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the May 30 teleconference
being approved? Hearing no objection, so those are approved and we'll get those
posted in the public archive. And the narrative minutes were sent on Tuesday;
does anyone have an objection to the narrative minutes of May 30 being
approved? Hearing no objection, those are approved and we'll get those posted
in the public archive as well.

1.4 List of remaining action items from last telechat

  o Ignas Bagdonas to propose an additional question on YANG Model
    format validation for each of the styles of document write-ups.

Ignas: It's not yet complete, please keep this as in progress.

  o Roman Danyliw to talk to the tools team to reset the counters on
    substate change for documents in AD Evaluation.

Roman: That is in progress, there are a number of tools requests I need to
batch up and bring to everyone for discussion; it's more than just this one.
I'll send something out before the informal next week. So, it's in progress.

  o Roman Danyliw to draft text to be posted on ietf.org about reporting
    protocol vulnerabilities via an email alias and possible procedures
    on how to assign triage resources.

Roman: This is also in progress. I've started reaching out to a couple of WGs
to get their perspective on how they would react to this class of information
and get some feedback, but I don't have anything to share yet. I hope to have
something soon.

  o Suresh Krishnan to write a document on replacing the "updates" with
    new terminology (amends/amended by; extends/extended by; see also).

Suresh: This is still in progress.

  o Warren Kumari and Ted Hardie to write a document on Implementation
    Target Sets (aka Living Documents).

Warren: That's still in progress. There's one bit of text, but we still need to
discuss it more and come up with text for the other use cases. So, in progress.

Ted: Do you want to add that to the next informal, just for the discussion to
complete?

Warren: Probably, although you and I should chat.

Alissa: I was planning to do that anyway, to make sure it happens.

Warren: Woohoo, a forcing function!

  o Roman Danyliw and Barry Leiba to draft a starting point for the
    discussion on setting expectations with the WG Chairs in reference
    to responses to inappropriate or unacceptable behaviors.

Roman: Unless Barry has something, we have done nothing and that's on us.

Barry: We had promised to do it by this telechat and we failed. Let's try next
week, Roman.

Roman: Makes sense.

  o Martin Vigoureux to work with the IESG to create a list of possible
    IESG Tutorials and will prioritize them for scheduling on a series
    of Informal Telechats.

Martin: I have received some feedback, but not from everybody, so I will ping
ADs individually because I know my emails can get lost on the pile of other
emails I've sent to the IESG list. It's in progress.

  o All IESG to coordinate with their co-ADs and send a list of specific
    "hot topic" items that should be checked. The list to be provided
    for document authors.

Amy: I know we were waiting for at least one Area.

Benjamin: I think we're still waiting. And yes, that's the guilty party
speaking up.

  o Eric Vyncke to write up draft text for the NomCom to help them
    understand the rules for the NomCom.

Eric: Still a work in progress.

  o Suresh Krishnan to write up a NomCom Chair BCP (work with past
    chairs).

Suresh: Still in progress.

  o Eric Vyncke to draft text for a more coherent BoF Proposal for
    MEDIA OPS and add to the BoF Wiki.

Eric: It's done.

  o Roman Danyliw to shepherd the www.ietf.org analytics discussion
    with the community.

Roman: This is wrapped up in the first item, which is the larger tools things
to bring to the group. The call has closed and we got a lot of great feedback.
I need to drop the summary email on the list, but practically, it's going to
recommend that there's a number of things the IESG need to think about, and
Greg and I are pulling that list together with a proposal. We're going to chat
before we go back out to the community. So this is still in progress, but
really close to the next step.

  o Warren Kumari, Alvaro Retana, and Mirja Kuehlewind with Spencer
    Dawkins to continue discussion of the next Deep Dive topic for
    IETF 105.

Alvaro: It's still ongoing. Mirja reached out to some people to ask them to do
this, but we still haven't settled on whether this will happen or not.

Amy: So we'll keep this in progress and check back in next time.

  o Alexey Melnikov, Warren Kumari, and Suresh Krishnan to work with the
    authors of the recall draft on next steps.

Alexey: There was some work done, mostly by Suresh. Do we want to keep this
here?

Suresh: I think we've done all that we can do. Now it's for the proponents to
come up with the stuff. I'd say this is done.

Alexey: I agree. I don't think we'll forget about the topic. Mark it as done.

Warren: Let's mark it as done, but it would also be helpful if other IESG
people, in their copious free time, could have a look at the thread if they
aren't anyway. And yes, Suresh has been doing the huge majority of this; thanks
Suresh.

Amy: We will mark the action as done, and you'll let us know if any other
action items come out of anything related to this.

  o Alexey Melnikov to find designated experts for RFC-ietf-core-object-
    security [IANA #1141664].

Alexey: It is in progress.

  o Alvaro Retana to finalize the proposal for relabeling the IETF
    Meeting Agenda Conflicts, and discuss the proposal with the WG
    Chairs.

Alvaro: Still in progress.

  o Alissa Cooper and Alexa Morris to take the results of the doodle
    poll for a second 2019 IESG retreat (possibly combined with the IAB)
    and look at cost effective places.

Amy: I know we're talking about dates at the end of this call, so this is the
action item that will come after the dates are chosen.

Alissa: We don't need to revisit this every week. The next action, depending on
the discussion later, will be to decide if we are going to schedule the thing,
so this isn't even the right action item. You can mark this as done and we'll
come back to it after 105.

  o Alexey Melnikov to find designated experts for RFC 8554 [IANA
    #1142796].

Alexey: In progress.

  o Adam Roach to facilitate the discussion on WG Meeting Structure,
    related to alternate room layouts and the facilitation of
    discussion.

Adam: That's in progress. I have pending an action to send something to the WG
chairs list. I think that's where we want to have the conversation, unless
someone has a different idea about that.

  o Ted Hardie to write up use cases and requirements for Implementation
    Target Sets for a future IESG discussion (preliminary date for
    discussion: June 20, 2019 Informal Telechat).

Amy: This has a discussion date for next week so we'll take it then.

2. Protocol actions
2.1 WG submissions
2.1.1 New items
  o draft-ietf-idr-bgp-ls-segment-routing-ext-15  - IETF stream
    BGP Link-State extensions for Segment Routing (Proposed Standard) -
    1 of 5
    Token: Alvaro Retana

Amy: No discusses, but an open position for Alexey. Did you want to state one?

Alexey: No, and any other document where I don't have a position, I won't have
one.

Amy: OK. Eric, did you want to state a position?

Eric: I didn't have time to read it.

Amy: No discusses, so unless there is an objection this is approved.

Alvaro: This will need a revised ID, thank you.

Amy: Approved, announcement to be sent, revised I-D needed, and you can let us
know when it's ready.

  o draft-ietf-softwire-iftunnel-07  - IETF stream
    Tunnel Interface Types YANG Module (Proposed Standard) - 2 of 5
    Token: Eric Vyncke

Amy: No discusses, so unless there is an objection this is approved.

Eric: I need to check if the revised ID from this morning is fixing all
comments, so maybe revised I-D needed and I will clear it later.

Amy: If you think this revision might fix things, point raised, writeup needed
would be the more appropriate state. And you'll send us a ticket once it's
ready.

  o draft-ietf-softwire-map-radius-25  - IETF stream
    RADIUS Attributes for Address plus Port (A+P) based Softwire
    Mechanisms (Proposed Standard) - 3 of 5
    Token: Eric Vyncke

Amy: There is a Discuss. Do we need to discuss it today?

Eric: I need to check, the new one came out right before the call. I think this
fixes Suresh's Discuss, but I need to check.

Suresh via Jabber: I will clear right now.

Amy: With that clear, we don't have a Discuss, that looks like this is
approved. Eric, did you want to just check that, so we'll put it in point
raised so you can look at the notes. There are a number of notes in the
tracker, as well as a downref. Do you want us to add that downref to the
downref registry once the approval has been sent?

Eric: Yes, to be honest, I have no clue about the question you're asking; sorry.

Amy: This is actually a new question that we're asking. When a document is
approved, the Datatracker now tells us if there is a downref, and it looks like
this document has one listed for RFC 5176, an Informational RFC in the IETF
stream. If it's correct, we'll take it and add it to the downref registry.
Before this, it was your responsibility as the Area Director to do that, and
the Tools Team noticed that it wasn't being updated frequently when it should
have been. So the Datatracker will now tell us when a document possibly has a
downref.

Eric: OK. Then I guess we need to put it in the downref registry, right?

Barry: We don't need to put everything in the downref registry. It's a decision
we make.

Adam: Right; it's do we think this is ready to be used pro forma and not
announced on future documents if the same downref occurs; that's the decision
we're making.

Benjamin: And it may well be, but this particular document has a very long
section about why it is recommended for Informational rather than standards
track. The backstory is something like, some of the implementations already
existed at the time of publication did not want to be labeled as not conforming
to a standards RFC, and so the document had some very weak language in it so
that these implementations could still claim compliance even though they are
doing some things that are not so great, security-wise. And so the actual text
of the document still allows these not so great security-wise things to be
done. And it explains that it's Informational and not Standards-track as result.

Barry: It sounds to me like this document should never be in the downref
registry.

Eric: That is what I am getting from the discussion as well. Please don't put
it there.

Amy: So we will not add this downref to RFC 5176 to the registry. This is in
approved, announcement to be sent, point raised, writeup needed, and you'll let
us know when this is ready to be sent.

  o draft-ietf-sipcore-rejected-08  - IETF stream
    A Session Initiation Protocol (SIP) Response Code for Rejected
    Calls (Proposed Standard) - 4 of 5
    Token: Adam Roach

Amy: No discusses in the tracker, so unless there is an objection this is
approved.

Adam: I believe this will need a revised I-D; there were a lot of comments, and
some will require changes.

  o draft-ietf-grow-wkc-behavior-07  - IETF stream
    Well-Known Community Policy Behavior (Proposed Standard) - 5 of 5
    Token: Warren Kumari

Amy: No discusses, so unless there is an objection this is approved.

Warren: If folks are OK, I'd like to explain some of the backstory. I'll
mention this was originally Proposed Standard, then became BCP for a little
bit, but from a bunch of directorate review and AD comments, it was suggested
that this should be listed as updating RFC 1997, because when people read that,
they really, really, really should read this as well. The reason we were in the
bad situation was because people didn't know about this or had implemented
things poorly, causing operational issues. When reading 1997, you really should
read this, which is why this is an "updates," and why it's PS. And a number of
people asked why this says vendors SHOULD instead of MUST, the WG didn't think
it was appropriate for the IETF to tell vendors what to do. However, in this
particular case since it's documentation and not "you must implement," I think
maybe the comments people have been providing that this should be a "vendors
MUST" document is reasonable. So I will request the authors to change the
SHOULD to a MUST, and move this along. Does anyone have any strong grumps? So,
I think this is probably a revised I-D needed, just to change the SHOULD to a
MUST, and then we can progress this and the WG will be really happy because
this is something people feel strongly about.

Amy: And I see there is a note in the ballot writeup that you asked us to
remove before sending, which we will do. So we're just waiting for your
go-ahead, because this will go into approved, announcement to be sent, revised
I-D needed.

Warren: Actually, I think this can just be approved, because the SHOULD to
MUST, I can just drop a note and that can happen after, so it doesn't require a
revised I-D. We can ask the RFC Editor to do that during AUTH48, I think. Does
anyone object to that? [No.] Cool, done.

Amy: Okay, so this will go into approved, announcement to be sent, and we will
get this sent on Monday as we would normally.

2.1.2 Returning items
  o draft-ietf-teas-yang-te-topo-21  - IETF stream
    YANG Data Model for Traffic Engineering (TE) Topologies (Proposed
    Standard) - 1 of 1
    Token: Deborah Brungard

Amy: No discusses in the tracker for this document, so unless there is an
objection this is approved.

Deborah: We'll do this as point raised so the authors can get a chance to look
at the comments.

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-netvc-testing-08  - IETF stream
    Video Codec Testing and Quality Measurement (Informational) - 1 of 3
    Token: Adam Roach

Amy: A number of Discusses.

Adam: I do want to touch briefly on Roman's points. There is a bit of a
conundrum here. Substantial portions of what this doc relies on are living in a
Git repository. I understand the concerns that Roman is expressing here, which
is that we have this external resource that may change or disappear. So
minimally, we should probably point to a specific commit in the document, but
it's not clear if that is sufficient to address the point that Roman has
raised. I think we need to have a broader conversation around how we handle
these kinds of situations in the future. For this document in particular, I
know this specific team has experience taking large code bases, .TARing them up
and putting them in documents in base 64, if you look at the Appendix A of RFC
6716, there are hundreds of pages of exactly this. I wanted to ask Roman if
that's what he wants to do for this particular document, or is there some other
better way that we can move forward without doing that again--because a lot of
people really didn't like that approach.

Roman: I don't know how that approach would be reasonable, because that would
mean you'd have to take a whole lot of video files as well, right?

Adam: Yeah, so if you want to include the video files as part of what we
include here, you're probably talking about tens of thousands of pages of
base-64, which I imagine the RFC Editor would not be happy about.

Roman: There's a couple of ways to play this. I think the bigger question is,
does the IETF need a way to host information like that RFCs can point to for
things that are larger than documents and aren't code points. I think in the
case of this document, if we had a bunch of specificity around which part of
the repo, and honestly, saying that we know this stuff might disappear, but we
think this was valuable enough to get us through the test review, I'd be
willing to clear because this is Informational.

Adam: So to that specific point and not addressing the broader issue, just
having a very specific pointer to a subtree on GitHub and a commit
identification should be sufficient to move this forward, is that correct?

Roman: Yes, writ large, but the finesse is that it's not actually even GitHub,
it's another repo, right?

Adam: Sorry? I think all of the site encode here is on GitHub.

Roman: Ah, okay, fair enough.

Adam: I'll pass that along to the authors, and for everything else, I'll just
give the authors time to respond.

Roman: The key thing is that if we're going to do this, and I appreciate that
there is no other way to do it, then I think we need to put a massive
disclaimer saying that the value of this document is unknown over time because
the underlying pointers may disappear.

Adam: Right. That's reasonable.

Amy: Is this going to require a revised I-D?

Adam: Yes, it certainly will require a revised I-D.

  o draft-ietf-netvc-requirements-09  - IETF stream
    <Video Codec Requirements and Evaluation Methodology>
    (Informational) - 2 of 3
    Token: Adam Roach

Amy: This has a couple of Discusses.

Adam: Looking through Benjamin's, I'm not entirely certain on the points that
Bernard raised, that they're strictly on point. I think what he was conflating
is the fact that it's trying to use old technology as a baseline to demonstrate
improvement. Now, the authors haven't been particularly responsive, so Bernard
hasn't had that response and had a chance to respond to it, but I suspect that
it's a misunderstanding on his part regarding what the references to the older
technologies are intended to do.

Benjamin: Possibly. I mean, this is not my area of expertise at all, so I'm
relying on Bernard and you all to clue me in, but my reading of what Bernard
was saying is that the document was focusing on what kind of scalability
domains you would need for certain use cases, and that current use cases have
moved on past that to requiring different scalability requirements. The hard
requirements in this document are for temporal scalability, like changing the
frame rate on the fly. It would be nice to also support spatial scalability to
be able to change your resolution on the fly. I thought Bernard was trying to
say that in some of the current use cases for over varying quality links, you
effectively do need to be able to change the bit rate on the fly to have a
usable experience, and so the requirements that this document was trying to use
as hard requirements might not be the most current use case requirements.

Adam: I'll go back and re-read what he said, then. I didn't take that away from
it.

Benjamin: I would love to hear more back from Bernard responding to the
feedback from the authors, but I'm also happy to clear right now if you would
like me to.

Adam: Let's let this conversation play out. I don't want to presuppose that
your concerns aren't valid here. Let's see how that conversation goes with the
authors.

Benjamin: I'm happy to clear because I'm not sure I can formulate my concerns
in a concrete manner that's actionable, so it doesn't quite meet the Discuss
criteria.

Adam: Okay. Your call if you want to clear and trust that the conversation will
play out. I'm going to watch all the points that were raised, if you move that
to your comments so that the points that Bernard raised are at least addressed.

Benjamin: I will clear and move that to my comment so that I feel more
comfortable.

Amy: IESG Evaluation, Revised I-D Needed.

  o draft-ietf-pce-inter-area-as-applicability-07  - IETF stream
    Applicability of the Path Computation Element to Inter-Area and
    Inter-AS MPLS and GMPLS Traffic Engineering (Informational) - 3 of 3
    Token: Deborah Brungard

Amy: This has an unknown consensus, should this be yes?

Deborah: Yes.

Amy: There aren't any Discusses, so unless there is an objection this is
approved.

Deborah: We'll do it as point raised so the authors can respond to comments.

Benjamin: I did drop a very late position. I wanted to mention that this is an
Informational document that's an applicability statement, as opposed to an RFC
2026 applicability statement that's in the standards track. That's probably
okay with me, but I just wanted to mention that on the call so it had some
visibility.

Deborah: Yes, I saw that. I think it could go back and forth; Informational is
totally good, too. We have some well-seasoned chairs who can say why they chose
for that. I know folks are a bit wary of Informational documents, but this one
is a pretty key document because there is a lot of discussion in the industry
on connecting domains, ASes, everything with SDN control. As the document went
through a couple of scenarios, BGP LS, and then really key is the ITU work on
ASON, which you guys all are familiar with from several years ago. It's really
that work and other forums' work with this kind of architecture, it's important
for the IETF to put a stake in the sand and say this is how you can do it with
the tools we have today. It didn't get much interest in the WG, but it had a
lot of interest in--when we asked if this work was important, everyone raised
their hand, but the lack of review is because this is bread and butter to
everybody, so there wasn't much controversy at all. For something to point to,
like when folks are seeing other groups trying to reinvent the wheel on this
stuff, it's really important to have this kind of document to point to. Okay,
so we'll have the authors address the comments, and we'll do it as point raised.

Amy: So this will go into approved, announcement to be sent, point raised,
writeup needed, and you can let us know when that's ready to go.

3.1.2 Returning items
  NONE

3.2 Individual submissions via AD
3.2.1 New items
  NONE

3.2.2 Returning items
  NONE

3.3 Status changes
3.3.1 New items
  NONE

3.3.2 Returning items
  NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items
  o conflict-review-sheffer-tls-pinning-ticket-00
    IETF conflict review for draft-sheffer-tls-pinning-ticket
      draft-sheffer-tls-pinning-ticket-11
      TLS Server Identity Pinning with Tickets (ISE: Experimental)
    Token: Benjamin Kaduk

Amy: There are no Discusses, so unless there is an objection this is approved
with the note that is currently in the tracker.

Benjamin: I expect Adrian to have more changes to the document and for us to
not request the IESG note, but I think for the current document this is
appropriate.

Amy: Hearing no objection, we will send the conflict review with the current
note

3.4.2 Returning items
  NONE

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

4.1.2 Proposed for approval
  NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review
  NONE

4.2.2 Proposed for approval
  NONE

5. IAB news we can use

Ted: There is one thing to bring to the attention of the IESG, but I know there
is a bit of a minutes issue with this. The news is that although the RSOC had
recommended re-upping her contract, Heather has decided not to stand again for
RSE. SO what will currently happen is that her current contract will go through
the end of the year, and she's agreed to stay on past that point in a
consulting capacity if needed, and we will run a full RFP. This hasn't happened
in a while; she's been in the role for 7 years, so it is a bit new. The
minuting issue here is that the first announcement of this to the public will
take place in the IAB minutes with her RSE report to the IAB, where this is
noted. It would probably be better from a minuting perspective if that was the
place where we pointed the community to, rather than "IAB new we can use" here.
So I'd ask that Amy and Cindy coordinate this so that the IAB minutes are
published first, I'd appreciate it.

Amy: This would only be recorded in the narrative minutes, because we generally
don't record this section in the official minutes, but we can embargo the
narrative minutes until the IAB minutes from this are posted.

6. Management issues

6.1 Proposed IESG Telechat Dates Between IETF 105 and IETF 106
    (Secretariat)

Amy: We have two proposals. One starts with a formal on August 8, and one with
an informal on August 8 and it goes on from there. I did mark out the proposed
joint retreat week. In version 2 that would be a formal and in version 1 that
would be an informal. Of the 4-5 responses I got, only one person preferred
proposal 2, but that was for personal reasons, and everyone else either didn't
care or preferred proposal one.

Adam: Proposal 2 is also better for me for personal reasons, I'd have to miss
two formals in proposal 1, but that's just me.

Amy: Any other comments? I think we have a very slight preference for proposal
1 over proposal 2, so is there any objections to adopting proposal 1 as the
telechat schedule going forward between 105 and 106? Hearing no objection, we
will adopt proposal 1, and we will get these in the marked in the calendar and
put them in the Datatracker. So our first meeting after IETF 105 will be
Thursday, August 8 as a formal telechat.

6.2 [IANA #1142688] renewing early allocations for draft-ietf-bess-evpn-
    optimized-ir (IANA)

Amy: It looks like this doc needs an extension to the early allocations.

Michelle: That is correct. We're looking for an extension for these and
hopefully the document will make its way through eventually.

Martin: Yes, it's in my stack. Some of these allocations have had a long wait
now. I would really welcome if the IESG could approve this.

Amy: Any objection to approving an extension to the early allocation for this
document? Hearing no objection, this is approved and we can send the official
note to IANA.

6.3 Reserving dates for 2nd retreat (Alissa Cooper)

Alissa: I wanted to come to closure on this from the IESG's perspective.
Looking at the Doodle, availability is tough. There wasn't anywhere we could
all get together if we all blocked out the dates. The best we could do either
with the IESG on it's own or joint with the IAB, we'd be missing about 4
people. I wanted to get a sense if we should block out dates either on our own,
or jointly?

Barry: Given that we still have to have the discussion to have the retreat,
blocking out the dates at least enables us to have the discussion on whether to
have it or not. So I think we should block out the dates. And as I said in
email, my preference would be joint with the IAB, but either one would work.

Benjamin: I agree with Barry, and the previous discussion had indicated that
the joint retreat would be more valuable, so I think blocking out the joint
dates seems to make the most sense.

Alissa: So that means blocking out October 8-11 for a retreat in Europe. And
I'll confirm with the IAB. If they're unwilling for some reason, that doesn't
necessarily change things; I think at least some people on the IAB were okay
with blocking out the dates. Let's do that, and we can revisit after IETF 105
if we actually want to book something.

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

Amy: The conflict resolution will be next week at the informal because the
preliminary agenda comes out on the 21st. So that will have the conflict
resolution for you all and Liz

Cindy: Before everyone jumps off, if you have to make any changes to your BOF
requests in the wiki, for room size or conflicts, please make sure that those
are in by the end of the day today, because we're going to start requesting the
sessions for those.

-----------------------------------------------
* Please see the Datatracker (https://datatracker.ietf.org/doc/)
for details on documents that are under discussion by the IESG.