Narrative Minutes interim-2019-iesg-08 2019-04-11 14:00
narrative-minutes-interim-2019-iesg-08-201904111400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2019-04-11 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, 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
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kuehlewind (Ericsson) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Huawei) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alexa Morris (AMS) / IETF Secretariat
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Martin Vigoureux (Nokia) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area

REGRETS
---------------------------------
Heather Flanagan / RFC Series Editor
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

OBSERVERS
---------------------------------
Joe Hall
Jason Livingood
Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Anyone have an objection to the minutes of the March 14 telechat being
approved? Hearing no objection, so we will get those posted. Anyone have an
objection to approving the narrative minutes from March 14? Hearing no
objection, so we'll get those posted as well. With that we'll move on to our
list of outstanding tasks.

     o Alvaro Retana to send email to the IESG with proposed re-labeling of
       scheduling conflicts.

Alvaro: I think this one's done. We talked about it in Prague. However, I did
pick up at least one thing from that discussion. I guess this one we can mark
as done and I'll take care of the other one by the retreat.

     o Suresh Krishnan to discuss naming experts for the registries created
       by draft-irtf-icnrg-ccnxsemantics with Allison Mankin.

Suresh: I sent a message to Allison asking if she handed this over to Colin and
I didn't hear anything back, so I'll take it up with Colin after this meeting.

     o Ben Campbell to write up text on the IESG's expectations regarding
       conflicts of interest and the disclosure of funding sources.

Amy: Did this happen before Ben stepped down?

Alissa: This did not happen.

Barry: Why can't Ben still do this? I'll ask him and you can assign this to me.

     o Suresh Krishnan to draft a new proposed IESG Statement on the
       procedure to reference material behind a paywall, that includes the
       existing text and adds comments from the discussion, Eric Rescorla,
       and Barry Leiba.

Suresh: I just sent it before the meeting, so unless I hear something let's
consider this done.

     o Roman Danyliw and Barry Leiba to identify and catalogue common
       problematic and inappropriate behaviors from individuals in the IETF
       community both at in-person meetings and on email lists.

Barry: That was done before the IETF meeting.

Alissa: On the last two, there is some further next step, right? Should we peg
somebody with what the next step is so we continue to track it?

Barry: You can certainly leave me on; I don't know about Roman.

Roman: I think we need to talk about what the next steps are. Perhaps this
would be a good retreat topic.

Barry: Let's have some discussion before the retreat. Roman, if you and I can
prepare for that, it will be good. I'll add it to the wiki.

Alissa: Same for the paywall; Suresh, you'll let us know when we're going to
publish it?

Suresh: I'll give people a day or two to comment and then I'll let you know.

Amy: So it sounds like that action item is done but there are more followup
steps to do. We'll add that and move on.

     o Suresh Krishnan to report on the progress of the response to the
       Liaison Statement on "Request to update the IoT and SC&C Standards
       Roadmap and the list of contact points."

Suresh: I got zero response from the IoT directorate so I'd say this is OBE.
The deadline has passed.

     o Spencer Dawkins (Roman Danyliw?) to provide an update for "IETF
       Notifications of Emerging Work" to Greg Wood.

Amy: I saw some email on this but I didn't know if there was followup.

Roman: To make that happen we need a little tooling help; specifically we need
to get a list of what just got adopted in the WG. There's an ask to the tools
team and when we have it we'll figure out how to start working that data.

Amy: So the action item is done and we're waiting for tools team support.

     o Alissa to draft a revision to the Meeting Room Policy and communicate
       it to the LLC Board.

