Skip to main content

Narrative Minutes interim-2019-iesg-11 2019-05-30 14:00

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

Narrative minutes for the 2019-05-30 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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 (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Amy Vezza (AMS) / IETF Secretariat
Magnus Westerlund (Ericsson) / Transport Area

Ignas Bagdonas (Equinix) /  Operations and Management Area
Heather Flanagan / RFC Series Editor
Alexey Melnikov / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

Adrian Farrel
Greg Wood

1.2 Bash the agenda

Amy:  Does anyone want to add anything new to the agenda? I did get a late
management item from Roman that made it on.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the May 16 teleconference
being approved? Hearing no objection, so those are approved. Does anyone have
an objection to the narrative minutes of May 16 being approved? Hearing no
objection there.

1.4 List of remaining action items from last telechat

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

Suresh: Colin just got back to me and told me all the context has been lost in
the transition of the IRTF chair, so I forwarded him all the communications I
had with Allison and he promised to discuss further with the IRSG but I don't
think it will happen any time soon. I would close this [action item] and when
he gets back to me I'll put in a new item to say what he says.

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

Barry: You can call that done; we're waiting on the LLC to do its version and
then we'll coordinate with them. We can open up another action item if we need
after that.

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

Amy: Ignas could not join us today so we'll mark 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's still in progress; I've gotten various feedback from the IESG and
I need to consolidate all the feedback to bring that back as a proposal for us
to figure out what to do, since we have different opinions. Please do keep that
on the list.

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

Roman: That's also still in progress.

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

Suresh: That's in progress.

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

Warren: Ted's been doing all of the work.

Ted: There has been a document written but the discussion of whether it's the
right document or not is still in progress. I guess the question is: how do we
come to a conclusion on whether we want to go forward on this theory or revert
to either the datatracker or other theory?

Alissa: A feeling I have about this is people asked for a way to have something
like a living document which has actual content, and that is stable but updated
with some frequency that's different from all of the other outlets we have now.
This is an interesting thing, but it's not that thing. I feel like if we go
forward with this then a lot of people who are waiting for the other thing will
say, this isn't what we asked for. I realize it's more complicated than that
but that's my feeling at the moment. I'm not sure what to do about that.

Ted: There's more than one kind of living document and this is definitely only
one of the kinds we might produce. For the implementation targets, what this in
effect does is allow you to use the Internet-Drafts, which are now
semipermanent publications, or at least continually accessible publications, in
a document that describes how they fit in to some particular technology. I
think it's the combination of this as a frame and the Internet-Drafts which
gets you to the other kind of living document. If what people actually wanted
was not a framing mechanism that combined with the Internet-Drafts to give you
that, then this is definitely not the right approach and we'd have to start
over. That question gets us back into, how is this not a replacement for the
RFCS?  This approach is something that augments the current mechanism we have,
the Internet-Drafts and RFC series, but doesn't supplant any of them. If we
want to go back into a brainstorming session about what the requirements the
community is expecting are, I'm happy to do that. I still think either adopting
the datatracker mechanism Mirja pointed to or some flavor of what http and quic
were doing would still be valuable, because there are a bunch of people who
come into the Hackathon or some other implementation event wanting to tackle a
particular piece of technology but finding the state of play distributed over a
lot of mailing list discussions that's very hard to boil down. Maybe that's not
valuable enough for everyone to spend time on but I do think it's worth at
least asking the community whether we ought to systematize in one of the three
ways that's out there right now.

Warren: Yes I agree it is worth doing, but I don't think this is what the
community had been expecting or thinking of as living documents. I think maybe
we built something new as well, which is worth pursuing, but it doesn't really
solve the use case the community had been asking for. I realize I should have
been doing more to push it along.

Mirja: That's the whole problem, is that we're talking about at least three
different use cases, and the solution for those use cases might be different.
For example the implementation draft, I think putting it on GitHub is exactly
the right thing because that's where the implementers will look for it. The
only thing that might be missing is a quick link from the datatracker to the
GitHub. What you have in mind is another use case and I think Ted has another
use case there.

Ted: It sounds like we probably need to have the use case discussion once more
time before we go forward with this. Can I suggest we make that an agenda item
for an informal, not next week but the one after that, and we'll go through
those and revisit? I think this did do what the action item says, except for
the "aka living documents." I don't think this is all living document use cases
met, it meets a subset of that of a particular type. We probably need to work
out as Mirja says what use cases are still in play and what we want to do there.

Alissa: That sounds good. If you're willing to write up the use cases and maybe
some requirements that derive from them so we can try to assess how many
versions of this would be required to meet the various requirements, that would
be useful to structure the discussion.

Ted: I'll do what I can.

Alissa: You don't have to. That's an action somebody can take.

Ted: I'm willing to do it, because it's not going to come due for a couple
weeks. In that couple of weeks I should be able to get through the pile of
other stuff and get to this, although it may be a bit sketchy. I can at least
try something.

Alissa: Okay, thanks.

     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.

Barry: I haven't done anything with that. I presume you haven't either, Roman?

Roman: I believe we are in progress.

Barry: We are in very slow progress. We will do something in the next couple of

Roman: Yes. Certainly no earlier than next week though.

     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.

Amy: Martin is not with us today so we'll keep this 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.

Roman: SEC has not yet closed this.

Warren: We do have a bunch of wiki pages to point to, we just need to get them
organized in a format that's more useful.

Alissa: More generally, should we capture these on the IESG wiki as opposed to
email? Should we try to coalesce them in one place?

Warren: Probably.

Roman: I would have suggested the first starting point would have been each
area puts this set of recommendations on their respective wiki, we can make a
list of references, and figure out what to do from there given what the content
looks like.

Mirja: The wiki page I've been sending around is our wiki page for our review
team to which topics they should look for, which is kind of what you're asking

Alissa: So maybe once the SEC one comes in we can make sure there's a spot on
the IESG wiki that points to all of these things.

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

Amy: Eric could not be here today, so we'll keep that in progress for him.

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

Suresh: This is still in progress; I'm waiting to hear back from a few more

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

Amy: Eric could not be here today, so we'll keep that in progress for him.

     o Roman Danyliw to shepherd the analytics discussion
       with the community.

Roman: I am out in the field shepherding this along. We have a post out to
ietf-discuss with a closing of mid next week and we've been collecting
feedback. Unfortunately the snag we've hit now is that due to the latest server
configuration we've temporarily lost the pointer to the PDF describing the
proposal. We have the PDF in a link in an attachment so folks can still read it
and we hope to have that resolved as soon as possible. So please leave it up
but it's in flight and we won't have resolution likely until mid next week.

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

Warren: Not going brilliantly. I'm unclear. I had thought, but I guess I was
incorrect, that Magnus and Mirja and Spencer were running with it, but it looks
as though possibly I was misinformed. It's useful we have these action items to
remind us, and is there any progress on that?

Mirja: I did discuss with Magnus a little. We kind of agreed that we don't see
a transport topic coming up right now. Either we need more brainstorming, but
I'm a little reluctant to involve more and more people without having a clear
holder. Or we should cancel the Transport topic and figure out if we have a
different topic for the next meeting.

Warren: I had thought we'd decided that how the network interacts with
transport was the topic. I thought we thought that was a good topic whether we
called it a BoF or a deep dive or spaghetti with marinara sauce that it was
still something useful for the community. But maybe that's changed.

Magnus: I think the problem is to pull this together in a form that makes
sense, and interacts and doesn't create more havoc than it needs to. I don't
see a clear path.

Mirja: Also in the past MTU discovery, this is an active discussion in INT area
as well as TEAS WG, so having a separate session at this point in time is not

Warren: I suspect it's too late to organize a new deep dive for this meeting,
so maybe we'll try it in Singapore.

Mirja: The other topic I was proposing, and I would probably have some people
in mind to ask, is how does a NIC work. But that seemed to be less interesting
for everybody else on the call.

Warren: I think that does seem interesting, especially if it includes stuff
like the offloading, etc.

Mirja: I would call some people in the UNIX community and figure out what the
innovations are in the space for them right now.

Warren: Should we take this offline and see if we can get it organized? If so,
who wants to be part of that?

Mirja: The two of us can talk a little bit and I can tell you the two or three
people I have in mind and then I can contact them if you think that's a good

Warren: Does anyone think that would be harmful to have that discussion? Deep
dive, BoF, whatever we call it?

Mirja: Ted, I don't remember if the IAB was planning to have technical plenary
or not at the next meeting. Can you remind me?

Ted: Yes, in fact you were going to talk today about the fact we were going to
ask to have the technical plenary as a separate session in front of the
administrative plenary, remember all that?

Mirja: Yes. But, there will be a technical plenary this time, right?

Ted: Yes.

Mirja: So the other question for the deep dive is when would we actually have

Warren: I thought the plan was that since we're starting later, we'd have it in
the morning before sessions.

Mirja: Okay, just wanted to make sure. Let's take it offline.

     o Suresh Krishnan to update the text for material behind a paywall
       to update the reference to section 7.1; update the document shepherd
       writeup; and draft text for a possible IESG statement to circulate
       with the WG Chairs.

Suresh: I sent this text out two weeks ago and got three +1s from Alissa,
Mirja, and Warren. Unless I hear something by let's say next Wednesday, I'll
ship this off to the WG chairs list to see what people think about it. As we
talked about before, it's supposed to be an IESG statement. So if you have any
comments, please send them by next Wednesday. I'll call this done.

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

Suresh: Alexey and Warren are kind of out of commission so I picked it up. One
thing that came up is that the authors want to go for a virtual BoF, so we have
to figure out how to do that. I raised issues and I don't have satisfactory
answers for them. I also summarized some of the issues that came up in the IETF
discussion. I don't think they've been answered and I think we probably have to
spend a little time making sure we track the issues that came up and how they
were addressed. Some people say "that's not going to be an issue" but without
any basis, so I think we need to spend more time on it. This is in progress.

Alissa: Specifically on the virtual BoF proposal, that needs to be dealt with
one way or the other. Most of the items that would typically be included in a
BoF proposal were not included. I think it would help to do some off list
engagement with the authors to get that going.

Suresh: Sounds good. I'll get to it.

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

Amy: Alexey could not be here today, so we'll keep that in progress for him.

     o Alissa to report back on the discussion about the Meeting Room
       Policy at LLC Board retreat.

Alissa: This is done. Eventually there will be a firm policy but this action
item is done.

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

Amy: Alvaro could not be here so we'll mark this 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.

Alissa: I believe we're waiting on Ben to fill out the Doodle.

Ben: I'm signing for my house purchase later today and expect to do the Doodle
after that.

Alissa: I think there's something emerging from this Doodle but I wanted to
wait for Ben's availability. Once that's done I'll send email about it. You can
keep this in progress.

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

Amy: Alexey could not be here today, so we'll mark that in progress for him.

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

Amy: Adam could not be here today, so we'll mark that in progress for him.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-pim-igmp-mld-yang-13  - IETF stream
   A YANG Data Model for Internet Group Management Protocol (IGMP) and
   Multicast Listener Discovery (MLD) (Proposed Standard)
   Token: Alvaro Retana

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

Ben: Not objecting per se, just the coverage of the explicit tracking topic
Mirja had brought up and I'd briefly made a discuss point; I guess we should
probably finish that in email but I'm not entirely sure their proposed text
covers the full breadth of the potential considerations. I'm happy to do that
in email, just mentioning we probably don't want to just approve this as is.

Amy: Alvaro did say he did want this to go into Point Raised. We'll have Alvaro
take the next steps to fix what needs to be fixed. With that we'll move on.

 o draft-ietf-roll-useofrplinfo-29  - IETF stream
   Using RPL Option Type, Routing Header for Source Routes and
   IPv6-in-IPv6 encapsulation in the RPL Data Plane (Proposed Standard)
   Token: Alvaro Retana

Amy: I have no Discusses in the tracker, so unless there's an objection now it
looks like this one is approved. Alvaro did request this go into Revised ID

Suresh: There was a late review. Alvaro had requested an IoT-DIR review and it
came in late, yesterday evening. I think Revised ID Needed would be the best
place to go for this.

 o draft-ietf-acme-caa-07  - IETF stream
   CAA Record Extensions for Account URI and ACME Method Binding
   (Proposed Standard)
   Token: Roman Danyliw

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

Roman: No, I'd like the discussion to continue on the list.

Amy: Okay. Is this going to be Revised ID Needed?

Roman: Yes, definitely.

 o draft-ietf-calext-eventpub-extensions-13  - IETF stream
   Event Publishing Extensions to iCalendar (Proposed Standard)
   Token: Alexey Melnikov

Amy: There are a number of Discusses but unfortunately Alexey could not be here
today. It looks like this is going to continue on in email unless someone has
something to discuss right now.

Barry: No, this will continue in email. This is going to have to be a Revised
ID Needed, I'm sure, given the changes that are being requested.

 o draft-ietf-lamps-rfc6844bis-06  - IETF stream
   DNS Certification Authority Authorization (CAA) Resource Record
   (Proposed Standard)
   Token: Roman Danyliw

Amy: I have no Discusses in the tracker, and one open position for Ace.

Warren: I'm a No Objection.

Amy: Then it looks like this one is approved if there are no objections now.

Michelle: We still have some open IANA questions that we're not getting
responses on. It would be great to get those resolved before it gets approved.
I can send you an email in the next hour and notify you exactly what they are
and what we're waiting on.

Roman: That would be helpful, thank you. Regardless, this will need a Revised
ID; some of the comments are very helpful and I'd like to see them incorporated
into the text.

 o draft-ietf-mmusic-rfc4566bis-35  - IETF stream
   SDP: Session Description Protocol (Proposed Standard)
   Token: Adam Roach

Amy: I have a number of Discusses in the tracker, but Adam isn't here. Does
anyone have an idea if this will need a revised ID?

Barry: It definitely will; there's at least an ABNF change that's going to have
to be made.

Amy: Then we'll leave this in IESG Evaluation with Revised ID Needed.

 o draft-ietf-tsvwg-tinymt32-03  - IETF stream
   TinyMT32 Pseudo Random Number Generator (PRNG) (Proposed Standard)
   Token: Magnus Westerlund

Amy: There are a couple of Discusses; do we need to discuss any of those today?

Magnus: No I don't think so; Revised ID needed.

2.1.2 Returning items

 o draft-ietf-tsvwg-rlc-fec-scheme-14  - IETF stream
   Sliding Window Random Linear Code (RLC) Forward Erasure Correction
   (FEC) Schemes for FECFRAME (Proposed Standard)
   Token: Magnus Westerlund

Amy: We have a Discuss; do we need to discuss that today?

Magnus: No I don't think so, I think it's fairly straightforward. Revised ID

2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-lamps-hash-of-root-key-cert-extn-05  - IETF stream
   Hash Of Root Key Certificate Extension (Informational)
   Token: Roman Danyliw

Amy: We have a Discuss; do we need to discuss that today?

Roman: No, Revised ID is right here.

 o draft-ietf-sipbrandy-osrtp-09  - IETF stream
   An Opportunistic Approach for Secure Real-time Transport Protocol
   (OSRTP) (Informational)
   Token: Alexey Melnikov

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

Barry: Make this Point Raised, please. While I'm here, both of these documents
(lamps and sipbrandy) are ones that were Informational and we wondered why, and
the shepherd writeup didn't tell us. Can we all please talk to our chairs and
remind them about the part of the document status question that says "why is
this the correct status?" Most of the shepherds don't seem to be answering that
part. I understand that if it's Proposed Standard it's obvious that this is a
standard it seems silly to say, but the question is there if it's not obvious
land they need to pay attention.

Ben: That's a good point Barry. I guess for this OSRTP document in particular
there's some longer history that goes back at least to when I was preparing to
join the IESG that to me does make informational the correct status.

Barry: I didn't want to discuss that particularly on the call, just that if
that sort of information is in the writeup, then we don't have to wonder.
That's all.

Amy: This will go into Point Raised, Writeup Needed and Alexey can take it from

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-kanugovi-intarea-mams-framework-00
   IETF conflict review for draft-kanugovi-intarea-mams-framework
     Multiple Access Management Services (ISE: Informational)
   Token: Suresh Krishnan

Amy: There are no Discuss positions, so unless there's an objection it looks
like this conflict review message can go back to the ISE.

Suresh: There's one point Ben brought up that I'll send off in a note to Adrian
off list -- a curious use of the word "other IETF technology" could imply this
is an IETF technology. I'll send the note to Adrian but otherwise sounds good
to approve. Thanks.

Ben: Adrian did reply that he acknowledged those comments; I don't remember if
that was to just me or to all of us.

Suresh: I didn't see that.

Barry: In any case Adrian does see the messages in the datatracker.

Amy: It looks like this no problem message is clear to go back to the ISE with
the note that's currently in the tracker. We'll do that on Monday as normal.

 o conflict-review-jenkins-cnsa-cmc-profile-00
   IETF conflict review for draft-jenkins-cnsa-cmc-profile
     Commercial National Security Algorithm (CNSA) Suite Profile of
   Certificate Management over CMS (ISE: Informational)
   Token: Benjamin Kaduk

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

Ben: I'm a little uncomfortable with that; the actual ballot has only existed
for about a day, so I'm tempted to push this back another week and give people
an actual chance to look at it.

Barry: You could put it in Point Raised and hold it until Ben thinks there's a
critical mass, right?

Amy: It can be approved and it can wait for you.

Ben: Okay, let's do that then.

Amy: This will go into Approved, Announcement to be Sent, Writeup Needed.
You'll just need to send us a ticket when the number of people you're
comfortable with have reviewed this.

3.4.2 Returning items

 o conflict-review-nottingham-safe-hint-01
   IETF conflict review for draft-nottingham-safe-hint
     The "safe" HTTP Preference (ISE: Informational)
   Token: Barry Leiba

Amy: I have a Discuss for this.

Barry: Yes. I really don't know where to go with this; Mirja, thank you for
writing up the short text you did. I appreciate that. What it tells me is that
I think I'm not going to convince you that we don't need an IESG note, and
you're not going to convince me that we do. So I don't know where to go from
here. It seems a little funny to have an IESG note that simply repeats what's
going to be in the documents anyway. Maybe try another pass at why you think an
IESG note is so important when we are putting that text in the document?

Mirja: We had this discussion last time, that none of the options we have for
the conflict review fit quite perfectly well.

Barry: I don't agree with that; I think the one we're using does fit perfectly
well. That's the core of our disagreement.

Mirja: The difference for me is that an IESG note is something that is
explicitly stated by the IESG. So instead of just saying, no we don't see any
conflict, we say "yes, this can be published as no conflict, but we also have
concerns because it was previously in the IETF process and it was rejected
there." That's an explicit note that the IESG has an opinion on this. If you
just put that text in the document it doesn't say anything about what the
feedback from the IESG was.

Barry: Then we need to make sure we have consensus in the IESG on that. I
certainly disagree with you, and I think Alissa has weighed in that she agrees
with you. Do any other ADs want to comment?

Mirja: Can I first ask why do you think an IESG note is a problem? I don't
think it's a problem, it's just reflecting what we have discussed.

Barry: Calling it a "problem" is a little strong. I know Adrian has said to me
he thinks an IESG note should be used as a last resort, and I agree with that.

Mirja: I very much disagree with that.

Barry: That's our basic disagreement.

Suresh: I agree with Mirja on this and Barry, I think we do have precedent. I
agree with you that part of the text can be gone, where it says it doesn't have
IETF consensus. The other part is that it was considered in IETF and rejected.
We have precedent for this in 7974 where we had text that got added to the
document and talks about why it didn't get through. Consider me on Mirja's side
on this one, but I think the text could use some work.

Barry: I think the text Mirja wrote, if we're going to do an IESG note, is
fine. I understand there's a precedent for saying this. My point here is that
it's going to be said in the body of the document itself. That's why I don't
think we need an IESG note. Other comments? There's where the problem is, we
don't have enough ADs who really care about it to decide what to do. Let me go
a different way. Does anyone agree with me that having it in the document body
is sufficient and we don't need an IESG note? Okay, guess that settles it and
we'll put in the note. Mirja, I'll use the text you proposed unless anyone
objects to that.

Mirja: Let's ask that question: Does anyone object to putting an IESG note in?

Ben: I have mixed feelings. In some cases having the content in the body of the
document that this was considered and explicitly rejected for these reasons,
that can be enough. If we do put an IESG note in we do want to be careful about
the specific wording and make sure there's IESG consensus on it. I'd propose we
do another round of this with specific proposed text for the note.

Alissa: I was going to suggest the same. I might even change my ballot position
if that's the route we're going down. If we can wordsmith the IESG note that
would be useful.

Barry: I'll put Mirja's proposed text into the conflict review document and
let's discuss among the IESG by email. Let's try to resolve that in a couple of

Mirja: Is there a way to reset all the ballot positions? Because it's
completely different now.

Barry: That's not a bad idea. I'll do that and we'll go from there. Amy, do I
need your help on that or can I do it myself?

Amy: I'm not exactly sure; I think we might need to do that for you. We'll
experiment after the call and let you know what needs to be done.

Barry: Excellent. I'll be in touch after the call. Does anyone else want to
comment on this or are we done now? Okay, thanks everyone.

Amy: Okay, so this sounds like it's going in AD Followup for now.

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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Mirja: A couple of things to report from the IAB retreat. One I briefly
mentioned already was the future of the technical plenary. One outcome is that
it's probably useful to split out the technical and administrative plenaries in
the agenda, so there's a well defined start time for those who just want to
come to the technical plenary. The proposal is to split off the technical
plenary for the first hour and mark it that way in the agenda; the first hour
will be tech plenary and afterward the administrative plenary. I don't have the
exact items in my mind but it's basically switching the order of things in the
plenary. And if there will not be a technical plenary there will be one hour
extra for side meetings or even the deep dive. Any feedback on that?

Warren: The technical plenary often generates interest & excitement. Of course,
the other plenary does as well. But if at the end of 55 minutes there's a line
of 27 people at the microphone ranting about a particular topic, are we really
going to tell them to go away? Note that I'm perfectly fine with that.

Suresh: We can tell them to come back at the open mic.

Mirja: The plan is to actually keep to the hour.

Alissa: We've done that in the past even with the technical plenary in the
middle of the slot.

Mirja: I will provide this feedback to the IAB. The second thing is a
discussion they had about the document draft-iab-protocol-maintenance-03. It's
about how we're not doing a good job of protocol maintenance. We have this
practice, for example, of leaving mailing lists open even when we close the
group. This doesn't really trigger what we want because people don't know there
is still a list. It's not easy for people on the outside to find the right
mailing list and ask about maintenance. I wanted to bring this back because
that's maybe something for the IESG to consider too. Maybe we could have
something like "inactive" instead of closed. If people are interested I'll
bring it back to the informal at some point. Or actually, Ted, is there a plan
to have further discussion on that in the IAB?

Ted: We're still talking about whether or not to adopt the draft. Jari had some
additional feedback on it. I think probably we'll end up adopting it but not in
its current version. It would be great if the IESG read the current version and
gave feedback to the IAB about how useful or not useful it is. Once we get into
the question of what specific steps does the IESG want to take in response to
it, then we can have that in a joint meeting in Montreal or just a joint email

Mirja: Another thing is that the IAB also reviewed their current tasks and one
is providing shepherds to BFs. There was a little bit of a discussion with two
outcomes: one is that the IAB is still happy to do that and they are also
welcome to be asked much earlier than the BoF call, which should be more
useful. If you have an activity and you have need for an IAB shepherd, they are
happy to be involved early on. The second part is that the IAB plans to
outreach to the community that there is this opportunity to ask for a shepherd.
Finally, the IAB also adopted a practice of announcing adoption discussions of
documents on the architecture-discuss list. In the future, starting from now on
basically, when the IAB plans to adopt a draft on a call they will discuss it
on the architecture-discuss list. I think that's it.

Ben: On the BoF shepherds topic, is it expected requests will still come from
the IESG, or will they come from BoF proponents directly?

Mirja: I believe there's also an opportunity for BoF proponents to ask but I'm
not sure how this will be implemented.

6. Management issues

6.1 [IANA #1143383] Management Item: Acceptance of media type registration from
standards organization National Center for Geospatial Intelligence Standards

Michelle: We're looking to see if we can add this to the list of standard
organizations that can get standards tree media types. Any objections?

Barry: It seems like a reasonable thing to me.

Ted: It seems like this was going to be an unusual request, so I'd process this
request but not add them to the list. I don't know if that's possible.

Barry: It's possible. Why would you object to adding them to the list? You're
probably right they are not going to request more media types.

Ted: Just because the center itself doesn't seem to be an SDO; it's a national
standards body that does a very limited amount of things. It's not one that
we'd for example consider liaising with. I have no objection to this
registration, but I wouldn't make it a general approval.

Barry: The point of the list is not to only have SDOs, but organizations we
think are suitable for making these requests in the standards tree. I'm okay
with making this a one off registration.

Ted: Did they request specifically to be added to the list?

Barry: This is an automatic thing; when someone requests a standards tree
registration, we consider whether they're suitable for being added to the list.

Ted: Thanks for that.

Barry: Michelle I guess the answer is, process this registration, put them in
the standards tree, but do not add them to the list.

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

Barry: Back to the conflict review on safe-hint -- the ballot is cleared and
the text is updated, so everybody please re-ballot on that. Thanks.