Alissa: Still working on this.

     o Ben Kaduk or Roman Danyliw to identify designated experts for RFC 5580
       [IANA #1139586].

Ben: I think I can take this one, but I haven't made any action on it yet.

     o Alissa Cooper to work on a response plan for the Liaison Statement "LS
       on RoHC utilization for Ethernet header compression"

Alissa: This was an error, so you can take it off.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-spring-segment-routing-mpls-19  - IETF stream
   Segment Routing with MPLS data plane (Proposed Standard)
   Token: Martin Vigoureux

Amy: I have a consensus flagged as Unknown, which is a little unusual for
documents in this state. Should that be the automatic yes?

Martin: Yes.

Amy: Great, we'll make sure that's a yes. There are a couple of Discusses in
the tracker. Do we need to discuss those today?

Martin: We can; though I think those shouldn't be difficult to resolve. Alvaro
and I had a chat yesterday about his points 1-4, and I think we have a way
forward. I'm waiting for the author's view, but it might simply be resolved by
removing a sentence and doing a bit of cleanup to avoid giving the impression
we're specifying behaviors. On his point 1.5, Ben you had a Discuss on that
paragraph as well, and Deborah had two, although she moved it to a comment. I
think we have a different reading of what that paragraph means, but I wonder if
rather than trying to rework it, the best option would be to simply remove it.
I don't think it's conflicting 8402 but apparently it's creating confusion and
I don't think it adds any important requirement compared to what is already
written in 8402. I'll discuss with the authors but one option might be simply
to remove that paragraph since the base paragraph in 8402 is very clear. I
think you can leave your Discuss until that is resolved of course.

Alvaro, on your point 2, I understand you would like to make a couple of
changes from a "should" into a "must" to guarantee consistency across
implementations. Am I correct?

Alvaro: Yes, pretty much. The way it's specified right now it's not guaranteed
the steps are deterministic so we might end up with who knows what.

Martin: I'll discuss with the authors on that. I'm not opposed but I don't
think it will change anything. These are requirements on configuration aspects
and we can't guarantee that even if we put a "must."

Alvaro: I understand "must" means nothing unless someone actually does it, but
if the specification doesn't even say that, then we're lost.

Martin: Okay. We'll see what the authors think. I understand your point, I
don't have a strong objection, and it's a logical change, so we'll see.  Ben, I
think you had a Discuss relating to that and I think this could also solve your
issue, although yours is a bit more specific. I'll do that quickly since we
have a lot of documents to discuss. You raise a good point on the algorithm
value; it doesn't exist in 8402. Strictly speaking it is in the IGP extensions
document, so rather than referencing 8402 we might reference the IGP extension
here. I'm not sure about your issue on the different lengths of the byte
strings. We do a check per fact type, so each fact type has the same
descriptors. If we do that we will always be checking the same type of byte
string. See what I mean?

Ben: Okay, yes.

Martin: Okay, good. So I think we have a way forward and we'll see what the
authors reply. I think everything can be easily resolved. We can leave all the
Discusses and likely a revision will be needed.

Amy: So we're going to put this in Revised ID Needed and with that we can move
on. Thanks.

 o draft-ietf-manet-dlep-pause-extension-06  - IETF stream
   DLEP Control Plane Based Pause Extension (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a number of Discusses in the tracker. Do we need to discuss any of
those today?

Alvaro: I think most of them I want the authors to engage. The only one maybe
we want to discuss here today is Alissa's. I did send an email about five
minutes before the telechat; I don't know if you saw it and if you want to talk
about it more here.

Alissa: I'm sorry, I didn't see the latest.

Alvaro: Okay. We can do it by email. We'll definitely need a revised ID for
this one.

 o draft-ietf-mmusic-data-channel-sdpneg-25  - IETF stream
   SDP-based Data Channel Negotiation (Proposed Standard)
   Token: Adam Roach

Amy: I have a couple of Discusses in the tracker. Do we need to discuss any of
those today?

Adam: I don't think so. If I read things correctly we have a solution for
Magnus's, and Roman, there hasn't been a response to yours yet, has there?

Roman: Yes, there has been, and they answered everything I needed.

Adam: Okay, so we're just waiting for a new version here and then you both can
clear. I think we're just Revised ID Needed here then. Thanks.

 o draft-ietf-pce-gmpls-pcep-extensions-14  - IETF stream
   PCEP extensions for GMPLS (Proposed Standard)
   Token: Deborah Brungard

Amy: I have a number of Discusses in the tracker. Do we need to discuss any of
those today?

Deborah: I don't think so, unless someone had something. The authors and chairs
are involved in dialogue and they're on top of stuff. Definitely a Revised ID
will be needed.

 o draft-ietf-ccamp-rsvp-te-bandwidth-availability-14  - IETF stream
   Ethernet Traffic Parameters with Availability Information (Proposed
   Standard)
   Token: Deborah Brungard

Amy: I have a number of Discusses in the tracker. Do we need to discuss any of
those today?

Deborah: I don't think so, unless someone has something. The authors have been
very involved so I think they've pretty much wrapped everything up. Definitely
a Revised ID is needed.

Magnus: I don't think I've received a response yet.

Amy: Okay, so Revised ID Needed for this.

 o draft-ietf-bess-bgp-vpls-control-flags-07  - IETF stream
   Updated processing of Control Flags for BGP VPLS (Proposed Standard)
   Token: Martin Vigoureux

Amy: I have no Discusses, but an open position for Ace. Did you want to state a
position?

Warren: No thank you, I read most of it but didn't get a chance to ballot.

Amy: Unless there's an objection now it looks like this on is approved. I'm
hearing no objection. There are no notes in the tracker; are there notes needed?

Martin: I'd like the authors to check on the comments.

Amy: This will go into Approved, Announcement to be sent, Revised ID needed.

 o draft-ietf-extra-imap-fetch-preview-03  - IETF stream
   IMAP4 Extension: Message Preview Generation (Proposed Standard)
   Token: Alexey Melnikov

Amy: I have a couple of Discusses in the tracker. Do we need to discuss any of
those today?

Alexey: I don't think this needs discussion, unless anybody wants to. We're
waiting for a new revision on this one.

 o draft-ietf-ccamp-alarm-module-08  - IETF stream
   YANG Alarm Module (Proposed Standard)
   Token: Deborah Brungard

Amy: I have a couple of discusses in the tracker. Do we need to discuss any of
those today?

Deborah: I don't think so, unless somebody wants to. I would like to say I
appreciate everyone's comments, because this document isn't really a
telecommunications document; it references 20 year old ITU standards but it's
more on factory type alarms. The authors say this is what's needed for 3GPP
support. It was done in CCAMP because they have the most expertise and got
quite a bit of review, but as all of you it's not my field of expertise. I
never heard the word "shelving" either, so I agree with all of you and thank
you for giving it some more scrutiny. The WG did our best but it's sort of left
field for all of us. If anyone has anything to say, the authors are in
dialogue. I'd say this is Revised ID Needed.

 o draft-ietf-iasa2-rfc4071bis-09  - IETF stream
   Structure of the IETF Administrative Support Activity, Version 2.0
   (Best Current Practice)
   Token: Alissa Cooper

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

Alissa: Thank you. This should go into Point Raised so we can resolve the
remaining comments.

Barry: In particular Suresh's comment on 6.5 needs clarification but that's
relatively minor.

Alissa: Yes, I think that's the last one.

 o draft-ietf-iasa2-consolidated-upd-07  - IETF stream
   Consolidated IASA 2.0 Updates of IETF Administrative Terminology
   (Best Current Practice)
   Note: RFC Editor note

   There is a typo in the title of section 4.2 (which also propagates
   to the table of contents), s/Adminstrative/Administrative/
   Token: Alissa Cooper

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

Alissa: This one is, I believe, ready to go. I put the typo into an IESG note
for the RFC editor.

Amy: This is approved. When we send the announcement I have two RFCs to go into
the downref registry. Do you want us to add those on the approval announcement?
3710 and 6702.

Alissa: Sure.

Amy: That's a new thing that's being called out for us now, adding RFCs to the
downref registry when they happen.

 o draft-ietf-dnsop-algorithm-update-09  - IETF stream
   Algorithm Implementation Requirements and Usage Guidance for DNSSEC
   (Proposed Standard)
   Token: Warren Kumari

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

Warren: I'd like the authors to take another look and make sure they've
addressed all the comments. Thanks everyone.

Adam: Both Ben and I commented on moving some references from informative to
normative, so as long as you don't disagree with that in principle I suggest
this is probably Revised ID Needed.

Warren: That shouldn't require another Last Call, so okay. Thank you. Approved,
Revised ID Needed.

 o draft-ietf-pce-stateful-pce-p2mp-12  - IETF stream
   Path Computation Element (PCE) Protocol Extensions for Stateful PCE
   usage for Point-to-Multipoint Traffic Engineering Label Switched
   Paths (Proposed Standard)
   Token: Deborah Brungard

Amy: I have a couple of Discusses in the tracker. Do we need to discuss any of
those today?

Deborah: I don't think so, the chairs and author are responding. This is
definitely a Revised ID Needed.

 o draft-ietf-netmod-module-tags-07  - IETF stream
   YANG Module Tags (Proposed Standard)
   Token: Ignas Bagdonas

Amy: I have a number of discusses in the tracker. Do we need to discuss any of
those today?

Ignas: Yes please. Adam, starting from yours about the downref, yes that was an
oversight. Now what to do with this? Either move that to informative or put it
to the downref registry. I still need to wait for the authors to respond what
they think, although I think an easier way would be to move it to informative.

Adam: I meant this more as a pro forma thing; I just wanted to make sure that
all the Ts were crossed, Is dotted, and point the IESG to it to make sure we
were okay with it. I'm fine with it where it is, as long as it appears in the
minutes that we looked at this and considered it. I saw Alissa replied on the
list something along the same lines.

Alissa: I don't think this is an oversight; it changed from -06 to -07 based on
the last call review from the Gen-ART reviewer. based on the way this document
is referenced here, it doesn't really seem necessary.

Ignas: What I meant was it was an oversight from my side that they didn't put
it into the comments.

Alissa: I think it's fine as is.

Barry: I don't think a Last Call is necessary either.

Ignas: The other thing about the technology standard, Alissa's comment; I think
that's a fair comment and the word standard probably doesn't fit. Let's wait
for the authors. Ben, about the security thing, I'll leave that for the authors
to respond. Alexey, about non-ASCII things; this was discussed some time ago. I
don't remember the details but this was coming from somebody having a wish to
have the text in their native language. I agree this probably opens more
problems than puts value into overall. Let's wait on what the authors have to
say but it's definitely a fair comment.

Alexey: I think you have to ask IANA what their tools are for checking validity
and how they're going to inspect these.

Ignas: So this definitely will be Revised ID Needed.

 o draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04  - IETF stream
   BGPsec Algorithms, Key Formats, and Signature Formats (Proposed
   Standard)
   Token: Warren Kumari

Amy: I have a couple of Discusses in the tracker. Do we need to discuss any of
those today?

Warren: For Alexey, I think we agree it should be Obsolete instead. On
patterns, that's an issue they need to fix. I think they have a way forward and
if we keep it as Revised ID needed, and after they've done that people can
clear.

 o draft-ietf-sidrops-https-tal-07  - IETF stream
   Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
   (Proposed Standard)
   Token: Warren Kumari

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

Alexey: I'd like an answer to my comments, if that's okay.

Warren: Point Raised, then.

 o draft-ietf-dmarc-eaiauth-05  - IETF stream
   E-mail Authentication for Internationalized Mail (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: I don't know, Ben, do we need to discuss?

Ben: I didn't get a chance to look at the updated revision. I had to step away
from this document. With respect to the other point, I'm willing to accept
Barry's point that this is sufficiently well specified for the people who are
implementing it, so I suspect I'll drop my second discuss point when I
re-ballot.

Barry: [The author] is right that the implementation is vanishingly small but
nevertheless, it is part of the protocol and I think it needs to be
appropriately specified. I think you should hold on to that one.

Benjamin: I'm definitely going to hold on to that one, but the second part I'll
yield to the arguments you presented.

Barry: I'd really like you to push back on [the] attitude that it's okay to
leave something unspecified if nobody cares. Either it needs to be formally
deprecated or properly specified.

Alexey: Or even explaining that it's not allowed because it's not used. A
sentence or two would be helpful.

Barry: That's properly specified. Whatever the right answer is, it's not just
to ignore it.

Alexey: So I think Revised ID Needed for this one.

2.1.2 Returning itemsd

 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-clue-datachannel-15  - IETF stream
   CLUE Protocol data channel (Experimental)
   Token: Adam Roach

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

Adam: Yes, it's Revised ID needed. Thank you.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-hollenbeck-vcarddav-icann-rdap-extensions-00  - IETF stream
   vCard Format Extensions: Internet Corporation for Assigned Names
   and Numbers (ICANN) Extensions for the Registration Data Access
   Protocol (RDAP) (Informational)
   Token: Alexey Melnikov

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

Alexey: Can I have this in Point Raised? I just want to double check the
comments.

Ben: I sent one very late about addresses in the examples.

Alexey: Yes, I thought that was a very good point.

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-irtf-cfrg-re-keying-00
   IETF conflict review for draft-irtf-cfrg-re-keying
     draft-irtf-cfrg-re-keying-15
     Re-keying Mechanisms for Symmetric Keys (IRTF: Informational)
   Token: Benjamin Kaduk

Amy: I have no discusses in the tracker, so unless there's an objection it
looks like this conflict review message can go back to the IRSG. Hearing no
objection, so the note is okay and we'll get that sent to the IRSG.

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 o Relay User Machine (rum)

Amy: I have no blocking comments for the review, so it looks like unless
there's an objection, RUM is ready to become a new WG.

Adam: I believe that is correct. Send the white smoke up the chimney.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o JSON Mail Access Protocol (jmap)

Amy: We have no blocking comments, but I also don't have a good idea of whether
this is going to require external review. It sounds like maybe it does; is that
true?

Alexey: I think so. The scope is being extended a little bit to take on
calendaring stuff so I think external review is fine.

Amy: Okay. I've got no blocking comments for external review so if there are no
objections we can get that sent out.

Ben: I'm happy to have this go to external review; just noting that I sent a
late comment about potentially needing to talk about security properties for
the new transports.

Alexey: Okay; that would be a great point to review before final approval.

Ben: Exactly. I'm happy to do that during external review.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Mirja: They are organizing a workshop on comparing deployment expectations vs
deployment realities and that will take place on June 4 and 5 in Finland. The
call for that workshop will go out yesterday or today, so if you're interested
in that, watch out.

6. Management issues

6.1 [IANA #1139586] Designated experts for RFC 5580 (IANA)

Amy: We talked about this at the top of the call; Ben is going to take the
token to identify experts.

6.2 Living Documents (Alissa Cooper)

Alissa: I added this because we ran out of time for it at IETF 104. I thought
we should come back to it if we have more to discuss.

Warren: I'd kind of completely forgotten this was on the agenda for today. I
thought it was for the retreat. I just emailed out updated slides in PDF form;
the main thing that's different is at the end I added a preview of what things
might look like. I also clarified somewhere that this can point at either
internet-drafts or RFCs or anything else an AD thinks is worth having an easily
findable, stable reference to. I also sent out email before IETF 104 with a
rough writeup of what I think these are. If people could have a look and reply
to that, just to make sure that it's largely sane, I'll massage the text into
something that looks more reasonable for the IETF as a whole to look at. That's
the general plan and I'd like to get feedback on what people think of the
general idea, and/or anything else.

Mirja: I got an empty email from you, at least in my inbox. I do think we need
more discussion here. I can see everything between adding some kind of support
in the datatracker, to let chairs mark a document as having WG consensus, to
doing something more official where we actually write down an experiment in an
RFC and figure out all the details. I'm not sure what we're targeting; I think
there are a lot of open questions.

Suresh: Move versions of the documents that are considered stable.

Warren: Instead of trying to figure out all the answers, this would be
interesting to launch as an experiment, and as we learn stuff we can figure out
adding stuff to the datatracker and making it more formal.

Mirja: What does 'launch an experiment' mean to you? Just send an email that we
should do this from now on?

Warren: Well, I'd take my original outline text and write it up in more words,
getting more feedback from the IESG, instead of trying to fully build out the
process, do it more iteratively. Maybe this is a better topic for the retreat.

Barry: Do you want to do it as a formal experiment?

Mirja: Which means writing it as an RFC, right?

Barry: That's right.

Warren: No, I wasn't thinking a formal experiment. I was thinking a webpage we
can put some links on.

Mirja: I don't think that's a super great idea if we're talking about something
that is an indication of WG or IETF consensus where you have a formal
component. The other thing I really worry about is getting people outside the
IETF even more confused about what we want people to read and not read and
what's a standard and not a standard, and so on.

Alissa: I think the tricky part here is balancing the motivation Warren talked
about of wanting to iterate with the fact that there's going to have to be
different marking or naming of these documents, or they need to live in a
slightly different place, or something to distinguish them from what we already
have, which is drafts and RFCs. There's some small amount of support or tooling
or something that's required even just to do an experiment. I'm definitely with
Warren that I'd like this to be minimal overhead to get it going, but I do
think it has to be distinguishable from what we already have.

Barry: To clarify what I'd said, look at RFC 3933, which is how IETF process
experiments work. It doesn't require an RFC, it requires an internet-draft.
Read that document to see if that's what you want to do or if you want to go in
a different direction.

Warren: Okay; I don't know what my next steps are, besides reading that
document and seeing if we can discuss this more at the retreat. Maybe Mirja and
I can sit down before the retreat properly starts and get a better
understanding of where we each come from.

Mirja: That would be great. Providing chairs a tool to mark something WG
Consensus, for example, is something we can easily do and might already help in
a lot of cases. Maybe I need to understand the goals a bit better.

Alissa: Warren, can you re-circulate the slides not in Keynote format?

Warren: Yes. Adam's PDF version is the older one.

Alissa: I mentioned this in passing in the GIT working group and I have a bunch
of people who are chomping at the bit to have this and want to use it in
various ways, so I might share your description with them to get their feedback.

Warren: That would be great, especially if we can understand what people want
to use this for, that can help Mirja and I understand the intended use case. I
had thought a very informal thing to make it easier to find something, with
description on what each one does, to make it easier for readers to understand
the purpose. Much more informal than what Mirja's thinking.

Mirja: I think that's also a good point. People have heard of this and they
want their document to be a living document, but probably for different reasons
than you want yours to be a living document, so getting some of these example
cases and understanding really what people want is a good thing to do.

Alissa: I sent a couple of examples in the thread during IETF 104 but there are
more too.

Warren: There are some in the slide deck too.

Alissa: Warren, can you add it as as topic on the retreat page?

Warren: Yes.

6.4 IESG Approval of the MCPTT Off-Network Protocol (MONP) port request
(3gpp-monp) for UDP [IANA #1127933] (Mirja Kuehlewind)

Mirja: This is the thing we've been discussing for a while. Originally the 3GPP
sent multiple requests for different ports and we had some longer discussion
about the general pattern. We already approved one port for an internal control
interface at the end of last year. This request took longer because went back
to the experts and requested another review, because they only looked into one
specific aspect; this is a port coming from 3gpp that is not used on an
internet wide scale. But based on the discussion we had in the IESG, we'd still
like to allocate them a port in order to make sure there is interoperability.
There were a couple of different parts that the review brought up about
versioning, security, and congestion control. The experts are still concerned
about the scope. I'm bringing this back to the IESG to have approval of this
port. Any concerns? [Hearing none] Then I think we can tell them to assign the
port.

6.3 IESG Retreat Agenda (Alissa Cooper)

The IESG discussed agenda planning for the retreat and the list of topics has
been updated on the wiki.

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

Ted: The IAB workshop on design expectations and deployment realities, aka
DEDR, has not been scheduled for June 4 and 5 in Helsinki. We hope to send the
call for papers out at the end of the week.